Case Studies Elevator control system Elevator control system Comet case studies From task structuring to target system configuration.

Centralized solution - - Determine tasks for each subsystem - - Define task interfaces - - Design of data abstraction classes Task structuring

Centralized solution - -Elevator Control System is mapped to a single CPU or to a multiprocessor configuration with shared memory - -Elevator Status&Plan object is accessible to all elevators and to the scheduler - -We can use a centralized repository of data Assumptions

Task structuring Centralized solution - - Analize all the objects on the collaboration diagrams - - Apply the task structuring criteria Procedure

Elevator subsystem Task structuring Elevator button Interface - Asynchronous input device interface criterion - Asynchronous input device interface criterion -> Separate task - - Task inversion criteria -> One task handles all the elevator buttons

Task structuring Elevator subsystem Elevator Manager -Structured as a Coordinator Object

Task structuring Elevator subsystem Elevator Status&Plan -Passive data abstraction object -> doesnt need a separate thread of control

Task structuring Elevator subsystem «state dependent control» :ElevatorControl «entity» :ElevatorStatus&Plan «coordinator» :Scheduler «output device interface» :DirectionLamp Interface «external output device» :FloorLamp «output device interface» :MotorInterface «external output device» :Motor D10a: Departed (Floor#) D10: Departed (Floor#) D6a: Off Up Direction Lamp D6: Up D9: Elevator Started D6a.1: Direction Lamp Output D8: Motor Response D7: Start Up Motor Command Elevator Control

Task structuring Each Elevator Control object is mapped to a separate Elevator Controller task It interacts with several output device interface objects such as: - -Motor Interface - -Door Interface - -Elevator Lamps Interface Do we need separate tasks? Elevator subsystem Elevator Control

Task structuring - -Passive devices - -Output request executed on demand - -The calling task has to wait for the output request to complete - -Elevator Controller doesnt execute concurrently with Motor Interface and Door interface By the Control Clustering Criteria we combine these tasks with the Elevator Controller task Elevator subsystem Output devices

Elevator Controller doesnt execute concurrently with Motor Interface and Door interface Elevator Door Opening Elevator at Floor Elevator Stopping Elevator Moving Entry/Departed Approaching Floor/Check This Floor Approaching Requested Floor/Stop,On Direction Lamp Elevator Stopped/Open Door, Off Elevator Lamp, Arrived Door opened/Start Timer Task structuring Elevator subsystem

For the Elevator Control subsystem we have four tasks Task structuring - -Elevator Buttons Interface - -Arrival Sensors Interface - -Elevator Controller - -Elevator Manager Elevator subsystem Summary

Task structuring Elevator subsystem

«external input device» : FloorButton Floor Button Request «subsystem» : Scheduler Floor Lamp Output «external output device» : DirectionLamp Direction Lamp Output «input device interface» :FloorButtonInterface «output device interface» :FloorLampInterface «output device interface» :DirectionLamp Interface «subsytem» :ElevatorSubsystem Service Request Floor Lamp Command «external output device» : FloorLamp Direction Lamp Command «data collection subsystem» :FloorSubsystem Task structuring Floor subsystem We start from the floor subsystem structure.

Task structuring Floor subsystem We determine the Floor Button Interface task We consider Floor Lamp Interface and Direction Lamp Interface - -Are passive output devices - -Receive concurrent requests from the Elevator Controller instances We use monitors tasks to serialize the requests

Centralized solution Task structuring

Centralized solution Task structuring

Define Task interfaces Task structuring - -Consider message interfaces between concurrent tasks - -Map them to loosely or tightly coupled messages - -Add name and parameters of each message

Define Task interfaces Task structuring For instance: ElevatorRequest <<asynchronous input device interface>> input device interface>> :Elevator Buttons Interface <<coordinator>>:ElevatorManager ElevatorRequest(Elevator#,floor#,direction) <<asynchronous input device interface>> input device interface>> :Elevator Buttons Interface <<coordinator>>:ElevatorManager

Define Task interfaces Task structuring

Define Task interfaces Task structuring

Design of Data Abstraction Class Task structuring > Elevator Status&Plan + arrived(elevator#,floor#,direction) + departed(elevator#,floor#,direction) + checkThisFloor(in elevator#,in floor#,out floor status, out direction) + checkNextDestination(in elevator,#out direction) + updatePlan(elevator#, floor#, direction,out idlestatus) + selectElevator(in floor#, out elevator#,in direction)

Distributed Solution -Subsystem Structuring - -Design of Device Interface classes -Design of information hiding classes - -Design of Device Interface classes - -Design of State-Dependent classes -Detailed software design - -Design of Connector objects - -Design of Composite Tasks -Target system configuration

Distributed solution General description - -Multiple nodes interconnected by a LAN - -No shared memory Physical configuration: - -All communication is via loosely coupled messages

Task structuring Distributed Solution

Distributed solution General description - -Now the Scheduler and the multiple instances of the ElevatorManager cannot directly access Elevator Status&Plan data object An emerging issue We may: Embed ElevatorStatus&Plan in a server object Use replicated data

Distributed solution General description Server solution - -Clients access the ElevatorStatus&Plan with a synchronous message with reply Risk of Bottleneck!

Distributed solution General description Data replication solution - -Each instance of the Elevator Subsystem maintains a Local ElevatorStatus&Plan - -The Scheduler Subsystem maintains an Overall Status&Plan Faster data access

Distributed solution Subsystem Structuring Structure of Elevator Subsystem - -Similar to the centralized solution -Each Elevator subsystem contains a Local Elevator Status&Plan object

Distributed solution Task structuring

Distributed solution Task structuring

Distributed solution Subsystem Structuring Structure of Scheduler Subsystem - -Elevator Status&Plan Server Task -Elevator scheduler - -Receives Status and commitment messages - -Updates Overall Elevator Status&Plan - -Receives Service Requests messages

Distributed solution Subsystem Structuring

Design of information hiding classes - -Device Interface classes - -Data abstraction class(distributed) - -State Dependent class We design the operations of

> Floor Lamp Interface + initialize() +off() > Arrival Sensor Interface + initialize() + read(out sensorInput) Design of device interface classes Design of information hiding classes

Design of device interface classes > Motor Interface + initialize() + stop(out stopped) + up(out started) + down(out started) > Door Interface + initialize() + open(out opened) + close(out closed) Design of information hiding classes

Design of Data Abstraction Class > LocalElevator Status&Plan + arrived(elevator#,floor#,direction) + departed(elevator#,floor#,direction) + checkThisFloor(in elevator#,in floor#,out floor status, out direction) + checkNextDestination(in elevator,#out direction) + updatePlan(elevator#, floor#, direction,out idlestatus) Design of information hiding classes

Design of Data Abstraction Class > OverallElevator Status&Plan + arrived(elevator#,floor#,direction) + departed(elevator#,floor#,direction) + updatePlan(elevator#, floor#, direction,out idlestatus) + selectElevator(in floor#, out elevator#,in direction) Design of information hiding classes

Design of State Dependent Class > Elevator Control + processEvent(in event,out action) + currentStatus():Status Design of information hiding classes

Detailed Software Design Two main phases: - -Design of the connector objects - -Design of the composite tasks

Detailed Software Design Design of connector objects We introduce connectors to hide the details of message communication. The sender tasks should be unaware of the location of the receiver tasks Location transparency

Detailed Software Design Elevator subsystem Design of connector objects

Detailed Software Design Messages from Arrival Sensor Interface and Elevator Manager to Elevator controller never overlap-> We can use one message buffer instead of two We introduce three message queue connectors to hide the details of asynchronous(and possibly remote) communication Elevator subsystem Design of connector objects

Detailed Software Design Design of connector objects

Detailed Software Design Elevator Controller Task embeds - -Three output device interfaces - -One state dependent control object - -Two objects that provide synchronization Design of composite tasks

Detailed Software Design - -Each device interface object for an asynchronous I/O device is placed inside the task supporting that device - -Resource monitor tasks embed the passive I/O interfaces for the devices they operate Design of composite tasks

Detailed Software Design Design of composite tasks

Distributed solution System Configuration Target system configuration - -Instances of the component types are defined - -Component instances are interconnected - -Component instances are mapped to physical nodes

Distributed solution System Configuration A possible physical configuration - -One Elevator Subsystem for each elevator node - -One Floor Subsystem for each floor node

Distributed solution System Configuration

Definition Control Clustering criteria Another possible physical configuration - -All instances of the floor subsystem mapped to one node - -One Elevator Subsystem for each elevator node