18-649 Project 3

Event-triggered Behavioral Requirements and Traceability

Check the course webpage for due dates

*Please submit all project-related questions to {email} -- 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, you will construct your full event-triggered requirements from the scenarios/sequence diagrams in project 2 and demonstrate traceability between the requirements and sequence diagrams.

For this part of the project you will finish writing your requirements for an Event-based System .   Follow the format of the "formula for behavioral requirements" you'll see in multiple lectures. A particularly important concern for event-triggered design is that only one message can be used as the trigger for an action. If you need two messages to trigger an action, you will generally need to use multiple behavioral requirements and intermediate variables to do this. 

Assignment:

Here is the minimum reqirement chart for this project.

Now let's use the scenarios & sequence diagrams from the last project to create the requirements.

In this assignment, you SHOULD NOT re-write the given time-triggered requirements for some components (DoorControl, CarPositionControl and Dispatcher) back to behaviorial requirements.

In a few cases, such as for the safety subsystem, behavioral requirements in the pre-provided project materials do not follow this event-based rule. That is because they have been implemented in a time-triggered style. You'll be changing to time-triggered in the next project. For this project, however, you must do all your work in an event-triggered style so you can understand how that approach to design works. (You do not need to re-do existing material in a time-triggered style unless it forms a part of the required hand-in items for this assignment.)

For reference, recall the design documents mentioned in Project 2:
This week, you'll be adding requirements to Behavioral Requirements II.

What you'll find in Behavioral Requirements I is the complete message dictionary for the elevator system.  In Behavioral Requirements II, you will find a set of behavioral requirements that is complete, except some are omitted and are your responsibility to fill in. Your job is to fill in the missing requirements and submit them to us as a list of numbered requirements following the numbering scheme used in the rest of the document. You should not worry about failure modes for this project phase; for the time being assume that all sensors and actuators are working at all times. You must NOT change the Constraints in this project phase.

You will also be doing traceability in this assignment, both from Sequence Diagrams to Requirements, and Requirements to Constraints. Your portfolio includes a partial example of:
Note:  For project 3 you are not required to command the drive to a speed faster than Slow.  At Slow speed, the AtFloor[f, b] is essentially your commit point.  However, if you wish to control the elevator Drive at Fast speed, you need to calculate the commit point for the elevator based on the drive acceleration profile.

We want you to use the UML sequence diagrams you created in the last project to develop your behavioral requirements.  Here is the procedure for developing your behavioral requirements:

  1. Use the Scenarios and Sequence Diagrams from project 2 to generate your behavioral requirements for each control system object. We've provided some examples, but again, these are sub-optimal so you may want to write your own. Follow the format of the "formula for behavioral requirements" for an event-based system you'll see in multiple lectures. A particularly important concern is that only one message can be used as the trigger for an action. If you need two messages to trigger an action, you will generally need to use multiple behavioral requirements and intermediate variables to do this.
  1. Ensure traceability by completing the Sequence Diagrams to Requirements Traceability table.  Expand the Excel template in the portfolio to include a row for each requirement and a column for each sequence diagram arc.  Be sure to follow the instructions given in the notes page of the Excel template. 
  1. Each behavior should match up with one or more Sequence Diagram messages (complete backward traceability).
  2. Each Sequence Diagram message should apply to at least one text behavior requirement (complete forward traceability).  
  3. When tracing to multipart requirements (as in the example in #1 above), you should trace to each subrequirement (with the understanding that it includes the common text).  So in example, you would trace to R1.1a and R1.1b, but NOT R1.1 by itself.
  4. There can be as many overlaps as necessary as long as every Sequence Diagram message and requirement is covered. 
  5. If a requirement only sets a state variable and does not set any output, then the requirement will not trace to any sequence diagram arc.  In this case, it is acceptable to trace it to the "Setting State Variable" column in the traceability table.
  6. Some arcs in the sequence diagram will originate from system modules (like the smart sensors).  Since you do not have requirements for these objects, just put a single entry for each system object in the System Modules section and indicate the arcs that trace to that object.
  7. 7. If a requirement is related to a message that is not consumed by any controller, you may trace it to the "Future Expansion" column. In the elevator, only messages that have no consumers (e.g., mHallLight and mCarLight messages) can be traced to "Future Expansion
  8. Your traceability table must include all 7 of the controllers.  For the controllers that you did not write requirements for (DoorControl, CarPositionControl and Dispatcher), you should trace to the requirements that have been provided.
  9. You must have a team member DIFFERENT from the author of the behavioral requirements perform the traceability check on each Sequence Diagram. The team member who performs the check for each object should record his/her name on the traceability check.  Complete and consistent traceability between your diagrams and documentation will be a major factor in your grade.



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 of what you submit. 

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/proj3/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 set aside a couple days in order to think about the requirements. There is not too much writing for this project, but quite a lotf 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 (135 points total):

This assignment counts as one team grade.   Be sure you follow the hand-in formats described above.  The grading criteria for project 3 can be viewed here.  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:

  •  (40 points) - 10 points per object for the requirements needed in the requirements framework (there are 4 objects total, because DoorControl, CarPositionControl and Dispatcher are provided). You do not need to re-write the time-triggered requirements for those components back into behaviorial requirements. Each member must do at least one object.
  •  (45 points) - 5 points per object for the Sequence Diagrams-to-Requirements Traceability (there are 7 objects total, because the DoorControl, CarPositionControl and Dispatcher need to be completed). PLUS 10 points for all the sequence diagram arcs being traced to a requirement or system module. Each member must do at least one object.
  • (25 points) - 5 points per object for the Requirements-Constraints Traceability (there are 5 objects total, because the DoorControl, CarPositionControl and Dispatcher need to be completed, but there are no constraints for the HallButton and CarButton controller.). Each member must do at least one object.
  • (20 points) - 5 points per object for completing a peer review of the requrements (there are 4 objects total, because DoorControl, CarPositionControl and Dispatcher are provided). Each member must do one review on a different object.
  •  (5 points) - A list of which points corresponding to which tasks were primarily completed by each team member (every point must be assigned to a specific team member). 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.
  •  (0 point. Must be completed or the project won't be graded) - The minimum requirement chart that indicates the minimum work for each group member. Please remember to replace "Member X" with your name & andrewID. An example can be found in project 2
  • Each team member must satisfy the minimum stated per-member requirements (e.g., one object for each activity). Team members who omit any required per-member activity will receive a zero contribution grade.

    We want you to go through the process of developing behavioral requirements from UML scenarios and sequence diagrams, which is why we're requiring that you show traceability between them. Consistency and coherence are the two criteria we're looking for. 


    Back to course home page