18-649 Project 11

Check the course webpage for due dates

Please submit all project-related correspondence to


At this point, you have completed most of the design and testing of your fast elevator.  In this project you will complete testing on the updated 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 statechart for each requirment that your runtime monitor is checking. The statechart should mirror the actual state of the elevator and contain both valid and invalid states. An example statechart for the requirement "never stops on floor 6" might look something like this:

Sample statechart

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 simulator.framework.RuntimeMonitor.

Your runtime monitor shall meet the following requirements:

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.

It might be that you receive a handful (4 to 6) warnings that are due to unusual passenger conditions that put your elevator into a gray area of the specifications (perhaps one you didn't realize you had). An example is if a passenger gets on and then gets off at the same floor/hall. Many teams execute all acceptance tests including the final project with no warnings. If you have a handful of warnings through the final project and they are a result of benign corner cases such as this then that will be OK. (You MUST receive TA approval for any warnings; don't use this as an excuse to blow off things that really do need to get fixed.) Many teams have projects with NO warnings, and we encourage you to get there if you can. In every case we have seen, any team with more than 10 warnings on a huge acceptance test we run for the final project has bugs in their elevator.

The point of the grading monitor is so that students don't slack on their own monitor and then pass all test because their own monitor ignores problems. So if there is a conflict between your monitor and the grading monitor (i.e., your monitor says "OK" and TA monitor doesn't), then what you need to do is help the TAs understand that your monitor is doing a sufficient job in those cases. This should consist both of explaining why representative violations aren't a real problem, and also walking the TAs through the monitor design so they can see that you are monitoring the right stuff.

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 of your 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 appropriately.

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.

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:

Handing In Results

Grading Criteria:

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:

Each team member must satisfy the minimum stated per-member requirements. Team members who omit any required per-member activity will receive a zero contribution grade.
Back to course home page