Software Architecture Document

Elevator system
Pham Van Cu, Doan Duy, Nguyen Mau Toan, Chau Ngoc Phuong
Version 1.0
January 2015

Revision History
NOTE: The revision history cycle begins once changes or enhancements are requested after the initial
version of the Software Architecture Document has been completed.
Date

Version

Description

Author

01/15/2015

1.0

Initial version of SAD for

comments by team

Ivan Dontsov

02/22/2012

1.1

Some changes after Maureen

Rottschaefer review

Ivan Dontsov

02/28/2012

1.2

More changes after team

review

Ivan Dontsov

03/04/2012

1.3

Ready for the next review

Ivan Dontsov

03/14/2012

1.4

Number of changes after

review and online discussions,
Ready for final review

Ivan Dontsov

Elevator
System System

ii

January 2015

Table of Contents

1.

Introduction....................................................................................................................... 1
1.1.

Purpose.................................................................................................................................... 1

1.2.

Scope....................................................................................................................................... 1

1.3.

Definitions, Acronyms, and Abbreviations.................................................................................2

1.4.

References............................................................................................................................... 2

1.5.

Overview.................................................................................................................................. 2

2.

Architectural Representation...........................................................................................3

3.

Architectural Goals and Constraints...............................................................................4

4.

3.1.

Security.................................................................................................................................... 4

3.2.

Persistence............................................................................................................................... 4

3.3.

Reliability/Availability................................................................................................................ 4

3.4.

Performance............................................................................................................................. 4

Use-Case View..................................................................................................................5

5.

4.1.

Actors....................................................................................................................................... 6

4.2.

Use-Case Realizations............................................................................................................. 7

Logical View...................................................................................................................... 7
5.1.

Overview.................................................................................................................................. 7

6.

Process View..................................................................................................................... 8

7.

Module Decomposition View............................................................................................9

8.

Data View........................................................................................................................... 9

9.

Deployment View............................................................................................................ 10

10.

Size and Performance.....................................................................................................11

11.

Issues and concerns.......................................................................................................11

Software Architecture Document Template

1.
1.1.

Introduction
Purpose
The purpose of this document is to describe the requirements for an elevator control system in a
building. The elevator control system will behave and how it will operate with other components
of the elevator system as a whole. The purpose of this document is to describe the

Elevator
System System

iii

January 2015

requirements for an elevator control system in a building. The elevator control system will
behave and how it will operate with other components of the elevator system as a whole.
In order to depict the software as accurately as possible, the structure of this document is based
on the 4+1 model view of architecture.

The 4+1 View Model allows various stakeholders to find what they need in the software
architecture.
1.2.

1.3.

1.4.

Scope
This document describes the details of the elevator control system, including the physical
components of the system, the behavioral and functional requirements. Stakeholders who
require a technical understanding of Process Specification Tools are encouraged to start by
reading this document, then reviewing the Process Specification Tool UML model.
In the following part of this report, overview of document and distributed elevator systems are
given in section 1, 2 and 3. In section 4 and 5, the design of our elevator control system is
presented from a static structural point of view, i.e. the Use Case diagram and the Class
diagrams are presented and analyzed. Process view, implementation view and deployment view
are illustrated in section 6, 7 and 8 respectively. Section 9 is the conclusion.
Definitions, Acronyms, and Abbreviations
User (passenger): Person who uses elevators service.

Outside user (passenger): This is a user who is outside of the car and want to be
served by pressing [UP] or [DOWN] button at a specific floor.

Inside user (passenger): This is a user who is inside of the car.

Elevator controller: This component controls and synchronizes the operation of the
elevator system.

SAD: Software Architecture Document.

UML: Unified Modeling Language.

References
1. 4 +1 architectural view model http://en.wikipedia.org/wiki/4%2B1_architectural_view_model
2. From teacher website http://www.nguyenvvu.net/i219-fall2014/

Elevator
System System

iv

January 2015

3. SAD template
http://sce.uhcl.edu/helm/RUP_school_example/wcsoftwareprocessweb/templates/ana_desi/
pt_sad.htm
1.5.

Overview
In order to fully document all the aspects of the architecture, the Software Architecture
Document contains the following subsections.
Section 2: describes the use of each view
Section 3: describes the architectural constraints of the system
Section 4: describes the use-case view of the system
Section 4.3: describes the most important use-case realization.
Section 5: describes the logical view of the system.
Section 6: describes the process view of the system.
Section 7: describes the development view of the system.
Section 8: describes the deployment view of the system.
Section 9: conclusion.

2.

Architectural Representation
This document details the architecture using the views defined in the 4+1 model [KRU41], but
using the RUP naming convention. The views used to document the DTCPII tool application are:

Use Case view

