Elevator Top-Level Requirements

• All passengers shall eventually be delivered to their intended destination floor.
• Any unsafe condition shall cause an emergency stop.
• An emergency stop should never occur.
• Performance shall be optimized to the extent possible, where performance is defined by the formula:
• ( 4 * average_passenger_delivery_time) +  maximum_passenger_delivery_time
  Performance is improved by reducing that value (short delivery times are better).   Delivery time is counted from the time a passenger arrives at a floor to begin a trip and ends when that passenger exits the elevator car.  (Note: this is an arbitrary formula for this project, but the general idea holds true for real elevators.)

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 suffices "_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...
(Note that in the above examples, "f" is a floor number (1 ... MaxFloor), "b" is a hallway (front or back), and "d" is a direction (up or down))

Similarly, subscripting may be eliminated in general if desired using an underscore notation. e.g.:
        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 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).

Car refers to the elevator Car that travels in a hoistway.  The movement of the Car itself is hidden within the environment model and thus only indirectly observable/controllable by the control system via sensors and actuators.

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.  In a real elevator the controllers have to figure out the system state for themselves when power is applied.

The following letters are used as subscripts for replicated objects, and have meanings as defined:
f - floor number (integer 1...MaxFloor)
b - front/back hallway {Front, Back}
r - right/left {Right, Left}
d - direction {Up, Down}

System Sensors:

• AtFloor[f, b](v): Floor proximity sensor.   v = {True, False}.
  One per Floor and Hallway [f, b] combination.
  Indicates True at a point where the Car is approximately level with floor f.  However, for all floors f which do not have a front hallway, AtFloor[f, Front] will always be False for those values of f.  For all floors f which do not have a back hallway, AtFloor[f, Back] will always be False for those values of f.  It is assumed that the width of the Stop zone is such that the Drive has enough time to switch from going at Slow speed to Stop and still have the car level with the floor.
  Set to False at initialization, except the lobby switch is set to True at initialization.
  AtFloor[f, b] shall be set True if and only if CarPosition is within 350 msec of travel time of floor position f at Slow speed in either direction and there is a hallway at [f, b].
  

• CarLevelPosition(x): Car position sensor.  x = {integer 0 .. } in millimeters
  One per Car.
  Reports approximate position of car in hoistway based on position sensors placed at 10 cm intervals in the hoistway.  Gets updated each time the car passes one of these sensors.
  Set to Lobby position at initialization.
   
• CarCall[f, b](v): Car Call buttons.  v = {True, False}.
  One per Floor and Hallway [f, b] combination, all located in the CAR. However, those [f, b] combinations which are non-existent hallways for this building do not have a car call button, and those CarCall[f, b] values will never be set True.
  Set to False at initialization.
   
• DoorClosed[b, r](v): Door Closed switches.   v = {True, False}.
  One per Door [b, r] for b = {Front, Back} and r = {Left, Right}.
  Indicates True when the Door[b, r] is fully closed.
  Set to True at initialization.
  DoorClosed[b, r] shall be True if and only if DoorPosition[b, r] has a value less than 1.
   
• DoorOpened[b, r](v): Door Opened switches.   v = {True, False}.
  One per Door [b, r] for b = {Front, Back} and r = {Left, Right}.
  Indicates True when the Door[b, r] is fully open.
  Set to False at initialization.
  DoorOpened[b, r] shall be True if and only if DoorPosition[b, r] has a value greater than 490.
   
• DoorReversal[b, r](v): Door Reversal sensors.   v = {True, False}.
  One per Door [b, r] for b = {Front, Back} and r = {Left, Right}.
  Indicates True whenever the Door [b, r] senses an obstruction in the doorway.
  Set to False at initialization. 
  

• HallCall[f, b, d](v): Hall Call buttons.   v = {Pressed, Idle}.
  One per Floor, Hallway, and Direction [f, b, d] combination, all located in the hallways. However, those [f, b, d] combinations which are non-existent hallways for this building do not have hall call buttons (also topmost floor does not have Up buttons; bottommost floor does not have Down buttons), and those HallCall[f, b, d] values will never be set True.
  Set to False at initialization.

• HoistwayLimit[d](v): Safety limit switches in the hoistway.   v = {True, False}. One pair per Car, d = {Up, Down}.
  A HoistwayLimit[d] switch activates when the car has over-run the hoistway limits (used as a trigger for emergency stopping). The d=Up switch is at top of hoistway; d=Down switch is at bottom of hoistway.
  Set to False at initialization.
   
