Dr Richard Peters, Peters Research Ltd

This paper was published in the International Journal of Elevator Engineers. Volume 4 No.2 (2002). It is reproduced with permission from The International Association of Elevator Engineers. This web version © Peters Research Ltd 2009.

Abstract

Elevate is traffic analysis and simulation software used by consultants, elevator companies and researchers world-wide.  The program runs under Windows, reflecting the dominance of this platform, and customers expectations for easy to use graphical user interfaces.  Other platforms may need to be considered in future years.  A detailed description of the main simulation classes provides an outline specification for Elevate’s object orientated elevator simulation.  Elevator simulation is becoming increasingly more flexible and powerful.  Current and possible future developments to Elevate are discussed.

Introduction

Elevator simulation models of varying sophistication have been written and applied for many years.  The continuing improvements in computer technology and software development tools make increasing complex and comprehensive simulation models feasible.

The author writes primarily from his own experience in developing the traffic analysis and simulation software package, Elevate[1].  Other simulation programs have different approaches, but most of the key issues, variables and functions will be similar.

The discussion will be of interest to those who want to understand the basic principles of how an elevator simulation works.  For aspiring authors of elevator simulations, the class descriptions and flow diagram provide a good starting point for development.

Software technology

When writing a simulation, choosing the software technology to apply is an early and important decision.

The author began writing elevator simulation programs in the 1980’s.  At that time, most engineering programs were being written for the IBM PC with Microsoft DOS.  In the early 1990’s Microsoft Windows emerged as the dominant operating system and users began to expect easy to use, graphical user interfaces.

Elevate is written using Microsoft Visual C++.  This is the author’s favoured development tool as Microsoft Windows is currently the most widely used operating system.  C++ allows the developer to apply objected oriented programming as discussed in following sections.  It also produces very fast and portable (re-usable) code.

Future development tools and platforms for elevator simulation will be determined by the continued dominance or loss in popularity of Windows.  If Windows looses favour, alternatives will need to be considered.  Two possibilities are:

• Java applications – the Java language is closely related to C++, but runs on a “virtual machine” that is available for different operating systems.  So, a single version of the software can run under all popular operating systems. Other single source to multiple platform development tools are emerging, and will be popular with developers.
• Internet applications can be run on the user’s machine (client side) and on the computer hosting the web site (server side).  For an Internet elevator simulation program, the author envisages a client side application in Java to enter data, view the simulation display and present the results.  The client side application would link to a server side application, which would perform the simulation calculations in C++ or other language.

Both alternatives are already technically feasible but the development platforms are less mature, so some advanced functionality would not be available, and the programs would run slower than native Windows applications.

Software development tools are continually improving, so the best tools for elevator simulation need to be kept under review.

Introducing objects

Traditional structural programming techniques break a program into several smaller tasks by defining a set of functions.  Object oriented programming (OOP) builds on this by introducing objects.  In an object, both the variables and functions are grouped together.  The behaviour (i.e. the variables and functions) of an object is defined by the class to which it belongs.  Each object is an “instance” of a class.

Object oriented programming uses abstraction to allow the programmer to consider the important details of the problem in hand, and to ignore unnecessary complexities.  Encapsulation is applied to hide the details of a solution so that the solution is easier to understand.

For an example of how OOP is mimicking the real world, consider Ginger the cat in Figure 1.

Figure 1   Ginger the cat ^{graphic from [2]}

The world has a class cat.  Everything in the cat class has a set of the same variables (no of paws, age, sex, etc.) and a range of functions (if you chase it runs; if you pat it, it  purrs).  Ginger is an object, and an instance of the cat class.  He has all the functions and variables of a cat.  The cat class utilises abstraction and encapsulation:  If we feed Ginger, he will eat without us having to understand the complexities of his digestive system; we can concentrate on the tasks in hand such as preparing his food and stroking him.

Returning to elevators, we can define the class elevator with variables such as capacity and speed, and functions such as StartJourney().  We can create as many elevator objects as we need; each elevator object is independent, but may use all the variables and functions defined by the class.

OOP helps break down complex problems into manageable parts that are easy to work with as they represent familiar ideas or components.   The approach works extremely well for elevator simulation.  The author’s original simulation program in Fortran became more difficult to enhance as the program became larger and more complex.  Elevate is object orientated and currently has over 20 000 lines of software code, yet adding additional functionality is relatively straightforward.

Class descriptions

Elevate has over 30 classes.  Many are related to the user interface and other supporting features.  The main simulation classes, their principle variables and functions are discussed in the following subsections.

Building class

The building class defines the building in terms of number of stories and story heights.  The variables and functions are summarised in Table 1.

Table 1   Building class variables and functions

Motion class

The main purpose of the motion class is to enable an elevator object to determine its current position and speed while travelling.  It can also tell the elevator when it will arrive at its next stop, and whether or not it can stop in time if a new call is registered in front of its next scheduled stop.  The variables and functions for the motion class are defined in Table 2.  Implementation is based on ideal elevator kinematics formulae[3].  Examples of the velocity – time plots generated by the motion class are given in Figure 2.

Table 2   Motion class, variables and functions

Figure 2   Velocity-time plots generated by motion class

Elevator class

The elevator class defines an elevator (rated speed, capacity, floors served, etc.) and its current status (position, speed, load, etc.).  The motion class is applied to enable the elevator to move according to the selected journey profile.  The elevator class includes algorithms to allow elevators to answer landing and car calls according to the principles of directional collective control.  (Most elevator control systems adopt a directional collective control strategy regardless of the complexities of the dispatcher algorithms.)  The main elevator class variables and functions are defined in Tables 3 and 4.

Table 3   Elevator class variables

