18649 - Behavioral Requirements II

Distributed Controller Requirements


18649 <semester>
Group x - Student names and andrewIds

Introduction

This document describes the complex sensor, actuator, and environmental objects in the system.

Table of Contents

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:

Passengers arrive at the elevator landings according to the specifications of the passenger input files.  Passengers may also begin the simulation already in the car.

Assumptions:

Passengers do not "fight" each other for position in entry and exit queues.

Passengers weigh 150 pounds each.

Input Interface:

Output Interface:

Constants:

These constant values are the same for all passengers:

Parameters:

Passenger behavior is parameterized by the following values.  These values are defined per-passenger and may differ from passenger to passenger.  These values are constant during the passenger's  interaction with the elevator.

State:

These state values are maintained by the passenger during the interaction with the elevator:
Note: The implications of the missedOpenings state variable are subtle. For example, consider a situation in which only some passengers are boarding the elevator and the rest are staying in the hallway, even with a very long door dwell. This may be due to incorrect lantern signals, even if they are only temporary. Only some of the passengers will choose to ignore incorrect or wrong-direction hall lantern signals due to their particular missedOpeningThreshold value having been exceeded. Those passengers who have not exceeded their threshold will stay in the hallway until some future boarding opportunity.

Passenger Metrics:

There are two metrics of interest for passengers:  delivery time and satisfaction.

Delivery time is measured from the time the passenger arrives at the landing to the time that the passenger exits the car at their destination.  Lower delivery times are better.

Safisfaction is a measure of the undesirable behavior that the passenger observes during their interaction with the elevator.  Undesirable behaviors are behaviors that deviate from normal elevator behavior, but do not (in general) affect the eventual delivery of passengers.  The satisfaction score begins at 100 (a perfect score).  Each time the passenger observes an undesirable behavior, the passengers satisfaction is reduced by multiplying the current score by a factor that depends on the severity of the behavior observed.  A higher satisfaction score is better, with 100 being a perfect score.  The specific deductions for undesirable behavior are listed below, with the factor by which the satisfaction score is reduced.
Note that sometimes, especially in high traffic scenarios, it may be impossible to avoid having some deductions for a small number of passengers.

Constraints:

1.1: Passengers are prevented from entering or exiting the Car whenever the appropriate doors are not open far enough.

1.2: If Passenger p is outside the car and the CarWeightAlarm is triggered, the passenger shall not try to enter the car or press a hall call for 10 seconds after the doors fully close.

Behaviors:

Because passengers are inherently event-triggered, their behaviors differ from those of the other system objects. 

1.3.  When the passenger arrives at the start landing, if the hall call light it is not lit, the passenger shall press the hall call button in the hallCallDirection.
1.4.  While waiting for the car (while the doors are closed at the landing), the passenger shall monitor the hall call button in hallCallDirection and shall press it again if the hall call light is extinguished.
1.5.  When the passenger is waiting at the landing and the doors at the start landing begin to open, the passenger shall try to enter the car if:
  1.5.1  The leveling error at the floor is less than or equal to 5mm OR IgnoreLeveling is set to true AND
  1.5.2  The car lantern is consistent with the passenger's direction of travel OR missedOpenings exceeds missedOpeningThreshold (If neither car lantern is lit, the passenger will always consider the direction consistent.) AND
  1.5.3  The doors are open wider than the width constant.
1.6  After the passenger has entered the car, if the direction arrow becomes inconsistent with his travelDirection and the doors are still open, the passenger shall exit the car at the start landing.
1.7.  The passengers shall traverse the door one at a time.  Passenger priority shall be determined by the following guidelines:
   1.7.1  Passengers exiting the car shall take priority over passengers entering the car.
   1.7.2  Passengers in the car shall exit on a first-come-first-serve basis.
   1.7.3  Passengers at a landing shall enter on a first-come-first-serve basis.
   1.7.4  If a passenger fails to enter or exit the car, the passenger shall return to the end of the appropriate car or hall queue.
