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 onmicrocontrollers. The earlier version of it is still used by Schindler Hungaria Kft. Thanks to theinnovation the point-to-point connections (the number of cables and so the cable length) could bedramatically reduced. In addition the ability to repair and the modularity has been also improved. Thecomplexity of the system has been simplified and the costs could be lowered also. Until today a demoelevator system has been made which consists ofthree storey (called EIF) card. One ofthese executesthe tasks of the main controller (so called IF). For both card types a control software was developedin Cprogramming language, whereby the new system capacities could be demonstrated.

1. INTRODUCTION

The development was motivated by renew andcompletely redesign a conventional elevator controllerwith point-to-point connections which was given andwas developed more than 10 years earlier. Of courseall the technical solutions and tricks are outdated andcan not compete with the newly designed systemshowever the services which can be delivered areunique in their fields.

On the one hand the costs must be cut down. Thismeans the point-to-point wiring must be replaced witha cost efficient and reliable solution. The maincontrolling system must be updated to be capable tothe new solutions.

On the other hand the complexity of the presentsystem must be simplified. At the same time theability to repair can be improved.

This paper stated how the listed steps wereachieved.

2. INTRODUCING THE OLD SYSTEM

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

(Fig. 1). Between the cards a special system bus canbe found so called MMT Bus which is protected byproprietary rights.

CONTROLLER

IENGINE

CONTROLLER

CPU ECC DLC PUl PU2 PU3

I

Fig. 1. Present solution of the elevator controller.

2.1. Functionality ofthe control cards

The main program runs on the CPU card. After itprocesses the I/O signals it controls the elevator cabin.

The engine is controlled by the ECC (EngineControl Card).

The cabin's lighting and the movement of thecabin's doors are controlled by the DLC (Door andCabin control Card).

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

.451 30th ISSE 2007

The I/O signals of the floors are processed by thePeripheral Unit cards (PU1, PU2 and PU3).

2.2 Disadvantages

Every single signal is processed in the maincontroller. This means if the user pushes any buttonon the 1st floor it's signal must be delivered up to 18thfloor up to the controller. There it will be processedand will be confirmed on the 1st floor. Each button,display, switch and sensor is connected to the mainsystem via dedicated wires. This solution requires ahuge number of connection points and also a hugequantity of cables. Both of them carry enormous risksof malfunction. Besides this disadvantage more cablerequires more money of course.

The present system has a lack of modularity. It cannot be upgraded with one more PU card to be able tomanage more than 18 storeys. The main program alsocan not be modified to be able to control more than itis stated.

Any failure means a lot of time to discover. Thedefective parts can not be changed easily because it isa closed system.

3. CONCEPT OF THE NEW SYSTEM

According to the disadvantages of the presentsystem the motivation is unambiguous. Reducingwiring, upgrading the whole system with the newestavailable technology and improving flexibility.

Reducing wiring means a replacement with a four-wired system bus. Upgrading means a replacement forthe storey cards. These modification plans can be seenon Fig. 2.

CONTROLE

CONTROLLER

C 'CDLC PUl PU2 PU3 EIF

Iii illEIF

CPU ECC IlF

3.1. Compatibility

Because of the time limitations of the project themain control program which is running on a Z80microprocessor (CPU card) had to be kept. (This willbe another project to completely replace this card.) Inthis situation the modifications had to be drawbackcompatible with the untouched parts of the system.This must be solved by the new IF card which is themost important part of the development. It simulatesthe old status for the CPU and ECC cards, while itmakes an interface for the two new four-wired systembuses (Fig. 3.).

MMiTbus BUSIF EFI

EIF

-EIFi

-EIFn

Fig. 3. Two separated system bus.

3.2. EIF cards

These cards control and process all the I/O storeysignals so they are indispensable. They must beequipped on every floor otherwise the system will notwork. Their jobs are:

- Process the elevator control buttons. If it issuccessful it must be confirmed for the user.

- Two 7 segment displays must be driven inorder to show the actual position of the cabin.

- The cabin's actual moving direction must bedisplayed.

- A direct contact must be made with the IFcard.

- If a query exists an answer must be sent to theIF which contains whether the user has called

Fig. 2. Schematic diagram of the new system.

