94.586 Object-Oriented Design of Real-time Systems...Winter 2001 C-1 Copyright C. M. Woodside 2001 Developing a Real-time System Architecture Perspective

94.586 Object-Oriented Design of Real-time Systems...Winter 2001 C-1Copyright C. M. Woodside 2001

Developing a Real-time System Architecture

• Perspective– develop a view of functions, behaviour and (tentatively) of

components (e.g. use cases, collaborations, static modeling)– architecture: defines the organization and its attributes

• emerges from general concerns and desired behaviour• conceptual organization, concurrency• concrete module architecture

– detailed design of components

• Architecture families and issues


What is architecture?

• organization of components and interactions– what components– more important for larger more complex systems– especially prominent for systems with concurrent processes.

• distributed• parallel• real-time (to meet deadlines)

• architecture establishes the requirements for detailed design


Recognize typical architectures

• Hierarchical: control at the top– client server: info retrieval; client pulls information up– master-slave: processing; master pushes commands and data down

• Hierarchical: control distributed– higher levels have a wider perspective but changes enter at the periphery

• Pipeline: data flows through– control at a higher level, over all– control at one end

• at beginning, control flows along same path as data, or separate, and pushes data through

• at end, control goes in reverse direction and pulls data through• Shared memory (memory, database, tuple space, DSM, etc) • Messaging (point to point, broadcast, publish and subscribe)


Process of deriving and evaluating it...• The subject of Applied Software Architecture, by Hofmeister, Nord and Soni

(HNS)• Global concerns

– Factors: of the product, technology to be used, and the developer organization.• for each factor: identify, describe, volatility, impact

– Issues arising from the factors– solutions or strategies for dealing with issues

• Conceptual architecture– conceptual components/interactions are described by their requirements or their

attributes, rather than as designs ..... (e.g. half-call controller)– focus is on high-level control and functional interactions rather than actual

internals.......components all potentially concurrent... – very like the RoseRT view!!– we will reason from UCMs– we will consider necessary concurrency issues more seriously here, using

UCMs...


Process of... (2)

• Module architecture view in next step.... more concrete – possibly re-arranged, from evaluation of resource requirements– intended real components, with real interactions

• at the object level, these are the elements of Gomaa’s architecture, • his four types of object (interface, entity, control and application logic)

– high-level control usually becomes meshed into execution of functions– again, we will consider necessary concurrency– UCM is now only a reference for tracing back to the big picture

– .....Gomaa seems to leap directly to this step• Execution architecture view expresses configuration questions

– processes, threads, processors, OS, midware– concurrency is settled here, by HNS– location, migration of functions


Role of UCMs

• initially to establish what is being talked about– what operations– what components

• allows architecture to be modified and manipulated, to address issues

• semantics of the UCM model• reasoning about UCMs• Navigator tool


Image processor example (HNS)• platform...

– probe with camera and other sensors, and motion control; – acquisition by imaging computer– control and viewing at control station; – remote viewing/processing stations

• operations:– image or image-sequence acquisition,

• built-in and user-defined acquisition procedures• acquisition and display rate, speed/quality tradeoff

– image processing and storage, – display at control station– export for remote viewing or processing


Requirements

• examples....– data rate for acquisition and display– upgradeable (platform, OS, camera, sensors, algorithms)– recovery from failures during acquisition


Image processor UCMs (1)

probe data acquire postprocess formatview

store

acquisitioncontrols

displaycontrols

send

exportcontrols

Probe Acquisition Postprocessing User Control Interface

Network

Database


Creating an Architecture: HNS approach based on a “global analysis”

• Identify factors of several kinds.... these are relevant aspects.– they suggest factors coming from the product, technology, organization– factors have an aspect of stability, and of impact

• Identify issues related to the factors– goals, potential problems– an issue can arise or involve several factors

• Create strategies for dealing with the issues

• Use the strategies in creating the architecture

• this is a creative process using ingenuity, with no right answers


Global analysis: product factors• Functional features

– acquisition procedures: may change every 2 years, affects performance, image processing, and the UI

– image processing: library; algorithms change, affects image processing and UI– image types: new types may be added, affects storage, acq. and image-p., and export

