The development was motivated by renew and

completely redesign a conventional elevator controller

with point-to-point connections which was given and
was developed more than 10 years earlier. Of course
all the technical solutions and tricks are outdated and
can not compete with the newly designed systems
however the services which can be delivered are
unique in their fields.
On the one hand the costs must be cut down. This
means the point-to-point wiring must be replaced with
a cost efficient and reliable solution. The main
controlling system must be updated to be capable to
the new solutions.
On the other hand the complexity of the present
system must be simplified. At the same time the
ability to repair can be improved.
This paper stated how the listed steps were
achieved.

2. INTRODUCING THE OLD SYSTEM

It was developed by a Hungarian company at the
end of the 80's [1]. It is able to attend a maximum of
18 storeys. There are six control cards: CPU, ECC,
DLC, PUI, PU2 and PU3. These cards are located in
the main controller which is on the top of the elevator

1-4244-1218-8/07/$25.00 2007 IEEE 451

.
Microcontroller based elevator controlling system

Akos Becker')
Department of Electronics Technology, Budapest University of Technology and Economics, Budapest, Hungary
akos .becker@freemail.hu

Abstract. This paper introduces a new solution of elevator controlling system which is based on
microcontrollers. The earlier version of it is still used by Schindler Hungaria Kft. Thanks to the
innovation the point-to-point connections (the number of cables and so the cable length) could be
dramatically reduced. In addition the ability to repair and the modularity has been also improved. The
complexity of the system has been simplified and the costs could be lowered also. Until today a demo
elevator system has been made which consists of three storey (called EIF) card. One of these executes
the tasks of the main controller (so called IF). For both card types a control software was developed
in C programming language, whereby the new system capacities could be demonstrated.

1. INTRODUCTION
(Fig. 1). Between the cards a special system bus can
be found so called MMT Bus which is protected by
proprietary rights.

I
CONTROLLER

CPU ECC DLC PUl PU2 PU3

IENGINE
CONTROLLER

Fig. 1. Present solution of the elevator controller.

2.1. Functionality of the control cards
The main program runs on the CPU card. After it
processes the I/O signals it controls the elevator cabin.
The engine is controlled by the ECC (Engine
Control Card).
The cabin's lighting and the movement of the
cabin's doors are controlled by the DLC (Door and
Cabin control Card).

30th ISSE 2007

 The I/O signals of the floors are processed by the
Peripheral Unit cards (PU1, PU2 and PU3).
2.2 Disadvantages
Every single signal is processed in the main
controller. This means if the user pushes any button
on the 1st floor it's signal must be delivered up to 18th
floor up to the controller. There it will be processed
and will be confirmed on the 1st floor. Each button,
display, switch and sensor is connected to the main
system via dedicated wires. This solution requires a
huge number of connection points and also a huge
quantity of cables. Both of them carry enormous risks
of malfunction. Besides this disadvantage more cable
requires more money of course.
The present system has a lack of modularity. It can
not be upgraded with one more PU card to be able to
manage more than 18 storeys. The main program also
can not be modified to be able to control more than it
is stated.
Any failure means a lot of time to discover. The
defective parts can not be changed easily because it is
a closed system.
3. CONCEPT OF THE NEW SYSTEM
According to the disadvantages of the present
system the motivation is unambiguous. Reducing
wiring, upgrading the whole system with the newest
available technology and improving flexibility.
Reducing wiring means a replacement with a four-
wired system bus. Upgrading means a replacement for
the storey cards. These modification plans can be seen
on Fig. 2.
CONTROLE
CONTROLLER
C 'CDLC PUl PU2 PU3 EIF
Iii ill
EIF
CPU ECC IlF
Fig. 2. Schematic diagram of the new system.
1-4244-1218-8/07/$25.00 2007 IEEE
3.1. Compatibility
Because of the time limitations of the project the
main control program which is running on a Z80
microprocessor (CPU card) had to be kept. (This will
be another project to completely replace this card.) In
this situation the modifications had to be drawback
compatible with the untouched parts of the system.
This must be solved by the new IF card which is the
most important part of the development. It simulates
the old status for the CPU and ECC cards, while it
makes an interface for the two new four-wired system
buses (Fig. 3.).
MMiTbus BUS
IF EFI
EIF
-EIFi
-EIFn
Fig. 3. Two separated system bus.
3.2. EIF cards
These cards control and process all the I/O storey
signals so they are indispensable. They must be
equipped on every floor otherwise the system will not
work. Their jobs are:
- Process the elevator control buttons. If it is
successful it must be confirmed for the user.
- Two 7 segment displays must be driven in
order to show the actual position of the cabin.
The cabin's actual moving direction must be
-
displayed.
- A direct contact must be made with the IF
card.
- If a query exists an answer must be sent to the
IF which contains whether the user has called
452 30th ISSE 2007
 the cabin or not. If it is so the direction also
