Discrete Event Elevator Simulator Architecture

Discrete Event Elevator Simulator Architecture

Discrete Event Elevator Simulator Architecture Mohamed Aladem, Lutfi Al-Sharif Mechatronics Engineering Department, The University of Jordan, Amman 11942, Jordan Abstract: Analytical calculation methods have been traditionally used to design and evaluate elevator systems performance. The problem in these calculations methods is that they rely on many simplifications and assumptions in order to make the calculations possible. Where the traffic design requirements are more complicated, computer simulations are needed. In this paper, a vertical transportation simulator design is proposed along with a sample implementation called ElevSim. The simulator can be used to study different traffic conditions, different elevator configurations and different group control algorithms. Keywords: simulation, elevator, lift, discrete event 1.0 INTRODUCTION A traffic analysis is the study of the performance of a group of elevators, based on assumptions about the expected traffic situation. A traffic analysis should cover a variety of important traffic situations, especially when planning new buildings. Traditionally, designers have relied on analytical methods based on formulas which only cover a very limited range of traffic situations (usually, only up-peak traffic). The formulae reflect theoretical assumptions rather than a realistic behaviour of elevator groups. Where the traffic design requirements are more complicated, computer simulations are needed [1]. Our objective is to build a flexible yet powerful elevator simulator in order to perform traffic analysis studies. The simulator must be flexible in order to allow the user to insert his/her group control algorithm with minimum ease and draw required performance measurements. It must also be extensible, i.e., new performance parameters or new simulation entities can be added easily. This discrete-event simulator uses event-scheduling world view [2]. The ideas and concepts in this paper are presented in a programming language agnostic manner. They can be applied in any object-oriented programming language such as C++, C# or JAVA. A sample C++ implementation can be found at: https://bitbucket.org/alademm/elevsim 2.0 PREVIOUS WORK Some of the notable achievements in the field of elevator simulation are:

Page 1 of 15

Discrete Event Elevator Simulator Architecture

Figure 1: Basic Simulator Classes.

• Elevate, which is a popular vertical transportation analysis and design tool developed by Peters Research. Elevate is based on the time-slice simulation approach. For more information: www.peters-research.com • Building Traffic Simulator (BTS) is developed by KONE Corporation and utilises discrete-event simulation [4]. Monte Carlo simulation has also been used to find the value of the round trip time. MCSETAD (pronounced ‘maxi-tad’) stands for Monte Carlo Simulation Elevator Traffic Analysis and Design. It is a tool developed by the authors utilising Monte Carlo Simulation [3]. The complete source code is available at: https://bitbucket.org/alademm/mcsetad/ 3.0 SIMULATOR OVERVIEW A basic UML diagram of the simulator classes is shown in Figure 1. 4.0 CORE CLASSES 4.1 Event Event class abstracts event concept. It contains the following attributes: • Event type, an instance of the Event Type enumeration as shown in Figure 1. This enumeration contains all the possible events. Entities will use this attribute in order to decide how to respond to the event. • Event time, a floating-point number holding the event time. Event times are absolute, i.e., they are relative to time zero (the time when the simulation started). The simulator will use this attribute to update the simulation time, and entities will use it indirectly to schedule future events as will be discussed in detail later. • Additional Arguments, the event may need to use these to contain additional information. For example, to contain information about the identity of the sender of this event is and who the intended receiver is. Page 2 of 15

Discrete Event Elevator Simulator Architecture 4.2 Entity Entities can respond to events and schedule new ones. It is an abstract base class with only one pure virtual method called OnEvent. Whenever an event occurs, the entity’s OnEvent method will be called and the event will be passed as a parameter. Any entity must derive from this class and provide its own implementation for the OnEvent method to model its own behaviour. As it is processing the current (i.e., imminent) event, most probably it will need to schedule future events for itself or other entities; it can do so by creating an event object with the appropriate event type, time and additional parameters, then asking the simulator to schedule this event into its future event list and the simulator will take it from there. Remember that event times are absolute, so when an entity creates an event in order to schedule it, it must give it the correct time relative to time zero. A quick trick to do so is to query the imminent event time; this time represents the current absolute time, then it can be added to the appropriate interval and the desired event initialised with this time and scheduled. Note that if it is required that an event take place immediately, the event can be scheduled with time of the imminent event. 4.3 Simulator The simulator is responsible for conducting the simulation by keeping track of the future event list, dispatching the imminent event to the registered entities and updating the simulation time. The most important attributes of the simulator are: • • •