• UI– interactive control of acquisition: changes approx 3 years, affects UI, acq. and storage– user defined parameters: stable, affects acquisition and storage

• Performance– data rate from probe: changing with probe hardware, affects acquisition performance– performance requirements: not quite stable

• Dependability...• Failure handling (detect/report/recover)...• Servicing...• Cost: budget amounts: inflexible.... affects the components for image acquisition• Example issue: easy addition and removal of features

• idea: separation of components by concerns


Global analysis...technology factors • processor type: frequent changes, expected to be transparent• memory: 64 MB chosen to keep cost down... could be increased... would allow

more complex image processing.• probe hardware (to detect and capture signals) and interface: expect upgrades every

3 years... affects acquisition and image processing• OS: real-time kernel on standard processor... features change in 2 years, OS change

in 4 years• OS: POSIX compliant... stable.... affects all software• Image data format is standardized... likely to change every 3 years... large impact

on image processing and post-processing.• Image-processing algorithms... stable... minor impact

• Example issue: Changes in hardware are expected...processor, probe, interface• idea... encapsulate the changes by a software interface.

• another: changes in software technology: OS, and software components• idea... encapsulate with in-house interfaces


Global analysis...organizational factors

• Management: build-vs-buy: ready to buy... helps to meet schedule– schedule vs functionality: schedule has priority...ready to compromise on

features: impact on first release date• Staff skills: OOA and design: some designers have skills... training is possible...

moderate impact on good design– multithreading and multiprocessing: limited skills... threading is too complex

for training in the time... moderate to large impact on performance• Schedule: time to market 2 years... no flexibility... large impact on choices• Features: features are prioritized and somewhat flexible... moderate impact on

schedule• Budget: head count is X... impact on schedule

• Issue: Aggressive Schedule needed


Global analysis...issues lead to strategiesStrategies arise from analysing issues... they can be related to several factors... they affect the architecture .• example arising from organizational factors: Aggressive Schedule Issue

– three strategies suggested: • re-use existing in-house components• buy rather than build• make it easy to add/remove features (and reduce initial functionality)

• example from technology factors: Changes in Hardware (probe, processor)– strategy suggested: • encapsulate the hardware with software that offers a general interface

• another: Changes in Software Technology... strategy: use standards• example from product factors: Easy Addition/Removal of Features

– three strategies suggested: • separate components by concerns (processing, communications, control, data, UI)

• encapsulate features in separate components• decouple the UI model from the rest

• another: Throughput– strategy: • use concurrent processes for independent threads of control

• another: Acquisition performance– strategy: • separate time-critical components from others

• use shared memory• another: Recovery from errors... strategy: • introduce a recovery feature with persistent data


Develop Conceptual Architecture• Use cases and UCMs• Global analysis leads to some strategies which are architectural, for instance:

– easy addition/removal, when applied to the acquisition and processing steps, suggests the use of specialized components and three strategies:

• a flexible pipeline model for both kind of processing (components can be snapped in)

– interfaces become a concern...• components for specific features• encapsulate domain-specific data in generic structures

– acquisition performance suggested separating the time-critical components in the image-capture and processing chain, from others

• Consider the previous UCM but change the components to separate the time-critical imaging operations (data handling during actual acquisition) from control, storage and export

• Pipeline structure and components for processing are a more detailed concern for later.....


Conceptual Architecture... redivide the UCM

probe data acquire postprocess formatview

store

acquisitioncontrols

displaycontrols

send

exportcontrols

Probe Acquisition Postprocessing User Control Interface

Network

Database

Imaging

Acquisition

Exporting


Conceptual Architecture in UCM

probe data collect postprocess formatview

store

acquisitioncontrols

displaycontrols

send

exportcontrols

Network

Database

Imaging

Acquisition

Exporting

process

probecontrol

acquisition management

Monitor

retrieve

Export

Acquire


Architecture notation in HNS• Components with ports

– (stereotype ccomponent of UML Active class)– may have nested components (UML Composition)

• Ports– (stereotype cport of UML Class)– have bindings to roles, (cbinding, st of UML Association)– have connections to ports for nested components

(cconection, st. of UML Association)– bindings have protocols defined as in ROOM (message

lists in each direction)• First-class connector with roles

