Csci 582 Case Studies reza@aero.und.edu. Objectives : 1 discuss different architectural styles...

Csci 582Csci 582Case Studies

reza@aero.und.edu

Objectives : 1Objectives : 1

• discuss different architectural styles (solutions) to the same problem– Comparative analysis of solutions (pros and cons)

• Cases:– Key Word In Context (KWIC)– Mobile robotic– Signal Processing Systems– Compiler Designs– Cruise Control systems– …

Objectives: 2Objectives: 2– KWIC problem

• Main Program/subroutine• Abstract data type architectural styles• Implicit innovation solution• P/F solution

– Mobile robotic system solution• Control architecture• Layered architecture• Implicit invocation• Blackboard architecture

Key Word In Context (KWIC):1Key Word In Context (KWIC):1

• Used to contrast different criteria for decomposing a system into modules [Par72]

• KWIC1.The system accepts an ordered set of lines;2.Each line is an ordered set of words;3.Each word is an ordered set of char;4.Lines can be “circularly shifted” by removing the

first word and appending it at the end of the line;5.System outputs a listing of all circular shifts of all

lines in alphabetical order

Example of KWICExample of KWIC

KWIC:2KWIC:2

• Used by D. Parnas to compare different module decomposition of a system

– Criteria used to decompose the system was based on Flowcharts and information hiding

• Used mainly to show the effect of change w.r.t. Data and Algorithms

• Extended by Garlan for– Functional Enhancement to eliminate circular shift

starts with noise words (a, an)– Performance (time/space)– Reuse

KWIC: Overall Design ConsiderationsKWIC: Overall Design Considerations

• Main Design Considerations:– Maintainability:

• Ability to withstand design changes (algorithms , Data, and extensibility)

– Performance: • Space and time.

– Reuse: • How reusable are the entities?

Shared Data Solution: Pros and consShared Data Solution: Pros and cons

• Good– Provide a good support for data sharing– Performance

• Bad– Ability to handle change

• A change in the data storage format affect almost all of the modules

• Changes in processing algorithms/enhancement cannot be done easily

– Decomposition does not allow reuse

Pros and consPros and cons

• Good– Algorithms and data representation can be changed in

each module without effecting others– Strong support for reuse

• Bad– Not good for enhancement

• To add new features, the existing modules must be modified or add new module(compromises simplicity)

– May effect performance [GKN92]

Pros and consPros and cons

• GOOD– Functional/feature enhancement (good)

• Additional modules can be added by registering them via change-of-data

– Reuse (good)– Separation of concerns (Data representation from

computation)• Bad

– Difficult to control the processing order (bad)– Reasoning about correctness (bad)– Cost : Data Driven requires more space (bad)

Pros and consPros and cons

• Good– Simplicity– Reuse– Change/enhancement

• Bad– Difficult to use it for Interactive system– space (filters need to copy all data to output

ports)

Development of software product Development of software product lines: Design of Oscilloscope lines: Design of Oscilloscope

productsproducts• An Oscilloscope is an instrumentation system that– Samples electrical signals– Display pictures (known as traces) on the screen– Perform some kind of measurements on the signals

also display them on the screen– have a complex software to perform dozens of

measurements with internal storage, various interfaces (NTW, HW, etc), and complex GUI and visualization system.

Development of a reusable system architecture for Oscilloscope:

Design ConsiderationsDesign Considerations

• Main Design Considerations– Reusability (reusable system architecture)

• Design domain specific software architecture that formed the core of the next generation of Tektronix (product Family and marketability)

– Performance (must be quickly reconfigured)– Usability– Modifiability (HW change and new requirements)

OOD used to clarify data types used in Oscilloscopes: Wavefroms, signals, measurements, trigger modes, etc.OOD was unsuitable to model the overall system design and task partitioning (e.g., which object should the user use to talk to system?)

Signal processing HW

Waveform acquisition transformer to digitized signals and store them for later usage

Display functions mapping digitized waveforms and measurements to visual representations

Display functions

LayeredLayered

• layered looked promising because it decomposed the functionality into well-defined abstractions– Not a good IDEA

• Problem:– Boundaries between various functions conflicted with the needs to directly

monitor (interact)with various functionality and mode of a system because all interactions MUST be done by visual representation