• DriveSpeed(s,d): main drive speed readout.   s is speed s = {double 0 .. } in meters/sec
                                                                   dis direction d = {Up, Down, Stop}
  One per Car.
  Provides information about the current drive speed set by Drive(s,d) !! but this is the actual drive status rather than the status commanded by Drive(s,d).  (Note that there will be a time delay between commanding the drive to change speed and the drive actually attaining that speed.  This lets you know when the commanded speed is actually attained.)
  Initialized to (0, Stop).
   
• CarWeight(x): Car weight sensor.   x = {int 0 .. } in tenths of pounds (lbs)
  One per Car.
  Provides information about current total weight of passengers in the car in tenths of pounds (lbs).   The car weight sensor shall not be affected by the acceleration/deceleration of the car.   MaxCarCapacity is the maximum allowable weight for safe travel in car.
  CarWeight is set to 0 at initialization. (Car is empty)

Environmental-Only Sensors:

• DoorPosition[b, r](x): Amount that the door is open.   x = {integer 0 .. 500}
  One per Door [b, r] for b = {Front, Back} and r = {Left, Right}.
  Value is the amount the door is open as a thousandth of doorway width.  Each DoorPosition[b, r] can range from 0 to 500.  With both Door_Front[r] open at 500 the entire front doorway is opened overall. With both Door_Back[r] open at 500 the entire back doorway is opened overall.
  Set to 0 at initialization (front doors closed).
   
• CarPosition(x): Vertical position of car.   x = {integer 0.. } in millimeters
  Tracks the position of the car in meters (not the same as floor number or CarLevelPosition).
  Set to Lobby position at initialization.

System Actuators:

• DoorMotor[b, r](m): Door motor.   m = {Open, Close, Stop}
  One per Door [b, r] for b = {Front, Back} and r = {Left, Right}.
  Opens and closes the door.  It is permissible to transition directly from Open to Close and Close to Open without first commanding a Stop.
  Set to Stop at initialization; see DoorMotor object description for details.
   
• CarLantern[d](k): Car Lanterns.     k = {On, Off}.
  One set per Car, d = {Up, Down}.
  These are the Up/Down arrows placed on the car door frames. Used by Passengers on a Floor to figure out whether to enter the Car.
  Set to Off at initialization.
   
• CarLight[f, b](k): Car Call Button lights.   k = {On, Off}.
  One per CarCall[f, b] button.
  The light inside the car call button, used to indicate to passengers that a car call has been registered by the dispatcher.
  Set to Off at initialization.
   
• CarPositionIndicator(f): Position Indicator in Car.      f = {integer 1..MaxFloor}.
  One per Car.
  Displays floor status information to the passengers in the Car.
  Set to 1 at initialization.
   
• HallLight[f, b, d](k): Hall Call Button lights.   k = {On, Off}.
  One per HallCall[f, b, d] button.
  The light inside the hall call button, used to indicate to passengers that a hall call at that Floor f has been registered by the Dispatcher for direction d.
  Set to Off at initialization.
   
• Drive(s,d): 2-speed main elevator drive.   s is speed s = {Fast, Slow, Stop}
                                                             d is direction d = {Up, Down, Stop}
  One per Car.
  Moves the Car up and down the hoistway according to a velocity profile that depends on a variety of physical factors.
  Set to (Stop, Stop) at initialization; see Drive object for details.
  Note that current Drive speed can be determined via DriveSpeed(s,d)
   
• CarWeightAlarm(k): Car weight overload alarm.  k = {On, Off}.
  Buzzer that sounds when the CarWeight sensor detects that the elevator is weight overloaded (above MaxCarCapacity).  It's the signal to the passengers that at least one must step off the elevator before it continues operation.
  Set to Off at initialization.

Environmental-Only Actuators:

• EmergencyBrake(b): Emergency stop brake.  b = {On, Off}
  Supplies emergency braking in case of safety violation such as hoistway limit over-run or movement with doors open. One per Car.  Can be used exactly one time, after which elevator hoistway requires significant repair maintenance.  Triggering the EmergencyBrake in simulation means that either a safety-critical sensor/actuator has been broken or your elevator controller has attempted unsafe operation.  (If the EmergencyBrake activates during your final project demo due to an attempt of unsafe operation, there will be a scoring penalty.)
  Set to Off at initialization.
   