– (stereotype cconnector of UML Active Class)– connect components with the same encapsulation– may contain components and connectors, to describe

complex connectors like an ORB, for instance• Roles (eg, sender, receiver)

– (stereotype crole of UML Class)– binding to ports, and to roles of nested connectors

Connector

Component

Component

nestedcomponent

Port

Role

connection

binding (and protocol)


Conceptual Architecture in HNS (Fig 4.6)


Explanation of Conceptual Components• Probe Control: encapsulates the probe control interface for probe motion and

acquisition, and configures the Data Collection component• Acquisition Management: configures the image processing and the probe• Acquire: provides the UI for acquisition.• Data Collection: encapsulates the probe data interface and transmits raw data• Image Processing: converts the raw data to image frames

– may include a pipeline of functions for data formatting• Post Processing: applies image enhancement algorithms

– may include a pipeline of functions• Monitor: encapsulates the user display and its controls• Image Collection: captures and stores images for later export. Can also provide the

stable storage needed for error recovery.• Export: provides the UI for exporting images to other workstations• Comm: handles network communications with other workstations.


UCM over HNS Conceptual Architecture

• Stubs for ImageProcessing and PostProcessing– configured by

control


Decomposition of ImageProcessing component

packetize

process

acqControl


Conceptual Components of ImageProcessing

• Packetizer converts raw data to packets• PacketPipe conveys packets to the processing part• ImagePipeline is some number from zero up, of subsystems in

parallel– cardinality shown by * (UML... implicit cardinality of 1))– this could in principle allow parallel enhancement processing on

segments of the picture, if a multiprocessor were installed

• ImagePipeline is provided to hold the pipeline planned for the image preprocessing... this might include noise filtering and compensation for probe response.


Decomposition of ImagePipeline component


UCM over ImagePipeline Stub


Conceptual Components of ImagePipeline• PipelineMgr is created for a particular acquisition, configured for the acquisition

procedure.– it configures the entire pipeline of functions, and then manages the flow of

frames through the pipeline.– it initializes stages, and the sequence of stages, depending on the acquisition

procedure– it requests the start of processing

• Client/server is a conceptual connector which initializes the Framer and each Imager stage

• Event is a conceptual connector which initiates processing of an image.• Framer begins at an event... it pulls packets from the Packetizer, and creates

meaningful image frames from the packets, according to a standard• ImagePipe is a conceptual connector which conveys frames, using the standard• Imager is one of a sequence of pipeline stages which carries out some image-

processing algorithm on the image frame


Recovery Issue

• data that has been acquired should not be lost in a failure (crash, or power failure), but it should be possible to continue on from that point– raw data or processed? since processing is done as data is acquired, we will

say, processed.– we have it stored now.

• suggested: a recovery subsystem, with dedicated components for cleanup and crash recovery– UI elements to allow the operator to make choices about the restart– discovery of the point at which recovery is to start: this may require additional

data to be saved• configuration and acquisition procedure definition• state of all components periodically??

• suggested: a separate recovery mode for each conceptual component.– recovery control path– access to data for re-initialization


Diagnostics Issue

• separate from recovery, is the logging of information to help understand problems.– logging– access to logs

• suggested: diagnostic reporting from all components– uniform policy– one embedded component for detecting and logging, one for

access (consider: should access really be by component, or for the whole system??)

• suggested: use common tools to define and deliver error messages– (issue: reduce effort)

• suggested: use standard logging services


Resource budgeting

• memory budgets for components in the image flow path• time budgets for executing functions on the image flow path• reaction time budgets for reacting to command events?• e.g., a data rate of 2 MB/sec for probe data


Evaluation

• evaluate the conceptual architecture, particularly against the global analysis issues, and revise if necessary.– ... architecture evaluation to be revisited


Module View Architecture• what it is... how different

– a repartitioning to generate the actual class architecture for large modules. So:• a module will have an implementation• a module may be one or more conceptual elements• may differ from conceptual partitioning, based on evaluation

– Layers, subsystems and modules– modules accept calls or messages, do all their own interpretation and mediation

• Layers.... suggested by level of abstraction (these look a bit like our initial UCM-based components, however!)– GUI– Applications: management, postprocessing, storage and export operations– ImageProcessing: preprocessing stuff– probe services: probe control, data collection– system services