The future event list, a list that contains all the pending events (i.e., events that are yet to take place). Entities list, a list of all the registered entities that can schedule new events and will be notified by the events as they happen. Simulation time, current time of the simulation. It is numerically equal to the imminent event time.

Prior to starting the simulator, it must be initialised. The initialisation sequence involves the following: • • • •

Adding the entities to the entities list and constructing the building object (instance of the Building class and the only one in the simulation). Resetting simulation time to zero. Any new simulation needs to start from zero time. Clearing the future event list from any possible events from a previous simulation. Bootstrapping (to be described later).

The single most important and interesting method is execUntil(double endTime). This method runs the event loop until simulation time exceeds the time specified by endTime. Each iteration of the event loop executes a single event. The event loop can be summarised as: 1. The future event list is sorted in ascending order in accordance with the event time. 2. The first event in the list is the imminent event. It has the minimum event time. 3. Removal of the imminent event from the list and update of the simulation time to be equal to its time. Page 3 of 15

Discrete Event Elevator Simulator Architecture 4. Passing the imminent event to all entities in the entities list through the OnEvent method. 5. After the last step has been completed, each entity gets its chance to respond to the event as necessary. So the imminent event is no longer needed and has therefore to be deleted. 6. Repeating the last steps until the simulation time exceeds the end time. From the discussion above, it is now clear why event time is absolute. Scheduling an event with a time that is equal to the imminent event time results in its immediate execution. However, there is a problem with this scheme. When the simulator starts, the future event list is empty so the simulation cannot be started? There are still no events in the future events list, entities do schedule future events as a result of the execution of the imminent event, so no event will ever be scheduled and the system will remain idle forever. For this reason, it is necessary to kick start the system. This is done manually by initialising an event or two that are sufficient to start the system; this is termed bootstrapping. In this case, two events are scheduled: GENERATE_PASSENGER event will trigger the Passenger Base to start generating passengers, and passengers will start their way into the system by first registering their landing calls and the complete elevator system will start; and CONTROLLER_UPDATE that will trigger the group controller to start allocating calls. 4.4 The Building The building class is not an active entity and therefore it does not derive from Entity class. Physically speaking, the building itself is no more than a container for the floors, elevators and people, so this modelling is natural. The building class includes the following attributes: • •

•

Floor list, a list of floor objects that constitute the building itself. Elevator list, a list of references to elevators in the building. In the actual C++ implementation, this would be a list of pointers to elevator objects. When the simulator is being initialised the elevator objects will be constructed. Then the building will add pointers to the newly constructed elevators in its elevator list and the simulator will add a pointer to them in the entities list. Arrival Rate, the total arrival rate of the building.

The building class also includes several methods that aid in the interactions between different entities in the building. For example, when the controller needs information about an elevator or the building itself, it will ask the building. Floor. The floor class is a small one that contains only a handful of attributes and they are: • • • •

Arrival Rate, the arrival rate of that floor, used in mixed traffic situations. Height, the height of the floor. Population, the population of the floor. Up and Down Buttons, Boolean values indicating the status of up and down buttons on that floor.

Page 4 of 15

