18-649 Project 11

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.
Clarification Update: The High Level Reqirements log is the Verification Results section of the verify/verfication.html file.

Assignment:

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:

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 must meet the following requirements:

Your runtime monitor must clearly demonstrate that it has no false negatives: if there is a violation of any of the high-level requirements, the violation must be detected and your verifier must clearly indicate which requirement was violated.
Your 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 class.
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 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:

Pass all unit tests - all tests must pass with 0 failed assertions. You do 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 below. Be sure to use the "-b 200" option to enable the finite bandwidth setting. You are not required to pass these tests for this project, but you must include a detailed description of the issues that are preventing the elevator from passing any test.

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:

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/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 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 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 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.
30 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