• ?? logging.... recovery??


Layers• Commonly associated with level of abstraction• high levels of abstraction have more coverage:

– scope across a variety of system functions and components– across the timeline of an operation– across larger units of data

Control operations Layer Data scope

HI.. setup acq. procedure UI whole sequence

sequence the pipe steps Mgt/App individual images

trigger build frame ImageProc framing and image building

position probe, set Probe bitstream from probe

controls

LOW probe operations System Services

Hardware


Layers

Fig 5.4• GUI• Applications, includes management and the non-time-critical parts of

acquisition – (mixes whole-process and single-image-step handling... keep an

eye on this?)• ImageProcessing includes the time critical parts, which must keep up

with the probe data rate.– mixes bitstream, frame and first image stage

• ProbeService includes the probe interfaces for control and data• SystemServices includes the communications for export.

• notice the mixed motivations... layers can be anything...


Layers• tend to have inter-layer “uses” relationships that go in one direction

(e.g. “down”)• within a layer there may be sublayers... or anything goes.

Processing moves up in abstraction here, and control moves down:

Data scope

whole sequence

image scope

framing

bitstream from probetime

control operations data movement

start collectingsetup storedresult


Elements of module architecture

• module, interface, package........ visibility of interfaces

<<module>>ModuleA

<<module>>ModuleB

requires interface

InterfaceB

provides interface

<<subsystem or layer>>


alternative description, for interface operations

<<module>>ModuleA

<<module>>ModuleB

requires interface

interfaceB

<<module>>ModuleA

<<module>>ModuleB

dependency

<<interface>>InterfaceB

read()update()

realization

realization

no attributes for an interface


Where do we get modules from?• conceptual components• functions• ports and connectors, even roles...

• it may be useful to focus first on ports and connectors and build up the architecture from the edge in, as described in HNS:

• in ImageProcessing (fig 4.7), the Packetizer and the PacketPipe can be merged to get a buffer manager “MPacketizer” that builds packets and manages a packet buffer

– this is accessed by the next component to fetch the packet• next, the packetIn port becomes a MPacketMgr, for Framer to access

packets and build an image.• Framer is a module, and writes images to a module MImageMgr, which

manages an Image buffer– this MImageMgr handles image communications between stages (?)


Styles of module architecture: pipeline

• push,

• pull,

• mixed

Stage1IF1

Stage2IF2

Stage3IF3

Stage1 Stage2IF1

Stage3IF2

Stage1IF1

Stage2IF1/2

Stage3IF2

IF3

IF3

doesn’t say anything about passing the data... could be by calls...


Pipeline with storage between stages

• separate buffers

• global buffers

Stage1IF1

Stage2

IF1/2

Stage3

Buffer1/2

IF2/3

Buffer2/3

Stage1IF1

Stage2

IBuffer

Stage3

GlobalBuffer


Styles of module architecture: hierarchy Client-server Master-slave Inverted Master-slave

Client1 Client2

IServer

Server

IServer2

Server2

Master

ISlave1

Slave1

IServer

Server

Slave2

ISlave1

Master

ITask

Slave1

IServer

Server

Slave2

ICmd

ITask


Hierarchy with shared storage Client-server,,,,

Client1 Client2

IServer

Server

IStore

SharedStore


Peer - to- Peer architecturesDirect interaction Publish and Subscribe (e.g. by tuple space)

Peer1 Peer2

ITS

TupleSpace

Peer3Peer1 Peer2 Peer3

Peer1 Peer2 Peer3

IStore

Store

Shared memory


Shared memory example... Gomaa Fig 16.7


example as shared-memory module architecture

:CustomerInterface :OperatorInterface

IServer

ATMControlMessageQ

bankServerProxy

:CardReaderInterface

:ATMController

cardReaderBuffer

promptMessageQueue


Subscription/notification.. Gomaa fig 13.13Client

IServer

:ServerCoordinator

Iarchive

Archive

:SubscriptionServer

:EventDistributor

:EventMonitor

IEvent

Isubscribe/query

Inotify


Principles for concurrency in architecture