must be told.
- The instructions from IF must be processed.
These cards have a great advantage of processing
the signals locally and they do not need to be
delivered up to the main controller. Of course this
must be succeeded in a definite time.
3.3. FIF card
The cabin's movement sensors' signs and its
signals are processed by the FIF. It follows logically
from this that, it is located in the cabin. So FIF jobs
are:
- Processing and confirming the buttons and
keyed buttons.
- Processing sensor signs.
Sensors' signs are the most important job for the
FIF. These tell the position of the cabins. Thanks to
them the software can control the engine when to stop,
to break, accelerate or whether the cabin is overrun or
not. In this case the processing time is really
significant. There is absolutely no room for any delay.
Therefore FIF requires a faster system bus to IF as
EIF. In this case a so called 'Hard Real Time' system
must be equipped.
3.4. IF card
From all of them this is the most complex card. IF
is the key to the improvement. On one side it
simulates the old status to the CPU and ECC cards so
the main control program can be used. On the other
side it makes a separated interface to the FIF and the
EIF cards.
It uses a four-wired system bus to communicate
with the EIFs. This protocol based on master-slave
communication where IF takes place as a master. The
program runs periodically and makes a query to each
EIF. In this case a soft real time system is equipped. If
a failure occurs probably will be solved in the next
query. A failure only means a delay in the
confirmation of any action. For example: After
pushing any button the user have to wait a half second
more to be confirmed his action.
Communication with FIF requires more accuracy
and short response time. In this case there is no master
or slave card because only two units communicate
with each other. The movement signs must be
1-4244-1218-8/07/$25.00 2007 IEEE
processed as soon as possible. This is solved by
interrupts.
4. COMMUNICATION
12C, CAN, RS485 and MODbus were examined in
three different aspects:
- The selected bus must be as simple as possible
to be capable to a newly designed protocol.
- It must have a huge protection against EMC.
- Must be fast enough to communicate through
at least 20 storeys.
Taking these aspects in consideration the 12C is not
fast enough and the protection against EMC also not
the best. MODbus is difficult too, not fast enough and
also has problems against EMC. RS485 was refused
by personal experiences.
CAN was the optimal choice. Its EMC protection
is one of the best. It has a 250kbps communication
speed on 200m (1 OOm up, and 1 00m down calculating
with 20 storeys.) and it is not necessary to use the
official CAN protocol. So it meets all the
requirements and also was supported by Meldetechnik
Kft. the main financial sponsor of the project.
4.1. Communication protocol
As it was mentioned IF uses a master-slave
communication to communicate with EIFs. IF makes a
periodic query to each EIF. As soon as the EIF
receives this message sends back an answer
immediately. This answer contains the status of
confirmation LEDs and whether a user called the
cabin or not. IF processes this message and modify the
record belonging to that specified EIF and makes
changes if it is necessary. The IF will use these answer
message and the cabin actual position to create the
new polling message on the next query. In the new
message IF gives orders to EIF how to modify the
displays' status. This means that every polling
message is the confirmation of the earlier received
answer message.
During development an exact delay time was
specified in 250ms. Within this time a confirmation
must be made after any button was pushed on any
storey. With 20 floors this means 12,5ms polling time.
If IF does not receive answer from an EIF within
12,5ms will make a query to the next EIF card. This
453 30th ISSE 2007
failure is stored by IF and will be sent in the next
polling message to that EIF. Thanks to this solution
the EIF will know that there was a mistake and the
new information will be sent instead of the earlier.
If IF permanently can not receive the answer from
a specified EIF an error massage will be sent to the
main controller.
To improve safety each message contains a
checksum. If there is a failure in the message on the
receiver side newly created checksum will not match
with the received one. In this case the receiver will
throw away the message. This situation is the same
like IF or EIF can not receive answer on time.
4.2. Structure of messages
From IF a 7 byte long message is sent to EIF (Fig.
4.).
3E Adclress 1.Digit I 2.Digit I LED
Speci al EIFF Data
Byte Address
Fig. 4. IF's message.
First byte of this message is a special byte which
identifies that this message was sent by IF.
Second byte is the EIF's address. Messages will
not be processed by other EIF cards with different
address.
The third and the second bytes contain the cabin's
actual position which must be displayed on the two
seven segment displays. There is an option to these
two byte can contain any error messages also.
The next byte contains the confirmation LED's
status. The first four bit of this byte is the mode
selector. Two operating modes are possible: normal
mode or flashing. The last four bits refer to the LEDs'
status.
With the control byte's last bit can be indicated
whether a problem occurred during the last query. The
other bits can be used as different error codes but this
is not implemented in the software yet.
Last byte is the checksum.
Only a 3 byte message is sent by the EIF as an
answer for the IF query (Fig. 5.).
1-4244-1218-8/07/$25.00 2007 IEEE
Address I Dat
IAII 8 8 Il CU
Dt I
EIF EButton+LEDI Checksum
Address State
Fig. 5. EIF's answer message.
In this case there is no special byte because it is not
necessary. None of the addresses can match with the
special byte.
First byte of this message is the EIF own address.
This is really helpful because of this the IF knows
whether there was an answer from the polled EIF or
not. The failure can be immediately turned out.
Next byte contains the changes since the last
message. The states of buttons and confirmation
LEDs.
I Control CSum The last byte is the checksum.
Checksum
5. SOFTWARE
In this section the two control software will be
briefly introduced which was developed for the IF and
EIF cards.
Both of them were developed in C programming
language. The other option was the Assembly. It
generates a smaller program code and more efficient.
On the other hand programming in C is much easier. It
reduces development time and the code is more
visible even it is huge.
Two different software was developed. One for the
IF and one for the EIF cards. Both have a same
structure. The main function initializes the hardware,
variables and enables interrupt routines. After this
comes an endless cycle (Fig. 6.).
Main
Hardware Initialization
Initialization of Variables
Enable IT
T-
Fig. 6. Structure of the main function.
454 30th ISSE 2007
 The interrupt routines are responsible for the
