Koichiro Ochimizu, JAIST

Elevator Control System

Koichiro Ochimizu
School of Information Science
Japan Advanced Institute of Science and Technology

Exercises

• Elevator Control System

• Banking System
• Cruise Control and Monitoring System
• Distributed Factory Automation System
• Electronic Commerce System

Hassan Gomaa, “Designing Concurrent, Distributed,

and Real-Time Applications with UML”, Addison-
Wesley, Object Technology Series, 2000.

Elevator Control System 1

Koichiro Ochimizu, JAIST

COMET
User (Concurrent Object Modeling and
architectural design mEThod)
Requirements
Modeling

Analysis
Modeling
Design
Modeling Incremental
Throwaway Software
Prototyping Construction
Incremental
Software Customer
Integration
Incremental System
Prototyping Testing

2006/2/23

Activities of each Phase(1/2)

• Requirements Modeling functional requirements defined

by actors and use cases
• Analysis Modeling
Static model: structural relationships among problem
domain classes depicted on class diagrams,
Dynamic model: objects and their interactions depicted
on either collaboration diagrams or sequence diagrams.
The state-dependent aspects of the system are defined
using hierarchical statecharts (finite state machines).
• Design Modeling The software architecture of the system
is designed. The analysis model is mapped to an operational
environment. Subsystem structuring criteria are provided.

Elevator Control System 2

Koichiro Ochimizu, JAIST

Activities of each Phase(2/2)

• Incremental Software Construction Selecting a subset

of the system to be constructed for each increment. The
subset is determined by choosing the use cases to be
Included in this increment. Incremental software
construction consists of the detailed design, coding, and
unit testing of the classes in the subset.
• Incremental Software Integration the integration testing
of each increment is performed. Integration test cases are
developed for each use case. Interfaces between the objects
that participates in each use case are tested.
• System Testing testing the system against Its functional
requirements.

ＣＯＭＥＴ Process
• Problem Definition
‒ Problem Description
‒ Definition of Functional Requirements by a Use Case Diagram and Use Case
descriptions
• Analysis
‒ Static Modeling of objects in a problem domain.
‒ Dynamic Modeling in a problem domain
• Collaboration Diagrams
• State Charts
• Consolidated State Charts
• Consolidated Collaboration Diagram
• Architecture Design ( Distributed, Non Distributed)
‒ Subsystem Design
‒ Task Design
‒ Information Hiding Class Design
• Detailed Design
‒ Connectors Design
‒ Composite Task Design
‒ Deployment
• Performance Analysis
‒ Worst-case scenario analysis
• Programming (Incremental)

Elevator Control System 3

Koichiro Ochimizu, JAIST

Problem Description
• Definition of Functional Requirements by
Use Cases
• Describing a class diagram of real world
entities is recommended.

Problem Description 1..* 1..* 1

Floor Elevator Arrival
1 1..* Sensor

1,2 1,2 1..* 1,2

Floor Floor Direction
Button Lamp Lamp
1..* 1..* 1 1
Elevator Elevator
Motor Door
Button Lamp

123456789

12345
6789

elevator control
program

Elevator Control System 4

Koichiro Ochimizu, JAIST

Use Case Model

Select Destination

Arrival Sensor

Elevator User
Request Elevator

Use Case Description

• Use Case name: Select Destination
• Summary: The user in the elevator presses an up or down elevator button to select a destination
floor to which move
• Dependency
• Actor: Elevator User (primary), Arrival Sensor
• Precondition: User in the elevator
• Description:
– 1. User presses an up elevator button. The elevator button sensor sends the elevator button
request to the system, identifying the destination floor the user wishes to visit.
– 2. The new request is added to the list of floors to visit. If the elevator is stationary, The
system determines in which direction the system should move in order to service the next
request. The system commands the elevator door to close. When the door has closed, the
system commands the motor to start moving the elevator, either up or down.
– 3. As the elevator moves between floors, the arrival sensor detects that the elevator is
approaching a floor and notifies the system. The system checks whether the elevator should
stop at this floor. If so, the system commands the motor to stop. When the elevator has stopped,
the system commands the elevator door to open.
– If there are other outstanding requests, the elevator visits these floors on the way to the floor
requested by the user. Eventually, the elevator arrives at the destination floor selected by the
user.
• Alternatives:
– 1. User presses down elevator button to move down. System response is the same as for the
main sequence.
– 2. If the elevator is at a floor and there is no new floor to move to, the elevator stays at the
current floor, with the door open.
• Postcondition: Elevator has arrived at the destination floor selected by the user.

Elevator Control System 5

Koichiro Ochimizu, JAIST

Use Case Description

• Use Case name: Request Elevator
• Summary: The user at a floor presses an up or down floor button to request an elevator.
• Dependency
• Actor: Elevator User (primary), Arrival Sensor
• Precondition: User is at a floor and wants to an elevator
• Description:
– 1. User presses an up floor button. The floor button sensor sends the user request to the system,
identifying the floor number.
– 2. The system selects an elevator to visit this floor. The new request is added to the list of
floors to visit. If the elevator is stationary, The system determines in which direction the
system should move in order to service the next request. The system commands the elevator
door to close. After the door has closed, the system commands the motor to start moving the
elevator, either up or down.
– 3. As the elevator moves between floors, the arrival sensor detects that the elevator is
approaching a floor and notifies the system. The system checks whether the elevator should
stop at this floor. If so, the system commands the motor to stop. When the elevator has stopped,
the system commands the elevator door to open.
– If there are other outstanding requests, the elevator visits these floors on the way to the floor
requested by the user. Eventually, the elevator arrives at the floor in response to the user
request.
• Alternatives:
– 1. User presses floor button to move down. System response is the same as for the main
sequence.
– 2. If the elevator is at a floor and there is no new floor to move to, the elevator stays at the
current floor, with the door open.
• Postcondition: Elevator has arrived at the floor in response to user request.

Use case Model

Stop
Dispatch Elevator at
Elevator Floor
Arrival Sensor

<<include>> <<include>> <<include>> <<include>>

Request Elevator
Select Destination

Elevator User

Elevator Control System 6

Koichiro Ochimizu, JAIST

Use Case Description

• Use Case name: Select Destination
• Summary: The user in the elevator presses an up or down elevator button to select a
destination floor to which move
• Dependency
• Actor: Elevator User
• Precondition: User in the elevator
• Description:
– 1. User presses an up elevator button. The elevator button sensor sends the elevator
button request to the system, identifying the destination floor the user wishes to visit.
– 2. The new request is added to the list of floors to visit. If the elevator is stationary,
Include Dispatch Elevator abstract use.
– 3. Include Stop Elevator at Floor abstract use case.
– If there are other outstanding requests, the elevator visits these floors on the way to
the floor requested by the user, following the above sequence of dispatching and
stopping. Eventually, the elevator arrives at the destination floor selected by the user.
• Alternatives:
– 1. User presses down elevator button to move down. System response is the same as
for the main sequence.
– 2. If the elevator is at a floor and there is no new floor to move to, the elevator stays
at the current floor, with the door open.
• Postcondition: Elevator has arrived at the destination floor selected by the user.

Use Case Description

• Use Case name: Request Elevator
• Summary: The user at a floor presses an up or down floor button to request an
elevator.
• Dependency
• Actor: Elevator User
• Precondition: User is at a floor and wants to an elevator
• Description:
– 1. User presses an up floor button. The floor button sensor sends the user request to
the system, identifying the floor number.
– 2. The system selects an elevator to visit this floor. The new request is added to the
list of floors to visit. If the elevator is stationary, then include Dispatch Elevator
abstract use case.
– 3. Include Stop Elevator at Floor abstract use case.
– If there are other outstanding requests, the elevator visits these floors on the way to
the floor requested by the user following the above sequence of dispatching and
stopping. Eventually, the elevator arrives at the floor in response to the user request.
• Alternatives:
– 1. User presses floor button to move down. System response is the same as for the
main sequence.
– 2. If the elevator is at a floor and there is no new floor to move to, the elevator stays
at the current floor, with the door open.
• Postcondition: Elevator has arrived at the floor in response to user request.

Elevator Control System 7

Koichiro Ochimizu, JAIST

Use Case Description

• Use Case name: Stop Elevator at Floor abstract Use Case
• Summary:
• Dependency
• Actor: Arrival Sensor
• Precondition: Elevator is moving
• Description:
– As the elevator moves between floors, the arrival sensor detects that the elevator is
approaching a floor and notifies the system. The system checks whether the elevator should
stop at this floor. If so, the system commands the motor to stop. When the elevator has stopped,
the system commands the elevator door to open.
• Alternatives:
– The elevator is not required to stop at this floor and so continues past the floor.
• Postcondition: Elevator has stopped at floor, with door open.