1-4244-1218-8/07/$25.00 ©2007 IEEE 452 30th ISSE 2007

the cabin or not. If it is so the direction alsomust be told.

- The instructions from IF must be processed.

These cards have a great advantage of processingthe signals locally and they do not need to bedelivered up to the main controller. Of course thismust be succeeded in a definite time.

3.3. FIF card

The cabin's movement sensors' signs and itssignals are processed by the FIF. It follows logicallyfrom this that, it is located in the cabin. So FIF jobsare:

- Processing and confirming the buttons andkeyed buttons.

- Processing sensor signs.

Sensors' signs are the most important job for theFIF. These tell the position of the cabins. Thanks tothem the software can control the engine when to stop,to break, accelerate or whether the cabin is overrun ornot. In this case the processing time is reallysignificant. There is absolutely no room for any delay.Therefore FIF requires a faster system bus to IF asEIF. In this case a so called 'Hard Real Time' systemmust be equipped.

3.4. IF card

From all of them this is the most complex card. IFis the key to the improvement. On one side itsimulates the old status to the CPU and ECC cards sothe main control program can be used. On the otherside it makes a separated interface to the FIF and theEIF cards.

It uses a four-wired system bus to communicatewith the EIFs. This protocol based on master-slavecommunication where IF takes place as a master. Theprogram runs periodically and makes a query to eachEIF. In this case a soft real time system is equipped. Ifa failure occurs probably will be solved in the nextquery. A failure only means a delay in theconfirmation of any action. For example: Afterpushing any button the user have to wait a half secondmore to be confirmed his action.

Communication with FIF requires more accuracyand short response time. In this case there is no masteror slave card because only two units communicatewith each other. The movement signs must be

processed as soon as possible. This is solved byinterrupts.

4. COMMUNICATION

12C, CAN, RS485 and MODbus were examined inthree different aspects:

- The selected bus must be as simple as possibleto be capable to a newly designed protocol.

- It must have a huge protection against EMC.

- Must be fast enough to communicate throughat least 20 storeys.

Taking these aspects in consideration the 12C is notfast enough and the protection against EMC also notthe best. MODbus is difficult too, not fast enough andalso has problems against EMC. RS485 was refusedby personal experiences.

CAN was the optimal choice. Its EMC protectionis one of the best. It has a 250kbps communicationspeed on 200m (1OOm up, and 100m down calculatingwith 20 storeys.) and it is not necessary to use theofficial CAN protocol. So it meets all therequirements and also was supported by MeldetechnikKft. the main financial sponsor of the project.

4.1. Communication protocol

As it was mentioned IF uses a master-slavecommunication to communicate with EIFs. IF makes aperiodic query to each EIF. As soon as the EIFreceives this message sends back an answerimmediately. This answer contains the status ofconfirmation LEDs and whether a user called thecabin or not. IF processes this message and modify therecord belonging to that specified EIF and makeschanges if it is necessary. The IF will use these answermessage and the cabin actual position to create thenew polling message on the next query. In the newmessage IF gives orders to EIF how to modify thedisplays' status. This means that every pollingmessage is the confirmation of the earlier receivedanswer message.

During development an exact delay time wasspecified in 250ms. Within this time a confirmationmust be made after any button was pushed on anystorey. With 20 floors this means 12,5ms polling time.If IF does not receive answer from an EIF within12,5ms will make a query to the next EIF card. This

1-4244-1218-8/07/$25.00 ©2007 IEEE 453 30th ISSE 2007

failure is stored by IF and will be sent in the nextpolling message to that EIF. Thanks to this solutionthe EIF will know that there was a mistake and thenew information will be sent instead of the earlier.

If IF permanently can not receive the answer froma specified EIF an error massage will be sent to themain controller.

To improve safety each message contains achecksum. If there is a failure in the message on thereceiver side newly created checksum will not matchwith the received one. In this case the receiver willthrow away the message. This situation is the samelike IF or EIF can not receive answer on time.

4.2. Structure ofmessages

From IF a 7 byte long message is sent to EIF (Fig.4.).

3E Adclress 1.Digit I 2.Digit I LED I Control CSum

Speci al EIFFByte Address

Data

Fig. 4. IF's message.

