System Requirements Specification

For an Elevator System Controller

In a Low-Rise Building




By Dave Chodos




For Dan Berry, CS 846














November 21, 2005
List of Changes from 2
nd
Partial SRS


Section 1
Removed variables (<floor>, <car>, etc.) from definition chart
Removed MC from definition chart, since the SRS should not mention MC
specifically but rather deal with a generic elevator system for a low-rise building
Clearly defined car status terms and roles used in the SRS
Renamed the Context Diagram for the Elevator Control System
Added a dashed box to indicate the boundary between the elevator system and the
users, showed the users in the Context Diagram

Section 2
Moved description of elevator system components from Product Perspective
subsection to Product Functions subsection
Removed description of components not relevant to SRS (e.g. light on/off switch)
Changed description of behaviour for alarm button, emergency stop button

Section 3
Changed system state diagram to reflect concurrency among activities, matched
abstraction level with the use cases, avoided flower pattern diagram
Added a number of previously missing entities to the conceptual diagram

Section 4
Added a number of previously missing requirements to both the functional
requirements table and the non-functional requirements table
Rephrased the use cases to use the active voice, and wrote more direct sentences
Specified the floor and direction indicators behaviour explicitly in the use cases
Dealt with the scheduling subsystem explicitly in the use cases
Dealt with some use cases from a user perspective instead of a signal perspective
to better specify the overall processes involved
Moved the system start-up and system shutdown use cases to the end of the
document so that the reader will be better able to understand these processes
Dealt with all alternatives and exceptions implied in the use cases
Specified the behaviour of components (e.g. door controllers, lifting system
motor) on a lower level
Removed use case exception dealing with the safety system, as it is outside the
elevator system

Table of Contents

1. Introduction 1
1.1 Purpose 1
1.2 Scope 1

1.3 Acronyms, Abbreviations, Definitions, Notational Conventions 1
1.4 References 2
1.5 Overview 2

2. General Description 3
2.1 Product Perspective 3
2.2 Product Features 3
2.3 User Characteristics 3
2.4 General Constraints 4
2.5 Assumptions and Dependencies 4

3. Specific Requirements 5
3.1 Functional Requirements 5
3.1.1 Overall System 5
3.1.1.1 System Sequence Diagrams 5
3.1.1.2 System State Diagram 7
3.1.2 Conceptual Diagram 8
3.1.3 State Diagrams 9
3.1.4 Collaboration Diagram 11
3.1.5 Sequence Diagrams 12
3.2 External Interface Requirements 17
3.2.1 User Interfaces 17
3.2.2 Hardware Interface-Application Program Interface 17
3.2.3 Communications Interface 17

4. Reference Tables and Descriptions 18
4.1 Functional Requirements Table and Traceability Document 18
4.2 Non-functional Requirements Table and Traceability Document 19
4.3 Use Case Descriptions and Use Case Diagrams 20

4.4 Index 30

i
Table of Figures

Context Diagram of Elevator System 2
System Sequence Diagram 5
System State Diagram 7
Conceptual Diagram 8
State Diagrams 9
Collaboration Diagram 11
Sequence Diagrams 12
Use Case Diagrams 29

ii
1
Introduction

1.1 Purpose
The purpose of this document is to describe the requirements for an elevator control system in a
low-rise building. This document shall serve as a contract between the elevator control system
manufacturer and the users of the elevator system passengers, operators and maintenance
people, and so forth detailing how the elevator control system will behave and how it will
operate with other components of the elevator system as a whole.

1.2 Scope
This document covers the details of the elevator control system, including the physical
components of the system, and the behavioral, functional, and non-functional requirements. This
document describes only the external systems and/or environments in which the elevator control
system shall work, with enough detail to complete an implementation of the system.

1.3 Acronyms, Abbreviations, Definitions, Notational Conventions
Definitions
This document uses a few phrases in precise ways to describe the elevator systems behaviour:
Floor Request: This is a signal for an elevator to move to a particular floor, either because of an
up/down button or a floor button press.
User: A user is any passenger wishing to travel from one floor to another
Operator: An operator is someone who is authorized to turn the elevator system on and off, and
has access to the keys needed to use the key controls in the elevator cars.
Repair crew: The repair crew is a group of people who are authorized to repair any part of the
elevator system if it should malfunction. It is assumed that once they have finished repairing the
system, they will restart the system or return the fixed car to auto mode, as appropriate.

A car in the elevator system may be in one of a small number of states, which will determine that
cars behaviour. These states are defined below:
Active: When the elevator system is turned on, all cars are put in this state. A car in this state
will accept floor requests and act on them as the requests reach the front of the cars destination
list. A car is assumed to be in an active state unless otherwise specified.
Hold: A car in this state will not accept floor requests sent by up/down button presses. As well,
when stopped at a floor, the doors will not open and close as normal. Instead, they will stay open
until a floor button is pressed in that car.
Stuck: A car in this state will not accept floor requests, and will remain in place until reset by a
repair person. This state is used for cars in an exceptional case.
Emergency: A car in this state will stop accepting floor requests, travel to the initial floor, open
its doors, and remain in place with its doors open until reset by an elevator operator

