Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Group9 f12 18649_final_presentation

210 views

Published on

no

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Group9 f12 18649_final_presentation

  1. 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. 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. 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. 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. 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. 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. 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. 8. State Chart 8 Dennis Liang
  9. 9. Statechart – Transition 1  Moving from ‘Idle’ to ‘Moving’  Condition  Travel != Direction.STOP 9 Dennis Liang
  10. 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. 11. Statechart – Transition 3  Moving from ‘Moving’ to ‘Door open’  Conditions  One mDoorClosed[f,*] == false, one mAtFloor[f,*] == true 11 Dennis Liang
  12. 12. Statechart – Transition 4  Moving from ‘Door open’ to ‘Idle’  Conditions  Both mDoorClosed[f,*] == true, target == floor == peak 12 Dennis Liang
  13. 13. Statechart – Transition 5  Moving from ‘Moving’ to ‘Door open’  Conditions  Both mDoorClosed[f,*] == true, floor != target or target != peak 13 Dennis Liang
  14. 14. Statechart – Transition 6 & 7  Moving from ‘Idle’ and ‘Moving’ to ‘Error’  Conditions  One mDoorClosed[f,*], all mAtFloor[*,*] == false 14 Dennis Liang
  15. 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. 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. 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. 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. 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. 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. 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. 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. 23 Questions? Group # 9 Dennis Liang Leo Lung Melvin Rayappa Samihan Yedkar Samihan Yedkar
  24. 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. 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. 26. Backup Slides 26
  27. 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. 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. 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. 30. Backup Slides 30
  31. 31. Backup Slides 31
  32. 32. 32

×