First byte of this message is a special byte whichidentifies that this message was sent by IF.

Second byte is the EIF's address. Messages willnot be processed by other EIF cards with differentaddress.

The third and the second bytes contain the cabin'sactual position which must be displayed on the twoseven segment displays. There is an option to thesetwo byte can contain any error messages also.

The next byte contains the confirmation LED'sstatus. The first four bit of this byte is the modeselector. Two operating modes are possible: normalmode or flashing. The last four bits refer to the LEDs'status.

With the control byte's last bit can be indicatedwhether a problem occurred during the last query. Theother bits can be used as different error codes but thisis not implemented in the software yet.

Last byte is the checksum.

Only a 3 byte message is sent by the EIF as ananswer for the IF query (Fig. 5.).

IAII I Dt I CU IAddress Dat8 8 l

EIF EButton+LEDI ChecksumAddress State

Fig. 5. EIF's answer message.

In this case there is no special byte because it is notnecessary. None of the addresses can match with thespecial byte.

First byte of this message is the EIF own address.This is really helpful because of this the IF knowswhether there was an answer from the polled EIF ornot. The failure can be immediately turned out.

Next byte contains the changes since the lastmessage. The states of buttons and confirmationLEDs.

The last byte is the checksum.

5. SOFTWARE

In this section the two control software will bebriefly introduced which was developed for the IF andEIF cards.

Both of them were developed in C programminglanguage. The other option was the Assembly. Itgenerates a smaller program code and more efficient.On the other hand programming in C is much easier. Itreduces development time and the code is morevisible even it is huge.

Two different software was developed. One for theIF and one for the EIF cards. Both have a samestructure. The main function initializes the hardware,variables and enables interrupt routines. After thiscomes an endless cycle (Fig. 6.).

Main

Hardware Initialization

Initialization of Variables

T-Enable IT

Fig. 6. Structure of the main function.

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

Checksum

454 30th ISSE 2007

The interrupt routines are responsible for theproper functionality. There are three different IT. Onefor receiving data, one for sending data and the lastone is for the timer interrupt. When an interrupt isoccurred the IT routine makes an inquiry which termcame true (Fig. 7.).

( TFoutine

iOsable IT, Save FRegisers|

/t > ~No Sede No No\

Yes Yes e

Fig. 7. IT routine's structure.

Sender and receiver interrupt routines are clear.The two 7 segment display must be multiplexedbecause of reducing connection pins. According tothis avoiding flashing a timer is required. Thisproblem is solved by the Timer IT.

by Philips [3]. The microcontroller can beprogrammed by ICSP (In-Circuit SerialProgramming). To each PIC belong 5 jumpers. Withthese EIF's own address can be set. Of course there isalso a display module where two 7 segment displayand four buttons can be found. With these buttonsnormal operating method can be simulated. Eachbutton has a confirmation LED.

With this demo system the system capacities canbe tested for example the maximum polling speed.The specification requires at least 12,5ms as it wasstated earlier. With this solution this can be reducedtill 1Oms. So the main program runs periodically andmakes a query to each EIF card in every 1Oms. Thismeans for 20 EIF the system needs only 200ms whichis less than the requested 250ms. In a different aspectin 1 second every EIF cards will be polled 5 times. Inpractice in a 20 storey building after pushing anybutton the user have to wait less than a half second tobe confirmed his action.

6. RESULTS 7. FURTHER ISSUES

Up today a demo system has been made which canbe seen on Fig. 8. This system consists of threeprototypes of EIF cards. Of course this system couldnot operate without an IF card. Therefore one EIFexecutes the tasks of IF. In this case this card islocated on the top of the picture.

In the near future an IF and a FIF card could bedesigned. They will be tested together with the CPUand ECC cards. If the test period's results arepromising 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 inHungarian)

[2] Microchip Technology Inc., "PIC18F4680 DataSheet", 2004

[3] Philips Semiconductors, "PCA82C250 Data Sheet",2000

Fig. 8. The mini elevator system during operation.

Each storey card is controlled by a PIC18F4680microcontroller [2]. The communication between thecards is supported by a PCA82C250 CAN transceiver

1-4244-1218-8/07/$25.00 ©2007 IEEE 455 30th ISSE 2007