18-649 Project 12
Check the course webpage for due
Please submit all project-related correspondence to
- Dated entries will be added here if the project is modified after
it is released.
At this point, you have completed most of the design and testing of
your fast elevator. In this project, you will have to make a
single design change and continue testing on the updated
1. High Speed Drive
1.1 Update to High Speed Drive
Consider this scenario: at your most recent project meeting your boss
informs you that the marketing department has decided to change the
target audience for your elevator product (didn't you get the
memo?). Now, the elevator has
to exhibit even
better passenger delivery
performance. In order for you to meet your new
performance requirements, your boss has gotten approval to use new,
top-of-the-line drive motors which accelerate at the same rate, but
have a much higher maximum speed.
Modify your design to work with the new drive speed parameters:
To make the simulator run at the fast speed, you will need to add a
"-fs 5.0" command to your simulator invocations. This raises the
fast speed in the drive control to 5 m/s. Make sure you run all
acceptance tests from this point forward using the -fs 5.0
option. Note that you do not need to use this option with unit
and integration tests, since the DriveObject is not instantiated in
those tests. However, you may need to change the messages that
are injected in your tests to simulate the correct fast speed.
- "Fast" speed is now 5 m/s.
- Acceleration and deceleration remains 1.0 m/s/s.
- "Slow" speed remains 0.25 m/s.
Pay special attention to how this change affects your elevator.
In particular, you may want to consider:
single entry to the issue log that describes the
customer's change in requirements and documents the design artifacts
that this change causes. If you find bugs after the initial
change is complete (e.g. through testing), you should log those as
- how the stopping distance and
commit point computations are affected.
- how this
modification will impact your network schedule. Remember
that you must obtain prior approval from the course staff before
changing message periods.
1.2 Peer Review
other than the module author complete a peer review of the
updated modules and update the Peer Review section of your portfolio.
Peer reviews that result in unfixed issues should be added to the Issue
reviews need to be conducted. If you change fewer than four modules,
then you shall review other artifacts that have not yet been previously
2. Complete Testing of Your Elevator Design
You must run all tests on your latest design:
We will execute these tests with an arbitrary random seed which we will
not divulge ahead of time. Passing these tests constitutes
"having a working elevator". Note:
to receive a grade in this
- Pass all unit tests - all tests
- Pass all integration tests - all
tests must pass with 0 failed assertions.
acceptance tests - run the following acceptance tests. Be sure to
the "-b 200 -fs 5.0" options to enable the finite bandwidth and new
fast speed settings. Your elevator must not reach 100% bandwidth
utilization when running acceptance tests.
Team Design Portfolio
The portfolio you submit should contain the most up-to-date design
package for your elevator system organized and formatted according to
guidelines. You are going to update
portfolio every week, so be sure to keep an up to date working
Ensure your design portfolio is complete and consistent.
The following is a partial list of the characteristics your portfolio
- Changes requested by the TAs in previous projects have been
- All required documents are complete and up-to-date to the extent
required by the projects (you do not need to update files or links
related to future projects).
- All documents include group # and member names at the top of the
document. (This includes code, where this information should
appear in the header field)
- Individual documents have a uniform appearance (i.e., don't look
like they were written by 4 individual people and then pieced together)
- The issue log is up to date and detailed enough to track changes
to the project.
Handing In Results
- Each team shall submit exactly one copy of the
- Follow the handin instructions detailed in the
Project FAQ to submit your portfolio into the afs handin directory (/afs/ece/class/ece649/Public/handin/proj12/group#/ontime/).
- Be sure you
follow the required format for the directory structure of the portfolio
and its location in the handin directories.
- Be sure to follow ALL
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).
This project counts as one team grade. Points are assigned as
follows. A detailed grading
rubric is available here.
This project assignment is worth 105 points:
- 20 points for the 5.0
m/s design change
- 20 points for 4 peer
reviews of the updated modules in the Peer
- 20 points for completely
passing all unit tests
- 20 points for completely
passing all integration tests
- 20 points for running
all acceptance tests and either passing the
tests or logging the results.
- 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.
Back to course home page