18-649 Project 4

Time-Triggered Design Using Statecharts

Due Thursday February 12, 2009 at 11:59 PM

Please submit all project-related correspondence to -- thanks!

Changelog:

This semester, your group will specify, design and build an elevator control system and use it to control a simulated elevator. You will learn of and deal with many of the details of building a distributed, real-time, embedded system.

In project 3, your project matured from concept to specification when you wrote the event-triggered behaviors for some of the controllers. In this project, you and your group will design the time-triggered behavioral requirements for those controllers. Then, you will express each controller using a state chart.

Assignment

You will transform your requirements specification from an event-triggered system to a time-triggered one, and complete a detailed design document. No longer are there discrete events that cause information processing and state changes in your controllers. In your time-triggered system, once during each cycle (we use cycle here as some unit of time determined by processing and control needs) a time triggered machine looks at the information it has available to it, possibly calculates some internal variables, and decides whether it should transition to a new state. For each non-environmental object, you will complete a detailed design using UML state charts as described in the required reading.

PLEASE KNOW THAT CODE AND DESIGN ARE DIFFERENT THINGS. Code should be well designed, but there should be no actual code in your design. If there is code, it is not a design, and so it will be graded as code and not a design---which means you will earn no points for that submission item. Pseudo code is acceptable for expressing guard conditions, state outputs, and so on, but you should use it as little as possible.

The procedure for this assignment is:

  1. Rewrite your event-triggered behavioral requirements to be time-triggered. This means that a behavior can use multiple input conditions to cause an action. This may or may not be necessary for your group, but if you found yourselves doing tricky state variable manipulation to get a correct event-triggered behavior that would be simpler and easier if only you could have two or more events trigger a behavior, it's probably best to rewrite the requirement to make your design simpler.
  2. Keep track of changes to your design using the issue log.  If you make any substantive changes to your behavioral requirements (such that an outside observer would notice a different behavior), you must document those changes in the issue log which is included with the project portfolio template.  If, in the course of writing requirements or statecharts, you find that you must add or modify your scenarios and sequence diagrams, you must document these changes in the issue log as well.
  3. Design a state chart for each non-environmental control object: The state charts shall be time-triggered with guard conditions, not event-triggered. Although you may not agree with this design choice, you are required to design a pure time-triggered system.  Time triggered design is a often a good choice for reliable, distributed systems, and our goal is to teach you this technique.  For detailed information about time-triggered design, see the following section of this writeup and the course lecture notes.
  4. Ensure backward and forward traceability by documenting the relationships between each behavior requirement and each state chart transition arc or state. In order to do forward and backward traceability in one table, construct a table with the requirement numbers across the first row and the states and transitions down the first column.  Put an X in the appropriate cells to indicate that a state/transition supports a requirement. See the example. A correct design will have at least one state or transition for each requirement and at least one requirement for each state or transition. So, every row and every column should have at least one X in it.
  5. Turn in your complete team design package.

Time-Triggered Design Overview

Follow these guidelines when doing your time-triggered design.  These guidelines are very strict, but are intended to guide you down the path to a time-triggered design.  In some cases, these requirements are more restrictive than other guidelines (such as some UML techniques which we specifically prohibit).  These restrictions are in place to prevent you from making design choices that will make your life more difficult later on.

In this project phase, you may not change the input or output interfaces for any of the control objects.

Time Triggered Requirements

Time triggered requirements DO:

Time Triggered Statecharts

Time triggered statecharts DO:

Time triggered statecharts DO NOT:

UML has a very rich syntax for defining nested statecharts.  We advise you to avoid nested states as much as possible.  However, if you choose to use nested states, observe these additional restrictions:

Additional Notes

Note that transition actions and entry actions are specifically prohibited.  These are very tricky to get right in implementation, and can easily lead to deadlock or other race conditions. In general, if you think you cannot avoid these, then you can implement them in a strict time-triggered way using intermediate states.  However, we urge you to avoid this approach.  Intermediate states add latency and complexity.  If you choose to use intermediate states in your design, note that they must follow all the guidelines for normal states (like setting all outputs).  In the implementation phase, you will not be allowed to make more than one transition in a single execution of the controller.

Examples

For an example of time-triggered requirements, statecharts, and traceability, you may refer back to the TestLight example from Project 1.

You may notice that the passenger object specification has actions on transitions.  This is because the passenger is inherently event driven.  For this reason, you should not base your design on the passenger specification.



If you find any problems or "bugs" with the assignment, please let us know immediately so we can fix it. While we'll do everything we can to give you a quick response, there are reasonable limits to our availability. If we have to make a change we'll announce the change on blackboard. In the unlikely event we make a major and/or urgent change, an email from the course staff will accompany any announcement on blackboard.

Team Design Portfolio

The portfolio you submit should contain the most up-to-date design package for your elevator system organized into the following directories.  You are going to update your portfolio every week, so be sure to keep an up to date working copy. 

Files that you should update for this week are:

Ensure your design portfolio is complete and consistent

The following is a partial list of the characteristics your portfolio should exhibit:

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/project4/group#/ontime/).

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).

If you don't already have an ECE account send e-mail to gripe@ece.cmu.edu and Cc to staff list requesting a course account for 18-649.

This is probably a new experience for most of you. We don't expect perfection. We expect an honest, good-faith attempt to complete the assignment, getting as much help as is appropriate from your classmates and lab partners. We suggest you leave at least a week of time to think about the requirements. There is not too much writing for this project, but quite a lot of thinking. If you stumble we'll make sure you get fixed up before the next project segment, and in fact will hand out a complete set of requirements as the solution set. (BUT, if you really want to win the performance contest, you'll probably have to be a bit more clever than the baseline solutions we help people come up with...) You'll be allowed to change the behaviors in later labs for optimization and debugging, but you should give this your best shot. (In particular, we expect that people will take several project phases to create a good dispatcher, as some things just can't be specified well without a lot of experimentation.)

Grading Criteria:

Grading will be based on providing a complete state chart design for each control object for which you are responsible, and documented traceability between the state chart transition arcs and states and your group's requirements specification.  Consistency and coherence (your design must match your requirements) are the two criteria we're looking for.  We will not be grading your new requirements specifications beyond making sure that they match your state charts and are time-triggered, but keep in mind that effort spent now in producing a good design is likely to reduce the amount of time you will spend during unit and integration testing. So, it's a good idea to make updates as you go.

This assignment counts as one team grade.

Grading will be as follows 115 points total

Course home page