• concurrency is provided by separate tasks and threads– task is the same as process, a program unit dispatched by the OS

• provide a concurrent task for:

1. managing an interface

2. a separate thread of control (cohesion) (separate responses)

3. parallel operations to provide capacity or speed

4. urgent operations, so they can be scheduled with priority

5. put together modules that communicate heavily (IPC is expensive)

6. components that might be replaced (because of the generality of the message-passing interface between processes)

7. a server for shared data that needs management (e.g. mutual exclusion)

8. conceptual components, if they line up with modules (HNS...)


Concurrency and Tasks... HNS Image-processor

Summary of the modules in the imaging data stream

responsiblility formanaging access to image buffers

initiates control

one controller per pipeline

pipelinestage (many)

mediates accessby a stage to image

data

makes imagesfrom packets

packet buffermanager


Derivation of pipeline tasks... from HNS

conceptual/moduleagreement

process per threadof control

(one pipeline stage)

client = thread of controlAcqControl is bound toit by messages

task per pipeline(different code)

process per threadof control

(framer = one pipeline stage)


Pipeline creation... one pipeline instance

• one client for many pipelines• one pipeline has its own image buffer, manager, framer (!!) and one or

more imager processes


All imaging tasks

packetizer taskmimic tasks and

memory for Pipeline

frame frompacket

control image data access

pipe stage

one AcqControlper pipeline

IPC is message-passing supportedby kernel primitives, all on one busand even in one processor

* for “many”


Behaviour of the image pipeline... pattern

OperationDestinationbuffer mgr

Sourcebuffer mgr

Sourcebuffer

Destinationbuffer

process

data?

readyread

request buffer

write


Imaging data flow (example from HNS)

pipestage processing here(read,write)


Imaging data flow with causality overlay by UCMframer and imager pull data thru

data

datadata

data


Assessing timing

• “schedulability” analysis• for situations with deadlines and periodic operations• simple analysis, even if arrivals are not periodic, but:

– have a minimum separation at least equal to the delay,– or have a larger period than the deadline

• then, set “period” = deadline delay, for a worst case analysis– period Ti– computation demand Ci

• Rate monotonic schedule uses fixed priorities, – highest priority to shortest period– pre-emptive


Utilization bound theorem

• Meets deadlines if sum of Ci/Ti < utilization threshold U(n)• (for n = 1, 2, 3,..... U(n) = 1, .828,, .779, ...... .69)

• consider example with (C, T) = (7, 13) and (x, 51)• largest feasible value for x satisfies (7/13) + (x/51) = 0.828• giving x = about 14.7

• RM scheduled, with first arrivals at 0 for #1 and 5 for #2:

0 5 7 13 20 26 33 39 46 52 56 59 #2 done idle

1 1 1 1 12 2


RM vs not...

• Opposite to RM scheduling... for (7, 13) and (14.7, 51):– #2 is given pre-emptive priority over #1 this time– disaster...

0 5 7 13 20 22 26 29 36 39 46 52 56

1 1 1 1 12 2

First of #1 finishes here, lateSecond one is already dueThird is about to arrive!!

51 sec


Completion time theorem

• RM– start all tasks at the same time... if every one meets its first deadline, they will

always work • non-RM:

– same, but allow for all higher priority tasks to pre-empt• those with shorter period, multiply by period ratio since multiple pre-

emptions• those with longer periods, once is worst case.

– plus allow for blocking by lower-priority tasks that can’t be pre-empted• once, at the start


Some additional performance issues

To reduce the blocking time due to locking or a semaphore: – minimize holding time in the code that uses it– reduce the locking granularity– introduce read and write locks (read == shared)

Possibly avoid blocking messages– blocking message holds the sender frozen (like a lock on the sender’s state)

Simplify the control flow– minimal choices lead to less overhead for decisions– more generally: EARLY BINDING of decisions reduces execution time

• e.g. static allocation, fixed size of data– a pure tradeoff of flexibility against execution time.

BUT... if you check if processing is required before doing it, it may SAVE work


Non-deterministic execution and performance

This is complex.... – variable execution means tasks may have to wait for a long one...

• IS IT BOUNDED?• buffering space needed;

– finite buffer space means one may also lose tasks (messages)• this may also somewhat limit the waiting,