Control System State

• DesiredFloor(f,b,d): Dispatcher's desired stopping Floor. (Sent from Dispatcher.)
                                                 f is desired Floor number, an integer .
                                                 b is hallway enabled for pick up b = {Front, Back, Both, None}.
                                                 d is direction d = {Up, Down, Stop}.
  The dispatcher uses this to indicate the next floor to stop at.  A direction of  Stop means that there is no preferred direction.  Directions of Up and Down have the implication that the elevator is "going up" or "going down" respectively.
  This value may change dynamically and non-monotonically.  Once doors begin opening the elevator is committed to perform a full door cycle operation and DesiredFloor can change to indicate the next Floor beyond the Floor where the Car is currently positioned.
   
• DesiredDwell(b, n): Dispatcher's desired dwell time for current door open cycle. (Sent from Dispatcher.)
                         n is a long integer number of msec.
                         b is hallway b = {Front, Back}.
  This is an optional way for the Dispatcher to override any dwell time used by the DoorController[b].

Environmental Objects

The objects associated with the following sensors and actuators are considered simple and are not described in detail beyond definitions provided in the preceding system sensor/actuator lists.  In each case, interfaces consist solely of the relevant sensor/actuator state and any obvious interactions with the environment.

AtFloor[f, b]
CarLevelPosition
CarCall[f, b]
DoorClosed[b, r]
DoorOpened[b, r]
DoorReversal[b, r]
HallCall[f, b, d]
HoistwayLimit[d]
DoorPosition[b, r]
CarLantern[d]
CarLight[f, b]
CarPositionIndicator
HallLight[f, b, d]
EmergencyBrake
CarPosition
CarWeight
CarWeightAlarm

Complex sensor, actuator, and environmental objects are discussed in the following sections.

1. Passenger[p]  (environmental object)

Replication:

• N passengers per system; N is unlimited subject to being less than steady-state carrying capacity of elevator.

Instantiation:

• Zero passengers at initialization.
• Passengers arrive at floor hallways as a Poisson process with mean interarrival times varying per hallway.  Lobby arrivals comprise 25% to 50% of all arrivals.

Assumptions:

• Passengers do not "fight" each other for position in entry and exit queues.
• Passengers weigh 150 pounds each.

Input Interface:

• DoorPosition[b, r]
• CarLantern[d]
• CarLight[f, b]
• CarPositionIndicator
• HallLight[f, b, d]
• CarWeightAlarm

Output Interface:

• CarCall[f, b]
• DoorReversal[b, r]
• HallCall[f, b, d]

State:

• P_START_F[p]: a constant starting floor for Passenger p.
• P_START_H[p]: a constant starting hallway for Passenger p, "front" or "back".
  
• P_DEST_F[p]: a constant destination floor for Passenger p.
• P_DEST_H[p]: a constant destination hallway for Passenger p, "front" or "back".
  
• P_DIR[p]: a travel direction for Passenger p, which corresponds to the direction of P_DEST_F[p] compared to P_START_F[p].
• Passenger p is enqueued in an entry/exit queue, with one such queue per direction per hallway, and one queue for each destination in the Car.  (i.e., there is a queue for going up at each hallway, a separate queue for going down at each hallway, and a queue for each hallway for exiting the Car).   The queue determines order of entry/exit and queue order is FIFO based on order of arrival of the passenger to the queue.  Any passenger not at the head of a queue is blocked and must wait to be at the head of the queue before entering or exiting the Car.  Passengers can only exit the hallway queues when the Car is at that hallway going in the correct direction and the doors are sufficiently open.

CONSTRAINTS:

BEHAVIORS:

2. Safety  (environmental object)

Replication:

• One Safety object per car.  This is a separate object to simplify system safety certification.

Instantiation:

• The safety system starts assuming a safe system state at initialization (initialization must ensure that an unsafe state is not transiently generated).

Assumptions:

• Sensors monitored by Safety object do not fail.
• Safety Object can always trigger EmergencyBrake.
• Safety Object does not fail.

Input Interface:

• mAtFloor[f, b]
• mCarWeight
• CarPosition (internal simulator variable)
• mDoorClosed[b, r]
• mDoorMotor[b, r]
• mDoorReversal[b, r]
• mDrive
• mDriveSpeed
• HoistwayLimit[d]

Output Interface:

• EmergencyBrake (internal simulator variable)
• mEmergencyBrake
  
• mHoistwayLimit[d]

State:

TIME-TRIGGERED BEHAVIORS:

3. Drive  (environmental object)

Replication:

• One Drive per Car, which tracks position of Car in hoistway as well as Drive direction/speed.  The electric motor of the Drive is double-wound, so that if one winding breaks the Drive can still deliver both slow and fast speeds at approximately half the torque as for Slow and Fast of a fully operational drive.  (There are many ways to deal with failure modes! This is a simple one for this project.)

Instantiation:

• Drive is Off at initialization.

Assumptions:

• Drive does not go faster than Fast speed.
• EmergencyBrake can stop car at any speed.

Input Interface:

• Drive
• EmergencyBrake (internal simulator variable)

Output Interface:

• CarPosition (internal simulator variable)

State:

• F_position[f]: an array initialized with the vertical position of each floor; used implicitly by the behaviors to determine floor position.

CONSTRAINTS:

BEHAVIORS:

4. DoorMotor[b, r]

Replication:

• Each Car has four DoorMotor[b, r], with each controlled by DoorControl[b, r].  DoorMotor[b, r] tracks the actual position of the door.

Instantiation:

• All DoorMotor[b, r] are at Stop at initialization.

Assumptions:

Input Interface:

• DoorMotor[b, r]

Output Interface:

• DoorPosition[b, r] (internal simulator variable)

State:

• D_position: integer with thousandth open of door, range of 0 to 500.

CONSTRAINTS:

BEHAVIORS:

5. DoorControl[b, r]

Replication:

• Each Car has four DoorControllers[b, r].  Each Door_Front[ r] contributes from 0% to 50% of the total DoorPosition_Front[r] , and each Door_Back[r] contributes from 0% to 50% of the total DoorPosition_Back[r] (100% = both doors open; 50% = one door open or both doors half-open, or some combination; 0%= both doors fully closed).

Instantiation:

• DoorControllers[b, r] shall command doors[b, r] to close at initialization.

Assumptions:

• DoorControllers[b, r] do not command doors to open when car is not level with a hallway [f, b].
• DoorControllers[b, r] do not command doors to open when car is moving.

Input Interface:

• mAtFloor[f, b]
• mDriveSpeed
• mDesiredFloor
• mDesiredDwell[b]
• mDoorClosed[b, r]
• mDoorOpened[b, r]
• mDoorReversal[b, r]
• mCarCall[f, b]
• mHallCall[f, b, d]
• mCarWeight

Output Interface:

• DoorMotor[b, r]
• mDoorMotor[b, r]

State:

• Cycles; integer with number of door cycles performed; initialized to 0.
• Dwell, long integer with number of msec desired for door dwell during current cycle.
• CountDown: a count-down timer for Door Dwell[b] (implemented in simulation by scheduling a future task execution at time of expiration)

CONSTRAINTS:

TIME-TRIGGERED BEHAVIORS:

6. DriveControl

Replication:

• There is one DriveControl, which controls the elevator Drive (the main motor moving Car Up and Down).  For simplicity we will assume this node never fails, although the system could be implemented with two such nodes, one per each of the Drive windings.

Instantiation:

• DriveControl initializes to Stopping the Drive.

Assumptions:

• DriveControl does not command Drive to move when any DoorClosed[b, r] is False.
• DriveControl only commands Drive to stop when car can be level with a floor.

Input Interface:

• mAtFloor[f, b]
• mCarLevelPosition
• mDoorClosed[b, r]
• mDoorMotor[b, r]
• mEmergencyBrake
• mDesiredFloor
• DriveSpeed
• mHoistwayLimit[d]
• mCarWeight

Output Interface:

• Drive
• mDrive
• mDriveSpeed

State:

• DesiredDirection = {Up, Down, Stop} computed desired direction based on comparing current floor position with Floor desired by Dispatcher.  This is implicitly computed and used as a macro in the behavior descriptions.
• CurrentFloor, is a shorthand notation for the value of whichever mAtFloor[f, b] is True, if any.  If CurrentFloor is invalid it has a mnemonic value of None.
• CommitPoint[f](v); v = {Reached, NotReached} calculated based on car's acceleration profile, current speed, and distance from the floor f, to determine whether or not the car can still stop at the next floor.