• What if the user decides to change a rate or choosing acquisition mode and parameters in the acquisition layer

Great improvement over layered!!!Problem? how the user should interact with system?

Great improvement over P/F!!!Problem? Still it suffers from poor performance because wavefrom can occupy a large storageBetter Solutions? Need to use several types of pipes

OOD LYR P/F MP/F

Reuse ? ? ? ?

Performance ? ? ? ?

Usability ? ? ? ?

Change ? ? ? ?

…

HW1: Due Feb.24: Complete the case studies using the following table: You need to briefly justify your comparative analysis for each style

Design of CompilerDesign of Compiler

• Compilers translate programming languages to machine language or other lanaguages

• They also interact with other programming tools such as interactive editors and debuggers.

• A compiler translates source code in a programming language to object code that can be linked with other object code and executed on a computer.

Design ConsiderationsDesign Considerations

• The architecture must respond to the usage profile of its Environment. – For example,

• student compilers must support rapid turnaround of small programs but need not be much concerned with the quality of the code or design

• For commercial compilers, performance may be very important requirement.

• The architecture must be compatible with its associated software development environment. This might, for example, be batch or interactive.

P/F-C P/F-S P/F-B

Reuse ? ? ?

Performance ? ? ?

Usability ? ? ?

Modifiability ? ? ?

…

Mobile RoboticsMobile Robotics

• Mobile Robotic systems– Controls a manned or semi-manned vehicle

• E.g., Car, Unmanned Aircraft system, etc.– Used in space exploration missions– Hazardous waste disposal– Underwater exploration

• The system is complex– Real Time respond– input from various sensors– Controlling the motion and movement of robots

– Planning its future path/move

Other contributing factorsOther contributing factors

• The complexity of mission robot should achieve and the complexity of environment (predictability)

• Unpredictability of environment• Obstacles blocking robot path• Sensor may be imperfect• Power consumption• Respond to hazardous material and situations

Design of Mobile RoboticsDesign of Mobile Robotics

• Design Considerations?1. Supports deliberate and reactive behavior

a. Robot must coordinate the actions to accomplish its mission and react to unexpected situations

2. Allows uncertainty and unpredictability of environmenta. The situations are not fully defined and/or predicableb. The design should handle incomplete and/or unreliable

information3. System must consider possible dangerous operations by Robot and

environment (safety)4. Flexibility (missions change/requirement changes)

Candidate architectural solutionsCandidate architectural solutions

• Possible design solutions include– Layered architecture– Control-loop system (sense-compute-control)– Implicit Invocation ( task-control)– Blackboard architecture

2. plan/control/compute

1. sense3. action

Controller (pros and cons)Controller (pros and cons)

• Good– Focus on performance and correctness– Simplicity (gradual change in behavior)

• Act and react– Safety

• Simplicity makes easier to duplicate – Reusability (Separation of concerns)

• Controller, sensors, motors are separated• Bad

– Simplicity (not good with rapid and different behavior mode)– Uncertainly is handled by iteration of trial-error(act and react) process– provides poor coordination: no leverage for decomposing complex tasks into

cooperating components

Layered ArchitectureLayered Architecture

• Used in the design of the Dolphin sonar and navigation system

• Implemented on the Terregator and Neptune mobile robots

• Model the system using 8 level of abstractions

motor

data fusion

Maintain model of the world

Schedule and plan

GUI

1

2

3

4

5

6

7

8

Pros and ConsPros and Cons

• Bad– Coordination– Performance– Separation of concerns (two abstractions)

• Data hierarchy (layer 2,3,4)• Control hierarch (layer 1, 5, 6, 7, 8)

– Rapid reconfiguration requires fast respond (active safety)– Reusability (interlayer coupling)

• Good– Abstraction supports handling of uncertainly: what is uncertain at low level

may become clear with added information available in the higher layers– Fault tolerance are supported by abstraction mechanism

Implicit InvocationImplicit Invocation

• The solution is based on a form of implicit invocation embedded in Task-Control Architecture (TCA)

• used to control numerous mobile robots (e.g., Ambler Robot)• TCA solution is based on

– Task Tree (provides actions)– Inter -process Communication (IPC)

• application independent central server and a number of application- specific processes

– Provide three functions (provides reactions)• Exception, Wiretapping, and Monitors

