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

ElevatorSystem 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

3.1. Security.................................................................................................................................... 4

3.2. Persistence............................................................................................................................... 4

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

3.4. Performance............................................................................................................................. 4

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

4.1. Actors....................................................................................................................................... 6

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

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

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

ElevatorSystem System iii January 2015

of the elevator system as a whole. 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.

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

1.3. Definitions, Acronyms, and Abbreviations

User (passenger): Person who uses elevator’s 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.

1.4. 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/

ElevatorSystem 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 viewAudience: 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 viewAudience: 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.

ElevatorSystem System v January 2015

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

Data viewAudience: Data specialists, Database administratorsArea: Persistence: describes the architecturally significant persistent elements in the data model Related Artifacts: Data model.

Deployment viewAudience: 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.

ElevatorSystem 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 car’s 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 car’s 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 car’s 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 floor’s keypad they call this action for a

service.

ElevatorSystem 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 floor’s 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

ElevatorSystem 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 floor’s 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 Floor’s controller to open its door.

12. The car plays a sound before opening the door.

13. Two doors (car’s door and floor’s 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 car’s keypad

2. The Car sends target floors to the Controller

ElevatorSystem System ix January 2015

3. The Controller runs a process to calculate a moving schedule of this car4. The Controller set the new schedule to this car5. At the same time, The Controller send the update info for all Display in floors6. The Floor which have the current use will close this door7. The door of this car also close at the this moment8. Finally, the car move to this target. This process is same as the moving process in scenario 1

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

o calTravelSchedule(): Update the travel schedule for a car when user update change/add/remove/quest the target floor.

o setTravelSchedule(): The Schedule for a car

o findTheServingCar(): Find the best suitable car go to the user’s floor.

- Car:

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

o Move(): Control the movement of the car.

o OnReachedNextFloor(): Send message to controller, in order to request Controller to open current door of floor.

o OnReachedTargetFloor(): Request Controller to open the door when it reached a target floor

o slowDown(): Stop the car when receive the command from the Controller

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

o holdOpen/forceClose(): Open/Close the door when user require

- Floor-Controller:

o Send request car to Controller when a User press a button -> SendCarRequest()

ElevatorSystem System x January 2015

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

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

5.3. Class diagram

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

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

ElevatorSystem System xii January 2015

ElevatorSystem 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

ElevatorSystem System xiv January 2015

ElevatorSystem 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, there’ll be only [UP] button and so on, if user is at the

highest floor, there’ll 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.

ElevatorSystem 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 floor’s 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. Car’s light is turn ON.

b. Car’s door is opened.

c. Floor’s 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 car’s

keypad.

1. Car’s processor gets and processes user’s 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:

ElevatorSystem 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

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

ElevatorSystem System xix January 2015

7. Development View

7.1 Overview

The development view, also known as the implementation view, illustrates a system

from a programmer’s 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 programmer’s 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.

ElevatorSystem 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 engineer’s 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:

- A main controller.

ElevatorSystem System 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

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

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

9. Conclusion

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

ElevatorSystem System xxiii January 2015