Discrete Event Elevator Simulator Architecture By making the floor a separate class, it can be separately enhanced by adding, for example, a panel for destination control systems. Also it is worth nothing that since the building contains a list of floors, each floor object is independent of the others. Each floor in the building can have a different height, population and individual floor percentage arrival rate. 5.0 ENTITY CLASSES 5.1 Elevator In our design, elevators are slaves to their master, the controller. That is, elevators will not start any journey unless commanded to do so by the controller, even for car calls. It is the controller’s responsibility to check the registered car calls in all elevators and landing calls at all floors, and take the appropriate actions. Attributes ID. An integer that represents the identity of the elevator in the simulation. Each elevator must, obviously, have a unique id in order to identify it from other elevators. Door status. The status of the doors: open, closed, opening or closing. Buttons. An array of Boolean values representing the status of each car button: whether it is pressed or not. Origin floor. An integer representing the origin of the current journey. The origin of a journey is the floor from which the elevator started moving from rest; so, for example, if the elevator has switched its journey while it is moving, the origin floor will not change. When an elevator comes to a complete stop at a floor, then, the origin floor must be updated to equal this floor, since this floor will be the origin of the next journey. Target. An integer representing the current target floor. Capacity. The rated capacity of the elevator. Rated Velocity, Acceleration and Jerk. Door Times. door opening time, door closing time, motor start delay and advance door opening. Journey Time. Time elapsed since the start of the current journey; it used in computing the kinematics. Motion profile times. These are a set of seven variables (from t1 to t7) that construct the motion profile of the current journey. Note that they are absolute (i.e., with respect to zero). Beam status. broken or not.

A Boolean variable representing whether the door light beam is

Page 5 of 15

Discrete Event Elevator Simulator Architecture Elevator direction. The current direction of the elevator: up, down or none. Committed direction. The committed direction of the elevator: up, down or none (i.e., not committed). Committed direction is an important concept in the simulator design. It is an answer to the question, who from the waiting passengers should the simulator board when the elevator arrives? In real-life situations, when an elevator arrives, people simply board, some may board even if the elevator is not heading toward their destination. In the simulator, rational passengers behaviour is assumed. In a simulation, where an elevator arrives at a floor, its direction becomes none and it does not know where it is heading beforehand since the controller does not have the required information yet (as it is not possible to predict the future). Thus an obvious question that arises is the algorithm by which the controller would decide which passenger should board which elevator. Any solution to this dilemma must be general as well as flexible. That is, it should not depend on a specific group control algorithm or a specific traffic pattern whatsoever. The proposed solution is the committed direction concept. The committed direction is the direction that the elevator is committed to transport passengers in. Only passengers going in the same direction as the committed direction of the elevator will board. If the committed direction of an elevator is none (uncommitted), no passenger will ever board that elevator, no matter how many times it goes up and down the building. The committed direction of an elevator is set by the controller using the setCommittedDirection method which takes one parameter, the required direction. So, the controller is responsible for setting the committed direction of any elevator, not the elevator itself. This is extremely important and the control algorithm writer must be aware of this and take it in consideration when writing the algorithm. The committed direction may not be the same as the elevator direction. For example, suppose that an elevator is currently stationary at the fifth floor, the up button is then pressed on the second floor and the controller has decided to allocate this call for that elevator. Since the passenger is going up, the controller must have set the committed direction of this elevator to up, then, it sets its target to the second floor. So, the elevator is going down to pick a passenger going up; its committed direction is up and its actual direction is down. Although the elevator may sometimes choose to ignore setTarget commands, it will respond to changing its committed direction at all times, even when it is stationary. Methods Setting Target. This method is used by the controller to set the elevator’s target floor. This method will be denoted as setTarget; and it will take only one parameter, an integer representing the target floor. When this method is called, it will first check if the elevator can actually respond to a target. An elevator will choose to ignore the setTarget command and therefore, will not change its current target in two situations: 1. If the controller has asked the elevator to stop at a floor but has not checked whether it can actually stop at it, the elevator will do the check and based on the result will respond. If it turns out that it cannot stop, it will ignore the command and continue its current journey normally. It is worth noting that the check is made by a method called canStop, which will be clarified later. Page 6 of 15

Discrete Event Elevator Simulator Architecture

