Implementation of Dispatching Algorithms for Elevator
Systems using Reconfigurable Architectures
Daniel M. Muñoz1 Carlos H. Llanos1 Mauricio Ayala-Rincón2 Rudi van Els1 Renato P. Almeida1
Departamentos de 1Engenharia Mecânica e de 2Matemática
1
Grupo de Automação e Controle (GRACO)
Universidade de Brasília, 70910-900 Brasília, D.F., Brazil. Phone: +55 61 33072313
{damuz,llanos,ayala,rudi,almeida}@unb.br
ABSTRACT
Elevator Group Control Systems (EGCSs) manage multiple
elevators in a building transporting efficiently passengers. The
performance of an EGCS is measured by means of several metrics
such as the average waiting time of passengers, the percentage of
the passengers waiting more than some predetermined time, power
consumption, among others. Four elevator dispatching algorithms
are analyzed and implemented using reconfigurable architectures
based on FPGAs. The system is based on Local Controller Systems
(LCSs), one for each elevator, and a protocol based on an RS485
network for interconnecting the LCSs. The FPGAs implement the
LCSs. A Java interface was implemented for testing and
monitoring the system and the EGCS function. The novelty of this
approach is that the LCSs are capable to run the different
dispatching algorithms, which are suitable for different passenger
traffic situations, while the EGCS only must determine the best
algorithm to be run in each LCS. The data traffic in the network is
reduced given that the EGCS is not directly involved in calculating
next floors to be visited. The algorithms were described in VHDL
and implemented on Spartan3 FPGA based boards.
Categories and Subject Descriptors: B.7.1 [Integrated
Circuits]: Types and Design Styles – Algorithms implemented in
hardware
General Terms: Algorithms, Performance, Design.
Keywords: Elevator Control Systems, FPGAs.
1. INTRODUCTION
Elevator Group Control Systems (EGCSs) are systems, which
manage multiple elevators in a building in order to transport
efficiently passengers.
The performance of the system is measured by means of several
metrics such as the average waiting time of passengers, the
percentage of the passengers waiting more than some
predetermined time, power consumption, among others. Basically
an EGCS is composed of quadruplets <h,c,e,g>, where h is the set
of hall-call buttons, c the set of car-call buttons, e the set of
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise,
or republish, to post on servers or to redistribute to lists, requires prior
specific permission and/or a fee.
SBCCI'06, August 28–September 1, 2006, Minas Gerais, Brazil.
Copyright 2006 ACM 1-59593-479-0/06/0008...$5.00.
32
elevators and g the group controller. In general, an EGCS must
select the more suitable elevator for a passenger(s) requirement(s).
This task is known to be very complex given that having n
elevators and receiving p hall-calls one has np possible cases.
Additionally, the system must deal with several factors as new
calls in the next time and flux of passengers in a given time. These
factors lead to the necessity of designing a flexible control having
the possibility to change dynamically the control strategy [10].
Microcontrollers were used for the implementation of techniques
of automation more frequently. For example, using Programmable
Logic Controllers (PLCs), as well as classic digital control
techniques. In the last decades the Programmable Logic Devices
(PLDs) arose, among them the Field Programmable Gate Arrays
(FPGAs) being the most important [3, 19]. The possibility of
reconfiguring the FPGAs by software makes possible the
implementation of different hardware architectures. Therefore,
these devices are a good solution to implement both control and
automation techniques. FPGAs flexibility opens a wide range of
architectural alternatives to implement these techniques directly in
hardware. Nowadays, FPGA devices are widely used among
industrial automation, automotive, digital signal processing, video
and audio applications, home appliance and toys industry among
others. These devices can be effectively applied to the realization
of the complex systems, with good performance and flexibility,
meeting the requirements of every process or products in a
customized way [7].
Several techniques for implementing EGCSs have been proposed
(see Section on related work). All these techniques are complex
and implicitly require that the EGCS solve the whole assign
problem for the elevator group. The task to determine the best
assign for hall-car-calls would be decided in a distributed
approach, given that usually each elevator has a Local Controller
System (LCS). In this case it is possible to allow for the LCS to
decide among several algorithms, which one can be suitable for
different traffic situations. In this case the EGCS only would
determine the best algorithm to run in the LCSs. The FPGA
implementation of the LCSs reduces area and power consumption
given that the different algorithm implementations share hardware
resources. Additionally, as a hardware implementation it improves
the system performance, which can be useful in high-speed
elevators environments.
Several dispatching algorithms were analyzed and implemented
using reconfigurable architectures based on FPGAs. The overall
system is based on a LCS for each elevator and an RS485 based
protocol network for interconnecting the LCSs. The FPGAs
implement the LCSs. A Java interface was implemented for
simulating the main tasks of an EGCS (the user manually chooses
the algorithm for each LCS) apart from testing and monitoring the
different EGCS functionalities. Additionally, this tool provides
commands to the system architecture through the RS485 interface.
The novelty of this approach is that the LCSs are capable to run
four different algorithms, which are suitable for different
passenger traffic situations. Thus, the EGCS only must determine
the best algorithm to be run in each LCS. This approach has direct
impact in reducing the data traffic in the network given that the
EGCS is not directly involved in calculating next floors to be
visited. The algorithms were described in VHDL and implemented
on Spartan3 FPGA based boards [5, 23]. As soon as an algorithm
is selected on a LCS the three others are disabled by stopping the
corresponding clock signals. This reduces the power consumption
of the system.
Section 2 describes works on elevator controller techniques.
Section 3 presents basic concepts of the proposed architectural
system. Section 4 describes the hardware implementation of the
algorithms. Before concluding, section 5 describes the Java
interface and shows the implementation of the network.
2. RELATED WORK
Elevators were introduced in the 1890’s when each car was
individually controlled by an attendant riding it. In the 1920’s it
was introduced the first semiautomatic elevator controller where
the attendant’s job was reduced to close the doors and start the car
[17]. The fully automatic elevator was introduced in the earlier
1950’s eliminating the attendant altogether. Because of the
increasing in processor speed and memory capacity it was possible
to implement complicated dispatching algorithms. Modern
dispatching algorithms employ expert system techniques, fuzzy
logic, rule and search-based strategies, learning approaches,
dynamic programming, among others.
The oldest elevator schedulers used the collective control principle
according to which cars always stop at the nearest floor call in
their running direction [12], a far from optimal strategy that
usually results in bunching – the phenomena where several cars
arrive at the same floor at about the same time [12]. The jamming
effect occurring during in down-peak traffic was analyzed in [9]
concluding that this is consequence of the cars synchronization
problem. Other approaches using zoning or sectoring were studied
in [2] and [20] avoiding bunching but being sub-optimal as well.
Companies such as Otis use techniques involving optimization
criteria. These criteria are grouped in a Relative System Response
(RSR) heuristic. This consists of a weighted sum of bonuses and
penalties. [14] described another Otis criterion for elevator
dispatching: the Remaining Response Time (RRT) which is
defined as the time necessary for a car to reach the respective floor
of the new hall-call, given several restrictions such as loading or
unloading passengers already assigned to it. Several problems
related with RRT are discussed in [12] such as ignoring the time
required for the passengers to get off.
Approaches using fuzzy logic based methods which are capable to
prescribe a correct assignment to a car given a new hall-call [21,
22]. Well-known criteria as Average Waiting Time (AWT) and
Residual Waiting Times (RWT) are discussed in [12]. Also,
techniques based in discrete-state Markov and Markov decision
problem formulation are shown in [4, 12, 13]. Also, techniques
33
based on AI, neural networks and genetic algorithms have been
reported [6,10,16,17,18].
Many studies have been done and important progress has been
made regarding algorithms to assign hall-calls. Several techniques
assume that the desired floors are equally likely, and later on
explain how non-uniform destination probabilities can be handled
[12]. Additionally, it is assumed that the full state of the problem is
known for the scheduling system; namely, the number of people
standing on each floor is known. It is clear that such information
cannot be obtained only by inspecting the number of hall-call
button pressed. To solve this, different approximations involving
several qualities are proposed [12].
In general, the problem of finding the best solution is very hard; in
fact, if n passengers are assigned to a car, there are n! orders for
them to be picked up. If all orders are allowed and will be
considered by the scheduling system, the corresponding planning
problem is NP-hard even for a single car [12, 15]. This problem
can be seen as a special case of the Dial-a-Ride-Problem (DARP)
where objects have to be moved between given sources and
destinations in a transportation network by means of a server.
DARP comprises well-known NP-hard problems such as the
traveling salesman problem. The special case of elevator
scheduling is the one where the transportation network forms a
caterpillar which also has been shown NP-hard [8]. In [12] a
heuristic is proposed, based on the fact that the elevator will move
in the current direction until all passengers who are requesting
rides in this direction are picked up and delivered. Afterwards, the
car moves to the first hall-call in the opposite direction, and
repeats the same procedure for all opposite hall-calls. This solution
is reported as being rarely sub-optimal [12].
3. DESCRIPTION OF THE SYSTEM
The system’s description is shown in the Fig. 1. There are an
EGCS, several LCSs and an RS485 based network system. The
EGCS is a high level system, which has to choose the best strategy
for each LCS.
MASTER Slave 1 Slave 2 Slave 3 Slave N
Rx Rx Rx Rx
RS 485 Network
Rx
Tx
Tx Tx Tx Tx
RS232
RS232
RS232
RS232
RS232
•••••
Elevator N
Elevator 1
Elevator 3
Elevator 2
•••••
Figure 1. The system environment
Each LCS manages the choice of the next floor to be visited and
implements the logic circuits for the motion system. The network
system is composed of several hardware nodes that implement the
physical layer of the network. Each LCS is connected with the
network nodes via serial interface (RS232). Characteristics of the
network were developed for this application (see Section 5).
Elevators have car buttons for choosing a desired floor and one or
two floor calling buttons. When they have two floor buttons, they
are used to determine the direction (up/down). The process to
assign an elevator is represented by the following steps:
a) A passenger who wishes to go to the floor x press a hall-call
button and stand waiting until the elevator moves to the floor
where the hall-call occurred.
b) The hall-call is transmitted to the LCS, which is currently
running a given algorithm. The LCS attends the solicitation.
c) The LCS transmits the solicitation to the EGCS (via the
RS485 based protocol).
d) The EGCS gather the data sent by the LCS and periodically
chooses what algorithm will be suitable for the current
situation. To do that a fuzzy system was implemented.
The Java interface runs over PCs (Fig. 1) and is capable to
represent different situations of a real elevator system sending data
and commands through the RS485 network to the LCSs.
4. THE ARCHITECTURES OF THE LCS
The implementation of the LCS follows the collective principle in
[12]. That is, the calls can be registered in an array, which can be
sorted according to a previous defined strategy. The basic structure
(illustrated in the Fig. 2.a) can be used for hardware
implementation of the collective principle. In this case hall-calls
are recorded in the array and the elevator control sequentially visits
every cell. Every array’s cell stores one bit and this bit can be set
by both hall-calls and car-calls. The elevator control turns-off the
corresponding bit whenever a floor is visited. This algorithm is
simple and guarantees that the next floor, which is related with a
call, will be visited in the next time.
4.1 Algorithms implemented in hardware
The algorithms follow the collective principle where the registered
calls are memorized and then, the elevator can pick several hall-
calls during the up/down trip.
Figure 2. Implemented algorithms in hardware
The car stops in a floor sequence at each hall-call without
considering the order in which the calls have happened. Otherwise,
the calls can be arranged in a time queue according to the order
they have been registered. Also, it is used the selective principle,
which selects the highest or lowest hall-call in order to define the
next floor to be visited in a given time. The algorithms can work
by using one or two buttons per floor. In the latter case, each
button allows the user to select a wished direction (up/down
buttons). The basic algorithms are classified as:
34
a) Collective/collective (C) implements the collective principle in
both the up- and down-ways. The car stops in the floor sequence
given by the floor calls during both the up- and down-trips. This is
done by taking into account the nearest floor-call instead the order
in which the calls were given. The Fig. 2.a shows the sequence of
visited floors in an up/down trip for an 8-floors building.
b) Selective-down/Collective-up (U) collects the hall-calls during
the up-trip. In the down-trip the system initially chooses the lowest
hall-call to be visited first (selective step). Following, the calls are
attended in sequence (collectively), stopping always in the nearest
calling floor, during the up-trip (see Fig. 2.b). This algorithm is
suitable when the up-direction traffic is the majority.
c) Selective-up/Collective-down (D) switches the up- and down-
premises of the previous one being suitable when the traffic is
majority in the down-direction (see Fig. 2.c).
d) Selective-Collective/up-down (CSud) is implemented by using
two hall buttons. It attends the up-hall-calls in a collective way
(collective step) (see Fig. 2.d). Before the car begins its down-trip
the algorithm chooses the highest hall-call due to a down-button
selection (selective step). Then this floor is visited (in the up-trip).
Afterwards, the system attends the down-hall-calls in a collective
way during the down-trip. Then, it chooses the lowest hall-call
(due to an up-button selection) to be visited. This is suitable when
the passenger traffic is equal in both up and down directions [12].
4.2 The basic hardware structure
The circuit is composed of an n-bit array and a multiplexer set,
where the ith cell represents the ith building floor (see Fig. 3). Each
multiplexer controls the signals coming from the hall-car-calls (Ei)
and control-unit signal (bit_rst signal). Every hall-car-call can be
registered in the array (by writing “1” in the respective cell).
Otherwise, the control unit can independently reset each cell by
writing “0” in the bit-line and selecting the respective ith cell by
using the Ci control bit.
Figure 3. Basic structure of the control system
4.3 Implementation of algorithms a), b) and c)
The architecture of the implementation for the first three
algorithms has two FSMs (see Fig. 4). The Fsm_reg determines
the next floor to be visited. The FSM receives the array bits and
one input coming from the door sensor (IR, indicating if the car
door is closed/open) as inputs. The Fsm_reg resets a floor bit
through the ControlMux bus where each bit represents a control
for a given multiplexer. Additionally, the bit_rst signal is used to
reset operation. Note that several cells can be reset
simultaneously. Register, Next and Display outputs are used for
monitoring the status of the system during FPGA operation. The
Fsm_reg has the following states: stop-state, up-state, down-state.
The FSM compares the current floor with the activated bits in the
array in order to determine the next floor to be visited. The current
floor is actualized at the up-state and down-state, which are
responsible to generate the ControlMux and bit_rst signals as well.
The second FSM (FSM_ele) is responsible to lead the car to the
respective next-floor apart from relays output signals such as Door
(controlling the elevator door), PWM (controlling the motor’s
speed, motor_dir (controlling the motor direction). The FSM_ele
has three states: init-state, up-direction-state and down-direction-
state. The FSM compares the current floor with the next-floor
(previously calculated by the FSM_reg) and relays the proper
signals to lead the car to a given floor.
Figure 5. Basic hardware structure for a sequential search

4.4 Selective-Collective/up-down algorithm

The architecture implementing this algorithm is depicted in the
Fig. 6. This algorithm must determine the next floor using the
inputs given by the up/down calls. In order to accomplish this, the
system has two array structures: Reg_comp1 and Reg_comp2
which are equal to those showed in the Fig. 3 and their Si and Di
inputs are coming from the up/down floor buttons respectively. In
addition, the system has two identical FSMs (FSM_reg_S,
FSM_reg_D) which have similar structure as the FSM_reg (Fig.
3). Each FSM has to determine the next floor to be visited
according to the state of these arrays. The module allocator
receives and manages the information coming from the two FSMs,
which consists essentially of whether all the calls in the array were
Figure 4. Basic architecture for the basic algorithms attended. The allocator module enables or disables each FSM
(Enable_S and Enable_D signals) using this information. When
The Collective/collective algorithm is based on a loop structure an FSM is enabled its output (next floor to be visited) is sent to the
over the FSM_reg, in which a sequential search is alternatively FSM_ele, otherwise the output coming from the other FSM will be
implemented in both directions. For Selective-down/Collective-up sent. The FSM_ele has the same function and structure as in the
the loop implements a sequential search beginning at the lowest previous algorithms. The area cost of these arrays is 2 O(n). The
selected array’s cell (with an active floor’s call) and selecting area cost of each FMSs is very similar to the previous cases.
(attending) each active cell until the highest selected one.
Afterwards, the loop begins with the new lowest selected array’s
cell. The Selective-up/Collective-down is similarly implemented.
Note that this hardware structure is very regular and easily adapted
for implementing the three algorithms.
The area cost of the hardware implementation refers directly to the
complexity of the architecture [1]. The array implementation cost
is O(n), where n is the number of floors. The area cost of the FMSs
tends to be proportional to the state encoding, that is O(log n) plus
the area cost of combinational resources. The FSM_reg module
must spend more area, given that it implements a loop structure for
treating the sequential search in the array. In this case it will be
consumed one 1-bit comparator (O(1)) and one 8-way multiplexer
whose area cost is proportional to O(n log n). The sequential
search was carried out using a VHLD for structure jointly with an
if statement in the FSM process. A possible hardware for
implementing the sequential search is depicted in the Fig. 5.
For timing analysis, the cost for gathering the inputs coming from
the floors belongs to O(1). In contrast the software implementation Figure 6. Hardware architecture for Selective-
of this part of the algorithm would tend to have a complexity of Collective/up-down algorithm
O(n), where n is the size of the array. The time necessary to Also, two FSM_reg are used for implementing the selective-
determine the next floor to be visited is Ω(n) where n is the floor collective approach. Otherwise, time analysis is very similar to the
number (because of the loop structure implemented to carry out previous solution, given that all modules are running concurrently.
these data). Given that the three modules (register structure,
FSM_reg and FSM_ele) are running concurrently the complexity 5. COMMUNICATION PROTOCOL AND
is equal to the worst case. In this case the cost of the FSM_reg is VIRTUAL ELEVATOR INTERFACE (VEI)
higher than the cost of FSM_ele given that FSM_reg carries out
the next floor to the FSM_ele module. The VEI was developed in Java and runs on PCs. It can be used to
set up building and elevator parameters such as the number of

35
elevators (1 to 8 elevators) and of floors (2 to 99 floors). The VEI FSM_reg calculates the highest down hall-call to define the next
is connected to the RS485 network through an RS232/RS485 floor (next = “111”, eighth floor).
converter (Fig. 1). Initially, the VEI sends the current time, hall
and car calls to the EGCS; afterwards, each LCS processes this The VHDL synthesis was done using the ISE Xilinx tool [23] and
information and sends back the status of each elevator; finally, the its results are showed in Table 1 for the Spartan 3 family. Table 2
VEI receives the data, generates an animation and displays the shows the synthesis results of the main components in the Spartan
waiting/traveling time in real-time. A simple communication 3 implementation, where it can be observed the cost and
protocol between the VEI and the LCSs manages the data traffic performance of each circuit component. The dispatching
through the serial port. The main communication protocol between algorithms of the elevator system were implemented for eight
the VEI and the LCSs is based on the RS485 network. In this floors. FSMs consume the most look-up table resources.
protocol each LCS is a remote station and the VEI is the host.
Remote stations can be operated either in mode free or slave. In the Table 1. Synthesis results of the Dispatching Algorithms
free mode, the LCS will send data to the host whenever a new Elevator System
event occurs in its sensors or inputs. In the slave mode, the LCS
only can send data to the host in response to commands. Device No 4 input Slice FFs IOBs Max Freq.
LUT MHz
The main communication protocol operation is based on host Virtex2P 1780 out of 507 out 25 out of 148.727
queries/responses from each remote device. Only in the free mode 47232 of 47232 812
the remote stations can transmit data without host permission. Spartan3 1767 out of 507 out 25 out of 70.641
Several commands were implemented for the communication 3840 of 3840 173
among devices, such as input-request, outputs-request.

6. RESULTS Table 2. Synthesis results for the Spartan3 implementation

The system has two parts: the communication part and the elevator 4 input Slice FFs IOBs Max
one. The former is composed of serial communication and network Function LUT Max: Max: Freq.
protocols (to support RS485 networking). The three first Max: 3,840 3,840 173 MHz
algorithms share the same basic hardware structure (Fig. 3). The Register 8 8 27
last algorithm (Collective-up/Selective-down) was implemented C 338 53 23 84.72
using two independent basic structures (section 4.4). Otherwise, U 372 52 23 74.00
the FSM, which implements the elevator car control, is shared by D 377 52 23 77.40
all implemented algorithms. Inputs of the system can be setup CSud 358 81 23 81.68
directly using the graphical VEI. Also, the outputs are animated in FSM_ele 60 36 13 134.26
VEI, showing real situations such as the motor elevator, door Serial
status and the car status display. 123 115 78 158.03
Comm
the Fig. 7 shows a ModelSim [11] simulation of the state machine VEI
111 66 37 103.45
for the Collective-up/Selective-down algorithm. It shows the FSM, Protocol
hall-calls inputs, motor, door and display outputs. After the system
is reset, the hall-calls E4, E5 and E7 are selected. It can be verified
7. CONCLUSIONS
in the register signal (Register = “01001111”), where the zeros are An elevator dispatching system based on four elevator dispatching
the hall-calls store up. The next signal (Next Floor) indicates algorithms was implemented on FPGAs. The communication
which one of these inputs is going to be attended first. For the between the Java testing interface VEI and the LCS devices and
collective-up algorithm, the E4 hall-call must be visited first. In the hardware necessary to support the network protocol based on
fact, the system is going to the fifth floor (E4, Next Floor = “100”). the RS485 interface were implemented on Spartan3 FPGA based
However, during the up trip the E3 hall-call is selected, and now it boards. The hardware resources consumed by the implemented
must be attended first. The system recognizes this call and it algorithms are very similar (see Table 2). The user can provide
becomes the next signal (Next Floor = “011”). Then, the elevator tests and choose the desired algorithm via network commands
will stop in the fourth floor. The next signal is the input of the using the developed Java interface VEI. The implementation tries
FSM elevator (Fsm_ele) where outputs such as at, current floor, to reduce area by sharing resources. For accomplishing this, the
motor, door and display obey the next signal that is calculated in same register structure is shared by the algorithms.
the state machine dispatching algorithm (FSM_reg).
The coupling of the modules is accomplished through multiplexers
the Fig. 8 shows the simulation of the system containing the fourth that are capable to implement the algorithm selection. Also, the
dispatching algorithms. The signal for algorithm selection FSM that implements the car control (motor control, door control,
(selalgor) chooses which one of the four algorithms will be run. etc.) is shared by the algorithms. Through the VEI the user can run
When it is setup as “100” the Selective-Collective/up-down real-time tests for a truly evaluation of the different control
algorithm is selected. The Up hall-calls E1, E5 (second and sixth strategies.
floors) and the Down hall-calls D3, D7 (fourth and eighth floors)
are pressed, stored up in the register and the FSM_reg selects the As future work we propose the implementation of other control
lowest up hall-call to define the next floor (next = “001”). Once the strategies such as the ones based on fuzzy expert systems for data
second floor is visited, the elevator goes to the sixth floor and once traffic passenger management and call assignment methods in
the sixth floor is visited, this selection is reset from the register and order to decrease the waiting time of passengers and the power
consumption of the elevator group control system (EGCS).

36
 Figure 7. Collective up / Selective down Algorithm simulation.
Figure 8. Algorithm selection in the elevator simulation.
9. REFERENCES
[1] S. G. Akl. Parallel Computation: Models and Methods. Prentice-
Hall, 1997.
[2] G. C. Barney, S. M. dos Santos, Elevator traffic analysis, design
and control. Peter Peregrinus, 1985.
[3] J. Becker and R. W. Hartenstein, Configware and Morphware
going mainstream. J. of System Architecture 49:127-142, 2003.
[4] Y. Cho, Z. Gagov, W. Kwon. Elevator group control with
accurate estimation of hall call waiting times. IEEE Proc. Int.
Conf. on Robotics and Automation, pp. 447-452, 1999.
[5] Digilent Inc. Available at www.digilentinc.com. Accessed in
2005.
[6] A. Fujino, T. Tobita, K. Segawa, K. Yoneda. An Elevator Group
Control System with Floor-Attribute Control Method and
System Optimization using Genetic Algorithms. IEEE Trans.
Ind. Elect. 44(4):546-552, 1997.
[7] Muller-Glaser, K. D.; Frick, G.; Sax, E.; Kuhl, M. Mutiparadigm
Modeling in Embedded System Design. IEEE Transactions on
Control System Technology 12(2):279-292, 2004.
[8] D. Hauptmeirer, S.O. Krumke, J. Rambau and H.-C. Wirth.
Euler is standing in line dial-a-ride problems with precedence-
constraints. Discrete Applied Mathematics 113:87-107, 2001.
[9] T. Hikihara, S. Ueshima. Emergent synchronization in multi-
elevator system and dispatching control. IEICE Trans. on Fund.
of Elect. Comm. and Comp. Sc., E80-A(9):1548-1553, 1997.
[10] C. Kim, K. A. Seong, H. Lee-Kwang, J. O. Kim. Design and
Implementation of a Fuzzy Elevator Group Control System.
IEEE Transactions on Systems Man and Cybernetics Part A
28(3):277-287, 1998.
[11] ModelSim. Available at www.model.com. Accessed in 2005.
37
[12] D. Nikovsky, M. Brand. Decision-Theoretic Group Elevator
Scheduling. AAAI Proc. 13th Int. Conf. on Automated Planning
and Scheduling, pp. 133-142, 2003.
[13] D. L. Pepyne, C. G. Cassandras. Optimal Dispatching Control
for Elevator Systems during Up-peak Traffic. IEEE Trans.
Contr. Syst. Technol. 5(6):629-643, 1997
[14] B. A. Powell, J . N. Williams. Elevator dispatching based on
remaining response time, US Patent, #5.146.053, 1992.
[15] B. Seckinger, J. Koehler. Online-Synthese von
Aufzagssteuerungen als Plannungsproblem. Workshop Planen
und Konfigurieren, Int. Bericht des Instituts fur Informatik der
Universität Wurzburg, pp. 127-134, 1999.
[16] M. Siikonen, J. Leppala. Elevator traffic pattern recognition.
Proc. 4th Int. Conf. Fuzzy Sys. Assoc., pp. 195-198, 1991.
[17] M. Siikonen. Elevator Group Control with Artificial
Intelligence. Research Report A67. System Analysis of
Technology, Helsinki University of Technology. 1997.
[18] M. Siikonen. Planning and Control Models for Elevator in
High-Rise Buildings. Research Report A68. System Analysis
of Technology, Helsinki University of Technology. 1997.
[19] V. Sklyarov, I. Skliarova, P. Almeida, M. Almeida. Desing
Tools and Reusable Libraries for FPGA-Based Digital
Circuits. IEEE Proc. Euromicro Symposium on Digital System
Desing, pp. 255-263, 2003.
[20] G. R. Strankosch. Vertical transportation: elevators and
escalators. Jhon Wiley & Sons, 1998.
[21] H. Ujihara, S. Tsuji. The revolutionary AI-2000 elevator group-
control system and the new intelligent option series. Mitsubishi
Electric Advance, 45:5-8, 1988.
[22] H. Ujihara, M. Amano. The latest elevator group-control
system. Mitsubishi Electric Adv., 67:10-12, 1994.
[23] Xilinx Corporation. ISE User Guide. Available at
www.xlinx.com. Accessed in 2005.