18-649 Project 11
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.
- Clarification Update: The High Level Reqirements log is the Verification Results section of the verify/verfication.html file.
At this point, you have completed most of the design and testing of
your fast elevator. In this project you will complete testing on
elevator. You will also use runtime monitoring to verify that
your design meets high level requirements.
1. Verifying High-Level Requirements with Runtime Monitoring
You must demonstrate that your elevator system meets the high level
requirements that were added in Project 8 (R-T6 through
R-T10). If needed, review the Runtime Monitoring Overview
from Project 7.
1.1 Write a Description of Your Runtime Monitor
To start out, you will provide a written description of your strategy
for runtime monitoring. Take a look at the inputs provided by the
Runtime Monitor class. For each high level requirement state one
or more specific run-time checks you could perform to ensure that
requirement is being met. For example, if a high level
requirement were "never stops at floor 6" you could write a monitor
that threw a warning every time the motor was commanded to stop while
the elevator was at floor 6. You must also include a
for each requirment that your runtime monitor is checking. The
mirror the actual state of the elevator and contain both valid and
An example statechart for the requirement "never stops on floor 6"
might look something like this:
If your elevator ever enters an invalid state, then you should throw a warning.
In your writeup, address each
of the high level requirements R-T6
through R-T10. (Hint: You may want to use a different statechart for
each part of R-T8.) Add your
writeup to the High Level
Requirements Verification page. Your
writeup must convince us that your
verification system enforces all high-level
requirements. Your writeup may not exceed 700 words.
1.2 Write a Runtime Monitor
Now you will implement the checks you described in part 1.1
above. Add a new class to the simulator.elevatorcontrol package
called Proj11RuntimeMonitor. Be sure you use the right name
because the monitor may be graded by an automated script that relies on
this name. Make sure Proj11RuntimeMonitor extends
Your runtime monitor must meet the following requirements:
- Your runtime monitor must
demonstrate that it
has no false negatives: if there is a violation of any of the
requirements, the violation must be detected and your
verifier must clearly indicate which requirement was
monitoring code must belong to the simulator.elevatorcontrol
package (the same directory as your other code) and be called
Proj11RuntimeMonitor. You must include the
code in the elevatorcontrol/ folder of your portfolio and fully link
and document all Java files in the package.html file, just like all the
rest of your code.
- Your monitor must be a subclass of the simulator.framework.RuntimeMonitor
- Your monitor must check each high level requirement and generate
a warning (using the provided warning() class in the RuntimeMonitor
parent class) if any high level requirement is violated. The
warning must name the
requirement that was violated and give a descriptive message of how it
was violated. For example , "R-T.6 Violated: Car stopped at
floor 5 FRONT when there were no pending calls."
If your monitor does
more than monitor the system (e.g. outputs any framework or network
messages, or affects the simulation state in any way, you will receive
significant deductions on the final assignment.
It is acceptable for your
monitor not to throw warnings during startup, but it must register any
violations of the high level requirements that occur after the elevator
has moved for the first time.
In order to verify that your design meets the requirements, we will
run your elevator against our own runtime monitor. Although the
grading monitor is not provided, you will receive the output of our
tests in your project feedback.
1.3 Peer Review the Runtime Monitor
For this project you will be peer reviewing your Runtime Monitor. You
must submit a formal peer review document for each portion
Runtime Monitor that traces to each of the high level requirements R-T6
through R-T10. Make sure to update the Peer Review Log and Issue Log
1.4 Execute the Runtime Monitor
Execute at least the following acceptance tests using the runtime
monitor. Log the tests, the test results, and any comments in the
High Level Requirements
Verification page of your portfolio.
2. Complete testing of your design
You must run all tests on your latest design:
For your final project handin, you will have to pass all
acceptance tests and turn in a complete and consistent design package,
so plan ahead accordingly.
- Pass all unit tests - all tests
NOT have to run with the "-b 200" option.
- Pass all integration tests - all
tests must pass with 0 failed assertions. You do NOT have to
run with the "-b 200" option.
- All acceptance tests - rerun all the acceptance tests listed
Be sure to use the "-b 200" option to enable the finite
bandwidth setting. You are not required
for this project,
but you must include a detailed description of the issues that are
preventing the elevator from passing any test.
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/proj10/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 115 points:
- 20 points for 4 peer
reviews of the updated Runtime Monitor 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.
points for your
runtime monitor, description, and the Verification Results log ( description and log are both located in verify/verfication.html).
- 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