proper functionality. There are three different IT. One
for receiving data, one for sending data and the last
one is for the timer interrupt. When an interrupt is
occurred the IT routine makes an inquiry which term
came true (Fig. 7.).
( TFoutine
iOsable IT, Save FRegisers|
/t > ~No Sede No
Yes Yes
Fig. 7. IT routine's structure.
Sender and receiver interrupt routines are clear.
The two 7 segment display must be multiplexed
because of reducing connection pins. According to
this avoiding flashing a timer is required. This
problem is solved by the Timer IT.
6. RESULTS
Up today a demo system has been made which can
be seen on Fig. 8. This system consists of three
prototypes of EIF cards. Of course this system could
not operate without an IF card. Therefore one EIF
executes the tasks of IF. In this case this card is
located on the top of the picture.
Fig. 8. The mini elevator system during operation.
Each storey card is controlled by a PIC18F4680
microcontroller [2]. The communication between the
cards is supported by a PCA82C250 CAN transceiver
1-4244-1218-8/07/$25.00 2007 IEEE
by Philips [3]. The microcontroller can be
programmed by ICSP (In-Circuit Serial
Programming). To each PIC belong 5 jumpers. With
these EIF's own address can be set. Of course there is
also a display module where two 7 segment display
and four buttons can be found. With these buttons
normal operating method can be simulated. Each
button has a confirmation LED.
With this demo system the system capacities can
be tested for example the maximum polling speed.
No\ The specification requires at least 12,5ms as it was
stated earlier. With this solution this can be reduced
e
till 1Oms. So the main program runs periodically and
makes a query to each EIF card in every 1 Oms. This
means for 20 EIF the system needs only 200ms which
is less than the requested 250ms. In a different aspect
in 1 second every EIF cards will be polled 5 times. In
practice in a 20 storey building after pushing any
button the user have to wait less than a half second to
be confirmed his action.
7. FURTHER ISSUES
In the near future an IF and a FIF card could be
designed. They will be tested together with the CPU
and ECC cards. If the test period's results are
promising the system can be used more widely.
REFERENCES
[1] Department Of Measurement and Information Systems,
"Microprocessor based elevator controlling system",
version: FLV-V02.1, 1989 (Project report in
Hungarian)
[2] Microchip Technology Inc., "PIC18F4680 Data
Sheet", 2004
[3] Philips Semiconductors, "PCA82C250 Data Sheet",
2000
455 30th ISSE 2007