2. At the moment it starts decelerating toward its current destination floor until its doors are completely closed again. If it can respond, there are two scenarios that need to be considered: 1. The elevator is currently stationary at the required target (i.e., it has a command to stop at a floor on which it is actually parked right now). In that case, it will update the target (set current target equal to required target) and schedule an ELEV_ARRIVED event to happen at this instant (as the elevator has in fact arrived). So the sequence of actions when an elevator arrives will commence. 2. The elevator, whether stationary or moving, can stop at the required target. The check is made by a call to the method canStop. If this is the case, it will update the target like before. It will then initialise the journey, a method that will be explored later. After that, it will carry out the necessary modifications to the journey to accommodate the case where the elevator is already moving. In the second scenario just mentioned, switching the journey while another journey is currently in progress requires more attention. This will be further discussed during the kinematic discussion. Journey Initialisation. This method is called by setTarget whenever it needs to initialise a journey as has been discussed. As in setTarget, this method takes the required target as a parameter. Based on the specified rated velocity, acceleration, jerk and the calculated journey distance, it will decide the journey condition (A, B or C) and calculate appropriate journey profile times (tn) that will construct the motion profile for this journey. Updating Kinematics. This is not a method by itself; rather, it is contained in the OnEvent method. It is mentioned here to describe how elevator kinematics is being updated. Elevator kinematics is based on [5] which contains a listing of all the equations and their derivation. As was discussed in the discussion about the event types available, there is an event corresponding to the end of each segment of the motion profile. Thus the event ELEV_T1 means that the elevator has reached the state corresponding to time t1 of its current journey (and so on for the rest of the journey motion profile). It is important to note that the profile starts from the origin, i.e., journey times are all with respect to zero and all equations in [5] are derived based on this assumption. The key problem is that there is a need to start a journey at any time during the simulation, and not just at zero time. If the equations are applied directly, the results will be incorrect. A little trick to work around this rather than re-deriving the equations, is to use a variable (it was denoted as Journey Time, see attributes above). The value of this variable will be reset to zero whenever a new journey starts from rest. After that the value will be updated in synchronism with the simulation time. So, this variable is zero at (t0), and is updated with the main simulation time during the journey. This is exactly what is required in order to successfully apply the kinematics equations. Thus journey time is going to be substituted in the equations rather than the simulation time itself. While velocity Page 7 of 15

Discrete Event Elevator Simulator Architecture equations provide the correct results directly, position equations will provide the position with respect to zero. Thus it is necessary to keep track of the position by recording the last position (the position of the origin floor) and according to the direction of the elevator, either adding or subtracting the results to/from the last position. Assume the elevator is starting a new journey from rest, the journey has already been initialised and the journey time variable has been reset to zero. Considering the motion profile, the elevator is currently at the origin and it needs to get to t1. So it will schedule the event ELEV_T1 to happen after (t1 - 0) from this point onwards (note that t0 is zero). After time passes, and the event ELEV_T1 scheduled becomes the imminent event, the elevator then needs to get to t2; so, it will schedule event ELEV_T2 to happen after (t2 - t1) from now and so on. It is important to keep the journey condition in mind, to know when the journey actually ends. For example, if the journey condition is C, and the elevator has received the event ELEV_T3, then it will schedule the event ELEV_ARRIVED after (t4 - t3) and not the event ELEV_T4. It is necessary to consider the case where the elevator is already moving. First, it is necessary to check that it is possible to switch the journey, after that, the new journey will be initialised. The journey time must not change, so it is necessary to complete with the new profile at the correct starting time, (which is another advantage of using a separate journey time). Then, it is necessary to check in which segment of the profile the elevator was when the switch was made. This is necessary in order to re-schedule the appropriate elevator kinematic event. For example, if the elevator was in the segment (t1→ t2) then it would have scheduled ELEV_T2 event which according to the new profile is not correct anymore. So, the old ELEV_T2 event must be cancelled, and a new one scheduled after (t2 - jt) where jt is journey time. This re-scheduling happens inside the setTarget method. Journey time is updated at elevator kinematics events and at controller updates. When the controller schedules an update for itself, it may need to get the current kinematic state of an elevator, so journey time must be updated to the current instant in order to get the correct results when substituting into the equations. Getting the Current Floor. A method named getCurrentFloor that returns the current floor of the elevator. When the elevator is stationary, the current floor is simply the floor it is currently parking at (the origin floor). But what if the elevator is moving? When exactly the elevator is at a certain floor? It will be assumed that when an elevator is no longer able to stop at a certain floor, then it is assumed to be at that floor (i.e., that floor is its current floor). The algorithm is described below: 1. If the elevator direction is none, then the current floor is the origin floor. 2. If the elevator direction is up then iterate over the floors from the origin floor till the last floor in the building, and check if the floor level is higher than the current position of the elevator and the elevator cannot stop at this floor, then this is the current floor. 3. Likewise, if the elevator direction is down, iterate over the floors from the origin till floor zero, and check if the floor under test is actually lower than current position of the elevator and the elevator cannot stop at it, then this floor is the current floor. Page 8 of 15

