18-649 Project 8

Smart Dispatcher, Fast Speed, and Correct Lanterns

Due March 19, 2009, at 11:59 PM

Please submit all project-related correspondence to

Changelog:

Dated entries will be added here if the project is modified after it is released.

Assignment

Before spring break your group specified, designed and implemented a simple elevator. The dispatcher for this elevator was required to be very simple and was also quite inefficient. Now that you have an elevator that will pass basic acceptance tests, you will be required to enhance and improve your elevator.

Assignment #8 requires you to design (not implement; you probably won't write any code this week) a more intelligent and realistic elevator dispatcher. You will create sequence diagrams and some state charts, but you are not required to write code. If you decide to work ahead, you should plan how you will test your improved elevator before you write any code.

TA meeting note: Be sure that you understand all the fields of the DesiredFloor(f,b,d) message before you go to your weekly TA meeting to discuss this project assignment! This is one of the trickiest parts of the elevator behavior, but it is essential to get it right.

The goal of this assignment is an improved dispatcher that makes your elevator behave in a more realistic and efficient manner. The basic dispatcher stops at every floor regardless of the passengers needs, and omits many basic functionalities we expect from elevators. To improve upon this behavior, your improved dispatcher must fulfill the additional set of high-level requirements below. In addition, you can begin to design in other optimizations and states if you choose to increase the passenger delivery performance metric. Enhancing the dispatcher to some degree now is a good idea, but keep in mind that adding more features will increase your testing load in the next phase of the project. Please plan accordingly.

New High-Level Requirements

From this project forward, your elevator shall meet the following additional high level requirements.

R-T4: The Drive shall be commanded to fast speed to the maximum degree practicable.
R-T5: The Car shall only stop at Floors for which there are pending calls.
R-T6: The Car shall only open Doors at Hallways for which there are pending calls.
R-T7: The Car Lanterns shall be use in a way that does not confuse passengers.

RT7.1: If any door is open at a hallway and there are any pending calls at any other floor(s), a Car Lantern shall turn on.
RT7.2: If one of the car lanterns is lit, the direction indicated shall not change while the doors are open.
RT7.3: If one of the car lanterns is lit, the car shall service any calls in that direction first.

Note: In the above requirements, it is permissible for the dispatcher to synthesize calls (via the mDesiredFloor message) in addition to passenger-initiated hall calls and car calls. This might become important for later project phases (for example up-peak optimization and fault tolerance).

Note: These high level requirements may conflict with some of the simple controller behaviors provided in the first half of the course. If you have been using those behaviors up to this point, you will need to modify them in order to meet these new requirements.

Go here to get the drive acceleration profile from project 3.

Optional Modifications to Network Interfaces

In order to facilitate more sophisticated and optimized dispatcher behaviors, you may make the following changes for this project or in any future project (when you are ready to do more optimization). Note that these changes are not required. You should be able to fully meet all high level requirements with the existing interfaces.

You may make one and only one of the following modifications to the input interface.:

Add mCarPositionIndicator to the input of the Dispatcher and DriveControl, OR
Add mDriveSpeed and mCarLevelPosition to the input of the Dispatcher.

If you make one of the above modifications, you must update the input interfaces for the appropriate controllers in the Requirements II document to reflect the change. You must also include a note in the requirements document that explains the purpose of the change and justifies why it is necessary.
Remember that all your documentation (including sequence diagrams) needs to be up to date, so changes to the interfaces will likely mean changes throughout the project. Be sure you log this change in your issue log and track all the resulting changes.
If you wish to make any modification other than one of the ones listed above, you must first obtain approval from one of the TAs. In that case, be sure to ask the TA how to document the change in your portfolio.

Improved Dispatcher Design

To design this dispatcher, you must create new sequence diagrams and some state charts. These changes may reach beyond the dispatcher module and these effects must be documented. Traceability must be updated and complete, including adding the above five high level requirements to the set of high level elevator requirements in the Requirements I document and tracing them throughout the design process.

The design package must reflect your dispatcher changes including:

all necessary new Sequence Diagrams
updated behavioral requirements for all controller objects
a new statechart for the dispatcher (statecharts for other objects are optional).

A large part of this assignment is following process and keeping your design package up to date.

A check-off list of all modified sequence diagram(s) is required. Add a checklist for each sequence diagram to the Scenarios and Sequence Diagrams document after the SD that it corresponds to. Have another team member perform this check. This check is minimal (we recommend you use the longer checklist from lectures, but the below simplified checklist is all that is mandatory):

Does each step in the scenario match an event in the sequence diagram?
Are all arcs labeled with a valid command in the sequence diagram?
Are all boxed items correct parts of the elevator architecture?

All behavioral requirements must be updated to account for the new and modified SDs. Be sure you update all traceability.

This week the only statechart you must update is your Dispatcher statechart. You can do the rest if you like and get ahead on things, but the Dispatcher statechart is the one we will be grading.

Update Your Design Portfolio

For this project, you will use the same portfolio structure as you have in previous projects. All of the files you submit for this project should have the same names and purposes as they had in previous projects. The contents of a file may change in this project (such as updating a statechart), but the purpose of each file renames the same (such as containing a complete list of all behavioral requirements and statecharts). If you create any new files (such as tests) that you want the course staff to see and give feedback on, your portfolio must have links to those files.

As always, if you change any part of your design, you must make the change to the appropriate documents in your portfolio, and that change must trace forward and backward to all other relevant documents. In particular, for this week you will probably update:

Behavioral requirements for all control objects.
Requirements/constraints traceability.
Statechart and traceability for the Dispatcher. You will make statecharts and show traceability for the other six control objects in the next project.
Scenarios and sequence diagrams.
Requirements/constraints traceability.

Any changes you make must be documented in your Issue Log.

Handing In Results

Each team shall submit exactly one copy of the assignment.

Follow the handin instructions detailed in the Project FAQ to submit your portfolio into the afs handin directory (/afs/ece/class/ece649/Public/handin/project8/group#/ontime/).

Be sure to follow ALL the portfolio guidelines detailed in the Portfolio Layout page.

Any submission that contains files with modification dates after the project deadline will be considered late and subject to a grade deduction (see course policy page for more information).

Grading Criteria:

This assignment counts as one team grade. If you choose to divide the work, remember that you will be graded on the whole assignment.
Project 8 is worth 65 points:

10 points for updated scenarios and sequence diagrams.
10 points for updated behavioral requirements.
5 points for updated Dispatcher statechart.
10 points for updated traceability.
5 points for the sequence diagram checklist.
20 points for complete design package and following all hand-in instructions.
5 points for an entry in the Improvements Log that tells us what can be improved about this project. If you encountered any minor bugs that we haven't already addressed, please mention them so we can fix them. If you have no suggestions, say so in your entry for this project.

If you choose to work ahead and go beyond the requirements for this project, that is fine. However, we may or may not provide feedback the parts of your design package that were not required. As with previous project phases, you must meet all the stated project requirements for this phase regardless of how much extra stuff you attempt to include.

Back to course home page