Audience: all the stakeholders of the system, including the end-users.
Area: describes the set of scenarios and/or use cases that represent some significant,
central functionality of the system. Describes the actors and use cases for the system, this
view presents the needs of the user and is elaborated further at the design level to describe
discrete flows and constraints in more detail. This domain vocabulary is independent of any
processing model or representational syntax (i.e. XML).
Related Artifacts : Use-Case Model, Use-Case documents

Logical view
Audience: Designers.
Area: Functional Requirements: describes the design's object model. Also describes the
most important use-case realizations and business requirements of the system.
Related Artifacts: Design model

Process view
Audience: Integrators.
Area: Non-functional requirements: describes the design's concurrency and synchronization
aspects.
Related Artifacts: (no specific artifact).

Module Decomposition view

Audience: Programmers.
Elevator
System System

January 2015

Area: Software components: describes the modules and subsystems of the application.
Related Artifacts: Implementation model, components

Data view
Audience: Data specialists, Database administrators
Area: Persistence: describes the architecturally significant persistent elements in the data
model
Related Artifacts: Data model.

Deployment view
Audience: Deployment managers.
Area: Topology: describes the mapping of the software onto the hardware and shows the
system's distributed aspects. Describes potential deployment structures, by including known
and anticipated deployment scenarios in the architecture we allow the implementers to
make certain assumptions on network performance, system interaction and so forth.
Related Artifacts: Deployment model.
3.

Architectural Goals and Constraints

3.1. Security
Transmitting signal has to be secured to prevent the system from outside attacking by electronic
signal.
3.2. Maintainability
System is easy to maintain or replace hardware components in case of unsafe situation or
hazard.
.
3.3. Reliability
System is expected to run continuously for years without errors (or in some cases recover by
themselves if an error occurs).The acceptable failure is once a year and when the failure
occurs, it should take at least time as possible to repair. The acceptable mean time for a
particular failure must be less than 10 minutes.
3.4. Availability
The system shall be working 24/7. When the system goes in under-maintenance, the display will
display message to notify passengers.
3.5. Performance
The maximum serving time per passenger is at most 5 minutes including the waiting time. The car is
moving with 30-60 meters/ minute speed.

4.

Use-Case View
In the 4+1 model, use-case view is used to illustrate the architecture serving as the plus one
view. The use-case view describes a list of steps that typically defines major interactions between
the role, known as an actor in UML, and a system. In the typical elevator system, the use-case view
represents all the central functionalities of the elevator that user can interact.
The use-case diagram shown in the figure is used for the use-case view.

Elevator
System System

vi

January 2015

4.1.

Use-cases

Figure 1: hello

As described in the figure, there are fifteen actions of the system. Functionality of each action is
explaining in detail as belows:
Choose floor: the action is only used by inside passengers. The inside passengers call this
action to register the destination floors to system by pressing buttons on the cars keypad.
Hold door open: the action is only used by inside passengers. The inside passengers call
this functions to keep the door open for their specific purposes, waiting another one for
example, by pressing the hold door button on cars keypad.
Close door: the action is used by both inside passengers and Elevator controller. When the
inside passengers want to close door immediately, they call this action by pressing the close
door button on cars keypad. Furthermore, whenever the car is ready to move or there is no
request to the car, the function is called to close the door.
Call for help: when the elevator is in the unsafe situation, inside passengers can press
emergency button in the car to make a favor.
Choose direction: the action is only used by outside passengers. When they need to be
served, by pressing a UP or DOWN button on the floors keypad they call this action for a
service.

Elevator
System System

vii

January 2015

Calculate travel schedule: this action is considered as an algorithm sets a suitable schedule
for cars. This action is used by the main controller (also treated as an actors) whenever
there is a request coming to the system.
Move: the action is only used by the elevator controller to let cars go up or down.
Open door: this action is only used by the elevator controller. Whenever the car reaches a
destination floor in its schedule, the function is called to open the door.
Slow down: the action is only used by Elevator controller. This is deceleration of the car
before stopping at a specific floor.
Indicate overload and over weight: the action is used by Elevator controller to check the total
weight of a car. This determines the permissible weight of the elevator.
Trigger brake: the action is used by Elevator controller in the unsafe situations. Whenever
this action is called, the brake is triggered to stop the car.
Play sound: the action is used by Elevator controller to play a sound whenever the car reach
es a destination floor in its schedule.
Update display: the action is used by Elevator controller to update the displays of car and
floor when the car reaches a destination floor in its schedule.
Pick up a car: this action is considered as an algorithm that can determine which car is the
best to serve a require.
4.2.

Actors
As described in the actors correspondence diagram above, actors could be one of three types:
1. Outside passenger is able to choose direction by press up/ down button in key pad of
elevator system.
2. Inside passenger could choose floor, hold door opened, close door, and call for help.
3. System Elevator controller is the third type of actor and is the system itself. It
handles all the physical and logical process of the elevator system.