Discrete Event Elevator Simulator Architecture

Figure 2: Testing the stopping ability graph.

Testing the Ability to stop. This method is called canStop, and takes the floor under test as a parameter. Generally, an elevator will not be able to stop successfully at a floor; if, according to the current kinematic state, the remaining distance to that floor is not sufficient to decelerate smoothly and stop. That is, there is a minimum stopping distance required by the elevator to come to a complete standstill. Equations for the minimum stopping distance can be derived; however, a special method is introduced in order to avoid unnecessary derivation. This idea is illustrated in Figure 2. These are the motion profiles for two journeys; both starting from the main terminal, one ending at the sixth floor and the other at the fourth floor. The plots were generated assuming equal floor height of five meters, and an elevator with speed 1.6 m/s, acceleration of 1 m/s2 and jerk of 1 m/s3. Assuming that the elevator was initially heading towards the sixth floor and during the journey it received a command to head for the fourth floor instead. Two scenarios can take place: 1. The elevator receives the command before the instant in time of 12.5 s. In this case, if the switch is made, the elevator can successfully decelerate towards the new target. Since it has not started decelerating yet, it still has the chance to do so. 2. The elevator receives the command after the instant in time of 12.5 s. In this case the switch cannot be accomplished successfully, because had the elevator been actually moving in accordance with the new profile, it would have started decelerating some time ago. So, if the switching of the profile is made, the elevator will not have the chance to decelerate fully and consequently it will miss its stopping point. To summarise, the idea is to construct a hypothetical journey from the origin of the current journey (the origin floor) and to the floor under test (destination floor). Then according to the current journey state a decision is taken as to whether such a Page 9 of 15

Discrete Event Elevator Simulator Architecture hypothetical journey can be successfully completed or not. To perform the comparison, a computation is carried out of the time that a journey starts decelerating (the corner after which the profile starts falling) of the hypothetical journey, and then this is compared to the journey time of the current actual journey. If the journey time is larger than decelerating time then it cannot stop; otherwise, it can. Event Processing. Event processing is implemented in the mandatory OnEvent method. It is assumed that the elevator will check that it is the target of the event. When the elevator schedules an event for itself, it will add its id to the event, and when it receives an event, it will perform the check. 1. If event type is ELEV_T1 • •

Update journey time to t1. Schedule event ELEV_T2 after (t2 - t1).

2. Else if event type is ELEV_T2 • •

Update journey time to t2. Schedule event ELEV_T3 after (t3 - t2).

3. Else if event type is ELEV_T3 • • •

Update journey time to t3. If journey condition is C – Schedule event ELEV_ARRIVED after (t4 - t3). Else – Schedule event ELEV_T4 after (t4 - t3).