• as a rule of thumb, mean waiting is related to the mean execution time of all work units, and the utilization of the resource (e.g. processor)– wait + execution = execution/(1 - utilization) is the law in some cases– in other cases it is a factor times this

• factor between .5 and 1 for reduced variablility of execution time• factor greater than 1 if high variability• pre-emptible tasks dont count at all• lower priority non-pre-emptible count, but less


Non-deterministic system performance (2)

• what to do, to get an estimate of capability?– utilization not too high is still a good rule, 60% is a reasonable limit– queueing analysis is the way to go, if there are simple processor queues with

FIFO waiting• special queueing analysis, such as LAYERED QUEUEING for message

queues at tasks, and lock request queues– use simulation if the system logic is a bit complex


Fault Tolerance or Reliability: Different levels of goals for different situations

• strongest: full functionality at all times (failures fully masked) (banking system?)• less strong: failure may happen but it satisfies safety conditions (no reactor

meltdown)(elevator?)• less strong: correct operation always but failures may induce gaps (full recovery)

(ATM machine?)• less strong: failures occur but can be partly recovered (image processor example)

– OR can mostly be recovered (telephony?)• medium high: failures occur but the system always continues running • medium: failures occur and crash the system, or part of it, but the system restarts

itself and errors are logged (UNIX network)• weak: system crashes but errors are logged, allowing later diagnosis (UNIX)• weakest: system crashes and user must restart (Microsoft WORD)(printers)


FT/Reliability and Architecture: Mechanisms for Handling Errors

Include the following...• error test in the code.... error detect... error message

– run-time correctness predicate checks• error logs (classified for seriousness?)• exceptions handled when errors are detected: avoid propagation of the error

– substitute an acceptable value (e.g. zero, if x > 0 is violated)– discard unsuitable case

• exceptions thrown to a higher level (e.g. to the caller of a procedure)– handled there, or thrown further up if no action can be taken

• active monitoring by a separate process– heartbeat messages detect process failure through timeout, or failure to respond

(also known as “keep-alive” messages)– audit process inspects the process state through shared memory, and tests

values for correctness


FT Mechanisms (cont’d)

• diagnostics (algorithms to identify the cause of a problem)• a recovery block is a module which combines execution, test of correctness, and

recovery action inside it• recovery:

– processes told to recover, if error is not too large; recovery model of operation in each process,

– restart of sick process• checkpointing of process state, or transaction state, to support restart• Layering of the system to contain failures and recovery within a layer• replication of services, data, communications pathways

– for standby in the case of failure– for redundant evaluation

• redundancy and voting


Architecture Features for Fault Tolerance

Include the following elements:• exception detection and handling at the procedure/method level:

– ad hoc– recovery block

• similar at the module level• separate process for logging

– by the entire system, by layer, by subsystem• separate process for audit or monitor

– twinned, one for one– one monitor or audit for a cluster, layer, or subsystem– monitor hierarchy, possibly in a management hierarchy

• redundancy• separate processes to take over for recovery, or for failsafe shutdown.


Exceptions within a global view of behaviour

....simplistic view due to limited outlook of the designer...

Normal States(including data states)

for normaloperation

as expected by the designer

Safe terminationstates

Unsafe terminationstates (crashed)

fatal exception

terminate

Abnormal States(but still running)

non-fatalexception


Exceptions in global behaviour... enlarge the view to include handling

S: Safe termination

states

C: Unsafe termination

states (crashed)

N: Normal States(including data states)

for normaloperation

as expected by the designer

fatal exceptions

terminate

A: Abnormal States(but still running)

(including exceptiondetected)

non-fatalexception

U: Exception thrownto user

repair

user recovers


A point of view...

• If you think of some possibility as likely, it becomes part of the planned system operation– enlarge your viewpoint to include the exceptions as additional

paths– e.g. PIN validation failure or cash exhausted, in ATM.

• even more serious exceptions become just part of the system behaviour– the distinction between Normal and Abnormal states is a matter of

a point of view• to the mentally prepared there are no exceptions.... just bad things

happening.


Java exceptions

• detect and handle locally... is not called an exception in Java... (N to A to N, within same method)

• only problems that happen in one context and are dealt with in another are called exceptions

