Home   :   Matrix Language   :   Model Examples   :   Passenger Elevator

Passenger Elevator Model

Introduction

The Passenger Elevator model describes a workable elevator (lift) system that employs a simplistic dispatching algorithm.  An assigner entity is used to resolve possible contention for elevators.

The model features several entities that have lifecycles shown later in the State Transition Diagrams (STDs) below.  Together, these entity lifecycles coordinate the behaviour of the system to events occurring in the Real World and generate their own events that have an effect on the Real World.

Overview

Real elevator systems can be very complex.  In a tall building with many floors and several elevators, there can be billions of different ways to allocate elevators to requests from floor buttons; and of course this must all be processed in a fraction of a second.  Sophisticated destination dispatching algorithms and passenger information acquisition systems are employed to make use of the available elevators in the most wait time efficient manner possible.

The terminology used in the model is North American based:

Elevator - In other English speaking countries this is called a lift.  Generally refers to the passenger visible parts of a vertical transport system.

Car - Confusingly, this can also be called a lift, but is actually the entire load carrying unit including the frame, cab and doors.  The cab or cabin is the enclosure in which passengers ride and is part of the car.

Door - Most elevators have two doors but conceptually this is considered as being just the one door in the model.  It also avoids having to name an entity in the plural which can only be a good thing.

Model Walkthrough

The Domain Bridge Diagram (DBD) shows the Elevator Management subject matter area as a separate top level domain.  The top level domain is known as the Application domain.

Normally, other lower level Service domains would appear on this diagram.  Typically, Service domains provide an input-output interface to the Real World, another system or satisfy some other requirements such as access to a database for persistent storage.

You can click on the diagram below to see the Elevator Management domain complete with bridges to a passenger Controls domain and an Elevator Machinery domain.

The Learning Edition of Matrix will only support the use of a single domain so a slight accommodation has been made to the Elevator Management domain.

Realm:Analysis_Of_Application

The Entity Relationship Diagram (ERD) for the Elevator Management domain shows the relationships between the various entities in the system.  The car entity is central to the diagram and is directly related to most of the other entities (but this does not have any modeling significance in itself).

It may seem surprising that an elevator model can function with just two attributes but it should be noted that in Matrix models the relationships between entities can be made do most of the “heavy lifting”.

At any point in the model's operation, we can find out what floor a specific car object is on by navigating the Car:Currently_at:Floor relationship and finding the related floor object.  We can see from the model that a car object can only be related (via Currently_at) to one floor object and since the relationship is unconditional, it must be related to only one floor object at all times.  This reflects the reality of any physical object existing in only one place at one time.

Similarly, other relationships the car entity has can be used to find out what is happening to the elevator in the Real World and also what will happen to the elevator in the immediate future.  For example, looking at the Car:Scheduled_to_move_up_to:Floor relationship we can predict which floors the car will shortly be visiting.

We can also determine which floors a car is allowed to stop at by traversing the Services relationships between car, car service and on to floor.

Domain:Elevator_Management

In behavioural terms, the floor entity lifecycle is quite simple as its purpose is to just pass on the hall button pushed event to the service assigner entity.

On all the STDs below you can click once to get the same diagram but on its own page.  Clicking again will reveal the same diagram again but this time annotated to show the source of input events and also which states produce events and their destination.

Entity:Floor

The door state machine is a bit more interesting but still fairly simple to understand as the states merely describe the states you would expect from any normal physical door.  The possible exception is the "Avoiding Obstruction" state which we would not normally expect to find in a non-automated door.  This extra state is used to model the response to a passenger or item of luggage getting in the way of the door.

The car entity instructs the door to Open and Close while the other events come from the elevator's door Machinery.  The door entity lets the car entity know when the door has opened and closed.  It is also solely responsible for controlling the elevator door motors.

Entity:Door

Car service is an entity that is used by the service assigner to manage the relationship between floors and cars objects.

The purpose of the car stop entity is to pass on events originating from button pushes inside the elevator cabin.  The button is pushed by a passenger requesting to travel to a particular floor.

Entity:Car_Stop

Assigner entities manage the allocation of shared resources.  It may not be immediately obvious why such an entity is required; after all when the model's generated code executes, the program can only do one thing at a time anyway.

For the usual application program you may indeed be able to "get away" with not considering contention issues but the model would not be correct.  If at a later date, the model was generated using another Model Compiler; one that implemented a distributed multi-tasking highly concurrent software architecture then the model would be seen to fail badly.

The mistake arises from not modeling what the system of entities contained in the problem space should do, but from the idea that you are describing what a program should do.

The Real World is naturally concurrent, things and events happen at the same time and in parallel.  This can't be avoided when modeling in the Real World and so the analysis formalism (notation) must take this fact into account and of course you as a modeler must think concurrently too.

For example, you must consider what happens when two passengers press their call buttons at exactly the same time when there is only one lift available?  In a highly concurrent implementation what should determine which floor the elevator will attend to first?

The method uses an assigner entity to manage this contention by serialising events at a single object.  Remember that an object's state machine can only action one state at a time.  Pending events exist in the object's pool until required.  You may think of a pool as a queue of events at the object and indeed this might be implemented as a queue but this way of thinking would not be entirely correct at the modeling level.

Entity:Service_Assigner

The car entity has three main stages.  Stopped, dealing with the schedule and moving.  When stopped it deals with events from the elevator car controls and interacts with the door.

Determining which passenger to attend to next involves examining its relationship to the floor objects.  When the car is moving it receives and sends several events to the elevator shaft machinery.

It's interesting to note that the model does not contain attributes (of Building) that hold the number of elevators or floors.  This information can be determined by the number of objects belonging to car and floor entities.

A car cannot be sent to a floor that does not exist because the existing buttons can only send cars to existing floors!  Of course, when executing the model under the Simulator an out of range number can be chosen.  It should be noted that the integer type chosen for the Floor.Number attribute does limit floor numbers to valid values.

Entity:Car

Matrix Model

Click on the Code Map diagram below to get a view of the code.

Expected Output

When the Matrix model is executed under the Simulator with all tracing turned off the following display output is produced in the command prompt window:

    Matrix Model Simulator - Learning Edition - Version 1.0.0

    Development on THU-02-JAN-2014 @ 12:18:41

    Copyright (C) 2014, Dark Matter Systems Ltd.  All rights reserved.

    Connection established: MATRIX*CORE - Version 0.5.2

$

$ | Passenger Elevator Scenario - Passenger Travels from First to Fifth Floor

$

$ | On each floor a control panel is set into the wall by the elevator doors.  A

$ | floor control panel has a call button.

$ |

$ | Inside the car there is another control panel containing seven floor request

$ | buttons plus an open door button and a close door button.

$ |

$ | Normally, both control panels are handled by a Controls service domain that

$ | supplies the following events:

$ |

$ |    |     Source: Floor Passenger

$ |    Floor : Request_service

$ |    |

$ |    |     Source: Car Passenger

$ |    Car      : Open_door

$ |    Car      : Close_door

$ |    Car_Stop : Go_to_floor

$ |

$ | Also, a Machinery service domain supplies the following car and door sensor

$ | events:

$ |

$ |    |     Source: Door Sensors

$ |    Door : Open_completed

$ |    Door : Obstruction

$ |    Door : Clear

$ |    Door : Close_completed

$ |    |

$ |    |     Source: Car Sensors

$ |    Car : Moving

$ |    Car : Floor_approaching

$ |    Car : Car_stopped

$ |

$ | In this simulation they are supplied by the developer.

$ |

$ | The events are specified in the model under the EventContext statement.

$ |

$ | A Matrix model acts on the Real World by issuing events to actuators via

$ | service domains.  In the Passenger Elevator model, exported events are

$ | directed to the Machinery domain and are indicated by an

$ | "EVENT -> Machinery::" prefix.

$

$

$ | Initialise System

$ | -----------------

$

$ | At the start of the simulation all elevators are at the first floor

$ | and there are no requests for service pending.

$

$ trace all off

$ trace display on

$ trace events on

$ trace states on

$

$ initialise all

$

$ display all

$

$

$ | Passenger Calls Elevator

$ | ------------------------

$

$ | All elevators at the first floor.  A passenger at the first floor wishes

$ | to travel up to fifth floor.

$

$ | Passenger at the first floor calls the elevator by pressing the call button.

$ create event identity Elevator_Management Floor Request_service 1

EVENT -> Machinery::Door_Opening

$

$ | Event generated by door sensor.

$ create event identity Elevator_Management Door Open_completed 1

$

$

$ | Passenger Enters Elevator

$ | -------------------------

$

$ | Passenger in car presses the fifth floor button.

$ create event identity Elevator_Management Car_Stop Go_to_floor 1 5

$

$ | Event generated as external timer event.

$ create event identity Elevator_Management Car Close_door 1

EVENT -> Machinery::Door_Closing

$

$ | Event generated by door sensor.

$ create event identity Elevator_Management Door Close_completed 1

EVENT -> Machinery::Car.Moving (Direction:UP)

$

$

$ | Elevator Starts Ascent

$ | ----------------------

$

$ | Event generated by car sensor.

$ create event identity Elevator_Management Car Moving 1

$

$ | Events generated by car sensor as it moves.

$ create event identity Elevator_Management Car Floor_approaching 1 2

$ create event identity Elevator_Management Car Floor_approaching 1 3

$ create event identity Elevator_Management Car Floor_approaching 1 4

$ create event identity Elevator_Management Car Floor_approaching 1 5

EVENT -> Machinery::Car.Slowing ()

$

$ | Event generated by car sensor.

$ create event identity Elevator_Management Car Car_stopped 1

EVENT -> Machinery::Door_Opening

$

$ | Event generated by door sensor.

$ create event identity Elevator_Management Door Open_completed 1

$

$ display entity Elevator_Management Car

$ display entity Elevator_Management Door

$

$

$ | Passenger Exits Elevator

$ | ------------------------

$

$ | Event generated as external timer event.

$ create event identity Elevator_Management Car Close_door 1

EVENT -> Machinery::Door_Closing

$

$ | Event generated by door sensor.

$ create event identity Elevator_Management Door Close_completed 1

$

$

$ host pause

Press any key to continue . . .

$

$ exit

        Model Simulation Elapsed Time: 00:00:01

    Disconnected from MATRIX*CORE on THU-02-JAN-2014 @ 12:18:42

An additional scenario file that simulates a busy elevator system involving all lifts and multiple elevator call requests is included in the Matrix download.