4. ELSE IF event type is ELEV_T4 • If journey condition is not C – Update journey time to t4. – Schedule event ELEV_T5 after (t5 - t4). 5. Else if event type is ELEV_T5 • If journey condition is A – Update journey time to t5. – Schedule event ELEV_T6 after (t6 - t5). • Else if journey condition is B – Update journey time to t5. – Schedule event ELEV_ARRIVED after (t6 - t5). 6. Else if event type is ELEV_T6 • If journey condition is A – Update journey time to t6. – Schedule event ELEV_ARRIVED after (t7 - t6). 7. Else if event type is ELEV_ARRIVED

Page 10 of 15

Discrete Event Elevator Simulator Architecture • • • • • •

Update origin floor (set origin floor equal to target, since the destination floor has been attained and it cannot be updated until the doors are closed again). Reset journey time to zero. Set elevator direction to none. Reset car button and both up and down buttons at the current floor. Set door status to opening. Schedule event ELEV_DOORS_OPEN after doors opening time minus advance doors opening time.

8. Else if event type is ELEV_DOORS_OPEN • Set doors status to open. • Schedule event PASSENGERS_START_ALIGHTING with the elevator’s id and current floor as additional parameters to happen at this instant. 9. Else if event type is ELEV_CLOSE_DOORS • Set doors status to closing. • Schedule event ELEV_DOORS_CLOSED after doors closing time plus motor start delay. 10. Else if event type is ELEV_DOORS_CLOSED • Set doors status to closed. • Schedule event UPDATE_PASSENGERS_REG at this instant. 11. Else if event type is CONTROLLER_UPDATE and the elevator is moving • Update journey time. 5.2 Passenger The PASSENGER class is not an entity (i.e., it does not do any event processing by itself). PASSENGER BASE is responsible for all activities related to passengers in the simulation. This class is merely a set of attributes that describe passengers, these attributes are: • • • • • • • • • •

Arrival time: Time passenger arrived at to the building; in other words, generated. Boarding time: Time passenger boarded on an elevator. Alighting time: Time passenger alighted from the elevator. Loading time: Time it takes the passenger to board on an elevator. Unloading time: Time it takes the passenger to alight from an elevator. Loading threshold: Elevator loading limit after which this passenger will not board. Arrival floor. Destination floor. Status: The status of a passenger (could be either: waiting, travelling or arrived). Elevator: The elevator that the passenger has used.

Note that only PASSENGER BASE has access to passenger objects and no other entity in the simulator can deal directly with passenger objects. 5.3 Passenger Base Page 11 of 15

Discrete Event Elevator Simulator Architecture PASSENGER BASE is the entity that controls and coordinates all kinds of passenger related activity and behaviour in the simulation. Its responsibilities include: 1. Passenger generation. 2. Board and alight passengers appropriately. 3. Register passengers landing and car calls. Passenger Generation. When the imminent event is GENERATE_PASSENGER, PASSENGER BASE will immediately generate a passenger object, giving it an arrival floor and a destination floor. It will the schedule the next GENERATE_PASSENGER event after the passenger inter-arrival time of the assumed arrival process. The widely accepted Poisson arrival process will be assumed. The interarrival time according to the Poisson process is given by:

δt = −

ln (1 − RAND )

λ

...where RAND is a random number between 0 and 1, λ is the passenger arrival rate in units of passengers per second. The first step in order to schedule the generation of the next passenger is to calculate the inter-arrival time; then schedule a GENERATE_PASSENGER event after this inter-arrival time. As mentioned previously, passenger generation is also used in bootstrapping the simulation. When the simulator is initialised it is necessary to schedule a GENERATE_PASSENGER event manually; this event, when processed, will trigger PASSENGER BASE to generate the first passenger and to schedule the next generation and the passenger generation “chain” will continue. It is worth noting that there are two possible options: either schedule the first passenger generation at time zero so the first passenger will always be generated at time zero, or manually calculate an inter-arrival time and schedule the GENERATE_PASSENGER event after this time; the second approach has been adopted since it gives a bit more realism (especially for the waiting time results). Basic probability principles will be used to assign origin and destination floors for each passenger. For example, assume a building with a basement, main terminal and five occupant floors. Assume an up-peak situation where the basement has an arrival rate of 20% and the main terminal of 80%. In order to assign an origin floor for a passenger, a random number is generated between 0 and 100, if this random number lies between 0 and 20 then the passenger will arrive from the basement; otherwise, he/she will arrive from the main terminal. The same basic idea can be used to assign the destination, but this time it is necessary to use the population of each floor to compute the probability of that passenger going to specific floor. It is also necessary to remove the origin floor from the calculation when assigning the destination floor in mixed-traffic situations, since a passenger will not go to a floor he/she arrived from! Passenger Alighting. Two events control passenger alighting from elevators, namely, PASSENGERS_START_ALIGHTING and PASSENGER_ALIGHTED. When an elevator arrives and completely opens its doors, it will schedule