• detect and throw a declared exception type– look at caller for a catch clause for this type. The

catch clause handles it.... in handling it, it may throw another exception for higher level to deal with. (still N to A to N)

– if no catch clause in the caller, it must throw it up to its own caller• this could end up at U or S

– if no catch clause anywhere, then program terminates if a command-line program (N to A to C)

U:user

C: crash

S: stop

A: abnormal

N: normal


Design for handling within the call path(as in Java)

I/F

mod-1

mod-2

mod-3* EXCEPTION * DETECTED

U

C

S

A

N

1. detect at mod-3, now in A.....or, occurs undetected, now in A2. handle it:....handle in mod-3, back to N....throw and handle in mod-2, back to A....throw to user, go to U, user recovers3. fail to handle it, but stop: go to S4. fail to handle it, dump core, go to C


Design for handling in a separate call path

.....by calling an exception subsystem

I/F

mod-1

mod-2

mod-3

mod-excp

I/F

mod-1

mod-2

mod-3

excp-1

excp-2

excp-3


Examples of exceptions handled locally

designed in by optimistic assumption:• cache miss... call a method to fetch from source• CSMA collision

input editing or checking:• virus detection in an input file or message

– discard and log– or, special module to remove and repair

• bad data in file just ignored (to log, call a special module)

deeper checking:• optimistic locking failure: abort and retry

A

N


Examples of exceptions handled locally (2)

• elevator door doesn’t close (blocked)– special module to handle: wait and retry, sound a

signal?A

N


Examples of exceptions thrown to user (transaction aborted)

• optimistic locking failure causing user to retry• attempt to withdraw too much money from the

bank• PIN validation failure• misspelled word in document• virus detection in program?• intrusion detection?• divergent iteration of equations, if detected before

it dumps core– but what if this is one of a sequence of solutions

and we don’t want to abort the sequence: then we want to handle it at the sequence control level.

U

A

N


Examples of exceptions handled externally

• real-time signal out of bounds, beyond the range for normal control– e.g. a boiler pressure too high; a temperature too high or too low– activate a safety subsystem

• some time-outs (considered separately)

• failed audit check of a process– audit process is already external


Examples of timeout exceptions

• packet not acknowledged... retransmit... local handling in same module that initialized the timer– timer returns control to the same module

• elevator doesn’t stop within a specified interval after command to stop– timer puts control to some kind of override controller

• liveness monitor misses heartbeat message reply– monitor pings the process, or sends it a message type that gets a

simple reply– after a timeout, the monitor control comes back to the monitor to

handle suspected process failure. (restart the process, perhaps).– here the monitor only exists to generate exceptions... it has no

“normal” function


Gomaa cases... how to handle exceptions

• Elevator: door doesnt close, elevator doesn’t stop– no button push for a long time: return to a standard floor

• Bank: authorization failure, out of cash– ATM processor failure– ATM power failure– ATM communications failure

• Cruise control: speed sensor failure, accelerator actuator failure


more..

• Factory automation: crashed computer in robot– network failure– out of dimension result from a manufacturing step: discard a part– infeasible robot speed requested?

• E-commerce: database crash during a session– invalid address for invoice– out of stock– catalog error on model or size


Distributed file system examplefrom: Architecture-Based Exception Handling, Valerie Issarny, Jean-Pierre Banatre,

Proceedings of the 34th Hawaii International Conference on System Sciences - 2001– a client failing to interact with a given file server due to either

actual failure at the level of the server machine or network, or simply a timeout whose value has been set too low;

– a client requesting a file access that cannot be serviced due to reasons such as unknown file or unauthorized access;

– a server failing to service a request due to the current server load.

“Configuration exceptions” affect the entire configuration, not just the one request, and may require reconfiguration:– failure of a server instance.... Such an exception is expected to be handled within

component instances interacting with the failed instance (monitor), – excessive delay, which may be offset using a thread for predictive prefetching– specify reconfiguration, as part of the architecture

• and what do do about the original parts (terminate or resume)

Documents

94.586 Object-Oriented Design of Real-time Systems...Winter 2001 C-1 Copyright C. M. Woodside 2001 Developing a Real-time System Architecture Perspective