4.3.

Use-Case Realizations
4.3.1

Outside passenger chooses direction use-case

Figure 2: Outside passenger chooses direction sequence diagram

Scenario 1: Outside passenger uses the elevator:

1. Passenger chooses moving direction via floors keypad (UP or DOWN).
2. The [Floor]s controller sends a car request to [Controller].
3. The Controller runs the process to determine what is the most suitable car for this request
Elevator
System System

viii

January 2015

4. When the car is determined, Controller sets the target floor to this car in order to ask this car to the
requesting floor.
5. At the same time with step 4, Controller also sends the command to update the display for all floors
display (Notify the new direction of this car).
6. When the Floor controller received the command from step 5, [Floor]s display reflects the direction
of each car.
7. Now the car starts moving to the target floor.
8. The car will check whether it reached to the target floor whenever it reached each floor (Note: In this
process, the car always sends the updating message to Controller to update its current floor for all
displays).
9. When the car reached its destination, a notify message will be sent to the Controller.
10. At the same time at step 9, the light of the car is turned ON.
11. When the Controller received the message from step 9, It sends a command to the Floors controller
to open its door.
12. The car plays a sound before opening the door.
13. Two doors (cars door and floors door) are opened at the same time.
4.3.2

System serves inside passengers use-case

Scenario 2: Outside passenger uses the elevator:

1.

User Choose target floors via cars keypad

2.

The Car sends target floors to the Controller

Elevator
System System

ix

January 2015

3.
4.
5.
6.
7.
8.
5.

The Controller runs a process to calculate a moving schedule of this car

The Controller set the new schedule to this car
At the same time, The Controller send the update info for all Display in floors
The Floor which have the current use will close this door
The door of this car also close at the this moment
Finally, the car move to this target. This process is same as the moving process in scenario 1

Logical View

5.1.
Overview
- According to the physical elements of a typical elevator. We need to model 3 main components of a typical
elevator : Controller, Car and Floor-Controller
-

Controller:
o

All process in the elevator system are executed by the controller, A car cannot connect or send
message directly to the floor without controller.

calTravelSchedule(): Update the travel schedule for a car when

user update change/add/remove/quest the target floor.

setTravelSchedule(): The Schedule for a car

findTheServingCar(): Find the best suitable car go to the users

floor.

Car:
o

It always move the car follow the schedule got from the
controller.

Move(): Control the movement of the car.

OnReachedNextFloor(): Send message to controller,

order to request Controller to open current door of
floor.

OnReachedTargetFloor(): Request Controller to

open the door when it reached a target floor

slowDown(): Stop the car when receive the

command from the Controller

onOverLoad(): Alarm to the user when the car is

overload

holdOpen/forceClose(): Open/Close the door when

user require

in

Floor-Controller:
o

Send request car to Controller when a User press

a button -> SendCarRequest()

Elevator
System System

January 2015

5.2.

5.3.

holdDoorOpened()/forceCloseDoor(): Receive the command from Controller to Open or Close the

Door

Main flow
Basing on the sequence diagram of previous part, we have two main connections: Controller Car and
Controller Floor. Giai thich them dieu khien ntn 1 controller 2 car, dieu khien floor bang cach dieu
khien hien thi. => toan

Class diagram
For the entire problem, we defined classes to fully describe the requirements as bellow:

Elevator
System System

xi

January 2015

Giai thich them => hien thi cua car khac voi floor ntn. Keypad cua floor khac voi keypad cua car ntn

6.

Process View

6.1 Overview
The process view deals with the dynamic aspects of the system, explains the system processes and
how they communicate, and focuses on the runtime behavior of the system. The process view
addresses concurrency, distribution, integrators, performance, and scalability, etc.

Elevator
System System

xii

January 2015

Elevator
System System

xiii

January 2015

I modeled Overweight checking diagram, Detect unsafe situation diagram and Execute
moving process diagram separately at 6.2.

6.2 Activity diagram

6.2.1 Moving process activity diagram

Elevator
System System

xiv

January 2015

Elevator
System System

xv

January 2015

The system includes 4 swim-lanes: User/ Passenger (outside passenger/ inside passenger),
Floor, Controller and Car. Detailed workflow is below:
1. From initial state, When user presses the button which indicates the moving direction
(if user is at the lowest floor, therell be only [UP] button and so on, if user is at the
highest floor, therell be only [DOWN] button)
2. Floor controller at a floor recognized signal from keypad, processed the command
then sends a request to get a car to the current floor.
Elevator
System System

xvi

January 2015