Page 12 of 15

Discrete Event Elevator Simulator Architecture PASSENGERS_START_ALIGHTING event immediately, PASSENGER BASE will then start alighting passengers. This works as follows: 1. Iterate over passengers list. 2. Check if a passenger is travelling on that elevator and wants to go to the current floor. 3. If such a passenger is found then, a. Set beam broken to true on the current elevator since a passenger is alighting. b. Remove the passenger from the elevator. c. Schedule PASSENGER_ALIGHTED event after passenger unloading time. 4. Otherwise, schedule PASSENGERS_START_ENTERING event since no more passengers want to alight. When PASSENGER BASE processes PASSENGER_ALIGHTED event, it will carry out the following: 1. Iterate over passengers list in order to check which passenger has alighted (using passenger id). 2. Set beam broken to false on that elevator. 3. Record the time the passenger has finished his/her journey (by setting passenger alighting time equal to current simulation time). 4. Schedule PASSENGERS_START_ALIGHTING event so that Passenger Base can check if other passengers want also to alight. This is very realistic: passengers alight as they normally do in the real world, where they get out of the elevator one at a time. It is also worth nothing that passenger alighting time is recorded exactly at the instant he/she just finishes getting out of the elevator. Passenger Boarding. Like passenger alighting, two events control passenger boarding from elevators, namely, PASSENGERS_START_ENTERING and PASSENGER_ENTERED. When passengers finish alighting, PASSENGER BASE will schedule a PASSENGERS_START_ENTERING event immediately so passengers can start entering elevator. PASSENGER BASE will respond to this event as follows: 1. Iterate over passengers list and check if a passenger must board the elevator, the conditions that must be satisfied are: a. Passenger is waiting. b. The passenger is on the same floor as the elevator. c. The beam is not broken (no other passenger is currently boarding). d. The passenger is going up and the elevator’s committed direction is up, or he/she is going down and the elevator’s committed direction is down. e. Elevator loading is less than the passenger’s loading threshold. 2. If all the conditions are satisfied, then this passenger needs to board this elevator, a. Set beam broken to true. Page 13 of 15

Discrete Event Elevator Simulator Architecture b. c. d. e. f.

Increase the elevator’s loading by one passenger. Record the passenger’s boarding time. Set passenger’s status to travelling. Record the elevator that the passenger has just boarded. Schedule a PASSENGER_ENTERED event after passenger loading time.

