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

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

3. 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

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

5. 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

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

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

8. 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

9. 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

10. 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

11. 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

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

13. Task structuring Elevator subsystem

14. «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.

15. 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

16. Centralized solution Task structuring

17. Centralized solution Task structuring

18. 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

19. 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

20. Define Task interfaces Task structuring

21. Define Task interfaces Task structuring

22. 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)

23. 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

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

25. Task structuring Distributed Solution

26. 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

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

28. 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

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

30. Distributed solution Task structuring

31. Distributed solution Task structuring

32. 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

33. Distributed solution Subsystem Structuring

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

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

36. 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

37. 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

38. 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

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

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

41. 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

42. Detailed Software Design Elevator subsystem Design of connector objects

43. 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

44. Detailed Software Design Design of connector objects

45. 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

46. 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

47. Detailed Software Design Design of composite tasks

48. 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

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

50. Distributed solution System Configuration

51. 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