This document summarizes a final project report for an elevator dispatcher design. It includes an overview of the dispatcher design process and requirements. A state chart shows the dispatcher's states and transitions. The implementation traces the state chart to code. Testing involved 10 acceptance tests and a runtime monitor. Project statistics on code quality and testing are provided. Lessons learned include starting early and working together. Design choices focused on simplicity. Advice includes using source control and reviewing assignments early.

1. 1
ECE 18-649
Final
Project Report
Dec 2, 2012
Group # 9
Dennis Liang
Leo Lung
Melvin Rayappa
Samihan Yedkar
Melvin Rayappa

2. 2
Overview
 Dispatcher Design Process
 Dispatcher overview
 High Level Requirements
 Behavior
 Time Triggered Requirements
 State Chart
 Implementation
 Testing
 Runtime Monitor
 Project Statistics
 Lessons Learned
 Strategies
 Design Choices
 Advice
Melvin Rayappa

3. Dispatcher Object
 Dispatcher - determines the order in which
floors and hallways are serviced
 High Level Requirement:
 R-T1. All passengers shall eventually be
delivered to their intended destination floor
3
Inputs Outputs
mAtFloor [f,b] mDesiredFloor
mDoorClosed [b,r] mDesiredDwell
mHallCall [f,b,d]
mCarCall [f,b]
mCarWeight
Melvin Rayappa

4. Dispatcher Object
 High Level Requirement:
 R-T4. The performance shall be optimized to
the extent possible
 R-T5. Passenger satisfaction shall be optimized
to extent possible
 R-T6. The Car shall only stop at floors for
which there are pending calls
4
Melvin Rayappa

5. Dispatcher Object
 High Level Requirement:
 R-T7. The Car shall only open Doors at
Hallways for which there are pending calls
 Dispatcher determines which floors to stop at
 R-T8.2. If one of the car lanterns is lit, the
direction indicated shall not change while the
doors are open
 Dispatcher changes desired direction
5
Melvin Rayappa

6. Dispatcher Algorithm
 Service in “cycles”
 Service all calls in one direction, then turn
around and repeat
 Peak – farthest floor in the direction of
travel
 Target – the desired floor
 Travel – current cycle direction
6
Melvin Rayappa

7. 7
Requirements
Time Triggered Requirements:
•11.4 mDesiredFloor.f shall always be set to Target.
•11.5 If target equals peak and there are no hall calls at the target floor in
the same direction, reverse Direction.
•11.6 Whenever any mDoorClosed [b, r] is False, then
• 11.6.1 Target shall be set equal to the closest car call or hall call (of
the same direction as current) between current floor and the peak.
• 11.6.2 mDesiredFloor.b shall be set to b, where f, b is whichever
mAtFloor[f, b] is True
• 11.6.3 mDesiredFloor.b shall be set to Direction
•11.7 If all mAtFloor[f, b] are False AND any mDoorClosed [b, r] is False (which
means doors are not closed between floors!) then
• 11.7.1 Target shall be set to 1
• 11.7.2 mDesiredFloor.b shall be set to None .
•11.8 If two mAtFloor[f, b] values are True with the same value f, then
mDesiredFloor.b shall be set to Both.
•11.9 mDesiredDwell shall always be set to a constant appropriate value for door
open dwell.
•11.10 Peak shall always be set to the farthest hall call or car call in the
same direction as current.
Melvin

8. State Chart
8
Dennis Liang

9. Statechart – Transition 1
 Moving from ‘Idle’ to
‘Moving’
 Condition
 Travel != Direction.STOP
9
Dennis Liang

10. Statechart – Transition 2
 Moving from ‘Idle’ to ‘Door open’
 Conditions
 One mDoorClosed[f,*] == false, one mAtFloor[f,*] == true,
travel == Direction.STOP
10
Dennis Liang

11. Statechart – Transition 3
 Moving from ‘Moving’ to ‘Door open’
 Conditions
 One mDoorClosed[f,*] == false, one mAtFloor[f,*] == true
11
Dennis Liang

12. Statechart – Transition 4
 Moving from ‘Door open’ to ‘Idle’
 Conditions
 Both mDoorClosed[f,*] == true, target == floor == peak
12
Dennis Liang

13. Statechart – Transition 5
 Moving from ‘Moving’ to ‘Door open’
 Conditions
 Both mDoorClosed[f,*] == true, floor != target or target != peak
13
Dennis Liang

14. Statechart – Transition 6 & 7
 Moving from ‘Idle’ and ‘Moving’ to ‘Error’
 Conditions
 One mDoorClosed[f,*], all mAtFloor[*,*] == false
14
Dennis Liang

15. 15
Implementation
Dennis Liang
case MOVING:
if (target == peak)
direction = getCallDirection(target, direction);
else {
if (travel == Direction.UP)
direction = Direction.UP;
else
direction = Direction.DOWN;
}
if (direction == Direction.STOP)
hallway = getCallHallway(target);
else
hallway = getCallHallway(target, direction);
mDesiredFloor.setFloor(target);
mDesiredFloor.setDirection(direction);
mDesiredFloor.setHallway(hallway);
...
//#transition "11.T.3"
if (!mDoorClosedArrayFront.getBothClosed() ||
!mDoorClosedArrayBack.getBothClosed() &&
floor != MessageDictionary.NONE)
newState = State.DOOR_OPEN;
State Action
SC to Code Traceability
Transition
Implementation
Implicit DesiredFloor
Computation

