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.
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
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
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
mDesiredDwell – one per hallway - A numeric value indicating the desired dwell time for the door. mDesriedFloor - The desired floor, hallway, and direction
mDesiredDwell – one per hallway - A numeric value indicating the desired dwell time for the door. mDesriedFloor - The desired floor, hallway, and direction
mDesiredDwell – one per hallway - A numeric value indicating the desired dwell time for the door. mDesriedFloor - The desired floor, hallway, and direction
mDesiredDwell – one per hallway - A numeric value indicating the desired dwell time for the door. mDesriedFloor - The desired floor, hallway, and direction