CONSTRAINTS:

EVENT-TRIGGERED BEHAVIORS:

7. LanternControl[d]

Replication:

• Two controllers, one for each lantern {Up, Down} mounted in the Car by the Car's front and back doors.

Instantiation:

• Lanterns are Off at initialization.

Assumptions:

• CarLanterns[d] are never commanded to be On at the same time.

Input Interface:

• mDoorClosed[b, r]
• mDesiredFloor
• mAtFloor[f, b]

Output Interface:

• CarLantern[d]
• mCarLantern[d]

State:

• DesiredDirection = {Up, Down, Stop} computed desired direction based on comparing CurrentFloor with Floor desired by Dispatcher.  This is implicitly computed and used as a macro in the behavior descriptions.

CONSTRAINTS:

EVENT-TRIGGERED BEHAVIORS:

8. HallButtonControl[f, b, d]

Replication:

• There are two HallButtonControllers[f, b, d] per hallway, one for each of the Up and Down HallCall buttons.    (Topmost floor does not have an Up button; bottom floor does not have a Down button.)  These accept HallCall button presses as well as control HallLight feedback lights.

Instantiation:

• All HallCalls are False at initialization.
• All HallLights are off at initialization.

Assumptions:

Input Interface:

• mAtFloor[f, b]
• mDesiredFloor
• mDoorClosed[b, r]
• HallCall[f, b, d]

Output Interface:

• HallLight[f, b, d]
• mHallLight[f, b, d]
• mHallCall[f, b, d]

State:

• CurrentFloor, is a shorthand notation for the value f of whichever mAtFloor[f, b] is True, if any.  If CurrentFloor is invalid it has a mnemonic value of None.

CONSTRAINTS:

EVENT-TRIGGERED BEHAVIORS:

9. CarButtonControl[f, b]

Replication:

• There is one CarButtonController per hallway [f, b], with all controllers located in the Car.    These accept CarCall button presses as well as control CarLight feedback lights.

Instantiation:

• All CarCalls are False at initialization.
• All CarLights are off at initialization.

Assumptions:

Input Interface:

• mAtFloor[f, b]
• mDesiredFloor
• mDoorClosed[b, r]
• CarCall[f, b]

Output Interface:

• CarLight[f, b]
• mCarLight[f, b]
• mCarCall[f, b]

State:

• CurrentFloor, is a shorthand notation for the value f of whichever mAtFloor[f, b] is True, if any.  If CurrentFloor is invalid it has a mnemonic value of None.

CONSTRAINTS:

EVENT-TRIGGERED BEHAVIORS:

10. CarPositionControl

Replication:

• There is one CarPositionControl instance in the car, which feeds values to the CarPositionIndicator.

Instantiation:

• The Car is initialized on the first Floor (Lobby).

Assumptions:

Input Interface:

• mAtFloor[f, b]
• mCarLevelPosition
• mDesiredFloor
• mDriveSpeed

Output Interface:

• mCarPositionIndicator
• CarPositionIndicator

State:

• CommitPoint[f](v); v = {Reached, NotReached} calculated based on car's acceleration profile, current speed, and distance from the floor f, to determine whether or not the car can still stop at the next floor.

CONSTRAINTS:

EVENT-TRIGGERED BEHAVIORS:

11. Dispatcher

Replication:

• There is one Dispatcher in the system, corresponding with the Car.

Instantiation:

• The Dispatcher is initialized to send the car to the Lobby, have the Lobby as the desired destination, and have a preferred direction of "Stopped" (i.e., no preferred direction).

Assumptions:

• Dispatcher never sets DesiredFloor.f to be above MaxFloor or below Lobby (1).

Input Interface:

• mAtFloor[f, b]
• mDoorClosed[b, r] 
• mHallCall[f, b, d]  
• mCarCall[f, b]   
• mCarWeight

Output Interface:

• mDesiredFloor
• mDesiredDwell

State:

• Target: an integer Floor number for desired Floor, initialized to Lobby = 1.
• DoorClosed[b,r], initialized to True.
• AtFloor[f,b], initialized to True.
  

CONSTRAINTS:

EVENT-TRIGGERED BEHAVIORS: