18-649 Project 4

Time-Triggered Design Using Statecharts

Check the course webpage for due dates

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


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.


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. This applies to requirements as well as statechart actions and trigger conditions.

The procedure for this assignment is:

  1. Rewrite your event-triggered behavioral requirements to be time-triggered. This means that instead of acting on events (like receiving a message), the controller modifies its outputs based on the current value of state variables. When you found yourselves doing tricky state variable manipulation to get a correct event-triggered behavior, you will find that time-triggered requirements make your design much simpler. 

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:

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


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.

For the first half of the course we are suggesting you design a really simple dispatcher while you learn the system, design techniques, and other aspects of the project. If you really want to have a more complex dispatcher you are welcome to do so. But, whaver you decided to design has to be working for the mid-semester hand-in, so don't be too aggressive. In the second half of the course we will require you to improve your dispatcher.

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

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. 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 (110 points total):

Here's the minimum requirement spread sheet. It should be placed in your Peer Reviews folder.

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.

The grading rubric for this assignment is available here (PDF). Please note that the grading rubric is only a general guideline and that you are still responsible for all the details in the writeup.  If the grading rubric and the project writeup conflict, the project writeup takes precedence.  If you find a conflict, please let us know by sending mail to the staff list.

Grading will be as follows:

Each team member must satisfy the minimum stated per-member requirements. Team members who omit any required per-member activity will receive a point penalty as follows:

Individual student penalties for not performing required tasks are:

Course home page