3. After receiving command from the floor, controller uses algorithm to find the most
suitable car to serve the request. When calculation process has been finished, moving
process is activated. Moving process is described as below: Controller concurrently
sends 2 requests:
a. Send request to all floors to update current status of the selected car (moving
direction, current floor).
b. Set request to the selected car to ask it to the target floor.
4. After step 3a and 3b, 2 below processes are executed concurrently:
a. All the floors display is updated based on current position of the selected car.
b. Selected car moves to the target floor. While moving, the car sends its current
position, moving direction to the controller and checks whether destination is
reached or not.
5. When destination is reached, 2 below processes are executed concurrently:
a. The car sends a message to notify the controller that it reached the target floor.
b. Controller requests floor and car to prepare to serve passenger.
6. After car and floor are ready to serve (after step 5), 3 processes are concurrently
executed:
a. Cars light is turn ON.
b. Cars door is opened.
c. Floors door is opened.
Moving process is end, now car is ready for passenger to get in and travel. Now
passenger gets in the car and start travelling by choosing the floor using cars
keypad.
1. Cars processor gets and processes users command from the keypad then registers
target floor to the controller.
2. After receiving command from the car, controller uses algorithm to find the shortest
path to serve the request. When calculation process has been finished, Controller
concurrently sends 2 requests:

Elevator
System System

xvii

January 2015

a. Send request to all floors to update current status of the selected car (moving
direction, current floor).
b. Set traveling schedule to the car to guide it to reach the destination.
3. After step 2, the car and floor close the doors concurrently and change to ready status.
The moving process is executed and moving process is described above. After
finishing moving process, passenger gets out of the car and workflow is terminated.
6.2.2 Over-weight checking activity diagram

Elevator
System System

xviii

January 2015

6.2.3 Detect unsafe situation activity diagram

We detailed each process separately but in the real system, 3 activity diagrams above cooperated as I
mentioned in 6.1.

Elevator
System System

xix

January 2015

7.

Development View

7.1 Overview
The development view, also known as the implementation view, illustrates a system
from a programmers view. The development focuses on the software components that are
concerned with software management. A development diagram if the typical elevator system
is considering in this section.
7.2 Development diagram
The main task of the programmer is to build programs that help to control each
hardware component as well as synchronize the communication of these components in the
system. Under the programmers view, each program is able to be considered as a software
component. In the typical elevator system, there are components as listed bellows:
- System control: the program synchronizes system operations and processes all the
system messages.
- Algorithm: the program manages algorithms that help to pick out the best car to
serve and calculate the shortest path for cars travel.
- Car control: the program controls cars operation.
- Brake control: the program controls brakes operation.
- Bell control: the program controls bells operation.
- Floor monitor: the program controls objects at each floor such as buttons.
- Display control: the program controls Displays operation.
- Door control: the program controls doors operation.
An UML development diagram of the typical elevator system is depicted in the figure.
The diagram includes components and connections between them.

Elevator
System System

xx

January 2015

As shown in the UML diagram, the System control component is connected with Algorithm
and Car control by two dependency connections since it can call programs of these
components. Similarly, the Car control component is also connected with Door control, Floor
monitor, Bell control, and Brake control components by dependency connections. Finally,
the Floor monitor components is also connected with Door control and Display control since
there are only display and door at each floor.
8.

Deployment View

8.1 Overview
The deployment view, also known as the physical view, describes the system from a
hardware engineers point of view. On the other word, the deployment view focuses on the
hardware components of the system and connections between them. In this section, we will
concentrate on the deployment diagram for a typical elevator system.
8.2 Deployment Diagram
As we know, the first thing we have to do to create a deployment diagram is to
determine hardware components of the system and connections between them. We here
analysis the system under control flow of hardware components. It is very easy to recognize
from the system description that the typical elevator system has following hardware
components:
-

Elevator
System System

A main controller.

xxi

January 2015

Car motors.

Door motors.

Car keypads.

Floor keypads.

Brakes.

Displays.

Speakers.

Weight measurement.

After determining hardware components, we have a deployment diagram of the

typical elevator as shown in the figure. The connections between components are also added
into the diagram. The connections are being explained in detail in the next part of this
section.

Deployment diagram of the typical elevator system

Elevator
System System

xxii

January 2015

8.3 Connections between components

As shown in the figure, the system has a main controller (an ARM Cortex processor
for example) that is connected with other hardware components by many different
communication standards and controls the system wholly.
There are six different communication standards used to connect the main processor
with other components as bellows:
-

GPIO (General Purpose IO) is used to connect the main processor with brakes, car
motors and door motors.

9.

I2C is used to connect the main processor with the car keypads and floor keypads.

UART is used to connect the main processor with bells.

RS-232 is used to connect the main processor with display.

SPI is used to connect the main processor with speakers.

ADC signal is used to connect the main processor with the weight measurement.

Conclusion
DTCPII tool deployment has not been considered yet. All future implementation details will be
included in this section.

Elevator
System System

xxiii

January 2015