Mission planning using Hierarchical task Tree

TCA: 1TCA: 1

• TCA design– Mission planning is based on hierarchies of tasks or

task trees• Parent tasks initiate child task• Temporal dependencies between pairs of tasks can be

defined– A must complete A must complete before B starts (selective

concurrency)• Allows dynamic reconfiguration of task tree at run time

in response to sudden change(robot and environment)

TCA: 2TCA: 2

• Uses implicit invocation to coordinate and/or integrate tasks– Tasks communicate using multicasting message (message

server or broker) to tasks that are registered for these events

• The communication mechanisms automatically marshall and unmarshall data,

• invoke user-defined handlers using publish/subscribe and client/server type messages, and both blocking and non-blocking types of messages.

TCA: SafetyTCA: Safety

• Strong support for fault Tolerant via– Exceptions: Certain conditions cause the execution of an associated

exception handling routines• i.e., exception override the currently executing task in the sub-tree

(e.g., abort or retry) tasks– Wiretapping: Message can be intercepted by tasks superimposed on an

existing task tree• E.g., a safety-check uses this to validate outgoing motion commands

– Monitors: checks information and execute some action if the data satisfy certain condition

• E.g. battery check

TCA: Pros and ConsTCA: Pros and Cons

• Separate actions and reactions• Support concurrency:

– Multiple actions can proceed at the same time, more or less independently (good)

– The degree of concurrency limited by the capabilities of the central server (weak)

– It is not clear how uncertainly will be handled TCA (bad)• Revising the tree?

– The three models (exception handler, monitor and wiretapping) require high performance (concurrent executions of handlers), safety, and fault –torrent (duplications of handlers) (good)

NASA and TCANASA and TCA

• NASA– TCA has been used on the Ambler, Ratler and Nomad

rovers, on the Tessalator tile inspection robot, – in the VEVI teleoperator interface, and for

autonomous spacecraft simulation. – In addition, descendants of the TCA communication

mechanisms (TCX and IPC) have been used in the Dante robot, and the Aercam project.

TCA: Pros and consTCA: Pros and cons

• Good– Safety

• Exception, monitor, wiretapping– Performance

• Allows multiple processes can proceed concurrently and in independently using central server

– Change• Support incremental and replacement

• Bad– Uncertainly – Central controller can become bottleneck

Blackboard ArchitectureBlackboard Architecture

• This solution was used in the NAVLAB project, as pert of CODGER system• Works with abstractions similar to those in the layered architecture• Main components include

– The captain (overall supervisor)– Map-navigator (high-level path planner)– Lookout ( monitors the environment for landmarks)– Pilot ( low–level path planner and motor controller)– Perception subsystem ( modules receives the raw data

form multiple devices and fuse them into meaning information)

Monitors landmark

supervisorHL path Planner

LL path Planer

sensor Fusion (correlate input from its diverse

sensors)

BLK: Pros and ConsBLK: Pros and Cons

• Good– Support cooperation and coordination of tasks– Resolving uncertainly (sensor fusion and Landmark detection)

• implicit invocation and database to maintain previous and next positions (dead-reckoning by Lookout module to identify landmark)

– Performance (concurrent)– Availability (duplicate)– Flexibility (subsystems are considered as independent systems)

• Bad– Reasoning– Reliability (what if BLK goes down?)

• blackboard is critical resource– No direct communication between subsystems

cruise-control systemcruise-control system

• The application of the control-loop solution to design of Cruise Control System(CCS)

• System MUST maintain – The speed of a car, even over varying terrain, when turned

on by the driver. – When the brake is applied, the system must relinquish

speed control until told to resume. – The system must also steadily increase or decrease speed to

reach a new maintenance speed when directed to do so by the driver.

Design ConsiderationsDesign Considerations

• A cruise control system provides autonomous (also casually supervised) control of the speed of a motor vehicle moving at highway speeds. For such a system, important design considerations include– Safety: Can the system fully control the vehicle, and can it

ensure that the vehicle will not enter an unsafe state as a consequence of the control?

– Usability: Can a driver with no prior experience with the system use it correctly?

– Performance: How fast does the vehicle respond to control inputs?

Possible solutionsPossible solutions

• Solutions– OOD– Control Loop Process– State Transition Diagram