1.8  The passenger shall block the door for doorTraversalDelay while entering or exiting the car.
  1.8.1  After doorTraversalDelay has expired, if the door is not open wide enough for the passenger to traverse the door, the passenger shall block the door for an additional doorBackoutDelay while returning the passenger's previous location (hall landing or car).
1.9  When the passenger enters the car, if the car call light it is not lit, the passenger shall press the car call button for his destFloor.
1.10.  While waiting in the car (while the doors are closed), the passenger shall monitor the car call button and shall press it again if the car call light is extinguished.
1.11  If the OverweightAlarm sounds, the last passenger to enter the car shall attempt to exit.
1.12  If the OverweightAlarm sounds and the doors are at least partially open at a landing, the passengers waiting at that landing shall wait a minimum of 10 seconds after the doors fully closed before they begin monitoring the hall call buttons again.
1.13  When the passenger is in the car and doors begin to open, the passenger shall attempt to exit if:
  1.13.1  The leveling error at the floor is less than or equal to 5mm OR IgnoreLeveling is set to true AND
  1.13.2  The car position indicator indicates destFloor AND
  1.13.3  The doors on the destHallway side are open wider than the width constant.
1.14  If the startFloor and destFloor are the same, after entering the car, the passenger shall immediately attempt to exit the car at the destHallway.

State Chart:

This state diagram and the accompanying tables describes the trigger conditions that can cause the passenger to move from one state to another, and the activities that accompany each state and transition.  Passengers are inherently event triggered, so their interaction includes actions on transitions.  You should NOT copy the passenger behaviors as a model for your elevator controllers.  The elevator controllers (DriveControl, DoorControl, etc) may not have actions on transitions.

passenger_state_diagram.png
Trigger #
Trigger Conditions
Actions
PT1
Injection time reached
Passenger joins hall queue.
PT2 Doors at start landing are open wider than width, car is level or leveling is being ignored, car lantern is consistent with travelDirection, passenger has priority to use the door.

PT3 After doorTraversalDelay, the door is not open wide enough for the passenger to enter.
Passenger registers a "failed to enter" satisfaction deduction
PT4 doorBackoutDelay expires
Passenger rejoins hall queue at the end of the queue. 
PT5 doorTraversalDelay expires and the doors are open wider than passenger width.
Passenger exits the hall queue and joins the car queue.
PT6 The CarWeightAlarm sounds and this passenger is the last passenger in the car queue.
Passenger stops monitoring the car call.
PT7 doorTraversalDelay expires and the doors are open wider than the passenger width.
Passenger rejoins hall queue.
PT9 Doors are fully closed and BackoffPeriod has elapsed.

PT10 CarWeightAlarm sounds and the passenger is in the hall queue with the doors at least partially open.

PT11 Doors at destHallway are open wider than passenger width, the car is level or leveling is being ignored, the position indicator indicates destFloor, and the passenger has priority to traverse the door.   OR, while the car is still at the startFloor and the doors on the startHallway are still open, the lantern changes to a direction that is inconsistent with the passengers travelDirection and the passenger has priority to traverse the door.

PT12 After doorTraversalDelay, the door is not open wide enough for the passenger to enter. Passenger registers a "failed to exit" satisfaction deduction.
PT13 doorBackoutDelay expires Passenger rejoins the car queue at the end of the queue. 
PT14 doorTraversalDelay expires and the doors are open wider than the passenger width. Passenger records delivery time and stops interacting with the simulation.
PT15
Car ceases to be overweight before the passenger can exit the car.
Passenger rejoins the car queue