Use Case Description

• Use Case name: Dispatch Elevator abstract use case
• Summary:
• Dependency
• Actor:
• Precondition: Elevator is at a floor with the door open.
• Description:
– The system determines in which direction the system should move in order to service the next
request. The system commands the elevator door to close. After the door has closed, the system
commands the motor to start moving the elevator, either up or down.
• Alternatives:
– If the elevator is at a floor and there is no new floor to move to, the elevator stays at the current
floor, with the door open.
• Postcondition: Elevator is moving in the commanded direction.

Elevator Control System 8

Koichiro Ochimizu, JAIST

Context Class Diagram

<<external input <<external output <<external input

device>> device>> device>>
ElevatorButton ElevatorLamp ArrivalSensor

1..* 1..* 1..*

1 1

<<external output <<system>> <<external output

device>> ElevatorControl 1 1..* device>>
1..* 1 System Door
Motor
1 1 1
1..*

<<external output 1..* <<external output 1..* <<external input

device>> device>> device>>
FloorLamp DirectionLamp FloorButton

Finding Analysis objects

• For every <<external input/output device>> object, there is
a corresponding software device interface object.
• Each elevator has a state-dependent control object called
Elevator Control, which control the elevator motor and
door.
• Because requests or the elevator can come at any time, a
decision is made to have a separate coordinator object,
called the Elevator Manager, to receive all incoming
requests for the elevator and to update the elevator plan.
• An entity object is needed for each elevator, which we call
Elevator Status & Plan.

Elevator Control System 9

Koichiro Ochimizu, JAIST

Collaboration Diagram
for Select Destination use case

E1: Ｅｌｅｖａｔｏｒ
Ｂｕｔｔｏｎ E2: Ｅｌｅｖａｔｏｒ E5: Ｅｌｅｖａｔｏｒ
Ｒｅｑｕｅｓｔ Ｒｅｑｕｅｓｔ Ｃｏｍｍｉｔｍｅｎｔ
<<input device <<coordinator>> <<coordinator>>
interface>>
：Elevator ：Scheduler
：Elevator
Button Interface Manager
:Elevator
User E5a: UP or Down

E3:Update E4: Acknowledge

<<state dependent
control>>
<<entity>> ：Elevator
：Elevator Control
Status&Plan

The message sequence description

• E1: The Elevator Button Request arrives at the Elevator Button
Interface object.
• E2: The Elevator Button Interface object sends the Elevator
Request to the Elevator Manager object.
• E3: The Elevator Manager sends the request to Elevator Status
& Plan, which adds the request to the list of floors to be visited.
• E4: The elevator plan is updated. An acknowledgement is
returned to the Elevator Manager object, which identifies
whether the elevator is idle.
• E5: The Elevator Manager sends an Elevator Commitment
message to the Scheduler, to inform it that this elevator is
committed to visit the given floor.
• E5a: If the Elevator is idle, the Elevator Manager sends an Up
(or Down) message to the Elevator Control object, directing it
to move in the desired direction. This case is handled by the
Dispatch Elevator use case.

Elevator Control System 10

Koichiro Ochimizu, JAIST

Collaboration Diagram
for Request Elevator use case

F1: Floor F2: Service F3: Scheduler

Button Request Request F4: Update
Request

<<input device <<coordinator>> <<entity>>

interface>> <<coordinator>>
：Elevator ：Elevator
：Floor ：Scheduler
Manager Status&Plan
ButtonInterface
: Elevator F5:
User F6: ElevatorCommitment Acknowledge

F6a: Up or Down

<<state dependent
control>>
：Elevator
Control

The message sequence description

• F1: The Floor Button Request arrives at the Floor Button
Interface object.
• F2: The Floor Button Interface object sends a Service Request to
the Scheduler object.
• F3: The Scheduler object selects an elevator and sends a
Scheduler Request to the Elevator Manager object in the selected
Elevator composite object.
• F4: The Elevator Manager object sends an Update message to
the Elevator Status & Plan to add the new request to the elevator
plan of which floor it is to visit.
• F5: An acknowledgement is returned to the Elevator Manager
object, which identifies whether the elevator is idle.
• F6: The Elevator Manager sends an Elevator Commitment
message to the Scheduler.
• F6a: If the elevator is idle, the Elevator Manager sends an Up (or
Down) message to the Elevator Control object, directing it to
move in the desired direction. This case is handled by the
Dispatch Elevator use case.

Elevator Control System 11

Koichiro Ochimizu, JAIST

Collaboration Diagram for Stop Elevator use case

<<external output <<external output <<external output

device>> device>> device>>
: DirectionLamp : ElevatorLamp : Motor

A5a.1:DirectionLamp A9a.1:ElevatorLamp A6: Stop Motor A7:Motor Response

