Case Studies Elevator control Elevator control system system Comet case Comet case studies studies From task structuring to target From task structuring to target system configuration. system configuration.
Mar 31, 2015
Case Studies
Elevator control Elevator control systemsystem
Comet case Comet case studiesstudies
From task structuring to target From task structuring to target system configuration.system configuration.
Centralized solution
- Determine tasks for each subsystem
- Define task interfaces
- Design of data abstraction classes
Task structuring
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 subsystemTask structuring
Elevator button Interface
- Asynchronous input device interface criterionAsynchronous 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 ObjectStructured as a Coordinator Object
Task structuring Elevator subsystem
Elevator Status&Plan
-Passive data abstraction object -> Passive data abstraction object -> doesn’t need a separate thread of controldoesn’t need a separate thread of control
Task structuring Elevator subsystem
«state dependent control»
:ElevatorControl
«entity»
:ElevatorStatus&Plan
«coordinator»
:Scheduler
«output device interface»
:DirectionLampInterface
«external output device»
:FloorLamp
«output device interface»
:MotorInterface
«external output device»
:Motor
D10a: Departed (Floor#)
D10: Departed (Floor#)
D6a: Off Up Direction Lamp
D6: UpD9:
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 taskIt 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 doesn’t 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 doesn’t execute concurrently with Motor Interface and Door interface
Elevator Door
Opening
Elevator at Floor
Elevator Stopping
Elevator MovingEntry/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 inputdevice»
: FloorButton
Floor Button
Request «subsystem»: Scheduler
Floor LampOutput
«external outputdevice»
: DirectionLamp
Direction Lamp
Output
«input device interface»
:FloorButtonInterface
«output device interface»
:FloorLampInterface
«output device
interface»
:DirectionLampInterfac
e
«subsytem»:ElevatorSubsystem
ServiceRequest
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 solutionTask structuring
Centralized solutionTask structuring
<<resourcemonitor>>
:FloorLampsMonitor
<<resourcemonitor>>:Direction
LampsMonitor
<<asynchronousinput deviceinterface>>
:FloorButtonsInterface
<<data collectionsubsystem>>
:FloorSubsystem
ServiceRequest
DirectionLampOutput
FloorButton
Request
FloorLampOutput
<<coordinator>>:ElevatorManager
<<asynchronousinput deviceinterface>>
:ElevatorButtonsInterface
<<asynchronousinput deviceinterface>>
:ArrivalSensorsInterface
<<subsystem>>:Scheduler
<<dataabstraction>>
:ElevatorStatus&Plan
Check NextDestination
Check ThisFloor(Floor#)
Arrived(Floor #)
departed(Floor #)
NextDestination
ApproachingRequested
Floor
Elevator #
SelectElevator
ArrivalSensorInput
ElevatorButton
Request
SchedulerRequest
ElevatorCommittment
ElevatorRequest
ElevatorLamp
Output
FloorLamp
Command
DirectionLamp
Command
ApproachingFloor(Floor #)
<<control subsystem>>:ElevatorSubsystem
<<controlclustering>>
:ElevatorController
AckUpdate
Up,Down
DoorCommand
DoorResponse
MotorCommand
MotorResponse
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:
ElevatorElevator
RequestRequest<<asynchronous<<asynchronous
input device input device interface>>interface>>
:ElevatorButtonsInterface
<<coordinator>><<coordinator>>
:Elevator:Elevator
ManagerManager
ElevatorElevator
Request(Elevator#,floor#,direction)Request(Elevator#,floor#,direction)<<asynchronous<<asynchronous
input device input device interface>>interface>>
:ElevatorButtonsInterface
<<coordinator>><<coordinator>>
:Elevator:Elevator
ManagerManager
Define Task interfaces
Task structuring
<<resourcemonitor>>
:FloorLampsMonitor
<<resourcemonitor>>:Direction
LampsMonitor
<<asynchronousinput deviceinterface>>
:FloorButtonsInterface
<<data collectionsubsystem>>
:FloorSubsystem
ServiceRequest
(floor#,direction)
DirectionLampOutput
FloorButton
Request
FloorLampOutput
<<coordinator>>:ElevatorManager
<<asynchronousinput deviceinterface>>
:ElevatorButtonsInterface
<<asynchronousinput deviceinterface>>
:ArrivalSensorsInterface
<<subsystem>>:Scheduler
<<dataabstraction>>
:ElevatorStatus&Plan
ArrivalSensorInput
ElevatorButton
Request
ElevatorLampOutput
OffFloor Lamp(floor#,direction)
On/OffDirection Lamp(elevator#,floor#,direction)
ApproachingFloor(Elevator#,Floor #)
<<control subsystem>>:ElevatorSubsystem
<<controlclustering>>
:ElevatorController
Up,Down
Check NextDestination(inelevator out
direction)
Check This Floor(inElevator#,inFloor#,out
FloorStatus,outdirection)
Arrived(elevator#,Floor #,direction)
Departed(elevator#,Floor
#,direction)
MotorCommand(out
MotorResponse)
Door Command(outdoor response)
UpdatePlan(elevator#,Floor #,direction out
idleStatus)
SchedulerRequest
(elevator#,Floor#,direction)
SelectElevator(infloor#,in
direction,outelevator)
ElevatorCommittment
(elevator#,Floor #,direction)
Elevator Request(elevator#,Floor
#,direction)
Define Task interfaces
Task structuring
Design of Data Abstraction Class
Task structuring
<<data abstraction>>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-Subsystem Structuring -Design of Device Interface classes
-Design of information hiding Design of information hiding classesclasses
-Design of Device Interface classes-Design of State-Dependent classes
-Detailed software designDetailed software design-Design of Connector objects-Design of Composite Tasks
-Target system configurationTarget system configuration
Distributed solutionGeneral description
-Multiple nodes interconnected by a LAN
-No shared memory
Physical configuration:
-All communication is via loosely coupled messages
Task structuring Distributed Solution
<<coordinatorsubsystem>>
:Scheduler
<<controlsubsystem>>
:ElevatorSubsystem
<data collectionsubsystem>>
:FloorSubsystem
<<external outputdevice>>
:DirectionLamp
<<external inputdevice>>
:ArrivalSensor
<<controlsubsystem>>
:ElevatorSubsystem
<<external outputdevice>>
:Door
<<external outputdevice>>
:ElevatorLamp
<<external inputdevice>>
:FloorButton
<<external outputdevice>>
:Motor
<<external outputdevice>>
:FloorLamp
SchedulerRequest
Arrival(Floor #)
Departed(Floor #)
ElevatorCommitment
ArrivalSensorInput
ElevatorLampOutput
ElevatorButton
Request
Floor LampCommand
Direction LampCommand
DoorCommand
DoorResponse
Direction LampOutput
Floor LampOutput
FloorButton
Request
Motor Response
MotorCommand
ServiceRequest
<<system>>:Elevator
ControlSystem
Distributed solutionGeneral 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 solutionGeneral description
Server solution
-Clients access the ElevatorStatus&Plan with a synchronous message with reply
Risk of Bottleneck!
Distributed solutionGeneral 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 solutionSubsystem Structuring
Structure of Elevator Subsystem
-Similar to the centralized solution
-Each Elevator subsystem contains a Local Elevator Status&Plan object
Distributed solutionTask structuring
<<coordinator>>:ElevatorManager
<<controlclustering>>
:ElevatorController<<asynchronous
input device >>:ArrivalSensors
<<asynchronousinput device>>:ElevatorButton
<<asynchronousinput deviceinterface>>
:ElevatorButtonsInterface
<<asynchronousinput deviceinterface>>
:ArrivalSensorsInterface
<<passive outputdevice>>
:ElevatorLamp <<passive outputdevice>>
:Motor
<<passive outputdevice>>
:Door
<<subsystem>>:Scheduler
<<entity>>:LocalElevatorStat
us&Plan
Check NextDestination
Check ThisFloor(Floor#)
Arrived(Floor #)
departed(Floor#)
NextDestination
ApproachingRequested
Floor
DoorCommand
DoorResponse
Arrived(Floor #)
Departed(Floor #)
ArrivalSensorInput
ElevatorButton
Request
MotorCommand
MotorResponse
SchedulerRequest
ElevatorCommittment
ElevatorRequest
ElevatorLampOutput
Floor LampCommand
Direction Lamp Command
ApproachingFloor(Floor #)
<<control subsystem>>:ElevatorSubsystem
<<subsystem>>:FloorSubsystem
Distributed solutionTask structuring
<<coordinator>>:ElevatorManager
<<controlclustering>>
:ElevatorController<<asynchronous
input device >>:ArrivalSensors
<<asynchronousinput device>>:ElevatorButton
<<asynchronousinput deviceinterface>>
:ElevatorButtonsInterface
<<asynchronousinput deviceinterface>>
:ArrivalSensorsInterface
<<passive outputdevice>>
:ElevatorLamp <<passive outputdevice>>
:Motor
<<passive outputdevice>>
:Door
<<subsystem>>:Scheduler
<<entity>>:LocalElevatorStatus
&Plan
Check NextDestination(inelevator out
direction)
Check This Floor(inElevator#,inFloor#,out
FloorStatus,outdirection)
Arrived(elevator#,Floor #,direction)
Departed(elevator#,Floor
#,direction)
DoorCommand(out
doorresponse)
Arrived(elevator#,Floor
#,direction)
Departed(elevator#,Floor #,direction)
ArrivalSensorInput
ElevatorButton
Request
MotorCommand(out MotorResponse)
SchedulerRequest
(elevator#,Floor#,direction)
ElevatorCommittment
(elevator#,Floor
#,direction)
Elevator Request(elevator#,Floor
#,direction)
ElevatorLampOutput
offFloorLamp (Floor#,direction)
onDirection Lamp( Floor #,Elevator#,direction)
ApproachingFloor(elevator
#,Floor #)
<<control subsystem>>:ElevatorSubsystem
UpdatePlan(elevator#,Floor
#,direction outidleStatus)
Up(elevator #)
Down(elevator #)
<<subsystem>>:FloorSubsystem
Distributed solutionSubsystem 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 solutionSubsystem Structuring
Design of information hiding classes
-Device Interface classes
-Data abstraction class(distributed)
-State Dependent class
We design the operations of
<<Output Device interface>>Floor Lamp Interface
+ initialize()+off()
<<Output Device interface>>Arrival Sensor Interface
+ initialize()+ read(out sensorInput)
Design of device interface classes
Design of information hiding classes
Design of device interface classes
<<Output Device interface>>Motor Interface
+ initialize()+ stop(out stopped)+ up(out started)+ down(out started)
<<Output Device interface>>Door Interface
+ initialize()+ open(out opened)+ close(out closed)
Design of information hiding classes
Design of Data Abstraction Class
<<data abstraction>>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
<<data abstraction>>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
<<state dependent control>>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 DesignDesign 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 DesignDesign 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 DesignDesign of composite tasks
Distributed solutionSystem Configuration
Target system configuration
-Instances of the component types are defined
-Component instances are interconnected
-Component instances are mapped to physical nodes
Distributed solutionSystem Configuration
A possible physical configuration
-One Elevator Subsystem for each elevator node
-One Floor Subsystem for each floor node
Distributed solutionSystem Configuration
DefinitionControl Clustering criteria
Another possible physical configuration
-All instances of the floor subsystem mapped to one node
-One Elevator Subsystem for each elevator node