3. Otherwise, if no more passengers want to board this elevator, then schedule an ELEV_CLOSE_DOORS event after door dwell time. When PASSENGER BASE processes a PASSENGER_ENTERED event, it will do the following: 1. Iterate over passengers list in order to check which passenger has boarded (using passenger id). 2. Set beam broken to false on that elevator. 3. Register his/her car call. 4. Schedule PASSENGERS_START_ENTERING event so that Passenger Base can check if other passengers want also to board. Update Passenger Registration. This will update passengers landing calls. Simply iterate over passengers list and update their landing calls by (re)registering them. Note that car calls are not affected. Event Processing. The OnEvent method implementation is straightforward now. It simply requires the checking of the event type passed by the simulator and acting in accordance with the methodology detailed above. PASSENGER BASE only deals with the six events mentioned. 5.4 Controller CONTROLLER, as its name implies, is the brain of the elevator system. It is the master that controls the elevators. It inherits from ENTITY class and thus is capable of event processing. It responds only to one event, CONTROLLER_UPDATE. The controller’s sole duty is to allocate (or assign) the landing calls in an optimum way to different elevators in the group. The allocation is done using the specified group control algorithm. The group control problem is multi-variable multiconstraint optimisation problem. The group control algorithm needs to utilise the available information in order to act in an optimum manner. Optimum is a vague term; an optimum allocation may mean to minimise passenger waiting time, minimise energy consumption ....etc. The primary objective of writing this elevator simulator is to let the user easily test the performance of his/her group control algorithm. It is necessary to distinguish between static and continuous allocation. In static allocation, the algorithm is only evaluated whenever a new call is made, whereas in continuous allocation, the evaluation is made every fixed amount of time and thus, previously allocated calls can be re-allocated. In this simulator, continuous allocation is assumed; however, it is still possible to simulate static allocation if needed. For example, a check can be made as to whether a new call has been made, and based on that a decision can be made as to whether to allocate it or not. Whenever the CONTROLLER encounters a CONTROLLER_UPDATE event, it will execute the group control algorithm. It will then schedule the next Page 14 of 15

Discrete Event Elevator Simulator Architecture CONTROLLER_UPDATE event after the specified allocation interval has elapsed. For example, if allocation interval is 0.5 seconds, the group control algorithm will be executed every 0.5 seconds. This event is also used in bootstrapping. The controller will schedule the next CONTROLLER_UPDATE when it executes the current one. Thus at the beginning of the simulation it is necessary to manually schedule a CONTROLLER_UPDATE event at time zero. In order to give the user of the simulator the flexibility of testing his/her algorithm, the scripting language of choice can be easily embedded and this class will act as the bridge between the script and the simulator. 6 Conclusions and Further Work In order to assist elevator designers in the complex design problems that they face, ElevSim was developed and its major aspects illustrated in this paper. Initially, ElevSim was designed using time-slice simulation approach. The major difficulty was in tracking the system state between time-slices, a problem that turned out to be more complicated than it first appeared. After that, it was re-designed using discreteevent simulation. A number of special solutions had to be applied, but it is more intuitive and provides much better performance and is much faster and more stable. The complete source code can be found at: https://bitbucket.org/alademm/elevsim The simulator can be enhanced in many ways. For example, more entities like escalators and double-deck elevators can be added. It is also possible to simulate the dynamics of the car itself, also build a motor energy model. Such a task can be complicated, because these are continuous-time models (i.e., modelled using differential equations). To solve this problem, the equations can be re-written as difference equations. Then a decision is made regarding the value of a suitable update interval for each model. An event type corresponding to each model is then added, as was done for the controller. Although this is not perfect, it is much better than making the whole simulator time-slice based in order to simulate continuous aspects of the system. Only continuous parts are time-sliced, and thus each entity can have its own time-slice independent of the others and whichever part is not needed can be turned off. REFERENCES [1] G. C. Barney, “Elevator Traffic Handbook: Theory and Practice”, Taylor & Francis, 2002. [2] Banks, J., Carson, J., Nelson, B., & Nicol, D. (2009). Discrete-Event System Simulation. Prentice Hall. [3] Lutfi Al-Sharif, Hussam Dahyat, Laith Al-Kurdi, “ The use of Monte Carlo Simulation in the calculation of the elevator round trip time under up-peak conditions”, Building Services Engineering Research and Technology volume 33, issue 3 (2012) pp. 319–338, first published on October 21, 2011 as doi:10.1177/0143624411414837. [4] H. Hakonen, “Simulation of Building Traffic and Evacuation by Elevators”, Helsinki University of Technology, April 2003. [5] R. Peters, “Ideal Lift Kinematic”, Elevator Technology 6, IAEE Publication, 1995.

Page 15 of 15