DEGREE PROJECT, IN COMPUTER SCIENCE , FIRST LEVEL STOCKHOLM, SWEDEN 2015
Constructing a Scheduling Algorithm For Multidirectional Elevators
JOAKIM EDLUND, FREDRIK BERNTSSON
Constructing a Scheduling Algorithm For Multidirectional Elevators
JOAKIM EDLUND, FREDRIK BERNTSSON
Degree Project in Computer Science, DD143X Supervisor: Danupon Nanongkai
Examiner: Örjan Ekeberg
Abstract
With this thesis we aim to create an efficient scheduling algorithm for elevators that can move in multiple directions and establish if and when the algorithm is efficient in comparison to algorithms constructed for traditional elevator algorithms.
To measure efficiency, a simulator is constructed to simulate an elevator system implementing different algorithms.
Because of the challenge of constructing a simulator and since we did not find either a simulator nor any algorithms for use in multidirectional elevator systems publicly, we decided to focus on these subjects.
The results in this thesis leads us to the conclusion that a multidirectional elevator algorithm is efficient to use under certain circumstances. If the traffic is concentrated to one floor in the building the multidirectional elevator system performs poorly but when the traffic is spread out it outperforms traditional elevators algorithms.
We hope that this research will inspire to further research in the area of multidirectional elevator systems.
Referat
Med denna rapport strävar vi efter att skapa en effektiv schemaläggningsalgoritm för hissar som kan åka i flera riktningar och fastslå om och när det är effektiv att använda en sådan, i jämförelse med algoritmer konstruerade för traditionella hissar som endast rör sig i två riktningar.
För att mäta effektivitet konstrueras en simulator för att simulera ett hissystem som använder sig av olika algoritmer.
På grund av utmaningen av att skapa en simulator och eftersom vi inte kunde finna varken en simulator eller någon publik algoritm som kan användas i ett flerriktat hissystem bestämde vi oss för att fokusera på dessa ämnen.
Resultaten i denna rapport leder till slutsatsen att en hiss som kan åka i flera riktningar är effektiv under vissa förhållanden. Om trafiken till hissen är koncentrerad till en våning i byggnaden kommer algoritmen prestera mindre bra men om trafiken är utspridd presterar den bättre än traditionella hissalgoritmer.
Vi hoppas att denna undersökning kommer inspirera fortsatt forskning inom området med flerriktade hissystem.
Contents
1 Introduction 1
1.1 Problem Definition . . . . 1
1.2 Problem Statement . . . . 2
1.3 Terminology . . . . 2
2 Background 3 2.1 Group Control . . . . 3
2.2 Group Control Examples . . . . 3
2.2.1 Nearest Car (NC) . . . . 3
2.2.2 Fixed Sectoring Common Sector System (FSO) . . . . 4
2.3 Measuring Performance . . . . 5
2.3.1 Average Waiting Time . . . . 5
2.4 Elevator Traffic Simulation . . . . 5
2.5 Existing Simulators . . . . 5
3 Method 6 3.1 Constructing the Simulator . . . . 6
3.1.1 Measuring Waiting Time . . . . 7
3.2 Test Data . . . . 7
3.2.1 Up-peak . . . . 7
3.2.2 Down-peak . . . . 8
3.2.3 Ordinary . . . . 8
3.3 Traditional Control Algorithm Implementation . . . . 8
3.3.1 Pseudo Code NC . . . . 9
3.3.2 Pseudo Code FSO . . . . 9
3.4 Optimisation of the NC Algorithm . . . . 10
3.5 Multidirectional Elevator Algorithm . . . . 10
3.5.1 Modified Nearest Car Calculation . . . . 11
3.5.2 Modified Sector Partitioning . . . . 11
3.5.3 Considerations . . . . 11
4 Results 12
4.1 The Constructed Simulator . . . . 12
4.2 Multidirectional Elevator Algorithm . . . . 13
4.2.1 Pseudo Code Implementation . . . . 14
4.3 Simulation Results . . . . 15
4.3.1 Traditional Algorithms . . . . 15
4.3.2 Multidirectional Algorithm . . . . 17
4.4 Comparison . . . . 20
5 Discussion 22 5.1 Efficiency . . . . 22
5.2 Algorithm Comparison . . . . 22
5.3 Possible Improvements . . . . 23
6 Conclusion 24
References 25
Chapter 1
Introduction
A traditional elevator is composed of shafts with elevator cars inside. The cars are connected to wires to make them able to move up and down in the shaft. Today, there mostly exist single shaft elevators with a single car, but systems with multiple shafts and cars are very common in larger buildings. Aside from the structure of the elevator they all share the same purpose to transport people from one floor in the building to another.
For large amounts of traffic the most common solution is to add parallel elevator shafts and use different sorts of group control algorithms to efficiently serve a lot of passengers.
However, recent development in technology has made it possible for future elevators to not only move vertically but also horizontally. As it has earlier been limited to the fact that the elevator cars move with wires, they can only move in two directions. Another downside is that high buildings become problematic due to the weight of the wire, so that there is a maximum height for a traditional elevator.
The new technology use magnetic levitation instead of wires and removes these restrictions. [1]
This will result in the possibility to create modern elevators, that can move in additional directions. This is interesting because the technology required to construct these kind of elevators has not existed very long, which means that there is considerably less research done in this area compared to traditional elevators.
1.1 Problem Definition
The purpose of this thesis is to study existing scheduling algorithms for traditional elevators mostly used today and use that knowledge to create an algorithm for a new kind of elevator capable of moving both vertically and horizontally. With less movement restrictions this will potentially be more efficient than old traditional elevators.
To measure efficiency of an elevator scheduling algorithm this thesis will show
results in average waiting time measured through traffic simulation. The simulation
CHAPTER 1. INTRODUCTION
will take different elevator traffic patterns in consideration to make the measured results more valuable. The invented algorithm will be compared to traditional scheduling algorithms to determine the efficiency of multidirectional elevators.
1.2 Problem Statement
The problem to be investigated is whether or not it is efficient to use an elevator system that can move in multiple directions instead of only moving upwards and downwards. The focus will be measuring average waiting time to determine the efficiency of the elevator model and different scheduling algorithms. It is expected to establish when it is efficient to use a multidirectional elevator rather than a traditional one. To summarise, the questions this thesis will be trying to answer are:
• Is it efficient to use an elevator that can move in multiple directions instead of traditional elevators?
• When is it more efficient?
1.3 Terminology
Car - The elevator car that transports passengers.
Shaft - The space in which the elevator cars travel.
Terminal floor - The floor where the entrance of the building is located.
General floors - Floors located above the terminal floor.
Chapter 2
Background
2.1 Group Control
Modern elevator systems are often composed of multiple elevator shafts and cars with the purpose of transporting passengers to their destinations in the building. In order to make the system operate efficiently and safely a group control is implemented.
The basic functionality of an elevator system group control is to appropriately coordinate the group of elevators by assigning cars to the incoming calls, sent by the passengers, and serving them as optimal as possible. [4]
2.2 Group Control Examples
There is a wide range of solutions to the elevator group control problem, however most existing group control algorithms are patented or kept secret by different elevator manufacturer companies. Many algorithms are based on the same principles.
Following are some of the fundamental algorithms mostly used as a starting point.
[5]
2.2.1 Nearest Car (NC)
The perhaps most basic solution used to solve the elevator scheduling problem is
the nearest car approach. It assumes that the person can choose to call for an
elevator to travel upwards and downwards. This means that the elevator will know
if the caller desires to move up or down when it receives the call. When the call
for an elevator is made a value called the figure of suitability (FS) is calculated for
each elevator in the same elevator group. The elevator with the highest FS will be
the elevator assigned to pick the person up. The FS is being calculated depending
on which state the elevator currently is in which results in four different rules. In
these rules d is the distance between the car and the landing floor, d=|car floor -
landing floor| and N is the number of floors. [5]
CHAPTER 2. BACKGROUND
1. FS = N + 1 - (d - 1) = N + 2 - d
This rule will come into effect if the elevator car is moving towards the landing call and the call is set in the same direction.
2. FS = N + 1 - d
This rule will come into effect if the elevator car is moving towards the landing call but the call is set to the opposite direction.
3. FS = 1
This rule will come into effect if the elevator car is already moving away from the landing call (the elevator is responding to some other call).
4. FS = N + 1 - d
This rule will come into effect if the elevator car is idle.
[5]
2.2.2 Fixed Sectoring Common Sector System (FSO)
FSO is a scheduling algorithm devised for dealing with off peak traffic. It divides the building into equally sized sectors equal to the number of elevator cars, except for the landing floor being its own sector. Every car will then have its responsibility to serve the landing calls in its assigned sector. If a sector above is considered vacant (the car with the responsibility for that sector is answering to a call) and it gets a call the elevator is allowed to serve the person in the sector above. In the special case of an elevator being the lowest occupied sector it will be allowed to answer a landing call in a vacant sector below it. If a lift leaves its sector it will be de-assigned from it and another elevator car can take its place. For an elevator car to be allowed to start or continue its movement it will have to be in response to:
1. Registered car calls.
2. Landing call registered in its sector.
3. Landing call in a vacant sector above and adjacent to the car’s assigned sector.
4. Landing call behind the car, assigned to an adjacent sector above, given the car is traveling upwards.
5. Landing call registered below the car if it is assigned to the lowest occupied sector.
[5]
CHAPTER 2. BACKGROUND
2.3 Measuring Performance
To determine which solution to the elevator group control problem is performing better the efficiency of it has to be measured. One way of measuring performance of an elevator system is to measure the average waiting time. This is a good metric to use when measuring elevator performance since this effectively reflects a passengers experience. [7]
2.3.1 Average Waiting Time
The waiting time is defined as the time period from the moment a passenger calls an elevator car to the moment when the elevator car arrives at the passenger’s floor.
This is the usual performance criterion when trying to optimise the performance of an elevator group control algorithm. [4]
2.4 Elevator Traffic Simulation
To simulate the traffic in an elevator system some different traffic patterns have to be considered to make the simulation more realistic. The different types of traffic patterns usually used for simulation are the following: Up-peak - The travel demand is focused from the terminal floor up to the general floors. Down-peak - The travel demand is focused from the general floors down to the terminal floor. Ordinary - The demand is random.
Earlier studies of typical office traffic shows that in the beginning of the workday a more up-peak traffic pattern is common and at the end of the workday the more common pattern is the down-peak traffic pattern. In the middle of the workday the ordinary traffic pattern seems to be more usual, except during lunch time where in the beginning of the lunch there is a down-peak traffic pattern and at the end of lunch an up-peak traffic pattern is more common. [2]. To simulate a complete workday the simulation has to combine these different traffic patterns. This will result in a more accurate simulation of a complete workday.
2.5 Existing Simulators
MCESim - An elevator simulator used to simulate an elevator system with multiple cars. [2]
Elevate - Elevator simulation software used to simulate traditional elevator system
with control algorithms and different buildings. [6]
Chapter 3
Method
To measure the performance of the constructed algorithms we need a simulator that can simulate elevator traffic, since it is not applicable to test new algorithms on real elevator systems. Most simulations done in previous studies are using software for traditional elevators. There is little or no examples of a simulator simulating traffic for elevators traveling in multiple directions. Therefore, to measure the multidirectional elevator algorithm in this thesis, a simulator is constructed. The simulator created during this thesis takes inspiration from the open source simulator MCESim.
3.1 Constructing the Simulator
Although the existing simulator MCESim is open source, the documentation is written in Japanese and the code base is large. It was therefore estimated that the overhead of rewriting MCESim to support two additional directions (left and right) would be heavier than writing our own simple simulator suited for the purposes stated in this thesis. However, the interface and class structure is inspired by MCESim. It is also written in Java.
The downside of using Java compared to a compiled language such as C is the performance. This is the same as with other high level interpreted languages and in this case is due to byte code. However, the run time performance of the simulator does not affect the output simulation results. This is because the measuring does not correlate with the run time of the program, but in simulation ticks. Therefore, the performance only affects the total run time of the simulation but not the outcome of it. Also, since the simulation is not applied to very large test data in this case, the difference in performance will be negligible.
The primary reason for choosing Java is because it is available on a large set
of operating systems which makes it easy to use in further researches and with
sufficient performance requirements. In addition, it is easy to prototype in java
thanks to the garbage collector that allows to avoid memory management.
CHAPTER 3. METHOD
3.1.1 Measuring Waiting Time
In order to calculate the average waiting time, every call remembers when it was created. When the passenger making the call is picked up, the call also registers the time. To calculate the waiting time for a single passenger the passenger’s pickup time is subtracted from the time of the passenger’s call creation. To get the average waiting time each passenger’s waiting time is summed up and then divided by the number of passengers that have been served by the elevator system during the simulation.
3.2 Test Data
To test the algorithms in this thesis, generated test data are used. The data is generated as passengers placed on floors. They make calls to inform the simulator where they want to go. The position of a passenger is defined by the traffic pattern used. In this thesis three different patterns are used.
Before starting the simulation, the test data is either generated or loaded from a file. It is saved in steps, where each step contains a list of passengers and their source and destination floors. Then, during the simulation the steps are continuously resolved and traffic are put into the elevator system.
By having different traffic patterns it follows that the test data will have more diversity. Therefore, we believe it will be easier to achieve better results and will also know if the algorithms have serious issues on some special type of test data.
3.2.1 Up-peak
As shown in figure 3.1, an example of the up-peak traffic pattern, it is clearly noted that the majority of the traffic occurs during the morning from the bottom floors traveling upwards.
Figure 3.1. Example of the up-peak traffic pattern. [5, p. 90]
Therefore, to generate the up-peak traffic, steps are generated according to the flow
in Figure 3.1. The time during the day is not of interest in this thesis, but to mimic
the different occurring patterns in an elevator system. During the up-peak in the
CHAPTER 3. METHOD
simulation we have chosen to have 80 percent of the generated people make calls from the terminal floor and have their stop-floor evenly randomised over the floors in the building. The rest will have their start and stop floors randomised. In none of the cases is the start-floor equal to the stop-floor.
3.2.2 Down-peak
The down-peak traffic is generated according to the flow in Figure 3.2. In contrast to up-peak the traffic instead occurs in the evening from the top floors traveling downwards.
Figure 3.2. Example of the down-peak traffic pattern. [5, p. 90]
Thus, the test data for down-peak in this thesis is generated by letting everyone’s start-floor be randomised over the floors in the building. 80 percent of the generated people have their stop-floor set to the terminal floor in the building and the rest will have it randomised. In none of the cases is the start-floor equal to the stop-floor.
3.2.3 Ordinary
The ordinary traffic pattern used as test data is supposed to simulate the traffic in between the peaks in the other patterns. As seen between morning and lunch in figure 3.1 and between lunch and evening in figure 3.2, the ordinary traffic is evenly spread out. The test data we use for this pattern is selected by letting each passenger have their start-floor and stop-floor randomised but can not be the same floor. [2]
3.3 Traditional Control Algorithm Implementation
These are the implementations created based on the studied traditional elevator
algorithm descriptions. The code calculates which elevator should answer a newly
created elevator call.
CHAPTER 3. METHOD
3.3.1 Pseudo Code NC
Call ← current call F S ← 1
N ← number of f loors
SelectedCar ← f irst car in building for Every car C in building do
d ← abs(C.location − Call.Location) if C is idle then
newF S ← N + 1 − d else if C is going down then
if Call is above then newF s ← 1
else if Call is below and Call direction is same as C then newF s ← N + 2 − d
else if Call is below and Call direction is not same as C then newF s ← N + 1 − d
end if
else if C is going up then if Call is below then
newF s ← 1
else if Call is above and Call direction is same as C then newF s ← N + 2 − d
else if Call is above and Call direction is not same as C then newF s ← N + 1 − d
end if end if
if newF S > F S then SelectedCar ← C F S ← newF S end if
end for
return SelectedCar
3.3.2 Pseudo Code FSO
Call ← current call for Every sector S do
if Call is in S then
SelectedCar ← S.assignedCar end if
end for
LowestSector ← f alse for Every sector S do
if S is not vacant and S is not highest sector then SectorAbove ← sector above S
if SectorAbove is vacant and Call is in SectorAbove then SelectedCar ← S.assignedCar
end if end if
if LowestSector = false and is not vacant then if S is not lowest sector then
SectorBelow ← sector below S
if SectorBelow is vacant and Call is in SectorBelow then
CHAPTER 3. METHOD
SelectedCar ← S.assignedCar end if
LowestSector ← true end if
end if end for
return SelectedCar
3.4 Optimisation of the NC Algorithm
The NC algorithm can be improved by forcing idle elevators go to floors with high traffic demand. For instance, during up-peak the terminal floor has a high traffic demand rate. If an elevator is idle high up in the building it can start to move downwards to the terminal floor, instead of waiting for a new call. This will reduce the time it takes for an elevator to serve a call coming from the terminal floor if the nearest elevator car is higher up in the building.
During down-peak the traffic demand is concentrated on going down. This means that idle elevators can reposition themselves to the middle of the building to increase the chance of shortening the distance to newly created calls.
These optimisations should probably lower the average waiting time.
3.5 Multidirectional Elevator Algorithm
When constructing the algorithm for a multidirectional elevator we had to define how such an elevator system would look like. To utilize the FSO and NC algorithms we decided it to be best to look at an elevator system that divides the entire building into a grid. For instance, a building with 30 floors could be made up of a grid that is 30 floors high and 5 shafts wide. If every square in the grid is considered a sector it would result in 150 different sectors in the elevator system. To put an elevator car on every single sector would end up in putting out 150 different elevators which would be unrealistically many. We decided to let sectors be divided the same way as in the traditional FSO algorithm, except for the situation of having more elevators than floors. In that case two elevators can share the same sector.
The difference in making a call between the traditional elevators and the multidirectional elevator is that in traditional elevators the caller can specify if it wants to go upwards
or downwards but in the case of multidirectional elevators the caller can also specify
that it wants to go sideways. In the multidirectional elevator system, a caller will
have a three button layout instead of a two button as in the traditional elevator
system. If the call is made to go sideways, the car assigned to that sector will always
handle the call but if the call is going upwards or downwards the nearest car will
be calculated to answer the call. This is the combination between the FSO’s and
the NC’s way of assigning an elevator to a call.
CHAPTER 3. METHOD
3.5.1 Modified Nearest Car Calculation
Since an elevator in this case can move horizontally the calculation for the nearest car has to take that into consideration. This means that the figure of suitability has to be calculated differently. A new variable for distance has to be introduced called h which is the horizontal distance between the elevator and the call. Also the number of vertical elevator shafts M, has to be taken into consideration.
1. FS = N + 1 + M + 1 - (d - 1) - (h - 1) = N + M + 4 - d - h This rule will come into effect if the elevator car is moving towards the landing call and the call is set in the same direction.
2. FS = N + M + 2 - d - h
This rule will come into effect if the elevator car is moving towards the landing call but the call is set to the opposite direction.
3. FS = 1
This rule will come into effect if the elevator car is already moving away from the landing call (the elevator is responding to some other call).
4. FS = N + M + 2 - d - h
This rule will come into effect if the elevator car is idle.
In contrast to the traditional NC calculations, these alterations are basically adding a new FS for each elevator car in the horizontal plane to the FS for the vertical plane. The sum of these two FS:s will indicate how suitable the elevator car is to be assigned to the current call.
Also, the multidirectional elevator algorithm can be improved by using the same techniques as describes in the optimisation of the traditional nearest car algorithm.
3.5.2 Modified Sector Partitioning
In order to divide the elevator system into sectors a fixed amount must be chosen.
Obviously, the amount of sectors will affect how the elevator performs. Therefore, to not flood the system with elevator cars, the max amount of sectors is set to N, the number of floors in the building.
3.5.3 Considerations
In the scenario where the amount of shafts is larger than the amount of floors (M >
N) the parameters of the algorithm has to be overlooked. To partition the sectors
correctly we transpose the building so that the floors represents shafts and vice
versa.
Chapter 4
Results
4.1 The Constructed Simulator
The simulator constructed during this study is composed of several components, the following.
• Building - Contains several Shafts and Floors.
• Shaft - Contains cars.
• Floor - Contains Passengers.
• Car - Contains passengers.
• Passenger - Creates calls.
• Call - Assigned to Cars.
• GroupControl - Assigns calls to cars.
• TrafficPattern - Generates traffic
As shown in the diagram below, the classes Building, Shaft, Floor, Car, Passenger and Call are used to simulate how a building with elevators function.
In addition to them, GroupControl and TrafficPattern are interfaces. By creating interfaces, one must implement a class based on the interface in order to use it in the simulator. This is used to implement different elevator control algorithms and traffic patterns in separate classes by implementing the interface in every one of them to customize their functionality. It makes different implementations very loosely coupled, which makes further simulations very easy.
The simulator engine is running in ticks. A tick can be compared to a processor
cycle. It is being used to ensure that the simulator will not be depending on the
speed of the computer running it. We benefit from this since the group control
CHAPTER 4. RESULTS
by the speed of the processor. Followed by this we have to set different parameters that affects the speed of the simulation.
• Ticks for a car to move between floors and shafts - 10
• Ticks for a car to load/unload passengers - 1
• Ticks in a step, to generate passengers - 50
It is important to note that these numbers will only affect the running time of the simulation and the value of these could easily be optimized for future simulations.
To make sure that we can achieve correct simulation results it is important to make sure that they do not change values during any of our tests, since the performance measurements depend upon the total amount of ticks. Figure 4.1 shows the basic structure of the elevator simulator.
Figure 4.1. Elevator simulator structure
4.2 Multidirectional Elevator Algorithm
The following pseudocode shows the final implementation of the algorithm constructed
during this study. The code calculates which elevator should answer a newly created
landing call.
CHAPTER 4. RESULTS
4.2.1 Pseudo Code Implementation
Call ← current call F S ← 1
N ← number of f loors M ← number of shaf ts
SelectedCar ← f irst car in building for Every car C in building do
d ← abs(C.f loorLocation − Call.f loorLocation) h ← abs(C.shaf tLocation − Call.shaf tLocation) if C is idle then
if Call is in C:s sector and call direction is horizontal then return C else
newF S ← N + M + 2 − d − h end if
else if C is going down then if Call is above then
newF s ← 1
else if Call is below and Call direction is same as C then newF s ← N + M + 4 − d − h
else if Call is below and Call direction is not same as C then newF s ← N + M + 2 − d − h
end if
else if C is going up then if Call is below then
newF s ← 1
else if Call is above and Call direction is same as C then newF s ← N + M + 4 − d − h
else if Call is above and Call direction is not same as C then newF s ← N + M + 2 − d − h
end if
else if C is going left then if Call is to the right then
newF s ← 1
else if Call is to the left and Call direction is same as C then newF s ← N + M + 4 − d − h
else if Call is to the left and Call direction is same as C then newF s ← N + M + 2 − d − h
end if
else if C is going right then if Call is to the left then
newF s ← 1
else if Call is to the right and Call direction is same as C then newF s ← N + M + 4 − d − h
else if Call is to the right and Call direction is same as C then newF s ← N + M + 2 − d − h
end if end if
if newF S > F S then SelectedCar ← C F S ← newF S end if
end for
CHAPTER 4. RESULTS
4.3 Simulation Results
A total of 30 different simulations where done for each algorithm and for each traffic pattern. Every simulation simulates the traffic of 10000 people using the elevator system in a building consisting of 30 floors with the first floor set as the terminal floor. The algorithms described in the graphs in this chapter are the following:
• NC - Nearest car algorithm.
• NCOpt - Nearest car algorithm with optimisation.
• FSO - Fixed Sectoring Common Sector System.
• Multi - Multidirectional elevator algorithm.
• MultiOpt - Multidirectional elevator algorithm using NCopt.
4.3.1 Traditional Algorithms
For the traditional algorithms a building with 2 to 10 elevator cars was used in the simulations.
Table 4.1 shows the average waiting time in ticks for the traditional algorithms with different traffic patterns.
Algorithm Down Peak Up Peak Ordinary
NC 109 160 114
NCOpt 88 154 114
FSO 156 245 94
Table 4.1. Simulation for a building with 30 floors, 5 shafts and 5 elevator cars.
The following figures 4.2 - 4.4 show the correlation between the number of elevators
and the average waiting time in ticks. The x-axis represents the number of elements
and the y-axis the average waiting time.
CHAPTER 4. RESULTS
2 4 6 8 10
150 200 250
Number of elevators
A v erage w aiting time (tic ks)
NC NCOpt
FSO
Figure 4.2. Up-peak pattern in a building with 30 floors
2 4 6 8 10
100 150 200 250
Number of elevators
A v erage w aiting time (tic ks)
NC NCOpt
FSO
Figure 4.3. Down-Peak pattern in a building with 30 floors
CHAPTER 4. RESULTS
2 4 6 8 10
50 100 150 200
Number of elevators
A v erage w aiting time (tic ks)
NC NCOpt
FSO
Figure 4.4. Ordinary pattern in a building with 30 floors
4.3.2 Multidirectional Algorithm
For the constructed multidirectional algorithm, a building with 10 to 50 elevator cars was used in the simulations. The building is 30 floors tall and 5 elevator shafts wide. The reason for choosing this building structure is to give a fair comparison in efficiency between traditional and multidirectional elevator systems. Having too few elevator shafts would result in a system too similar to a traditional elevator system. Furthermore, with too many elevator shafts it would result in a very wide building not representing a real world traditional elevator system.
Table 4.2 shows the average waiting time in ticks for the different versions of the multidirectional algorithm, with different traffic patterns.
Algorithm Down Peak Up Peak Ordinary
Multi 136 189 69
Multi Opt 115 184 69
Table 4.2. Simulation for a building with 30 floors, 5 elevator shafts and 25 elevator cars.
To make a fair comparison between the multidirectional and traditional elevator
system, the multidirectional system needs to use more elevator cars because it
contains many more possible pickup points. The traditional system has 30 floors
which gives 30 possible pickup points and the multidirectional elevator system has
30 floors and 5 shafts which gives 150 possible pickup points. Therefore, every added
CHAPTER 4. RESULTS
car to the traditional elevator system adds another 5 cars to the multidirectional elevator system. This is done in order to achieve the same relation between the number of pickup points and the number elevator cars, hence the higher number of elevators in Figure 4.5 - 4.7.
10 20 30 40 50
175 180 185 190 195
Number of elevators
A v erage w aiti n g time (tic ks)
Multi MultiOpt
Figure 4.5. Up-peak pattern in a building with 30 floors
CHAPTER 4. RESULTS
10 20 30 40 50
120 125 130 135
Number of elevators
A v erage w aiti n g time (tic ks)
Multi MultiOpt
Figure 4.6. Down-peak pattern in a building with 30 floors
10 20 30 40 50
60 80 100
Number of elevators
A v erage w aiti n g time (tic ks)
Multi MultiOpt
Figure 4.7. Ordinary pattern in a building with 30 floors
CHAPTER 4. RESULTS
4.4 Comparison
The following diagrams show a comparison between the multidirectional algorithms and the traditional algorithms. To fairly compare the different types of algorithms the axis showing the number of elevators has been altered to show a ratio of pickup points per elevator car. It results in flipping the diagram horizontally. This means that the lower the number the more elevators has been used and the higher the number less elevators has been used.
2 4 6 8 10 12 14 16
100 150 200 250
Pickup points per elevator car
A v erage w aiti n g time (tic ks)
Multi MultiOpt
NC NCOpt
FSO
Figure 4.8. Down-peak pattern in a building with 30 floors
CHAPTER 4. RESULTS
2 4 6 8 10 12 14 16
150 200 250
Pickup points per elevator car
A v erage w aiti n g time (tic ks)
Multi MultiOpt
NC NCOpt
FSO
Figure 4.9. Up-peak pattern in a building with 30 floors
2 4 6 8 10 12 14 16
50 100 150 200
Pickup points per elevator car
A v erage w aiti n g time (tic ks)
Multi MultiOpt
NC NCOpt
FSO
Figure 4.10. Ordinary pattern in a building with 30 floors
Chapter 5
Discussion
5.1 Efficiency
The efficiency is as noted earlier measured in average waiting time. Comparing other different multidirectional elevator algorithms is hard since there are no available in the public. The solution chosen is to compare to traditional elevators to determine how to design the multidirectional algorithm to make it efficient. In addition to this the simulator does not account for human factors. For example, normally a person that has to wait very long for an elevator to arrive may take the stairs instead.
Also, a person may not always want to enter an elevator if it is almost full. It follows that events will always end the way the simulator expects and may not be realistic for a real elevator system where human factors apply. Although, this does not matter since every algorithm compared use the same simulator and parameters and the only interesting result is the performance correlation between the studied algorithms.
5.2 Algorithm Comparison
The results for the comparison of the traditional algorithms in average waiting time for NC and FSO show that they perform differently depending on the traffic patterns, as shown in Table 4.1.
It shows that NC converges with the number of elevators during all traffic
patterns and performs well for the down peak and up peak pattern. The FSO
implementation does not perform equally during up peak and down peak, due to
the spread of elevator sectors. It is however more effective than NC during the
ordinary pattern but overall worse than NC during the others. An implication of
this might be that solely using FSO as a group control algorithm could result in
bad performance on average, but could have benefits when the traffic flow does not
origin from a concentrated source (ordinary pattern). Though, this depends on the
number of elevators as seen in figure 4.2 - 4.4, but may also depend on the building
CHAPTER 5. DISCUSSION