Justification for using Control viewJustification for using Control view

• The selection of an architecture commits the designer to a specific view of a problem.– E.g., Object Oriented view vs. Functional view

• The issue is which abstraction fits better for a specific problem• Control View is better because

– Leads us to specify the output – Separation of Process from Control– Determination of the set point is easier to verify if it is separated from

control– Provides powerful tools for selecting and analyzing the response

Possible questions on examPossible questions on exam

• Case Study and comparative analysis

RT-Embedded Systems vs Cyber Physical RT-Embedded Systems vs Cyber Physical Systems (CPS)Systems (CPS)

• Embedded system is the union of computing hardware, software immersed in a physical system it monitors and/or controls.

• The physical system is a given.

More: CPSMore: CPS

• Cyber-Physical Systems (CPS): Orchestrating networked computational resources with physical systems

• Co-design of physical system and controller (hybrid discrete and continuous systems)– Computation and networking integrated and coordinated with

physical processes. • The technical problem is managing dynamics, time, and

concurrency in networked, distributed computational + physical systems.

Networking

Physical

Compute

A typical CPS

SA challenges for CPS SA challenges for CPS

– Enriching model-based engineering with relevant views(e.g., physical, resource properties) to specify

• Physical • Software• Network • Resource aware (time/energy)

– Formal verification of a system composed of heterogeneous systems (analog and discrete systems)

• Testing (e.g., Lockheed Martin used to show presence of fault)• Formal Verification (e.g., Rockwell Collins used to show absence of fault)

– …

FutureFuture

Collision ScenarioCollision Scenario

CPS and HealthCare SystemCPS and HealthCare System• Applicability of CPS in Healthcare Systems (e.g., assisted living, elderly care, remote

patient monitoring systems)– How to use CPS in HealthCare Systems

• How to use Networked devices and Computations with physical systems (patients)

– What are the QA (e.g., security, scalability, performance, adaptability, etc.)?– What are the possible architectural designs? (Feedback loop, publisher and

subscribers, etc.)?– What are the architectural modelling and analysis?

» How to use MBE to specify and analyze the CPS?» What are the main issues using MBE to

– Infrastructure? How to utilize cloud computing as viable and reasonable infrastructure in design and realization HealthCare systems?

71

CPS and Healthcare System: 2CPS and Healthcare System: 2

• Integrations? CPS’s architecture demands computation, coordination, communications. What is the proper configuration and composition?

• Collections of heterogeneous/homogeneous Devices (e.g., biosensors producing ECG’s heart-rate data ) with different type of information

• How reliable are the devices? (abnormal reading, sampling, etc.)• Database Mgt (EMR)?

• Storage• Integrations• Processing

• Computation?• Modeling and notations

• Communication• Scheduling, protocol, NTW security, etc.

72

Taxonomy of CPSTaxonomy of CPS

• Applications of CPS in HealthCase– (semi/full) Assisted application (e.g., Health

Monitoring)– Controlled Environment (e.g., Hospitable)

73

Rules of thumb when designing most Rules of thumb when designing most archiecturearchiecture

• Rules are divided into categories– Process recommendation– Product recommendation

74

ProcessProcess

• Process guidelines– Use a single architect (or small team) to produce the

architecture– Base the architecture on a prioritized list of well-

defined Qas– Use views to document the architecture– Evaluate architecture for its ability to meet Qas– Use Incremental implementation to realize the

archiecture

75

ProductProduct

• Product Recommendations– Use well-defined modules whose functional

responsibilities are assigned using information hiding and separation of concerns

– Use existing solutions (PATTERNS/STYLES)– Separate modules that produce data from those that

consume data– Use small numbers of possible ways for components

to interact (helps understandability and productivities

76

ReferencesReferences

1. [Par72].D. L. Parnas. On criteria to be used in decomposing system into modules. CACM, 15(12):1053-1058, Dec.1972.

2. Mary Shaw, David Garlan, Robert Allen, Dan Klein, John Ockerbloom, Curtis Scott, Marco Schumacher: Candidate Model Problems in Software Architecture, CMU publication, Jan 1995

3. Some slides are borrowed from U of Waterloo4. Alberto Sangiovanni Vincentelli: Embedded System Design: Models, Validation and Synthesis

(RTES-CPS)