18649 - Behavioral Requirements I

System Objects and Message Dictionary


18649 <semester>
Group x - Student names and andrewIds

Table of Contents

Elevator High-Level Requirements

R-T1.  All passengers shall eventually be delivered to their intended destination floor.
R-T2.  Any unsafe condition shall cause an emergency stop.
R-T3.  An emergency stop should never occur.
R-T4.  Performance shall be optimized to the extent possible, where performance is defined by the formula:
R-T5.  Passenger satisfaction shall be optimized to the extent possible, where satisfaction is defined by the formula:
Note: The full set of example requirements provided should result in an elevator with safe behavior that meets top-level requirements other than having poor optimization of performance.  While it is obvious that the Dispatcher behavior can be optimized, there are also other, more subtle, behavioral optimizations possible as well.

Building description

The Building the elevator is in has floors numbered from 1 .. MaxFloor.  In this case, MaxFloor = 8

The setup of hallway entrances is as follows:
Floor Number
Hallway Description
8
FH only
7
FH and BH
6
FH only
5
FH only
4
FH only
3
FH only
2
BH only
1 (lobby)
FH and BH

"FH" is a shorthand for front hallway, and "BH" is a shorthand for back hallway  Floor #1, the lobby, is the lowest floor in the building.

Notation

Replication Notation

"[...]" indicates an array of objects or values.   There are 10 valid hallways, and so there are 17 separate and distinct HallCall[f, b, d] sensors -- 2 of them at each valid hallway, except for the top and bottom floors which only have 1 sensor per valid hallway.

"(...)" indicates a list of values associated with a sensor/actuator.  Single-valued inputs/outputs can have the "(" and ")" omitted as a notational convenience.

The suffixes "_up", "_down", "_front", and "_back" may be used in lieu of a direction subscript, to make things more readable. e.g.:
        HallCall_up[f, b] means HallCall[f, b, up]
        HallCall_down[f, b] means HallCall[f, b, down]
        HallCall_front[f, d] means HallCall[f, front, d]
        HallCall_back[f, d] means HallCall[f, back, d]
        HallCall_up_front[f] means HallCall[f, front, up]
        and so on...

Similarly, subscripting may be eliminated in general if desired using an underscore notation. e.g.:
        CarLantern_down means CarLantern[down]

Multi-attributed items may have a particular state referred to by concatenating elements, e.g.: Motor might have state FastUp or SlowDown. ("StopStop" can always be abbreviated by "Stop")

Single attributes of a multi-attribute item are referred to using "." notation.  For example DesiredFloor.f refers to attribute "f" of "DesiredFloor".

If a letter instead of a value is used in a subscript, it is assumed that it can take any valid value.  If the same letter is used in multiple clauses within a single requirement element, it is assumed that the letter takes the same value in all instances.  For example, in the phrase:
 "AtFloor[f, b] ... CarCall[f, b]  ...  HallCall[g, b, d]"
The Floor f and Hallway b for AtFloor and CarCall can be any valid floor and valid hallway, but would have to be the same floor and hallway.  However, the floor for HallCall might or might not be the same floor as for AtFloor and CarCall since it is a different symbolic letter.

Replication in Sequence Diagrams

Replication is a problem in UML Sequence Diagrams. Rather than introducing an attempt at formal notation (which gets very confusing quickly), we will resort to using comments when multiple instances of something are supposed to be coordinated (e.g., "wait for all doors to close" will be a text comment in Sequence Diagrams, but shall be represented rigorously in behavioral requirements).

Replication in Behavioral Requirements

Because the controllers are written in a generic way, it's important to pay attention to the way the replication notation is used in the behavioral requirements.  Here are some general guidelines:

Initialization

Because ultimately we will do this all in simulation, we're going to make your life easy by telling you the initial state of the system (the "initialization" state) such as putting the elevator car at the lobby floor with the doors closed.  In a real elevator the controllers have to figure out the system state for themselves when power is applied.

System Elements

This section describes the elements of the system that are already provided

The Car

The notation "Car" refers to the elevator Car that travels in a hoistway.  The movement of the Car itself is hidden within the environment model, so it can only be observed through sensors and controlled through actuators.

Physical State Sensors

These objects are instantiate in the system but do not have a network interface.  These objects must be read through the physical interface of a controller.

Smart Sensors