Notational Conventions
The diagrams in this document use standard UML notation (that is, graphs of states and
transitions, represented by rounded boxes and arrow-tipped lines, respectively) for most
2
purposes. In the system state diagram, concurrency and branching are represented using the
RHAPSODY notation proposed by Harel and Kugler [5].
Context Diagram of Elevator Control System



1.4 References
1. Howstuffworks.com. How Elevators Work. http://science.howstuffworks.com/elevator.htm
2. Karaidjian, Alex. SRS 1, submitted for CS 846, Fall 2005.
3. Kolla, Maheedhar. SRS 1, submitted for CS 846, Fall 2005.
4. Zalagenas, Rick, (Director of Maintenance and Utilities). Conversation on Oct. 18, 2005.
5. Harel, David and Kugler, Hillel. The RHAPSODY Semantics of Statecharts.

1.5 Overview
The rest of the document is laid out in the following manner. Section 2 gives a general
description of the system, and identifies the assumptions and constraints that are placed upon the
system. Section 3 describes the requirements of the system, and explores the relationships
between these requirements using conceptual, collaboration, state, and sequence diagrams.
Section 4 presents all the functional and non-functional requirements and describes the use cases
for the elevator controller system. The final subsection contains an index for the document.

Direction
buttons
Floor
buttons

Elevator Door
Controller
Lifting
System

Floor
Indicators
Legend

Instruction sent


Information sent
Car status
key control

Emergency
Stop button

Hold Doors
button
Elevator
Control System
Position
Sensor
Direction
Indicators
User
Operator
Elevator
Car
System
on/off
Elevator
Car Doors
Doors at
each floor

3
2 General Description

2.1 Product Perspective
The elevator system exists to help users get from one floor to another in the building. It is
particularly useful for those with physical handicaps who may find it difficult or impossible to
use the stairs. It is also quite useful for moving large or heavy objects between floors. The
elevator control system is an integral part of the elevator system which, as its name suggests,
controls the various components of the elevator system to ensure the system functions properly.

2.2 Product Functions
The elevator system is composed of a number of components, listed below:
The elevator car is moved from floor to floor by means of a motorized lifting system
The scheduling system determines which floor to send the car to, based primarily on user
requests and, possibly, additional factors such as time of day and usage patterns
The position sensor relays the position of each car to the elevator control system [4]
The elevator doors open and close to let users in and out of the elevator car. More
precisely, the elevator car doors allow access to an elevator car and the floor doors allow
access to the elevator shaft from that floor. Both sets of doors are controlled by an
elevator door controller, and can usually be thought of as a single unit.
Buttons on the wall and inside the elevator cars allow the users to select whether they
would like to go up or down, which floor they would like to go to, hold the elevator
doors, stop the elevator car, or to sound an alarm bell in the car
The floor and direction indicators show where a particular car is and which direction its
going in, thus giving the user some feedback
The car status key control allows the elevator to be set to Hold, Service or Auto
status. These settings are described in detail in section 1.3
The system startup/shutdown controls allow an elevator operator to start up or shut down
the entire elevator system [2]
The elevator system also contains a safety subsystem that ensures that, in the event of a
failure of some kind, the system wont put the users in any danger.
The main function of the elevator control system, as implied by the previous section, is to
coordinate the various components of the elevator system so that users can get from one floor to
another easily and efficiently. The elevator control system manages user input (such as buttons
being pressed), co-ordinates system behaviour (such as sending elevator cars from one floor to
another) and sends output messages (such as the floor that an elevator car is on) to provide the
user with feedback. The control system should be robust enough to be able to handle multiple
users getting on and off at multiple floors with conflicting goals (e.g. if, when two users get on
an elevator, one wants to go up and the other wants to go down). The control system should also
be able to handle emergencies in a manner that does not endanger the users in any way.

2.3 User Characteristics
It is assumed that the users (either on their own or through the use of a nearby stick) will be able
to press all the buttons in the elevator car and on the wall near the elevator shaft. As well, it is
4
assumed that the users will be able to read the numbers beside the buttons and thus decide which
floor they would like to go to. Finally, it is assumed that the users will have the presence of mind
in an emergency to use the emergency stop buttons and phone located inside the elevator car to
notify the proper people (elevator repair crew, security, fire department, etc.) in the event of an
emergency.

2.4 General Constraints
The Province of Ontario limits the amount of weight (1587 kg or 3500 lbs) that can be in an
elevator car at any one time. This can be used as the basis for an upper bound on the amount of
weight that the car needs to support, and also acts as a constraint on the number of users in a car.
It should be noted, of course, that this upper bound should not be the same as the legal limit it
should be some percentage above that limit, as per engineering guidelines.

Low-rise buildings, as their name implies, have relatively few floors, so this limits the number of
floors that need to be considered, and thus the time it will take users to get to their destination.
That is, the elevator will never need to travel more than a few floors to get a user to the floor they
want, thus providing an upper bound on the cars travel time (except in emergency or other rare
cases).

2.5 Assumptions and Dependencies
It is assumed that the users will follow the Ontario laws mentioned above, and thus the elevator
may be designed with those physical boundaries in mind.

It is also assumed that people will not cause the buttons to stick using some adhesive (e.g.
gum) or mechanical device. Thus, if a button is pressed, it will be released quickly.

It is assumed that only service people will be able to use the key controls. These controls allow
access to functionality that users should not have any need for.

It is assumed, for normal usage, that the building in which the elevator system is installed will
have power with which to run the elevators. However, it should also be noted that in the event of
a power failure, the elevators should not drop or become otherwise unsafe; this crucial
requirement of the safety system is usually satisfied via mechanical means such as
electromagnetic brakes [1].
3 Specific Requirements

3.1 Functional Requirements

3.1.1 Overall System
The functional requirements for the system are that the elevator control system should coordinate
and communicate between the various components of the elevator system to ensure that users
can get from one floor to another quickly and safely.

5
3.1.1.1 System Sequence Diagrams




Up/Down Button Pressed

User
Up/Down Button

Elevator Control System
Up/Down button pressed
Up/Down signal sent
Floor Indicators

Button illuminated
Direction Indicators
Direction indicator updated
Floor indicator updated
Button illumination stopped

While the car

has not yet
arrived at
users floor

Hold Doors Button Pressed
User
Hold Doors Button Elevator Control System
Hold Doors button pressed

Button illuminated
While the
Hold Doors
button is
pressed

Hold Doors pressed signal sent
Button illumination stopped

6




*
The stop signal may also be triggered by the car status key control being turned to service or
by an externally-generated fire alarm signal
Floor Button Pressed
















User
Floor Button Elevator Control System
Floor button pressed
Floor signal sent
Floor Indicators

Button illuminated
Direction Indicators
Direction indicator updated
Floor indicator updated
Button illumination stopped

While the
car has not
yet arrived at
pressed floor

Emergency Signal
















User
Stop Button Elevator Control System
Stop button pressed*
Stop signal sent
Floor Indicators

Button illuminated
Direction Indicators
Direction indicator updated
Floor indicator updated
Button illumination stopped

While the
car has not
yet ar rived at
initial floor

7
3.1.1.2 System State Diagram

8
3.1.2 Conceptual Diagram


9
3.1.3 State Diagrams

System Status Controller

Turn system on


Turn system off


Signal Processor*
Update Status Signal



Door Controller
Open Doors Signal



Close Doors Signals

[statusIsService]
Status Processor Emergency Processor.Emergency Signal()




System is
off
System is
o n

Start Accepting Signals
Not accepting
signals
Accepting
signals
Stop Accepting Signals
Move Car to Floor Signal
Emergency Signal
Hold Doors Signal
Car Position Signal
Doors are
closed
Doors are
open
Waiting for
status change
Processing
status change
Status Change Signal

[ statusNotService]
Car status changed

10
* In the transitions from the Signal Processor to other components (Door Controller, Floor
Request Processor, etc.) the names of the components have been omitted from the diagram for
the sake of conciseness. Also, one may easily infer the component for each signal from the signal
name (e.g. the Hold Doors signal should be sent to the Door Controller).
Lifting System Motor Controller



Position Processor

Arrival at Floor (Floor)


[notAtDestFloor] [atDestFloor] Send arrival message

Emergency Processor
Door Controller.Close doors()
Emergency Motor Controller.Move car(Direction) signal
Dir. Indicator.Update Direction (Dir.)












Move Car (Direction)
Car is stopped
Car is in
motion
Stop Car
Car has not reached
its destination
Processing
car arrival
Floor Indicator.Update Position (Floor)


Processing
emergency signal
Waiting for car
arrival message
Car is stopped in
emergency status
Motor Controller.Stop car()
Door Controller.Open doors()
Status Processor.Update status(Status)
Waiting for
emergency signal
11


Floor Request Processor

Processing floor
request signal
Door Controller.Close doors()
Motor Controller.Move car(Direction)
Dir. Indicator.Update Direction (Dir.)
Waiting for car
arrival message
Car is stopped at the
requested floor
Motor Controller.Stop car()
Door Controller.Open doors()
Floor request
signal
Waiting for floor
request signal
Floor request signal
12

3.1.5 Sequence Diagrams

13

Use Case 1: Car Dispatch





Scheduling
System
Floor Indicators
Door
Controller


Lifting System
Motor Controller


Signal
Processor

Floor
Request
Processor

1 . Process Signal (Signal)
. Open Doors 11