output output
Command
<<output device <<output device <<output device
interface>> interface>> interface>>
: DirectionLamp : ElevatorLamp : Motor
Interface Interface A5:Stop
Interface
A5a:On
<<timer>> A14:After DirectionLamp A9a:Off A8:Elevator Stopped
(Timeout) ElevatorLamp
: DoorTimer A10:Open
A13:Start Door
A1:Arrival Timer
A9:Open Door Command
Sensor <<output device
Input <<input device A2:Approaching <<state depend
interface>> Floor(Floor#)） control>> interface>>
: ArrivalSensor : ElevatorControl : Door
A12:Door Interface
:Arrival Sensor Interface
Opened A11:Door
A4:Approaching Requested A3:Check This
Floor (Floor #) Response
Floor (Floor #, direction) A9c: Arrived( Floor #)
A9b:Arrived(Floor #)
A16:No Request A15:Check <<external output
Next Destination
<<coordinator>> device>>
<<entity>> : Scheduler : Door
: ElevatorStatus&Plan

The message sequence description

• A1: The Arrival Sensor Interface object receives an input from the arrival sensor
external entity.
• A2: The Arrival Sensor Interface object sends the floor number in the
Approaching Floor message to the Elevator Control object.
• A3: The Elevator Control object sends a Check This Floor message to the
Elevator Status & Plan object, which checks whether the floor at which the
elevator is arriving is one where it should stop.
• A4: As the elevator is arriving at a requested floor, the Elevator Status & Plan
object sends the Approaching Requested Floor message to the Elevator Control
object. The message contains the floor number and the future direction. On
receiving this message, Elevator Control transitions from Elevator Moving state
to Elevator Stopping state.
• A5: As a result of the transition to Elevator Stopping state, the Elevator Control
object commands the Motor Interface object to Stop.
• A5a(parallel sequence): Elevator Control sends an On Direction Lamp (with up
or down as a parameter) to the Direction Lamp Interface object, which switches
on the real-world direction lamp(A5a.1).
• A6: The Motor Interface object sends the Stop Motor Command to the real-
world motor.
• A7: The Motor Interface object receives the Motor Response.
• A8: Motor Interface object sends an Elevator Stopped message to the Elevator
Control object, which then transitions to Elevator Door opening state.

Elevator Control System 12

Koichiro Ochimizu, JAIST

The message sequence description

• A9: On transitioning to Elevator Door Opening state, the Elevator Control object
sends the Door Interface object a command to Open Door.
• A9a(parallel sequence because there are four actions associated with the state
transition): The Elevator Control object sends an Off Elevator Lamp message to
the Elevator Lamp Interface object, which then sends an Elevator Lamp Output
to the external lamp to switch it off(A9a.1).The Elevator Control object sends the
Arrived message to both the Elevator Status & Plan object( A9b, third parallel
sequence) and the Scheduler object(A9c, Fourth parallel sequence).
• A10: The Door Interface object sends the Open Door Command to the real world
door.
• A11: The Door Interface object receives the Door Response.
• A12: The Door Interface object sends a Door Opened message to the Elevator
Control object, which then transitions to Elevator at Floor
• A13: The Elevator Control object starts a timer.
• A14: A timer event is generated after a period of time equal to timeout, causing
the Elevator Control object to transition to Checking Next Destination state..
• A15: As a result of the transition, Elevator Control sends a Check Next
Destination message to the Elevator Status & Plan object. The objective is to
determine the next destination just prior to departure, in case there has been a
recent update to the plan. If the elevator does not have any outstanding requests,
it transitions to Elevator Idle state (event A16). Otherwise, use the Dispatch
Elevator use

Stop Elevator at Floor use case:

statechart for Elevator Control
A2:Approaching Floor
Elevator Moving /A3:Check This Floor

A4:Approaching Requested Floor / A5：Stop,

A5a1：On Direction Lamp

Elevator Stopping

A8: Elevator Stopped / A9：Open Door, A9a：

Off Elevator Lamp, A9b,A9c: Arrived

Elevator Door Opening

A12:Door Opened / A13: Start Timer

Elevator at Floor

A14: After( Timeout) /A15: Check Next Destination

Checking Next Elevator Idle

Destination A16: No Request

Elevator Control System 13

Koichiro Ochimizu, JAIST

Collaboration diagram for Dispatch Elevator use case

<<external output <<coordinator>>

device>> : Scheduler
: FloorLamp
D7:Start Up Motor Command
D2a.1:Floor D10a: Departed
Lamp Output (Floor #) <<output device
<<external output
interface>>
<<output device device>>
D2a:Off Up Floor Lamp : Motor
interface>> D6:Up : Motor
Interface
: FloorLamp
Interface D9:Elevator D8:Motor Response
<<state Started
D3:Close Door
dependent D2: Close Door Command
control>> <<output device
<<output device : Elevator
interface>> interface>>
Control : Door Interface
: DirectionLamp D5:Door Closed
Interface D6a:Off Up
Direction Lamp D4:Door Response
D6a.1:Direction D10:Departed ( Floor #)
D1: Up Request
Lamp Output <<external output
device>>
: Door
<<external output
device>>
: Direction Lamp <<entity>>
: Elevator Status&Plan

The message sequence description

• Starting preconditions are different for Dispatch Elevator.
– Stop Elevator at Floor is the first case. On entering Checking Next Destination
state, Elevator Control sends a Check Next Destination message to Elevator Status
& Plan . Elevator Status & Plan sends an Up Request ( or Down Request )
message to Elevator Control, informing it of the direction in which to move.
– Elevator Control object is in Elevator Idle state is the second case. Elevator
Manager receives a message from either the Scheduler or the Elevator Button
Interface with a request for the elevator to visit the floor. Elevator Manager sends
a message to Elevator Status & Plan to update the plan. If the elevator is busy
servicing a request, Elevator Status & Plan returns an Acknowledgement message
with a null parameter. On the other hand, if the elevator is idle, Elevator Status &
Plan returns an Acknowledgement message with an up (or down) parameter.
• D1: {Source object} sends Elevator Control an Up Request message. Elevator
Control transitions to Door Closing to Move Up state.
• D2: As a result of this state transition, there are two concurrent outputs events.
Elevator Control sends a Close Door command to Door Interface. On the
statechart, the Close door event (as well as one other output event ) is shown
as an entry action, because the Up Request event can arrive from either the
Elevator Idle state or the Checking Next Destination state.
• D2a( parallel sequence): Elevator Control sends an Off Up Floor Lamp to the
Floor Lamp Interface object, which switches off the real-world

Elevator Control System 14

Koichiro Ochimizu, JAIST

The message sequence description

• D3: Door Interface sends a Close Door Command to the real –
world door.
• D4: The real-world door sends a Door Response when the door is
closed.
• D5: The Door Interface sends a Door Closed message to Elevator
Control, which transitions to Elevator Starting Up state.
• D6: Elevator Control sends an Up Command to the Motor
Interface object.
• D6a: Elevator Control sends an Off Up Direction Lamp request to
the Direction Lamp Interface object, which switches off the
direction lamp.
• D7: The Motor Interface object sends the Start Up Motor
Command to the real-world motor.
• D8: The real-world motor sends a Motor Response when the
elevator has started moving upward.
• D9: The Motor Interface object sends an Elevator Started message
to Elevator Control, which transitions to Elevator Moving state.
• D10: Elevator Control sends a Departed message to both the
Elevator Status & Plan and Scheduler object.

Dispatch Elevator use case:

Statechart for Elevator Control

Elevator Idle

D1: Up Request Door Closing to Move Up

D1: Up Request
Entry/ D2:Close Door
, D2a:Off Up Floor Lamp

D5:Door Closed / D6：Up, D6a：Off Up Direction Lamp

Checking Next Elevator Starting Up

Destination
Elevator Moving

D9: Elevator Started Entry/ D10, D10a:Departed

Elevator Control System 15

Koichiro Ochimizu, JAIST

No Request
Elevator Idle StateChart for Elevator Control
Entry/ update idle status

Door Closing to Move Up Door Closing to Move Down

D1:Up Down
Entry/ D2:Close Door Request Request Entry/ Close Door
, D2a:Off Up Floor Lamp , Off Down Floor Lamp
A2:Approaching Floor
/A3:Check This Floor Door Closed / Down, Off
D5:Door Closed / D6：Up,
D6a：Off Up Direction Lamp Down Direction Lamp

Elevator Moving Elevator Starting Down

Elevator Starting Up
Entry/D10,D10a:Departed Elevator Started
D9: Elevator Started A4:Approaching Requested Floor /
A5：Stop, A5a1：On Direction Lamp

D1:Up Request Elevator Stopping Down Request

A8:Elevator Stopped / A9：Door Opened, A9a：

Off Elevator Lamp, A9b,A9c:Arrived

Elevator Door Opening

A12:Door Opened /A13:Start Timer

Elevator at Floor

A14:After(Timeout) /A15:Check Next Destination

Checking Next destination

Consolidated Collaboration
Diagram
• Consolidated Collaboration Diagram shows
all the objects that participate In the use
cases and all the interactions between these
objects.

Elevator Control System 16

Koichiro Ochimizu, JAIST

Consolidated
Collaboration Diagram <<output device <<output device
<<timer>>
: Door Timer interface>> interface>>
: ElevatorLamp : Motor
Floor Lamp
<<output device Floor Interface Interface
Output After Up
interface>> Lamp ( Timeout)
: FloorLamp Command Off Elevator Down Elevator Started
Interface Lamp Stop
Start Elevator Stopped Door
Direction Timer
Lamp Direction Command
<<output device <<state
Output Lamp Open Door Close Door <<output device
interface>> dependent
Command
: DirectionLamp control>> interface>>
Interface : Elevator : Door
Door Door
Control Interface
Opened Closed
Check Next
Door
<<input device Next Destination
Check This Floor (Floor #) Response
interface>> Destination
ArrivalSensor : ArrivalSensor Approaching
Input Approaching Arrived( Floor #)）
Interface Floor ( Floor #)
Requested
Floor Departed( Floor Arrived ( Floor #)
#)）
Up, Down
<<entity>>
: Elevator Status&Plan
Departed( Floor #)
Elevator Update Acknowledge
Button Elevator Floor
Interface Request Scheduler Service Button
Request Request <<input device Interface
<<input device <<coordinator>>
interface>> <<coordinator>> interface>>
: Elevator : FloorButton
: ElevatorButton : Scheduler
Manager Elevator Interface
Interface
Commitment

Subsystem Structuring
• Structuring Criterion: Principles ”high coupling
within a subsystem and low coupling between
subsystems”
– Aggregate/composite object: Geographical location：If
two objects could potentially be physically separated in
different locations, they should be in different
subsystems to reduce communication cost
– Clients and servers must be in separate subsystems
– User interface objects are usually clients
– A control objects and all the entity and interface objects
it directly controls should all be part of one subsystem

Elevator Control System 17

Koichiro Ochimizu, JAIST

Component and Node

• A distributed application is structured into distributed
subsystems
• A subsystem is designed as a configurable component and
corresponds to a logical node.
• Thus a subsystem component is defined as a collection of
concurrent tasks executing on one logical node.
• More than one subsystem component (logical node) may
execute on the same physical node.
• The term “component” will be used to refer to a logical
node and the term “node” will be used to refer to a
physical node.

Configurable Architectures and Software Components

• Configurable Architecture
– An important goal of software architecture for a distributed application is to provide
a concurrent message-based design that is highly configurable.
– In other words, the same software architecture should be capable of being mapped
to many different system configuration.
– Thus, a given application could be configured to have each subsystem allocated to
its own separate physical node, or alternatively to have all or some of its subsystem
allocated to the same physical node.
– The decision about mapping subsystems to physical nodes is not made at design
time, but is made later, at system configuration time.
• Distributed Component
– A distributed component is an active object with a well-defined interface.
– A component is usually a composite object composed of other objects
• Steps in Designing Distributed Applications
– System Decomposition
Subsystems are defined by applying subsystem structuring criteria. All
communication between subsystems must be restricted to message communication.
– Subsystem Decomposition
Tasks are defined by applying task structuring criteria to each subsystem.
– System Configuration
The components instances of the target system are defined, interconnected, and
mapped onto a hardware configuration consisting of distributed physical nodes.

Elevator Control System 18

Koichiro Ochimizu, JAIST

System Decomposition
• Consider the use-case-based collaboration diagrams, which
show the objects that communicate frequently with each
other. This is generally a good basis for subsystem
structuring because objects that communicate frequently with
each other are good candidates for being in the same
subsystem. The object depicted on several collaboration
diagrams can only be part of one subsystem.
• If one object is located at a geographically remote location
from another object, the two objects should be in different
subsystems ( for an example, clients and servers)
• Objects that are part of the same composite object should be
in the same subsystem.
• On the other hand, objects in a aggregate subsystem grouped
by functional similarity might span geographical boundaries

Distributed Component Configuration Criteria

• Proximity to the source of physical data
Provide proximity of the component to the source of physical data to
ensure fast access to the data, particularly important if data access rates are
high.
• Localized autonomy
The component controls a given aspect of the system to do a specific site-
related service.
• Performance
A real-time component can perform a time-critical service at a given node,
with non-real-time or less time-critical services performed elsewhere.
• Specialized Hardware
A component might need to reside on a particular node because it
supports special-purpose hardware like vector processors.
• User Interface
A component providing a user interface might run on a separate node.
• Server
A server component is often allocated its own node.

Elevator Control System 19

Koichiro Ochimizu, JAIST

Type of subsystems for concurrent, real-

time, or distributed application domains
• <<Control>>
The subsystem receives its inputs from the external environment and
generates outputs to the external, usually without any human
intervention. It includes at least one state-dependent control object. In
some case, some Inputs data might be gathered by some other
subsystem (s).
• <<Coordinator>>
In cases with more than one control subsystem, it is sometimes
necessary to have a coordinator subsystem that coordinates the control
subsystems.
• <<Data collection>>
A data collection subsystem collects data from the external
environment.
• <<Data analysis>>
A data analysis subsystem analyzes data and provides reports and/or
displays for data collected by another subsystem.

Type of subsystems for concurrent, real-

time, or distributed application domains
• <<Server>>
A server subsystem provides a service for other subsystems. In the
simplest case, a server object could consist of a single entity object.
• <<User interface>>
A user interface subsystem provides the user interface and acts as a
client. There may be more than one user interface subsystems. A user
interface subsystem is usually a composite object that is composed of
several simpler user interface objects.
• <<I/O subsystem>>
In some systems, grouping al the device interface classes into an I/O
subsystem might be useful, because developing device interface
classes is a specialized skill.
• <<System services>>
Certain services are not problem domain-specific but provide system-
level services, such as file management and network communication
management.

Elevator Control System 20

Koichiro Ochimizu, JAIST

Subsystem Structuring
<<timer>> <<output device <<output device
: Door Timer interface>> interface>>
: ElevatorLamp : Motor
Floor Lamp
<<output device Floor Interface Interface
Output After Up
interface>> Lamp ( Timeout)
: FloorLamp Command Off Elevator Down Elevator Started
Interface Lamp Stop
Start Elevator Stopped Door
Direction Timer
Lamp Direction Command
<<output device <<state
Output Lamp Open Door Close Door <<output device
interface>> dependent
Command
: DirectionLamp control>> interface>>
Interface : Elevator : Door
Door Door
Control Interface
Opened Closed
Check Next
Door
<<input device Next Destination
Check This Floor (Floor #) Response
interface>> Destination
ArrivalSensor : ArrivalSensor Approaching Arrived ( Floor #)
Input Approaching Arrived( Floor #)）
Interface Floor ( Floor #)
Requested
Floor Elevator Subsystem
Departed( Floor
#)） Floor Subsystem
Up, Down Scheduler Subsystem
<<entity>>
: Elevator Status&Plan
Departed( Floor #)
Elevator Update Acknowledge
Button Elevator Floor
Interface Request Scheduler Service Button
Request Request <<input device Interface
<<input device <<coordinator>>
interface>> <<coordinator>> interface>>
: Elevator : FloorButton
: ElevatorButton : Scheduler
Manager Elevator Interface
Interface
Commitment

Subsystem Structuring
<<timer>> <<output device <<output device
: Door Timer interface>> interface>>
: ElevatorLamp : Motor
Floor Lamp
<<output device Floor Interface Interface
Output After Up
interface>> Lamp
• Door
: FloorLamp Interface object,( Timeout)
Command Motor Interface
Off Elevator
object, Down Elevator Started
Elevator
Interface Lamp Interface objectLamp are the parts
Stop of
Start Elevator Stopped
Direction a Elevator composite Timer
object. Door
Direction Command
Lamp
<<output•Each elevator
device Lamp
needs an Elevator
<<state Control object,
Output dependent Open Door Close Door <<output device
an ElevatorCommand
interface>> Manager object, and an Elevator interface>>
: DirectionLamp control>>
Status & Plan object.
Interface : Elevator Door
: Door
• The Arrival Sensor Interface object is placed
Control Opened in theDoor
Closed
Interface

<<input Elevator
device Subsystem because
Next
it isCheck
moreNext
Destination tightly Door
Check This Floor (Floor #) Response
coupled with this subsystem(
interface>> Destination Stop Elevator use case)
ArrivalSensor : ArrivalSensor Approaching Arrived ( Floor #)
Input Approaching Arrived( Floor #)）
Interface Floor ( Floor #)
Requested
Floor Elevator Subsystem
Departed( Floor
#)） Floor Subsystem
Up, Down Scheduler Subsystem
<<entity>>
: Elevator Status&Plan
Departed( Floor #)
Elevator Update Acknowledge
Button Elevator Floor
Interface Request Scheduler Service Button
Request Request <<input device Interface
<<input device <<coordinator>>
interface>> <<coordinator>> interface>>
: Elevator : FloorButton
: ElevatorButton : Scheduler
Manager Elevator Interface
Interface
Commitment

Elevator Control System 21

Koichiro Ochimizu, JAIST

Floor
Lamp
<<control subsystem>> <<output device
<<external :Elevator Subsystem Motor
Output interface>> Command <<external
output <<output device
: Elevator Lamp output
device>>
：Elevator Interface interface>> device>>
: Motor ：Motor
Lamp
<<timer>> Off elevator Interface Motor
Floor Lamp : Door Timer After Response
(Timeout) Lamp Up
Command
Down Elevator Started Door Command
Direction Start Timer Stop Elevator Stopped
<<sub Lamp <<state Open
Close
<<external
system>> Command dependent Door
Door <<output device
output
：Floor control>> interface>>
Subsystem
device>>
Approaching : Elevator Door Door : Door ：Door
Opened Closed Interface
Floor( Floor #)） Control Door
Arrival Check Next Destination Response
Sensor Next
Input Check This Floor( Floor #)）
<<external <<input device Destination
input interface>> Approaching Arrived( Floor #)
device>> : Arrival Sensor Requested
：Arrival Arrived( Floor #）
Interface Floor Departed (Floor #)
Sensor
Departed( Floor #)
<<entity>>
Up, Down
: Elevator Status & Plan

Acknowledge Scheduler
Elevator Update Request
<<external Button
input Request <<sub
<<input device system>>
device>> <<coordinator>>
：Elevator
interface>> : Scheduler
: Elevator Button : Elevator manager
Button Elevator
Interface Elevator
Request
Commitment

Subsystem Structuring
<<timer>> <<output device <<output device
: Door Timer interface>> interface>>
: ElevatorLamp : Motor
Floor Lamp
<<output device Floor Interface Interface
Output After Up
interface>> Lamp ( Timeout)
: FloorLamp Command Off Elevator Down Elevator Started
Interface Lamp Stop
Start Elevator Stopped Door
Direction Timer
Lamp Direction Command
<<state
Output
<<output device •Floor
Lampsubsystem composite object Open Door Close Door <<output device
interface>> dependent
CommandFloor Lamp Interface object
consists
: DirectionLamp control>> interface>>
Interface and Floor Button: Elevator
Interface object. : Door
Door Door
Control Interface
• Direction Lamp Interface object Opened
Check Next
is Closed
Door
<<input device allocated toNext
the Floor subsystem,
Destination
Check This Floor (Floor #) Response
interface>> because Destination
ArrivalSensor : ArrivalSensor Approaching Arrived ( Floor #)
Input Approaching Arrived( Floor #)）
Interface Floor ( Floor #)
Requested
Floor Elevator Subsystem
Departed( Floor
#)） Floor Subsystem
Up, Down Scheduler Subsystem
<<entity>>
: Elevator Status&Plan
Departed( Floor #)
Elevator The Scheduler
UpdateAcknowledgecoordinator
Button
Interface
Elevator object Scheduler
is allocated to its own Service Floor
Request Button
subsystem,
Requestbecause it is Request <<input device Interface
<<input device <<coordinator>>
interface>> : Elevator
independent of the number
<<coordinator>> interface>>
: Scheduler : FloorButton
: ElevatorButton Manager of floors
Elevatorand elevators Interface
Interface
Commitment

Elevator Control System 22

Koichiro Ochimizu, JAIST

<<control subsystem>>
: FloorSubsystem
Floor
Button Service
<<external Request Request
input <<input device
device>> interface>>
：Arrival : FloorButton
<<subsystem>>
Sensor
Interface : Scheduler

Floor
Lamp Floor Lamp
Output Command
<<external <<output device
output interface>>
device>> : Floorlamp
：Floor <<subsystem>>
Lamp
Interface
: Elevator
Direction Control
Lamp
Direction
Output
Lamp
<<external <<output device Command
output interface>>
device>> : DirectionLamp
：Direction
Lamp
Interface

Subsystems
<<external input <<external output <<external input
device>> device>> device>>
：Elevator Button ：Elevator Lamp ：Arrival Sensor

Elevator Button Interface Elevator Lamp Arrival Sensor Input

Output
Motor
Command <system>> : Door
Command
Elevator Control <<control <<external
<<external output System
subsystem>> output
device>> ：Elevator Subsystem device>>
：Motor Motor Scheduler ：Door
Door
Response Floor Lamp Command Arrival (Floor#） Request Response
Direction Lamp Departed (Floor #)
Command
Floor Elevator Commitment
Button
<<external input Request <<data collection <<coordinator
device>> subsystem>> subsystem>>
：Floor Button ：Floor Subsystem Service ：Scheduler
Request

Floor Lamp Output Direction Lamp Output

<<external output <<external output

device>> device>>
：Floor Lamp ：Direction Lamp

Elevator Control System 23

Koichiro Ochimizu, JAIST

Refined Static Model (Class Diagram ) for Elevator Control System

<<control subsystem>> ElevatorSubsystem
<<output device <<output device <<output device <<input device
interface>> interface>> interface>> interface>>
Door Elevator Lamp Motor Elevator Button
Interface Interface Interface Interface
1 1 1..*
1..* Requests
Controls Controls Controls
1
1
<<input device 1 1 1
Commands <<coordinator>> 1..*
interface>> 1..* 1 Elevator
Arrival Sensor <<state dependent control>> 1 1 Requests
Manager
Interface Notifies Elevator Control 1 Updates,
1 1..*
Notifies Checks
1 1..* 1..* 1..* 1 1Updates
<<timer>> 1 <<entity>>
Door Timer Elevator Status&Plan
Controls Controls Notifies

* * Updates
* 1 1

<<data collection subsystem>> FloorSubsystem <<coordinator subsystem>> Scheduler

1..* 1..* <<server>> 1 Updates
1 1
<<output device <<input device <<output device * 1 Elevator
Status & Plan
interface>> interface>> interface>> <<entity>>
Server
Direction Lamp Floor Button Floor Lamp Overall Elevator
Interface Interface Interface 1 1 Status & Plan
<<coordinator>>
1 Elevator Scheduler Selects
1
1..*
Requests

Task Structuring
• Design task structure and task interface by applying the
following task structuring criteria to problem domain
objects recognized as an consolidated collaboration
diagram.
‒ I/O task structuring criteria
Criteria to decide whether each device interface object is an
active object or not, considering the properties: interrupt-driven,
polling, communication, discrete data or analog data Criteria to
‒ Internal task structuring criteria make the
objects ( in a
Criteria to decide whether each internal object is an active object consolidated
or not, considering the properties: period, asynchronous, control, collaboration
UI. diagram )
‒ Task priority criteria active objects

Criteria to decide whether each internal object is an active object

or not, considering the properties: time-critical, computation
( CPU bound). Criteria to
‒ Task clustering criteria group the active
objects to
Criteria to group active objects selected by the above criteria, reduce the
considering properties: time, sequencing, control, mutual number of tasks
exclusion..

Elevator Control System 24

Koichiro Ochimizu, JAIST

Task Structuring Criteria (Outline)

• I/O task structuring criteria
– Asynchronous I/O Device Interface tasks
– Periodic I/O Device Interface tasks
– Passive I/O Device Interface tasks
– Resource Monitor tasks
• Internal task structuring criteria
‒ Periodic Tasks
‒ Asynchronous tasks
‒ Control tasks
‒ User Interface tasks
• Task priority criteria
‒ Time-Critical tasks
‒ Non-Time-Critical Computationally Intensive tasks
• Task clustering criteria
‒ Temporal Clustering
‒ Sequential Clustering
‒ Control Clustering
‒ Mutually Exclusive Clustering

I/O Task Structuring Criteria

Necessary to determine the hardware characteristics of the
I/O device that interface to the system, and the nature of the
data being input to the system to these devices.
‒ Asynchronous (active) I/O devices:
Asynchronous I/O device interface task is needed because the task is
activated by an interrupt from the asynchronous device.
‒ Periodic I/O Device Interface Tasks:
The task is activated by a timer event periodically, e.g. sensor-based
periodic I/O device interface tasks.
‒ Passive I/O Devices Interface Tasks:
The task is used when it is considered desirable to overlap
computation with I/O.
‒ Resource Monitor Task:
An input or output device that receives requests from multiple
sources should have a resource monitor task to coordinate these
requests, even if the device is passive. A resource monitor task has
to sequence these requests so as to maintain data integrity and
ensure that no data is corrupted or lost.

Elevator Control System 25

Koichiro Ochimizu, JAIST

Internal Task Structuring Criteria

• Periodic Tasks
An activity that needs to be executed periodically ( i.e. at
regular, equally spaced intervals of time) is structured as a
separate periodic task. The task is activated by a timer
event, performs the periodic activity.
• Asynchronous Tasks
The demand-driven( the arrival of internal messages or
events) activities are typically handled by means of
asynchronous tasks.
• Control Tasks
A task that executes a sequential state-chart is referred to as
a control task.
• User Interface Tasks
A user typically performs a set of sequential operations,
this can be handled by a use Interface task.

Task Priority Criteria

• Time-Critical Tasks
high priority. Asynchronous interrupt-
driven I/O task.
• Non-Time-Critical Computationally
Intensive Tasks
low priority, CPU bound task

Elevator Control System 26

Koichiro Ochimizu, JAIST

Task Clustering Criteria(1/3)

Reduce the number of tasks
• Temporal Clustering
Certain candidate tasks may be activated by the same
event, e.g. a timer event. If there is no sequential
dependency between the candidate tasks, they may be
grouped into the same task, based on the temporal
clustering. Some tradeoffs need to be considered.
‒ If some candidate task is more time critical than the others, the task
should not be combined.
‒ If two candidate tasks could be executed on separate processors,
they should not be combined.
‒ Preference should be given in temporal clustering to tasks that are
functionally related and likely to be of equal importance from a
scheduling viewpoint.
‒ Two tasks with different periods may not be clustered.

Task Clustering Criteria(2/3)

Reduce the number of tasks
• Sequential Clustering
The first candidate task is triggered by an asynchronous
or periodic event and the other are then executed
sequentially after it. These sequentially dependent
candidate tasks may be grouped. But,
‒ If the last candidate task in a sequence does not send an
inter-task message, this terminates the group of tasks to
be considered for sequential clustering.
‒ If the next candidate task in the sequence also receives
inputs from another source and therefore can be
activated by receiving input from that source, this
candidate task should be left as a separate task.
‒ If the next candidate task in sequence is of a lower
priority, they should be kept as separate task.

Elevator Control System 27

Koichiro Ochimizu, JAIST

Task Clustering Criteria(3/3)

Reduce the number of tasks
• Control Clustering
A control object, which executes a sequential state-chart,
is mapped to a control task.
‒ The actions activated during state transition are
executed within the thread of control of the
control object.
‒ The activity should be structured as a separate
task.
• Mutually Exclusive Clustering
Mutually exclusive tasks may be clustered.

Elevator Control System 28

Koichiro Ochimizu, JAIST

Non-Distributed Solution
• The Elevator Control System is mapped to a single CPU or
tightly coupled multiprocessor configuration
• The Elevator Status & Plan entity object is accessible to all
elevators as well as scheduler, so that one centralized
repository of data can be used

Floor
Lamp
<<control subsystem>> <<output device
<<external :Elevator Subsystem Motor
Output interface>> Command <<external
output <<output device
: Elevator Lamp output
device>>
：Elevator Interface interface>> device>>
: Motor ：Motor
Lamp
<<timer>> Off elevator Interface Motor
Floor Lamp : Door Timer After Response
(Timeout) Lamp Up
Command
Down Elevator Started Door Command
Direction Start Timer Stop Elevator Stopped
<<sub Lamp <<state Open
Close
<<external
system>> Command dependent Door
Door <<output device
output
：Floor control>> interface>>
Subsystem
device>>
Approaching : Elevator Door Door : Door ：Door
Opened Closed Interface
Floor( Floor #)） Control Door
Arrival
Sensor
The objects “Elevator Button Interface”
Check Next Destination Response
Next
<<external Input
<<input device Destination andCheck
“Arrival
This Floor(Sensor
Floor #)） Interface” are

input structured
interface>> Approaching Arrived( Floor #) separate task respectively,
as a
device>> : Arrival Sensor Requested
：Arrival
Interface Floor based on the asynchronous Arrived( Floor #）input device
Sensor Departed (Floor #)
interface task structuring criterion
Departed( Floor #)
<<entity>>
Up, Down : Elevator Status & Plan

Acknowledge Scheduler
Elevator Update Request
<<external Button
input Request <<sub
<<input device system>>
device>> <<coordinator>>
：Elevator
interface>> : Scheduler
: Elevator Button : Elevator manager
Button Elevator
Interface Elevator
Request
Commitment

Elevator Control System 29

Koichiro Ochimizu, JAIST

Floor
Lamp
<<control subsystem>> <<output device
<<external :Elevator Subsystem Motor
Output interface>> Command <<external
output <<output device
: Elevator Lamp output
device>>
：Elevator Interface interface>> device>>
: Motor ：Motor
Lamp
<<timer>> Off elevator Interface Motor
Floor Lamp : Door Timer After Response
(Timeout) Lamp Up
Command
Down Elevator Started Door Command
Direction Start Timer Stop Elevator Stopped
<<sub Lamp <<state Open
Close
<<external
system>> Command dependent Door
Door <<output device
output
：Floor control>> interface>>
Subsystem
device>>
Approaching : Elevator Door Door : Door ：Door
Opened Closed Interface
Floor( Floor #)） Control Door
Arrival Check Next Destination Response
Sensor Next
Input Check This Floor( Floor #)）
<<external <<input device Destination
input interface>> Approaching Arrived( Floor #)
device>> : Arrival Sensor Requested
：Arrival Arrived( Floor #）
Interface Floor Departed (Floor #)
Sensor
Each ”Elevator Control Object” is
Departed( Floor #)

Up, Down
mapped to a separate “Elevator
<<entity>>
: Elevator Status & Plan
Controller” task.
Acknowledge Scheduler
Elevator Update Request
<<external Button
input Request <<sub
<<input device system>>
device>> <<coordinator>>
：Elevator
interface>> : Scheduler
: Elevator Button : Elevator manager
Button Elevator
Interface Elevator
Request
Commitment

Floor
Lamp
<<control subsystem>> <<output device
<<external :Elevator Subsystem Motor
Output interface>> Command <<external
output <<output device
: Elevator Lamp output
device>>
：Elevator Interface interface>> device>>
: Motor ：Motor
Lamp
<<timer>> Off elevator Interface Motor
Floor Lamp : Door Timer After Response
(Timeout) Lamp Up
Command
Down Elevator Started Door Command
Direction Start Timer Stop Elevator Stopped
<<sub Lamp <<state Open
Close
<<external
system>> Command dependent Door
Door <<output device
output
：Floor control>> interface>>
Subsystem
device>>
Approaching : Elevator Door Door : Door ：Door
Opened Closed Interface
Floor( Floor #)） Control Door
Arrival Check Next Destination Response
Sensor Next
Input Check This Floor( Floor #)）
<<external <<input device Destination
input interface>> Approaching Arrived( Floor #)
device>> : Arrival Sensor Requested
：Arrival Arrived( Floor #）
Interface Floor Departed (Floor #)
Sensor
Departed( Floor #)
<<entity>>
Up, Down : Elevator Status & Plan
The “Elevator Controller” task is combined with
Elevator
“Motor Interface” and “DoorAcknowledge
Interface” objects, Scheduler
Update Request
<<external Button based on the control clustering criterion.
input Request <<sub
<<input device system>>
device>> <<coordinator>>
：Elevator
interface>> : Scheduler
: Elevator Button : Elevator manager
Button Elevator
Interface Elevator
Request
Commitment

Elevator Control System 30

Koichiro Ochimizu, JAIST

Floor
Lamp
<<control subsystem>> <<output device
<<external :Elevator Subsystem Motor
Output interface>> Command <<external
output <<output device
: Elevator Lamp output
device>>
：Elevator Interface interface>> device>>
Lamp
The “Elevator Manager (one instance in the : Motor ：Motor
<<timer>> solution) executes
non-distributed Offasynchronously
elevator Interface Motor
Floor Lamp : Door Timer After Response
Lamp Up
Command with the “Elevator Controller”
(Timeout) task. The “Elevator Elevator Started
Down Door Command
Manager Start
Direction
is structured
Timer as a separate coordinate
Stop task.
Elevator Stopped
<<sub Lamp <<state Open
Close
<<external
system>> Command dependent Door
Door <<output device
output
：Floor control>> interface>>
Subsystem
device>>
Approaching : Elevator Door Door : Door ：Door
Opened Closed Interface
Floor( Floor #)） Control Door
Arrival Check Next Destination Response
Sensor Next
Input Check This Floor( Floor #)）
<<external <<input device Destination
input interface>> Approaching Arrived( Floor #)
device>> : Arrival Sensor Requested
：Arrival Arrived( Floor #）
Interface Floor Departed (Floor #)
Sensor
Departed( Floor #)
<<entity>>
Up, Down
: Elevator Status & Plan

Acknowledge Scheduler
Elevator Update Request
<<external Button
input Request <<sub
<<input device system>>
device>> <<coordinator>>
：Elevator
interface>> : Scheduler
: Elevator Button : Elevator manager
Button Elevator
Interface Elevator
Request
Commitment

Task Architecture
(Non-distributed Elevator Control System)
Elevator Lamp Output

<<control subsystem>> Door Command <<data collection

：Elevator Subsystem <<control subsystem>>
:Floor Subsystem
clustering>> Door
: Elevator Floor Lamp
Approaching Response Command Floor
Floor (Floor #) Controller <<resource
Lamp
Arrival Sensor Check Next monitor>> Output
Input Next Destination : Floor Lamp
Check This Floor ( Floor #) Direction Lamp
<<asynchronous Destination Monitor
Command
input device Approaching Arrived (Floor #)
interface>> Requested
: Arrival Sensor Floor Departed (Floor #) <<resource Direction
Interface monitor>> Lamp
<<data abstraction>> : Direction Lamp Output
Up, Down : Elevator Status&Plan Monitor
Select Elevator
Elevator #
Elevator Button Acknowledge
Request Update
<<asynchronous Schedule <<asynchronous Floor
input device Request input device Button
<<coordinator>> <<co interface>> Request
interface>> : Elevator ordinator>> : Floor Button
: Elevator Button Manager
Elevator Elevator : Scheduler Interface
Interface
Request Commitment

Service Request

Elevator Control System 31

Koichiro Ochimizu, JAIST

Task Interface
( Non-distributed Elevator Control System)
Elevator Lamp Output

doorCommand( out
doorResponse)
<<control subsystem>> <<data collection
：Elevator Subsystem <<control subsystem>>
: Floor Subsystem
clustering>> offFloorLamp
: Elevator ( floor#,
ApproachingFloor(
Controller direction) <<resource floor
elevator#, floor#) Lamp
arrival monitor>>
checkNextDestination( in Output
Sensor elevator#, out direction)
offDirectionLam : Floor Lamp
p(elevator#, Monitor
Input <<asynchronous floor#, direction)
checkThisFloor( in elevator#, in
input device floor#, out floorStatus, out direction)
interface>> arrived(elevator#, floor#, direction)
: Arrival Sensor onDirectionLam <<resource direction
departed(elevator#, floor#, direction) Lamp
Interface p(elevator#, monitor>>
<<data abstraction>>
floor#, direction) : Direction Lamp Output
up(elevator#), : Elevator Status & Plan selectElevator( in Monitor
floor#, in
down(elevator#) updatePlan(el
direction, out
evator#,floor# schedulerReque
elevator#)
elevator ,direction, out st( elevator#,
<<asynchronous idleStatus) floor#, <<asynchronous
Button
Request input device direction) input device floor
<<coordinator>> <<co Button
interface>> interface>> Request
: Elevator ordinator>> : Floor Button
: Elevator Button elevatorRequ Manager
est(elevator#, elevatorCommit : Scheduler Interface
Interface
floor#, ment( elevator#,
direction) floor#, direction)
serviceRequest(floor#, direction)

Data Abstraction Classes

<< data abstraction>>
ElevatorStatus&Plan

+ arrived(elevator#, floor#, direction)

+ departed(elevator#, floor#, direction)
+ checkThisFloor( in elevator#, in floor#, out floorStatus, out direction)
+ checkNextDestination( in elevator#, out direction)
+ updatePlan(elevator#, floor#, direction, out idleStatus)
+selectElevator( in floor#, in direction, out elevator#)

Data abstraction class for centralized solution

Elevator Control System 32

Koichiro Ochimizu, JAIST

Distributed Elevator Control System

• The physical configuration consists of multiple nodes interconnected by a
local area network.
• Multiple instances of the Elevator Subsystem (one instance per elevator)
• Multiple instances of the Floor Subsystem (one instance per floor)
• One instance of the Scheduler subsystem
• All communication between the subsystems is via loosely coupled message
communication.
• There is no shared memory in a distributed configuration; thus the
Scheduler and multiple instances of the Elevator Subsystem can
not directly access the Elevator Status & Plan data abstraction object.
• Client-Server solution presents the potential danger of crating a bottleneck at
this server. Instead, an alternative solution is to use replicated data. Each
instance of the Elevator Subsystem maintains its own local instance of the
Elevator Status & Plan, called Local Elevator Status & Plan. The scheduler
also maintains a copy of the Elevator Status & Plan, called Overall Elevator
Status & Plan.

Distributed Elevator Control System

Deployment Diagram

：Elevator Subsystem
{1 node per elevator}

<< local area network >>

：Floor Subsystem ：Scheduler

{1 node per floor} {1 node}

Elevator Control System 33

Koichiro Ochimizu, JAIST

Distributed Software Architecture

<<external input <<external output <<external input
device>> device>> device>>
：Elevator Button ：Elevator Lamp ：Arrival Sensor

Elevator
Elevator Button Request Lamp Output Arrival Sensor Input

Motor Command Door

<system>> : Command <<external
ElevatorControl <<control
<<external output System subsystem>> output
device>> ：ElevatorSubsystem device>>
：Motor Floor Lamp Scheduler ：Door
Door
Command Arrived (Floor #） Request Response
Motor Response
Direction Lamp Departed( Floor #)
Command Elevator
Floor
Button Commitment
<<external input Request <<data collection <<coordinator
device>> subsystem>> subsystem>>
：FloorButton ：FloorSubsystem Service ：Scheduler
Request

Floor Lamp Output Direction Lamp Output

<<external output <<external output

device>> device>>
：FloorLamp ：方向ランプ

Task Architecture ( Distributed )

Motor Command
Elevator Lamp Output
Motor Response

<<control subsystem>> Door Command <<data collection

：Elevator Subsystem <<control subsystem>>
:Floor Subsystem
clustering>>
Approaching Floor : Elevator Door FloorLamp Floor
( Floor #)） Controller Response Command <<resource Lamp
Arrival
Sensor Check Next monitor>> Output
Input Destination : Floor Lamp
Next Direction Lamp
<<asynchronous Monitor
Destination Check This Floor ( Floor # ) Command
input device Arrived ( Floor #)
Approaching
interface>>
Requested <<resource
: Arrival Sensors Departed ( Floor #) Direction
Floor
Interface monitor>> Lamp
Arrived ( Floor #) : Direction Lamp Output
<<data abstraction>>
Up, Down : Local Elevator Status & Plan Monitor
Departed ( Floor #)
Acknowledge
Elevator Update
<<asynchronous Scheduler <<asynchronous Floor
Button
Request input device Request input device Button
<<coordinator>> interface>> Request
interface>> : Elevator <<subsystem>>
: Elevator Buttons : Scheduler : Floor Button
Elevator Manager Interface
Interface Elevator
Request Commitment

Service Request

Elevator Control System 34

Koichiro Ochimizu, JAIST

Task Architecture of Scheduler Subsystem

Arrive departe
d(eleva d(eleva <<coordinator subsystem>>
tor#,flo tor#,flo :Scheduler
or#,dir or#,dir
ection) ection)

<<server>>
: Elevator Arrived, Departed
Status & Plan Server

Elevator Update Plan

Commitment
<<data abstraction>> <<subsystem>>
: Overall : Elevator
Elevator Status&Plan Subsystem

Select Elevator
Service Elevator #
Request
<<subsystem>> <<coordinator>>
: Floor Subsystem : Elevator Scheduler

Scheduler request

Performance Analysis of Non- Distributed

Elevator Control System
• A building with 10 floors and three elevators10
• The Worst-Case Scenario
– Elevator button interrupts arrive with a maximum frequency of 10
times a second, which represents a minimum inter-arrival time of 100
msec. This worst-case scenario assumes that all 30 buttons are pressed
within 3 seconds.
– Floor button interrupts arrive with a maximum frequency of 5 times a
second, which represents a minimum inter-arrival time of 200 msec.
There are 18 floor buttons (2×8＋1＋1). This worst-case scenario
assumes that all 30 buttons are pressed within 3 seconds.
– All three elevators are in motion and arrive at floors simultaneously.
Three floor-arrival interrupts arrive within 50 msec of each other. This
is the most time-critical aspect of the probem, because when a floor
arrival interrupt is received, the Elevator Controller has to determine
whether the elevator should stop at this floor or not. If it need to stop,
the controller must stop the elevator before the floor has been past.
– Related usecases are “Select Destination”, “Request Elevator”, and
“Stop Elevator at Floor”.

Elevator Control System 35

Koichiro Ochimizu, JAIST

Event Sequences in Three UseCases

• Stop Elevator at Floor (Period = Ta)
– A1: The Arrival Sensors Interface receives and
process the interrupt
– A2: The Arrival Sensors Interface sends
“approaching Floor” message to the Elevator
Controller.
– A3: The Elevator Controller receives message and
checks the Elevator Status & Plan object to
determine whether the elevator should stop or not.
– A4: The Elevator Controller invokes “stop Motor”
operation if it should stop.

Event Sequences in Three UseCases

• Select Destination (Period = Tb)
– E1: The Elevator Buttons Interface receives and
processes the interrupt.
– E2: The Elevator Buttons Interface sends “elevator
Request” message to the Elevator Manager.
– E3: The Elevator Manager receives message and
records destination in Elevator Status & Plan object.

Elevator Control System 36

Koichiro Ochimizu, JAIST

Event Sequences in Three UseCases

• Request Elevator (Period = Tc)
– F1: The Floor Buttons Interface receives and processes the
interrupt.
– F2: The Floor Buttons Interface sends “service Request”
message to the Scheduler.
– F3: The Scheduler receives message and interrogates
Elevator Status & Plan object to determine whether an
elevator is on its way to this floor. Assume not, so that the
Scheduler selects an elevator.
– F4: The Scheduler sends a “scheduler Request” message
identifying the selected elevator to the Elevator Manager.
– F5: The Elevator Manager receives message and records
destination in Elevator Status & Plan object.

Task Parameters
Task CPU time Ci Period Ti Utilization Ui Assigned
Stop Elevator at Floor Priority

Arrival Sensors Interface 2 50 0.04 1

Elevator Controller 5 50 0.10 4

Total elapsed time = 34 msec Total utilization = 0.68
Select Destination

Elevator Buttons Interface 3 100 0.03 2

Elevator Manager( Case b) 6 100 0.06 5
Total elapsed time = 47 msec Total utilization = 0.47
Request Elevator

Floor Buttons Interface 4 200 0.02 3

Scheduler 20 200 0.10 6
Elevator Manager( Case c) 6 200 0.03
Total elapsed time = 76msec Total utilization = 0.38
Other Tasks

Floor Lamps Monitor 5 500 0.01 7

Direction Lamps Monitor 5 500 0.01 8

Elevator Control System 37

Koichiro Ochimizu, JAIST

Time-annotated sequence diagram

：Arrival ：Elevator ：Floor
：Elevator ：Elevator
Sensor Button Button ：Scheduler
Controller Manager
Interface Interface Interface

0
2 A2: approaching Floor
2
3 E2: Elevator Request
6
4 F2: service Request
10
5
14
6
18 F4: scheduler Request
20
∼
∼ 20 ∼
∼
40

6
46
50

Result of Analysis(1/3)
• Stop elevator at Floor (Ta=50msec)
‒ Execution time: Total execution time Ca＝2msec
(Arrival Sensors Interface)+5msec (Elevator
Controller). Execution utilization Ue=Ca/Ta=7/50=0.14
‒ Preemption by higher priority tasks: Total preemption
time Pa=3 (Elevator Buttons Interface)+4(Floor Buttons
Interface)=7msec。Preemption utilization Up=Pa/Ta
=7/50=0.14
‒ Blocking time: Total worst-case blocking time Ba=
20msec (Scheduler). Worst-blocking utilization Ub =
Ba/Ta=20/50=0.40
‒ Total Utilization= Ue+Up+Ub=0.14+0.14+0.40=0.68

Elevator Control System 38

Koichiro Ochimizu, JAIST

Result of Analysis(2/3)
• Select Destination (Tb=100msec)
‒ Execution time: Total execution time Cb＝3msec (Elevator
Buttons Interface)＋6msec(Elevator Manager). Execution
Utilization Ue=Ca/Ta=9/100=0.09
‒ Preemption by higher priority tasks with shorter periods: Arrival
Sensors Interface and Elevator Controller (preempts Elevator
Manager) can each execute twice during 100 msec period, giving a
preemption time of 14 msec.
‒ Preemption by higher priority tasks with longer periods: 4 msec
from Floor Buttons Interface to handle floor Button interrupt.
‒ Total preemption time Cp=14+4=18 。Total preemption
utilization Up= Cp/Tb = 18/100 = 0.18
‒ Blocking time: Worst-case blocking time Ba= 20msec (Scheduler).
Worst-case blocking utilization Ub = Bb/Tb=20/100=0.20
‒ Total Utilization= Ue+Up+Ub=0.09+0.18+0.20=0.47

Results of Analysis(3/3)
• Request Elevator (Tc=200msec)
‒ Execution time: Total execution time Cc＝4msec (Floor Buttons
Interface)＋20msec(Scheduler)＋6msec(Elevator Manager).
Execution utilization Ue=Cc/Ta=30/200=0.15
‒ Preemption by higher priority tasks with shorter periods: Arrival
Sensors Interface and Elevator Controller (preempts Elevator
Manager and Scheduler) can each execute four times for a total of
28 msec.
‒ Total preemption time Cp=28+18=46. Preemption utilization
Up=Cp/Tp=0.23
‒ Total elapsed time=30+46+0=76
‒ Total Utilization= Ue+Up=0.15+0.23=0.38

Elevator Control System 39

Koichiro Ochimizu, JAIST

Performance Analysis of Distributed

Elevator Control System
• one node per elevator, one node per floor, one
scheduler node.
• 40 floors and 12 elevators

Task Parameters
Task CPUtime Ci Period Ti Utilization Ui Assigned Priority
Elevator Subsystem

Arrival Sensors Interface 2 50 0.04 1

Elevator Controller 5 50 0.10 3

Elevator Buttons Interface 3 100 0.03 2

Elevator Manager 6 100 0.06 4
Floor Subsystem

Floor Buttons Interface 4 200 0.02 1

Floor Lamps Monitor 5 500 0.01 7
Direction Lamps Monitor 5 500 0.01 8

Scheduler Subsystem
Elevator Status and Plan Server 2 10 0.20 1
Elevator Scheduler 20 50 0.40 2

Network transmission delay = 2 msec

Elapsed time for Stop Elevator at Floor = 41 msec < 50 msec
Elapsed time for Select Destination = 48 msec < 100 msec
Elapsed time for Request Elevator = 82 msec < 200 msec

Elevator Control System 40

Koichiro Ochimizu, JAIST

Event Sequences for three Usecases

• Stop Elevator at Floor (Period = Ta)
– A1: The Arrival Sensors Interface receives and process the
interrupt
– A2: The Arrival Sensors Interface sends “approaching Floor”
message to the Elevator Controller.
– A3: The Elevator Controller receives message and checks the
Local Elevator Status & Plan object to determine whether the
elevator should stop or not.
– A4: The Elevator Controller invokes “stop Motor” operation if
it should stop.
– A5: The Elevator controller sends arrived message over the
LAN to the Scheduler subsystem, where it is received by the
Elevator Status & Plan Server.
– A6: The Elevator Status & Plan Server calls the arrived
operation of the Overall Elevator Status & Plan data abstraction
object.

Event Sequences for three Usecases

• Select Destination (Period = Tb)
– E1: The Elevator Buttons Interface receives and processes the
interrupt.
– E2: The Elevator Buttons Interface sends “elevator Request”
message to the Elevator Manager.
– E3: The Elevator Manager receives message and records
destination in Local Elevator Status & Plan object.
– E4: The Elevator Manager sends an “elevator Commitment”
message over the LAN to the Scheduler subsystem, where it is
received by the Elevator Status & Plan Server.
– E5: The Elevator Status & Plan Server calls the update Plan
operation of the Overall Elevator Status & Plan data abstraction
object.

Elevator Control System 41

Koichiro Ochimizu, JAIST

Event Sequences for three Usecases

• Request Elevator (Period = Tc)
– F1: The Floor Buttons Interface receives and processes the interrupt.
– F2: The Floor Buttons Interface sends “service Request” message over the
LAN to the Elevator Scheduler task in the Scheduler subsystem.
– F3: The Elevator Scheduler receives message and interrogates Overall
Elevator Status & Plan object to determine whether an elevator is on its way
to this floor. Assume not, so that the Scheduler selects an elevator.
– F4: The Elevator Scheduler sends a “scheduler Request” message
identifying the selected elevator over the LAN to the Elevator Manager task
in the selected elevator’s instance of the Elevator subsystem
– F5: The Elevator Manager receives message and records destination in the
Local Elevator Status & Plan object.
– F6: The Elevator Manager sends an elevator Commitment message over
the LAN to the Scheduler subsystem, where it is received by the Elevator
Status & Plan Server
– F7: The Elevator Status & Plan Server calls the update Plan operation of the
Overall Elevator Status & Plan data abstraction object.

Result of Analysis(1/3)
• Stop elevator at Floor (Ta=50msec)
‒ Execution time: Total execution time Ca＝2msec (Arrival Sensors
Interface)＋5msec (Elevator Controller) Execution utilization Ue=
Ca/Ta=7/50=0.14
‒ Preemption by higher priority tasks with longer periods.
Preemption time Pa=3 (Elevator Buttons Interface). Preemption
utilization Up=3/50=0.06
‒ Blocking time: Total worst-case blocking time Ba= 6msec
(Elevator Manager). Worst-case blocking utilization Ub =
Ba/Ta=6/50=0.12
‒ Total elapsed time=7＋3＋6 =16msec<50．Total Utilization=
Ue+Up+Ub=0.14+0.06+0.12=0.32
– Total elapsed time for Stop elevator at Floor＝16(Total elapsed
time for Elevator Subsystem)＋2 (Transmission Delay, 25byte,
100Ｍbau, Transmission Delay Dt = 200/100000 = 2msec＋23
Worst-case elapsed time of Scheduler system)＝16＋2＋23＝
41msec

Elevator Control System 42

Koichiro Ochimizu, JAIST

Result of Analysis(2/3)
• Select Destination (Tb=100msec)
‒ Execution time: Total execution time Cb＝3msec
(Elevator Buttons Inteface)＋6msec(Elevator Manager).
Execution utilization Ue=Ca/Ta=9/100=0.09
‒ Preemption time by higher priority tasks with shorter
periods: Arrival Sensors Interface and Elevator
Controller can each execute twice during the 100 msec
period, giving a total preemption time of 14 msec.
Up=0.14.
‒ Total elapsed time =9+14=23．Total utilization =
Ue+Up =0.09+0.14=0.23
‒ Total elapsed time for Select Destination Eb =23
(Elevator subsystem elapsed time)＋2(transmission
delay)＋23 (Scheduler subsystem elapsed time)
=48msec.

Result of Analysis(3/3)
• Request Elevator (Tc=200msec)
‒ Total elapsed time for floor subsystem Ef=4msec( floor
buttons Interface)＋1msec(transmission delay)=5msec.
‒ Total elapsed time for scheduler subsystem
Es=1msec(transmission delay)＋20msec(elevator
Scheduler)+ 1 msec (transmission delay)＋2msec
(Blocking time by Elevator Status & Plan subsystem)
＝1+20+1+2= 24msec.
‒ Execution time of Elevator Manager＝1+6+1=8．
‒ Total elapsed time of Elevator subsystem＝16+8=24．
– Total elapsed time for Request Elevator ＝
5+2+24+2+24+2+23=82

Elevator Control System 43