State
Description
Actions
INIT
passenger has not arrived at the hallway yet
none
WAITING_IN_HALL
waiting for the car to arrive at the start floor/hall, pressing the hall call Passenger presses and/or monitors the hall call.  Passenger may register a "repeated call press" deduction.
ENTERING in the process of entering the car Passenger may register a "car lantern direction change" deduction.
ENTER_BACKOUT backing out because the passenger failed to enter none
WAITING_IN_CAR waiting for the car to arrive at the destination Passenger presses and/or monitors the car call.  Passenger may register "missedOpeningThreshold exceeded", "skipped destination" or "wrong motion" deductions.  Passenger may register a "repeated call press" deduction.
EXITING exiting the car at the start or destination landing
none
EXIT_BACKOUT returning to the car because the passenger failed to exit none
OVERWEIGHT_EXITING exiting the car because it is overweight Passenger registers a "failed to exit" satisfaction deduction.
OVERWEIGHT_BACKOFF waiting after the overweight alarm has sounded none
DONE passenger delivered to destination none

2. Safety  (environmental object)

Replication:

Instantiation:

Assumptions:

Input Interface:

Output Interface:

State:

None

BEHAVIORS:

2.1    If all AtFloor[f, b]s are False and any DoorClosed[b, r] is False, set EmergencyBrake to on.
2.2    If any DoorClosed[b,r] is false when there is no landing at hallway b, set EmergencyBrake to on.
2.3    If DriveSpeed.speed exceeds LevelSpeed and DriveSpeed.direction is not equal to Stop and any DoorClosed[b,r] is false, set the Emergency Brake to on.
2.3    If any DoorReversal[b, r] is True and any DoorMotor[b, r] is anything other than Open or Nudge for greater than 200msec (accumulated while DoorReversal[b, r] remains True), set EmergencyBrake to on. 
2.4    If any HoistwayLimit[d] is True, set EmergencyBrake to on.
2.5    If a Drive command is not "adjacent to" or the same as the current DriveSpeed value, set EmergencyBrake to on.
2.5.1    In the following table, any entry with an 'X' means that that Drive command is considered adjacent to the corresponding value of {DriveSpeed}:

Drive Speed Values
Drive Command Values
FastSpeed >= DriveSpeed >= SlowSpeed, UP
SlowSpeed >= DriveSpeed > LevelSpeed, UP
LevelSpeed >= DriveSpeed > 0, UP
DriveSpeed == 0,STOP
LevelSpeed >= DriveSpeed > 0, DOWN SlowSpeed >= DriveSpeed > 0, DOWN
FastSpeed >= DriveSpeed >= SlowSpeed, DOWN
Fast, Up
X






Slow, Up
X
X
X
X



Level, Up

X
X
X



Stop, Stop


X
X
X


Level, Down



X
X
X

Slow, Down



X
X
X
X
Fast, Down






X

2.6     If DriveSpeed.speed exceeds LevelSpeed and DriveSpeed.direction is not equal to Stop and CarWeight MaxCarCapacity, set the EmergencyBrake to on.

3. Drive  (environmental object)

Replication:

Instantiation:

Assumptions:

Input Interface:

Output Interface:

State:

CONSTRAINTS:

3.1    If the EmergencyBrake is activated, it shall stop the Car regardless of Drive speed and direction.
3.2    Car movement caused by cable slip shall not exceed 1cm.

BEHAVIORS:

3.2    Drive(Stop,d) and Drive(s,Stop) shall stop the Car regardless of values for s or d.
3.2.1    The time to Stop the Car from Fast speed depends on the Car speed before Stop is commanded and is determined by an acceleration profile.
3.2.2    The time to Stop the Car from Slow speed shall be less than or equal to 250 msec.
3.2.2    The time to Stop the Car from Level speed shall be less than or equal to 50 msec.
3.3  Drive(level, d), where d is not Stop, shall move the elevator at a leveling speed in the direction d.
3.3.1  The time to achieve Level speed depends on speed preceding the Level movement command and is determined by an acceleration profile.
3.3.2  The actual velocity at Level speed depends on the drive equipment installed.
3.4    Drive(Slow,d), where d is not Stop, shall move the elevator at a slow speed in the direction d.
3.4.1    The time to achieve Slow speed depends on speed preceding the Slow movement command and is determined by an acceleration profile.
3.4.2    The actual velocity at Slow speed depends on the drive equipment installed.
3.5    Drive(Fast,d), where d is not Stop, shall move the elevator at maximum possible speed in the direction d as determined by a velocity profile.
3.6    CarPosition shall be updated according to integration of Car speed as determined by Drive() commands and an acceleration profile.
3.7   Cable slip may cause CarPosition to change while the Drive is commanded to Stop,