2 . Move Car
to Floor
Destination) (
5 . Move Car (Direction)
10 . Stop Car

3 . Check For
Available Car
8 . Update Position
( Floor)
Direction Indicator
6 . Update Direction

( Direction)
Position
Processor
. Car At Floor 7
(Floor)
. Car 9
Arrival
. Car is Available 4

14



Use Case 4: Hold Doors

Use Case 2: Car Movement


























Floor Indicators
Door
Controller


Lifting System
Motor Controller


Signal
Processor

Floor
Request
Processor

1 . Process Signal (Signal)

10 . Open Doors

2 . Move Car
to Floor
( Destination)

4 . Move Car (Direction)
9 . Stop Car

7 . Update Position
( Floor)
Direction Indicator
. Update Direction (Direction) 5
Position
Processor
. Car At Floor 6
(Floor)
8 . Car
Arrival
3 . Close Doors

Use Case 3: Update Floor Indicators







Floor Indicators
Signal
Processor

1 . Process Signal (Signal )


3 . Update Position (Floor)
Position
Processor
. Car At Floor (Floor) 2
15

1. Process Signal (Signal)











Use Case 6: Change Status

Use Case 5: Emergency Stop




. Move Car to Initial Floor 2

Floor Indicators
Door
Controller


Lifting System
Motor Controller


Signal
Processor

Emergency
Processor


1 . Process Signal (Signal)
3 . Close Doors
. Open Doors 10
. Move Car (Direction) 4
9 . Stop Car
. Update Position 7
( Floor)
Direction Indicator
5 . Update Direction
( Direction)
Position
Processor
. Car At Floor 6

(Floor)
. Car Arrival 8
Car Status
Controller
11 . Update Status (Status)
Door
Controller


Signal
Processor

2 . Open Doors
3 . Close Doors
16



Signal
Processor

1 . Process Signal (Signal)
Car Status
Controller
2 . Update Status (Status)
Use Case 7: System Startup




Lifting System
Motor Controller


Signal
Processor

Floor
Request
Processor

3 . Process Signal (Signal)
. Start Accepting Floor 10
Request Signals
5 . Move Car
to Initial Floor
6 . Move Car (Direction)
. Stop Car 9

Position
Processor
. Car At Floor 7
(Floor)
. Car 8
Arrival
Car Status
Controller
. Update Status (Status) 4
System
Status
Controller

. Turn System On 1
. Start up 2
17

3.2 External Interface Requirements
This section sets out in detail the specifications for each interface component of the system.

3.2.1 User Interfaces
The user interfaces can be divided into several categories: buttons, key controls, system controls
and indicators. Buttons (such as the floor and direction buttons) may be pressed at any time. Key
controls may only be activated by the proper key. Finally, system controls are only accessible
from an elevator control room, and thus would only be used by elevator operators.
Buttons
In general, buttons will light up when pressed, thus giving the user positive feedback. Also, all of
the symbols and numbers are raised or lowered from the buttons surfaces, which will help the
visually impaired figure out what the buttons do. In most cases, the buttons will press down and
then return to their original state without sticking. The alarm button, however, will stay pressed
down until it is pressed again, at which point it will return to its original state. The alarm button
causes the cars alarm to sound while it is pressed down, so this behaviour is logical [4].
Key Controls
Key controls may only be used by repair people and elevator operators. Key controls typically
switch between a limited number of states (e.g. fan on/off, car status of auto or hold).
System Controls
Use Case 8: System Shutdown

Lifting System
Motor Controller


Signal
Processor

Floor
Request
Processor

3 . Process Signal (Signal)
4 . Stop Accepting Floor
Request Signals
5 . Move Car
to Initial Floor

. Move Car (Direction) 6
. Stop Car 11

Position
Processor
. Car At Floor 8
(Floor)
10 . Car
Arrival
System
Status
Controller

. Turn System Off 1

. Shut down 2
Floor Indicators
9 . Update Position
( Floor)
Direction Indicator
7 . Update Direction

( Direction)
18
System controls are used to turn the elevator system on or off. They would typically be used
quite infrequently perhaps the system would be turned on early in the morning and turned off
late at night, or turned off at the start of holidays and turned on once the next term begins.
Indicators
The floor and direction indicators provide feedback to the user about where the cars are and
which direction they are going. There are floor and direction indicators in the elevator cars, and
there should be floor indicators above the elevator doors on each floor of the building.

3.2.2 Hardware Interface-Application Program Interface
The systems hardware interface shall consist of the elements needed for the various user
interface components described above to communicate with the elevator control system. Thus,
the hardware interface system needs to accept signals from elevator buttons, key controls and
system controls, and convey these signals to the elevator control system. With respect to this
document, this translation happens transparently, as the process is at a lower level of detail than
is appropriate for the documents focus.

3.2.3 Communications Interface
The communications interface in the elevator system consists of the rotary telephone which is
directly connected to a repair persons phone, which is staffed 24 hours a day. Thus, in the event
of an emergency, a user can pick up the phone and will be connected immediately to a repair
person, who will be able to assist the user or direct their call to the proper people. Although the
phone has a rotary dial, this is merely an indication of the type of phone rather than an
implication of any potential connection to an arbitrary phone number.
4 Reference Tables and Description

4.1 Functional Requirements Table and Traceability Document
Note: The Sources column has been omitted from this table, since the document only has one
source. Similarly, the Where Specified column has been omitted, since this is a partial SRS
and the requirements are only specified in this column.

Req# Name Description Details / Constraints Category
Related

Reqts
Related UCs
F1
System
Startup
Upon startup, the system
shall begin operation in a
reasonable initial state
May only be initiated
by an operator
E F14, N13 UC7
F2
System
Shutdown
The system shall be able to
be shut down in a safe and
efficient manner at any
point in time
May only be initiated
by an operator
E F4, F5,
F14,
N5N13
UC8
19
F3
Floor
Request
When the up/down button
is pressed, the closest
available car will be sent
to that floor
If all cars are busy,
then the floor will be
added to the
destination list of the
car that will get to that
floor soonest
E F4, F5,
F6, F9,
N5N12
UC1
F4
Car in
Transit
When a car is in motion, it
will update the floor
indicators in that car and
above elevator entrance
E UC3
F5
Car
Direction
Change
When a car changes
direction, its direction
indicator will be updated
E UC1, UC2
UC5, UC8
F6
Car Arrival When a car arrives at the
floor at the front of its
destination list, it will stop
at that floor
E F7, F8,
N7,
N10
UC1, UC2
UC5, UC8
F7
Open Doors
(auto mode)
When a car arrives at a
destination floor, its doors
will open and the doors at
that floor will also open.
They will remain open for
a short period of time, and
then close automatically
E F8, N5,
N6, N8,
N12
UC1, UC2
UC5
F8
Open Doors
(hold mode)
When a car arrives at a
destination floor, its doors
will open and the doors at
that floor will also open.
They will remain open
until the car leaves for a
different floor
E F7, N5,
N6, N8
UC1, UC2
UC5
F9
Close Doors Before a car leaves a floor,
its doors will close and the
doors at that floor will
also close


E F3,
F10,
N8,
N11
UC1, UC2
UC5
F10
Car
Movement
When a floor button is
pressed, the car will be sent
to that floor
The car may stop at
other floors first
E F4, F5,
F6, F7,
F8, N3-
N12
UC2
F11
Hold Doors The doors will stay open
while the Hold doors button
is pressed.
E N5, N6,
N8
UC4
20
F12
Emergency
Stop
When the Stop button is
pressed or the car is set to
service status, the
elevator car will
immediately go to the first
floor, both its doors and
the doors at the first floor
will open and remain
open, and the car will
ignore floor requests
E F14,
N5N13
UC5
F13
Fire Alarm When a fire alarm signal is
received, both elevator
cars will immediately go
to the first floor, both their
doors and the doors at the
first floor will open and
remain open, and the cars
will ignore floor requests
E F6,
N5N13
UC5
F14
Change
Status
When the car status key
control is turned, the cars
status will change to
Auto, Hold or
Service.
See section 2.1 for a
definition of Auto,
Hold and Service
status
E F7, F8,
F12
UC1, UC2
UC5, UC6

4.2 Non-functional Requirements Table and Traceability Document

Req# Name Description Details/Constraints Category
Related
Reqts
Related UCs
N1
Extra elevators
(Scalability)
Adding extra elevators
to the system should
happen smoothly
In practice, this is
limited by the layout
of the building
W
N2
System Failure
(Safety)
If the system fails, the
users should not be put
in any danger
Relies on the
functionality of the
safety system
M F12,
N13
UC1, UC2
UC4, UC5
N3
Universal
Accessibility
(Usability)
The system should be
accessible to people
with disabilities
M F3, F10,
F11,
F12
UC1, UC2
UC4, UC5
N4
Button
Illumination
(Usability)
The buttons in the
elevator car and on the
wall panel should light
up when pressed
W F3, F10,
F11,
F12
UC1, UC2
UC4, UC5

N5
Elevator Car
Door Open
Condition
(Safety)
The car doors shall only
open when the car is
stopped at a floor [2]
M F7, F8,
F11, N6
UC1, UC2
UC4, UC5
UC8
21
N6
Floor
Door Open
Condition
(Safety)
The floor doors shall
only open when a car is
stopped at that floor
M F7, F8,
F11, N5
UC1, UC2
UC4, UC5
UC8
N7
System
Response
Speed
(Reliability)
The system shall
process input and
produce output in an
efficient manner [2]
W F3-F8,
F11-F14
UC1-UC6
N8
Door
Open/Close
Speed
(Usability)
The doors shall open
and close gradually to
allow people to easily
enter and exit the car
Currently, the doors
take about 2 seconds
to open or close
M F7-F9,
F11, N5,
N6
UC1, UC2
UC4, UC5
UC8
N9
Elevator Car
Start Speed
(Usability)
The car shall gradually
accelerate from rest to
its standard speed in
order to provide a
smooth ride for users
W F3, F6,
F10,
F12,
F13
UC1, UC2
UC5, UC8
N10
Elevator Car
Stop Speed
(Usability)
The car shall gradually
slow down from its
standard speed to rest
in order to provide a
smooth ride for users
W F3, F6,
F10,
F12,
F13
UC1, UC2
UC5, UC8
N11
Door Close
Condition
(Safety)
The car doors will only
close if there is nothing
in the doorway
Ensures the user
will not get trapped
by the door
M F9 UC1, UC2
N12
Open Door
Time Period
(Usability)
When a car is in auto
mode, the doors should
wait 3 seconds between
opening and closing
M F7 UC1, UC2
N13
Initial Floor If an elevator car needs
to go to an initial
floor, it shall go to the
1
st
floor
If the 1
st
floor is
unsafe, then the
elevator will go
to the 3
rd
floor
M F1, F2,
F12,
F13
UC5, UC7
UC8
4.3 Use Case Descriptions and Use Case Diagram

Use Case Descriptions
Because this document describes the elevator control system, rather than the elevator system as a
whole, a precise distinction is made between actors and users. A user is either a person who is
using the elevator system to get from one floor to another or a repair person. An actor, on the
other hand, is usually a part of the elevator system (such as the down button) that sends a
message to the elevator control system. The elevator systems user interface lies between the user
and the elevator control system, and prevents the users from also being actors. In the following
use cases, the users are listed in brackets to indicate which people have access to which user
interface components.

Finally, the use cases that follow will refer to a floor being at the front of the list, which means
that the floor will be visited next by the car. The list might be ordered using first in, first out, or
22
it might take other factors such as proximity of the car to the floor or time of day into account.
This is regarded as an implementation decision, and is thus not dealt with in this document.

Name: Car Dispatch ID: 1
Event: A user presses the up/down button
Goal: Send a car to a floor in response to an up/down button press
System: Elevator Control System
Actors: Up/down button (pressed by user)
Overview: A car is sent to the floor where the up/down button was pressed
Pre-conditions: The elevator system is in a state where it will accept requests
Post-conditions: A car is at that floor, its doors are open and the floor doors at that floor
are open
References: F3, F5-F9, F14, N2-N12
Related Use Cases: UC 3
Typical process description
I nitiator Action System Response
1. User presses the up/down
buttons on a wall






while not at destination floor do
5. Floor sensor signals the cars
arrival at a non-destination floor

end while
7. Floor sensor signals the cars
arrival at the destination floor



2. Determine which car should be sent to the
floor
3. Add the floor to the cars destination list
4. Tell the lifting system motor in the
appropriate elevator shaft to move the car in the
proper direction
5. Send the current direction to the direction
indicator inside the car



6. Update the floor indicators (see UC 3)



8. Update the floor indicators (see UC 3)

9. Tell the lifting system motor in the appropriate
elevator shaft to stop
10 Tell the door controller to open the car doors and
the doors at that floor, wait three seconds, and then
close them again
Alternative 1: No car is available
23
2. Determine which car will be able to go to that
floor soonest
3. Add the floor to that cars destination list
4. When the floor gets to the front of the list, tell
the lifting system motor in the appropriate elevator
shaft to move the car up/down, as required to move
the car to the floor
(steps 5-10 as above)
Alternative 2: Car has Hold status
10. Tell the door controller to open the car doors and
the doors at that floor
Exception 1: Car fails to level
9. Car fails to stop at the same
level as the floor, possibly
because of excess weight



10. Set the cars status to stuck until the elevator
car is fixed by the repair crew
Exception 2: Doors fail to open or close
10. Elevator car doors or doors at
the floor fail to open or close


11. Set the cars status to stuck until the car is fixed
by the repair crew

Name: Car Movement ID: 2
Event: The user presses a floor button
Goal: Send a car to a floor in response to that floor button being pressed within that car
System: Elevator Control System
Actors: a floor button (pressed by user)
Overview: A car is sent to a destination as a result of a floor button press
Pre-conditions: The elevator system is in a state where it will accept requests
Post-conditions: The car is at the floor that was pressed, its doors are open and the doors
at that floor are open
References: F5-F10, F14, N2-N12
Related Use Cases: UC3
Typical Process Description
I nitiator Action System Response
1. User presses a floor button
inside an elevator car




2. Tell the door controller to close the car doors and
the doors at the floor the car is currently on

24




while not at destination floor do
5. Floor sensor signals the cars
arrival at a non-destination floor

end while
7. Floor sensor signals the cars
arrival at the destination floor

3. Tell the lifting system motor in the
appropriate elevator shaft to move the car in the
proper direction
4. Send the current direction to the direction
indicator inside the elevator



6. Update the floor indicators (see UC 3)



8. Update the floor indicators (see UC 3)
9. Tell the lifting system motor in the
appropriate elevator shaft to stop
10. Tell the door controller to open the car doors
and the doors at that floor, wait three seconds, and
then close them again
Alternative 1: Cars destination list is non-empty
3. Add the floor to the cars destination list
4. When the floor gets to the front of the list,
tell the lifting system motor in the appropriate
elevator shaft to move the car up/down, as required
to move the car to the floor
(steps 4-10 as above)
Alternative 2: Multiple buttons pressed
1. The user presses several floor
buttons


2. Add the floors pressed to the cars destination list
(steps 2-10 as above for each button pressed)
Alternative 3: Button(s) pressed while in motion
1. The user presses floor button(s)
while the car is in transit



2. Add the floors pressed to the cars destination list
3. Handle all floor requests preceding those just
added to the cars destination list (see UC1, UC2)
(steps 2-10 as above for each button pressed)
Alternative 4: Car has Hold status
10. Tell the door controller to open the car doors and
the doors at that floor
Exception 1: Doors fail to close
25
2. Elevator car doors or doors at
the floor fail to close


3. Set the cars status to stuck until the doors are
fixed by the repair crew
Exception 2: Car fails to level
7. Car fails to stop at the same
level as the floor, possibly because
of excess weight


8. Set the cars status to stuck until the elevator car
is fixed by the repair crew
Exception 3: Doors fail to open
8. Elevator car doors or doors at
the floor fail to open


9. Set the cars status to stuck until the doors are
fixed by the repair crew

Name: Update Floor Indicators ID: 3
Event: A cars position sensor signals that the car has arrived at a floor
Goal: Keep the floor indicators up-to-date while a car is moving
System: Elevator Control System
Actors: Cars position sensor, cars floor indicator and external floor indicator(s)
Overview: The system updates the floor indicators to indicate which floor a car is on
Pre-conditions: The elevator car is moving and in an active or emergency state
Post-conditions: The floor indicators show which floor the car is currently on
References: F4
Related Use Cases: UC1, UC2, UC5
Typical Process Description
I nitiator Action System Response
1. Floor sensor signals the cars
arrival at a floor




2. Send the current floor number to the floor
indicator(s) outside the elevator
3. Send the current floor number to the floor
indicator inside the elevator car

Name: Hold Doors ID: 4
26
Event: The Hold doors button is pressed
Goal: The doors are held open while the Hold doors button is pressed
System: Elevator Control System
Actors: Hold doors button in a car (pressed by user)
Pre-conditions: The elevator car is at rest
Post-conditions: The elevator car is at rest and its doors are closed
Overview: The elevator control system keeps the doors open while the button is pressed
References: F11, N2-N8
Related Use Cases: None
Typical Process Description
I nitiator Action System Response
1. User presses the Hold doors
button inside an elevator car





2. Tell the elevator door controller to keep the
car doors and floor doors open
3. Store any floor requests (from up/down
buttons or


4. Hold doors button released

floor buttons pressed inside the elevator) in the cars
destination list, but keep the car in place

5. Tell the elevator door controller to close the car
doors and floor doors
Exception 1: Doors fail to open
2. Elevator car doors or doors at
the floor fail to open


3. Set the cars status to stuck until the doors are
fixed by the repair crew
Exception 2: Doors fail to close
5. Elevator car doors or doors at
the floor fail to open


6. Set the cars status to stuck until the doors are
fixed by the repair crew

Name: Emergency Stop ID: 5
27
Event: The Emergency stop button is pressed, the cars status is changed to service, or
an external fire alarm signal is received
Goal: To return the car to the initial floor and allow passengers to leave the car
System: Elevator Control System
Actors: Emergency stop button (pressed by user), car status key control (turned by
operator), or a fire alarm signal (sent externally)
Overview: The elevator control system sends the car to the initial floor and
Pre-conditions: The system is in an active state
Post-conditions: The car is on the initial floor with its doors open, and in an
emergency state
References: F5-F9, F12-F14, N2-N10
Related Use Cases: UC3
Note: If a fire alarm signal is received, then this use case applies to all elevator cars in
the elevator system, instead of a single car
Typical Process Description
I nitiator Action System Response
1. User presses the emergency
stop button inside an elevator car






while not at destination floor do
5. Floor sensor signals the cars
arrival at a non-destination floor

end while


2. Tell the door controller to close the car doors
and the doors at the floor the car is currently on
3. Tell the lifting system motor in the
appropriate elevator shaft to move the car down
4. Send the current direction to the direction
indicator inside the elevator



6. Update the floor indicators (see UC 3)

7. Floor sensor signals the cars
arrival at the destination floor



8. Update the floor indicators (see UC 3)
9. Tell the lifting system motor in the
appropriate elevator shaft to stop
10. Tell the door controller to open the car doors
and the doors at that floor
11. Set the cars status to emergency

Name: Change Status ID: 6
28
Event: Car status key control is switched to auto or hold
Goal: Change the cars status to auto or hold, which changes the car door behaviour
System: Elevator Control System
Actors: Car status key control in a car (turned by operator)
Overview: Description of the car status key control switch process
Pre-conditions: None
Post-conditions: The cars status is set to active or hold
References: F14, N7
Related Use Cases: UC1, UC2, UC5
Typical Process Description
I nitiator Action System Response
1. Car status key control turned to
auto (by repair person)


2. Set the cars status to active, the cars door
behaves as specified in F7
Alternative 1: Status set to hold
1. Car status key control turned to
hold (by operator)


2. Set the cars status to hold, the cars door
behaves as specified in F8
Alternative 2: Status set to service
1. Car status key control turned to
service (by operator)


2. Set the cars status to service, the car behaves as
specified in UC 5

Name: System Startup ID: 7
Event: System is started up by an operator
Goal: The elevator system is in a state where it can accept floor requests
System: Elevator Control System
Actors: Elevator operator
Overview: Describes the process of starting up the elevator system
Pre-conditions: System is off
Post-conditions: Both cars are at the initial floor in an active state References: F1, N13
Related Use Cases: UC8
Typical Process Description
I nitiator Action System Response
29
1. Operator turns system on



while not at initial floor do
4. Floor sensor signals the
cars
arrival at a non-initial floor
end while
5. Floor sensor signals the
cars arrival at the initial floor


2. Set the status of both cars to active
3. Tell the lifting system motors in both
elevator shafts to move the cars up/down, as
appropriate






6. Tell the lifting system motor in both elevator
shafts to stop
7. Begin accepting floor requests

Name: System Shutdown ID: 8
Event: Elevator system is shut down by an operator
Goal: The system is shut down quickly and safely, allowing users to exit the system
System: Elevator Control System
Actors: Elevator operator
Overview: Description of process of elevator system being shut down
Pre-conditions: Elevator system is active
Post-conditions: Both cars are at the first floor, both car doors are open, the doors at the
first floor are open, all other floor doors are shut, the system will not process any floor
requests or signals from within the elevator cars References: F2, F5, F6, N5, N6, N8-
N10, N13
Related Use Cases: UC7
Typical Process Description
I nitiator Action System Response
30
1. Operator turns system off






while not at initial floor do
5. Floor sensor signals the cars
arrival at a non-initial floor

end while
7. Floor sensor signals the cars
arrival at the initial floor


2. Stop processing floor requests and signals
from within the elevator cars
3. Tell the lifting system motor in both elevator
shafts to move the cars down
4. Send the current direction to the direction
indicator inside the elevator



6. Update the floor indicators (see UC 3)



8. Update the floor indicators (see UC 3)
9. Tell the lifting system motor in both elevator
shafts to stop
10. Tell the door controller to open both sets of car
doors and both sets of the doors at that floor


31
Use Case Diagrams

User Actor Control System


The first available
elevator car is sent
to users floor


The users car
is sent to the
given floor


Holds elevator
doors open in
the users car





The users car is sent
to the initial floor, and
the doors are opened



Operator Actor Control System



The cars
status is
changed


The system
is initialized


The system is
shut down in
a safe manner





Up/Do wn button

Floor button

Hold Doors button


Stop button



Car status key control

System is turned on
System is turned off
32


Actor Control System

Fire alarm signal (external)




Elevator car position sensor



4.4 Index
Active, 3 alarm bell, 5 assumptions, 4
buttons, 5, 6, 7, 12, 16, 18, 21, 22 car, i, ii,
3, 5, 6, 7, 12, 14, 15, 16, 17, 18, 19,
20, 21, 22, 23, 24, 25, 26 collaboration,
4 conceptual, i, 4 direction indicators, 14,
18, 20, 23, 26 doors, 3, 5, 7, 12, 14, 15, 16,
17, 18, 19, 20,
21, 22, 23, 26 elevator control system,
ii, 5, 7, 12, 18, 22,
23 elevator door controller,
5, 22 emergency, i, 6, 12, 22,
23 Emergency, 3, 10, 15, 23
floor button, ii, 3, 7, 15, 20,
21 floor doors, 5, 18, 22, 26
Floor Request, ii, 14
functional, i, ii, 4, 7, 16

Hold, 3, 5, 15, 19, 21, 22 hold door, 7
indicators, i, 5, 12, 14, 18, 20, 22, 23, 26
initial floor, 3, 17, 23, 25, 26 key control, 5,
15, 23, 24, 25 key controls, ii, 6, 12 non-
functional, i, ii, 4 operators, ii, 12 position
sensor, 5, 22 repair crew, ii, 6, 19, 21, 23
safety, i, 5, 6, 16 scheduling system, 5
sequence, i, 3, 4, 7 shutdown, i, 5 startup, 5
state, i, 3, 4, 7, 12, 14, 18, 20, 22, 23, 25
Stuck, 3 up/down, ii, 3, 14, 18, 19, 21, 22,
25 use case, i, ii, 23 User, i, ii, 6, 12, 18, 20,
22, 23, 27
Both cars are sent to
the initial floor, and
their doors are opened
The position
indicators are
updated