16. 16
Testing
 10 acceptance tests
 All test ability of Dispatcher to deliver passengers
 All Dispatcher states except for error tested
 Runtime Monitor
 Test car only stops at floors with pending calls
Leo Lung

17. 17
Strategies for Correctness
 Pair Programming
 Ensure correct code gets committed
 Catch bugs as we develop
 Overnight Testing
 Run acceptance tests overnight
 Ensure no corner cases from specific seeds
Leo Lung

18. 18
Project Statistics
Leo Lung
Item MidSem Final
# of Sequence Diagrams 19 19
# of Sequence Diagram arcs 181 181
# of Requirements 53 49
# of Statecharts 7 7
# of Statechart States 20 21
# of Statechart Arcs 27 32
# of Non-Commented Lines of Code 1912 2802
# of Unit Tests 7 7
# of Integration Tests 19 19
# of Acceptance Tests 3 10

19. 19
Project Statistics
Leo Lung
Item MidSem Final
# of Peer Reviews 69 97
# of Bugs Found through Peer
Reviews
29 39
# of Bugs Fixed through Peer
Reviews
29 39
# of Bugs Found through Testing 23 35
# of Bugs Fixed through Testing 23 35
# of Issue Log Entries 16 23
# of Unresolved Defects 3 4
# of Change Log Entries 13 17

20. Lessons Learned
 Start early; iterate often
 Dispatcher has evolved to its current state,
based on multiple design iterations
 Work together
 Especially on system critical controllers,
important to have all hands on deck
 Whiteboarding solutions
 Brainstorming, sanity checking, optimizing
 Focus on simplicity
 Dispatcher as just 4 states, clear and
straightforward transitions
 Easy to debug
20
Samihan Yedkar

21. Design Choices
 Implicit target, peak, travel, direction,
hallway
 Computed within state itself
 Saves additional states
 Code compaction
 Algorithm is easy to test
 CommitPoint computation in FastSpeed
state
 Done dynamically
 Based on equations of motion
 1m buffer added for safety/hedge against
strange behaviors: err on the side of caution
Samihan Yedkar
21

22. Advice
 Use source control
 Review lab assignment early
 Email team to plan strategy
 Divide responsibilities based on controller efficiency
 Work together
 Incredibly helpful to bounce ideas and thoughts
 Whiteboard solutions
 Pair program
 Peer review
 Go over checklist right before submission
 Sanity checking
Samihan Yedkar
22

23. 23
Questions?
Group # 9
Dennis Liang
Leo Lung
Melvin Rayappa
Samihan Yedkar
Samihan Yedkar

24. Backup Slides
24
Transition Condition
11.T.1 travel != Direction.STOP
11.T.2 (mDoorClosed[f,FRONT] === false || mDoorclosed[f,BACK]
== false) &&
(mAtFloor[f,FRONT] == true || mAtFloor[f,BACK] == true)
&&
(travel == Direction.STOP)
11.T.3 (mDoorClosed[f,FRONT] === false || mDoorclosed[f,BACK]
== false) &&
(mAtFloor[f,FRONT] == true || and mAtFloor[f,BACK] ==
true)

25. Backup Slides
25
Transition Condition
11.T.4 (mDoorClosed[f,FRONT] === true && mDoorclosed[f,BACK]
== true) &&
(floor == target && target == peak)
11.T.5 (mDoorClosed[f,FRONT] === true && mDoorclosed[f,BACK]
== true) &&
(floor != target || target != peak)
11.T.6 (mDoorClosed[f,FRONT] === false || mDoorclosed[f,BACK]
== false) &&
(mAtFloor[f,FRONT] == false && mAtFloor[f,BACK] == false)
11.T.7 (mDoorClosed[f,FRONT] === false || mDoorclosed[f,BACK]
== false) &&
(mAtFloor[f,FRONT] == false && mAtFloor[f,BACK] == false)

26. Backup Slides
26

27. Backup Slides
27
Requirements
States 11.4 11.5 11.6.1 11.6.2 11.6.3 11.7.1 11.7.2 11.8 11.9 11.10
State 1: Idle X X X X X
State 2:
Moving
X X X
State 3:
Door open
X X X X X X
State 4:
Error
X X X X

28. Backup Slides
28
Requirements
Transitions 11.4 11.5 11.6.1 11.6.2 11.6.3 11.7.1 11.7.2 11.8 11.9 11.10
11.T.1
X
11.T.2 X X X
11.T.3 X X X
11.T.4
X
11.T.5
X
11.T.6 X X
11.T.7 X X

29. 29
Dispatcher Scenario/Sequence Diagram
Melvin Rayappa
 Use Case U9. Cycle Doors.
 Scenario/SD 9A: Elevator stops at Hallway. Dispatcher computes desired floor
Dispatcher
computes and
broadcasts
desired floor
Dispatcher
broadcasts
desired dwell
time

30. Backup Slides
30

31. Backup Slides
31

32. 32