4. DoorMotor[b, r]

Replication:

Instantiation:

Assumptions:

None

Input Interface:

Output Interface:

Velocity Profile:

State:

CONSTRAINTS:

4.1    D_position shall be within the range [0,50] regardless of DoorMotor[b, r] commands.
4.2    The DoorMotors[b, r] themselves shall not activate DoorReversal[b, r] sensors.
4.3    DoorMotors[b, r] shall operate properly even if transitioned between Open and Close (or Nudge) in either direction without an intermediate Stop command.

BEHAVIORS:

4.4    DoorMotor[b, r](Stop) shall stop changes in door position within 100 msec.
4.5    DoorMotor[b, r](Open) and DoorMotor[b, r](Close) shall cause door[b, r] to Open and Close respectively according to a velocity profile.
4.6    DoorMotor[b,r](Nudge) shall cause the door to close at a speed that is slow enough to avoid injuring passengers according to a velocity profile.
4.7    If the door is blocked by a passenger and the DoorMotor[b,r] is commanded to Nudge, the door shall stop when it makes contact with the passenger.
4.6    D_position shall be kept updated by a physical model to indicate current positions of simulated doors.

5. DoorControl[b, r]

Replication:

Instantiation:

Assumptions:

Input Interface:

Output Interface:

State:

CONSTRAINTS:

5.1    DoorClosed[b, *] shall be True when there is no mAtFloor[f, b] that is True.
5.2    Any DoorReversal[b,*] shall not be True for more than an accumulated time of 50 msec without causing all DoorControllers[b,*] to perform an Open or Nudge command.
5.3    Doors should keep moving in desired direction unless commanded otherwise, subject to the constraints of the door object.
5.4    All doors should be commanded to identical positions at all times.
5.5    If CarWeight(x) >= MaxCarCapacity, the doors shall open completely until the car is no longer overloaded.

TIME-TRIGGERED BEHAVIORS:

5.6    If any mAtFloor[f, b] is True and f equals mDesiredFloor.f, and mDriveSpeed = (0, d) or mDriveSpeed = (s, Stop) then:
    5.6.1  DoorMotor[b, r] shall be commanded to Open;
    5.6.2  CountDown shall be set to Dwell.
5.7    If mDoorOpened[b, r] is True, then
    5.7.1  DoorMotor[b,r] shall be commanded to Stop.
    5.7.2  CountDown shall be decremented.
5.8  If mDoorClosed[b, r] is True, then DoorMotor[b,r] should be commanded to Stop.
5.9  When CountDown <= 0, DoorMotor[b,r] should be commanded to Nudge.
5.10 If mCarWeight(g) >= MaxCarCapacity, and mDoorOpened[b, r] is False, DoorMotor[b, r] shall be commanded to Open.
5.11 Dwell shall be set to an appropriate value based on mDesiredDwell[b].
5.12 mDoorMotor[b,r] shall be set to the current value of DoorMotor[b,r]

6. DriveControl

Replication:

Instantiation:

Assumptions:

Input Interface:

Output Interface:

State:

CONSTRAINTS:

6.1    Drive shall have been commanded to Stop whenever any mDoorClosed[b, r] is False.
6.2    Drive shall have been commanded to Stop whenever any mDoorMotor[b, r] is commanded to Open.
6.3    The commanded value of Drive shall either be the same as or "adjacent to" the value of DriveSpeed.
6.3.1    In the following table, any entry with an 'X' means that that Drive command is considered adjacent to the corresponding value of {DriveSpeed}:

Drive Speed Values
Drive Command Values
FastSpeed >= DriveSpeed >= SlowSpeed, UP
SlowSpeed >= DriveSpeed > LevelSpeed, UP
LevelSpeed >= DriveSpeed > 0, UP
DriveSpeed == 0,STOP
LevelSpeed >= DriveSpeed > 0, DOWN SlowSpeed >= DriveSpeed > 0, DOWN
FastSpeed >= DriveSpeed >= SlowSpeed, DOWN
Fast, Up
X






Slow, Up
X
X
X
X



Level, Up

X
X
X



Stop, Stop


X
X
X


Level, Down



X
X
X

Slow, Down



X
X
X
X
Fast, Down






X

6.4    Drive should be Stopped whenever mEmergencyBrake is activated.
6.5    If mCarWeight(x) >= MaxCarCapacity, the drive shall not be commanded to {Slow, d} or {Fast, d}until the car is no longer overloaded.

EVENT-TRIGGERED BEHAVIORS:


7. LanternControl[d]

Replication:

Instantiation:

Assumptions:

Input Interface:

Output Interface:

State:

CONSTRAINTS:

7.1    Both CarLanterns[d] shall not be On at the same time.

EVENT-TRIGGERED BEHAVIORS:


8. HallButtonControl[f, b, d]

Replication:

Instantiation:

Assumptions:

None

Input Interface:

Output Interface:

State:

CONSTRAINTS:

None

EVENT-TRIGGERED BEHAVIORS:


9. CarButtonControl[f, b]

Replication:

Instantiation:

Assumptions:

None

Input Interface:

Output Interface:

State:

CONSTRAINTS:

None

EVENT-TRIGGERED BEHAVIORS:


10. CarPositionControl

Replication:

Instantiation:

Assumptions:

None

Input Interface:

Output Interface:

State:

CONSTRAINTS:

10.1    The Car can be at only one position at a time.
10.2    The CarPositionIndicator shall display the current floor whenever any of the doors are open.
10.3    The floor indicated by the car position indicator shall only change by one floor in either direction per update cycle, and should be a close approximation to the car's actual position.  The direction of change shall be in the same direction the Drive is moving. By "close approximation" we mean within stopping distance in the direction of motion.

TIME-TRIGGERED BEHAVIORS:

10.4     Whenever any mAtFloor[f, b] is True, CarPositionIndicator shall be commanded to display CurrentFloor. 

11. Dispatcher

Replication:

Instantiation:

Assumptions:

Input Interface:

Output Interface:

State:

CONSTRAINTS:

11.1    Target shall be a valid Floor number from 1 .. MaxFloor inclusive.
11.2    The desired direction d of mDesiredFloor(f, b, d) shall not be Up when f = MaxFloor .
11.3    The desired direction d of mDesiredFloor(f, b, d) shall not be Down when f = 1.

TIME-TRIGGERED BEHAVIORS:

11.4    mDesiredFloor.f shall always be set to Target.
11.5    mDesiredFloor.d shall always be set to Stop.
11.6    Whenever any mDoorClosed [b, r] is False, then
   11.6.1  Target shall be set equal to ((f mod MaxFloors) + 1)
   11.6.2   mDesiredFloor.b shall be set to b, where f, b is whichever mAtFloor[f, b] is True
11.7  If all mAtFloor[f, b] are False AND any mDoorClosed [b, r] is False (which means doors are not closed between floors!); then
    11.7.1   Target shall be set to 1
    11.7.2   mDesiredFloor.b shall be set to None .
11.8   If two mAtFloor[f, b] values are True with the same value f, then mDesiredFloor.b shall be set to Both.
11.9    mDesiredDwell shall always be set to a constant appropriate value for door open dwell.