Table 4   Elevator class functions

Dispatch class

The dispatch class defines rules for allocating which elevator serves which calls.  When a passenger presses a landing call, the dispatch class decides which elevator should serve the call.  The dispatch class variables and functions are defined in Table 5.

Table 5   Dispatch class functions and variables

Person class

The person defines a person, what time he/she arrives at the landing station, where he/she wants to go, their mass, etc.  Once the journey is complete, the class provides details about passenger waiting and transit times.   Variables and functions of the person class are defined in Table 6.

Table 6   Person class functions and variables

Flow diagram

Elevate is a time slice simulation; it calculates the status (position, speed, etc.) of the elevators, increments the time, re-calculates status, increments time, and so on.  A simplified flow diagram of simulation is given in Figure 3.

Future developments

There are many possible developments to an elevator simulation program such as Elevate.  Below are some of the enhancements that are in progress or under consideration.

Closer integration with installed control systems

Elevate allows users to program their own dispatcher algorithms into a dynamic link library (DLL) which is called by the program.  There is ever increasing interest in and demand for this feature; simulation is an excellent tool for developing, testing and demonstrating control systems.

Currently customers are programming dispatch algorithms in a format suitable for Elevate.  In the future we envisage closer and closer links between Elevate and installed control systems, so that algorithms can be exchanged with compatible systems at the click of a button.

Figure 3   Simplified flow diagram for object orientated elevator simulation

Total building models

There are a number of pedestrian modelling software tools. These have been developed to model the evacuation of buildings in an emergency, and the flow of people in transport terminals such as airports and train stations.

These programs currently have either very crude or no elevator model.  We are considering the possibility of linking programs so that the elevator model in Elevate can contribute a total models of building circulation.

The more advanced pedestrian modelling software programs are object orientated, so the interface between programs is conceptually simple.  In its normal mode, Elevate generates its person objects which push the landing buttons, wait for the elevator, get in and press the car call buttons, etc.  In a total building model the person objects will be created by the pedestrian modelling software.  A person object will move around the building until he/she needs to use an elevator, when he/she will be introduced into the elevator simulation model.  Once their elevator trip is complete, the person object will be returned to the total building model at the new floor level.

Traffic analysers

In the assessment of passenger service quality, the most important traffic analysis results are average passenger waiting and transit times.  Using simulation we can measure these results as we know at what time every passenger arrives, and how and when they are transported.

Traffic analysers can be interfaced with an installed elevator control system to record the time every landing and car call is made and cleared.  Many modern control systems incorporate similar functionality.  A range of traffic and performance measures can be determined, for example:

• average response time to landing calls by time of day
• distribution of response times
• distribution of car calls by floor

A traffic analysers does not measure average waiting and transit times as an elevator does not know when someone arrives in a lobby; it only knows when a landing or car call button are pressed.  There is often more than one person behind a call, but the traffic analyser will not know this.  (For this reason, it is generally unreliable to use a conventional traffic analyser results to assess the demand on an existing system, or to evaluate the benefits of modernisation.  The author recommends that designers carry out surveys counting people as opposed to calls.)

Within a simulation program it is straightforward to implement a compete traffic analyser.   This will have a number of applications:

• if using a simulation to model existing installations with an installed traffic analyser, the simulation traffic analyser should present similar results.
• there is a theoretical relationship between the passenger arrival rate and, the time from landing calls being cleared to being re-registered[4].  With simulation it will be possible to investigate this relationship further and possibly develop software that can estimate actual traffic flow from traffic analyser data.

Modelling of new technology

Established technology dictates that an elevator moves in one dimension, up and down a shaft.  And that there should only be one elevator per shaft.  This is a major limitation, especially in high rise buildings where the relative core space required by the elevators is high.  The ultimate solution it to have multiple elevators in a single shaft, and for them to be able to overtake though moving in at least two dimensions (side to side as well as up and down).   Elevate is currently being extended to model this so that one of our customers can develop an appropriate control system for a research project.  The drive technology to apply this control system is yet to be developed, but recent developments in self-propelled elevators [5] suggest that the concept is feasible.

Multiple deck elevators

Elevate currently models single deck elevators.  Double deck elevators will be added to Elevate in due course.  If required, it would be feasible to model triple, quadruple or even n deck elevators  (where n is any number).

Conclusions

Elevator simulation is now readily available and increasingly popular for traffic analysis and control system design.

In recent years software technology has developed so that complex programs are easier to develop.  Object orientated programming technology is extremely helpful to the developer, and graphical user interfaces help make programs easy to use.

An elevator simulation program requires many classes.  We have discussed Elevate’s principle simulation classes, which are building, motion, elevator, dispatch and person.

Elevate and other simulation programs will continue to be developed to provide increased functionality.  Some current and future possible developments have been discussed.  The author welcomes other comments and suggestions.

REFERENCES

1. Elevate traffic analysis and simulation software, distributed by Elevator World, Inc.
2. Perry G, Ross J  Visual C++ By Example (Indianapolis: Que Publishing) (1994)
3. Peters R D  Ideal Lift Kinematics: Derivation of Formulae for the Equations of Motion of a Lift International Journal of Elevator Engineers, Volume 1 No 1 (1996)
4. Peters R D  Green Lifts?  Proceedings of CIBSE National Conference 1994 (The Chartered Institution of Building Services Engineers) (1994) (republished by Elevator World, June 1995 and by Elevation, Autumn 1995)
5. SchindlerMobile elevator, www.schindler.co.uk

TRADEMARKS

Elevate is a trademark of Peters Research Ltd.  Microsoft, Windows and Visual C++ are either registered trademarks or trademarks of the Microsoft Corporation.