These sensor values are available for use by the control system.  The below-listed values will correspond to network messages in the implementation phase.
Note:  If an object that sends a network message is not instantiated (such as an atFloor sensor at a [f,b] without a landing), then no network message with that CAN id is ever sent.

Environmental-Only System State:

These values keep track of current system state.  They are not accessible to the control system, but have been used in the specifications for building the simulation system.

System Actuators

The below-listed values will correspond to network messages in the implementation phase.  All actuators are assumed to "remember" their last commanded value and stay there unless commanded otherwise or forced otherwise by system/environment constraints.

Environmental-Only Actuators

Control System Objects

In addition to the objects described above, there are several complex control system objects.  These objects are summarized below.  The detailed specification of these objects can be found in the Behavioral Requirements II document.  Environmental objects have already been designed and are provided by the system.  The other control objects will be the primary focus of your design effort.
  1. Passenger (environmental) - the simulated passenger that interacts with the physical interface of the elevator
  2. Safety Sensor (environmental) - monitors the system state and triggers the emergency brake if an unsafe condition is detected.
  3. Drive (environmental) - moves the car according to the Drive commands and the elevator acceleration profile.
  4. DoorMotor[b,r] (environmental) - moves the doors according to the DoorMotor commands.
  5. DoorControl[b,r] - controls the motion of the doors
  6. DriveControl - controls the motion of the car
  7. LanternControl[d] - controls a the direction lanterns
  8. HallButtonControl[f,b,d] - controls the hall lights and and monitors hall buttons at the landings
  9. CarButtonControl[f,b] - controls the car lights and and monitors car buttons inside the car
  10. CarPositionControl - controls the output of the car position indicator
  11. Dispatcher - determines the order in which floors and hallways are serviced

Network Message Dictionary

This section defines the network messages that may be sent.  The design MUST follow the message dictionary.  Following the message dictionary means:

Environmental Object Messages

These messages are sent by environmental objects and smart sensors provided in the system

Source Node Name
Message Name Replication
Number of fields
Description
Safety Object
mEmergencyBrake none 1
see object description
AtFloor Sensor mAtFloor floor, hall 1
see object description
Level Sensor
mLevel
direction
1
see object description
CarLevelPosition Sensor mCarLevelPosition none 1
see object description
Door Closed Sensor mDoorClosed hall, side 1
see object description
Door reversal Sensor mDoorReversal hall, side 1
see object description
Weight Sensor mCarWeight none 1
see object description
Weight Sensor mCarWeightAlarm   1
see object description
Door Opened Sensor mDoorOpened hall, side 1
see object description
Hoistway Limit Sensor mHoistwayLimit direction 1
see object description

Controller Messages

These messages are sent by the controllers that you will design.  In the later projects, you will be allowed to modify the message dictionary for the controllers in a limited way, but for the time being, you must implement the message dictionary given below:

Source Node Name
Message Name Replication
Number of Fields
Description
Drive Control mDriveSpeed
none 2
The current speed and direction of the car
  • Speed - a numeric value
  • Direction - one of {STOP, UP, DOWN}
Drive Control mDrive none 2
The commanded speed and direction of the car
  • Speed - one of {STOP, LEVEL, SLOW, FAST}
  • Direction - one of {STOP, UP, DOWN}
Dispatcher mDesiredDwell* hallway 1
A numeric value indicating the desired dwell time for the door.
Dispatcher mDesiredFloor** none 3
The desired floor, hallway, and direction
  • floor - the next floor to be serviced, [1,8]
  • hallway - the hallway to be serviced, one of {FRONT, BACK, BOTH, NONE}
  • direction - the intended direction of travel after servicing the desired floor, one of {UP, DOWN, STOP}
Door Control mDoorMotor hall, side 1
The current command to the door.  One of {STOP, OPEN, CLOSE, NUDGE}
Hall Button  mHallCall floor, hall, direction 1
Indicate the presence of a hall call in the direction at the floor and hall.  One of {true, false}
Hall Button  mHallLight floor, hall, direction 1
Indicate the state of the hall light  One of {true, false}
Car Button mCarCall floor, hall 1
Indicate the presence of a car call for a certain floor and hall.  One of {true, false}
Car Button mCarLight floor, hall 1
Indicate the state of the car light  One of {true, false}
Car Lantern mCarLantern direction 1 Indicate state of the car lantern  One of {true, false}

Removed messages


Notes:
*mDesiredDwell:
**mDesiredFloor: