18-649 Project 12
Check the course webpage for due
dates
Please submit all project-related correspondence to

Changelog:
- Dated entries will be added here if the project is modified after
it is released.
Assignment:
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
elevator.
1. High Speed Drive
Modification
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:
- "Fast" speed is now 5 m/s.
- Acceleration and deceleration remains 1.0 m/s/s.
- "Slow" speed remains 0.25 m/s.
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.
Pay special attention to how this change affects your elevator.
In particular, you may want to consider:
- 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.
You
should
add
a
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
design
change is complete (e.g. through testing), you should log those as
separate issues.
1.2 Peer Review
Have
someone
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
Log.
Four peer
reviews need to be conducted. If you change fewer than four modules,
then you shall review other artifacts that have not yet been previously
reviewed.
2. Complete Testing of Your Elevator Design
You must run all tests on your latest design:
- Pass all unit tests - all tests
must
pass
with
0
failed
assertions
- Pass all integration tests - all
tests must pass with 0 failed assertions.
- All
acceptance tests - run the following acceptance tests. Be sure to
use
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.
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:
You
must
pass
all
acceptance
tests
in
order
to receive a grade in this
course.
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
the portfolio
guidelines. You are going to update
your
portfolio every week, so be sure to keep an up to date working
copy.
Ensure your design portfolio is complete and consistent.
The following is a partial list of the characteristics your portfolio
should exhibit:
- Changes requested by the TAs in previous projects have been
applied.
- 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
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/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
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:
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
Review
Log.
- 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