2013 UKSim 15th International Conference on Computer Modelling and Simulation

FPGA Based Elevator Controller with Improved Reliability

Sithumini Ekanayake, Ruwan Ekanayake, Somasundaram Sanjayan, Sunil G. Abeyratne, S.D. Dewasurendra
Dept. of Electrical and Electronic Engineering
University of Peradeniya
Peradeniya, Sri Lanka
E-mail: [email protected], [email protected], [email protected], [email protected], [email protected]

Abstract— This paper introduces a novel method to improve Spartan 3AN FPGA which acts as the core of the controller
the reliability of a reconfigurable FPGA based elevator and tested on real hardware.
controller, which can be used for an elevator with any number
of floors, with specified inputs and outputs. It was clear that by II. IMPLEMENTATION OF THE CONTROLLER
simply changing a variable in the HDL code the controller can
be generated for an elevator with required number of floors. A. Preliminary Study
Thus in this paper the primary implementation and When developing a control algorithm it is always
verification procedure is given in detail together with a method
advantageous to have a model based design approach since
to improve the reliability. The flexibility in expansion of
initial specifications will be useful in later developments.
designs in an FPGA was considered thoroughly in the
proposed reliability improving method. The controller was
The study [2] shows a state chart model developed for a
developed using Verilog HDL throughout the research and a prototype elevator with three floors which was developed
description on the code development is included in the paper. further to come up with a reconfigurable controller for any
The controller generated was successfully implemented on a number of floors. Also Zhao et al. [3] clearly illustrate the
Xilinx Spartan 3AN FPGA and tested for a prototype elevator basic functions and demands of an elevator system with
with three floors. stages of development in detail. In this research the results
obtained in [2] were used in advancing the program
Keywords- Elevator, FPGA, Verilog, reconfigurable according to our requirements.
B. HDL Program Development
I. INTRODUCTION
FPGA has inputs/outputs that can be used as a bit vector
In controller implementation for a system several factors in programming directly. In the program this property is used
such as nature of the system, power consumption and in generating the data vectors. Also in the program, the data
reliability play vital roles in design considerations. At vectors are defined with the no of bits in a vector as equal to
present, PLCs are commonly used in control and automation the number of floors. These vectors will be generated
industry where easy programming environment is highly automatically when the number of floors is given.
expected. But for a complex reactive system, Field
Programmable Gate Arrays (FPGAs) can be recommended Eg. If number of floors is 3, the corresponding input
due to their inherently parallel processing capability. vector will be „xxx‟. If number of floors is 5 the input vector
An elevator (or lift) is a mechanism to transport human will be „xxxxx‟
beings or goods between floors of a building, vessel or other
structures. Since, mostly it is an arrangement that efficiently In the code, Proximity sensor inputs, Car call button
moves people, safety and the convenience of the travelling inputs and Hall call button inputs are the three input data
people should be certified. Therefore, implementation of vectors. Then a common vector is generated as a variable for
proper control systems for elevators is essential. An elevator any car button input or hall button input since any button
can be considered as a complex reactive system which input can be considered as a request for elevator car to reach
requires parallel event processing with large number of a particular floor. The direction of the elevator car is decided
inputs and outputs. Therefore FPGAs make a better solution by comparing the integer values of the common vector and
for implementing an elevator controller with added pros of the proximity sensor input vector. If the integer value of the
reconfigurability, less power consumption, low response common vector is greater than the integer value of the
times and flexibility in expansion of designs. proximity sensor input vector the motion will be forward and
In this research, our objectives were, developing an if the common vector integer value is less than the proximity
elevator algorithm for an elevator with any number of floors sensor input vector integer value the motion will be reverse.
and improving its reliability. There Verilog HDL was used At the moment the two integer values become the same the
due to its syntactical familiarity. Verilog is a hardware elevator car will be stopped. The Verilog program for the
description language (HDL) which is commonly used to reconfigurable elevator controller was developed using this
describe digital circuits in a textual manner in designing. For logic.
coding, simulation and synthesis purposes Xilinx ISE
software was used. The final design was programmed to a

978-0-7695-4994-1/13 $26.00 © 2013 IEEE 260

DOI 10.1109/UKSim.2013.128

Authorized licensed use limited to: AMRITA VISHWA VIDYAPEETHAM AMRITA SCHOOL OF ENGINEERING. Downloaded on April 09,2023 at 08:27:06 UTC from IEEE Xplore. Restrictions apply.
 In Verilog, basic building blocks used are the modules.
Firstly we need to define input and output ports, then inputs
and outputs are separated and the data types are defined.
There are two families of fixed data types in Verilog, „nets‟
and „registers‟. Nets (i.e. wire, tri, wand & etc.) establish
structural connectivity whereas Registers (i.e. reg, integer,
real, time & etc.) store information.
C. Simulation
Xilinx ISE software provides full range of editing,
synthesis and simulation and implementation tools for
Verilog development environment. After HDL program was
written and synthesized in Xilinx ISE, simulation tools were
used to simulate the developed program before downloading
Figure 1. Test bench waveform
to the FPGA development board so that the code behavior
could be verified. Initially a test bench waveform had to be
created by adjusting clock frequencies and widths as
required. Then the assumed inputs were given to the test
bench as shown in Fig. 1.
Consider a situation where the elevator car is at floor 0.
So the proximity sensor input is made „high‟ as shown in the
Fig. 1. Then assume a request is made from a car button to
reach floor 2. So the inverter forward output and brake
output should be „high‟ in order to move the elevator car.
Also, the light used to indicate the request should become
„high‟. To represent the moment that the car passes
proximity sensor of floor 1, relevant input is made „high‟ and
then at floor 2, the proximity input of that floor is made
„high‟ again. Thus there should be no difference at the output Figure 2. Simulation output
until the car reaches floor 2. At floor 2, the light indicator of
the request should be „low‟. While the car is at floor 2,
assume another request is made from a car button to reach B. Hardware Interfacing
floor 0. So the light indicator output of the request made
The hardware design for this research contains mainly
should become „high‟. Then again the proximity sensor
four parts; input circuit, output circuit, core of the controller
values of floor 1 and floor 0 in the input are made „high‟
(FPGA board) and plant (elevator). The major problem that
respectively. Therefore the outputs of inverter reverse and
we faced from very beginning was interfacing the FPGA
brake should be „high‟ until it reaches floor 0. At floor 0, the
inputs and outputs to the existing prototype elevator system.
light indicator of the request becomes „low‟ as previously.
Since the existing system voltages and FPGA input and
In the simulation the output is observed to verify whether
output voltage levels are different we had to design
the expected output was obtained. Fig. 2 shows the
intermediate circuits for voltage conversions. In the system,
simulation results obtained for the given input.
working voltage of the plant is 24 V DC while working
III. HARDWARE FOR CONTROLLER IMPLEMENTATION voltage level of FPGA input and output is 3.3 V DC. Thus
necessary input and output circuits were made in accordance
A. Prototype Elevator with Fig. 3.
The 24 V plant input signals are stepped down to 3.3V
For the controller implementation a prototype elevator using 4n35 optocoupler in the input circuit as the transistor in
consists of three floors was used. the optocoupler is biased when a 24 V DC signal is given
To move the elevator car up and down, main induction from the plant, so the FPGA input pin receives 3.3 V from
motor is driven in forward and reverse directions, the board itself. The advantage of using optocouplers is that
respectively, by providing two control outputs to main it isolates the 24 V system and 3.3 V system so that the
inverter. Also at the same time it is required to release the protection of the FPGA board is guaranteed. The FPGA
electric brake which activates a solenoid to provide three board generates an output for the corresponding inputs
control inputs for another inverter. according to the code developed in Verilog. The output of
the FPGA board is connected to output circuit where a relay
circuitry is used to step up 3.3 V to 24 V.

261

Authorized licensed use limited to: AMRITA VISHWA VIDYAPEETHAM AMRITA SCHOOL OF ENGINEERING. Downloaded on April 09,2023 at 08:27:06 UTC from IEEE Xplore. Restrictions apply.
 IV. PROPOSED RELIABILITY IMPROVING METHODOLOGY C. System Requirements
The research presented in the current paper proposes a
A. Soft Errors methodology to improve the reliability of the Xilinx Spartan
Soft errors are the transient faults that affect the devices FPGA based elevator controller through the knowledge of
causing a bit flip of a value stored in a memory cell so that
Redundant logic 0
the error can be recovered by re-writing the correct value.
These types of faults may affect both combinatorial and
Redundant logic 1 Majority Voter
sequential logic. When considering FPGA devices, the
occurrence of soft errors is a more problematic issue since
the user-programmed functionality of an FPGA depends on Redundant logic 2
the data stored in millions of configuration latches within the
device. Figure 4. TMR in a block diagram
Input Circuit
FPGA Board 24 V3.3 V
Plant 24 V TMR. Initially we identified the basic requirements of a
3.3 V
Output Circuit
control system for reliable operation.
3.3 V24 V  The system should have the ability to detect the
faults in the running system
 If there is any fault in the running system the control
Figure 3. Hardware design
system should able to shift the operation to a
redundant circuit
There can be two soft errors in common; Single Event Thus the reliability improving methodology was
Transient (SET) and Single Event Upset (SEU). SET is a developed under the constraint of earning maximum benefit
pulse on the signal that if latched in a register produces an of available resources.
erroneous value whereas SEUs may alter the logic-state of
any static memory element (latch, flip flop, or RAM cell) or D. Proposed Methodology
cause transient pulses in combinatorial logic paths. These In the proposed methodology there are three instances of
faults may corrupt the content of an application register our basic code as instance A, instance B and instance C so
causing an error in the data or in the control of the running that three parallel processes are running simultaneously.
application, implying an error in the computation. In another Fig. 5 shows the block diagram of the proposed
case, faults may affect a configuration register, causing either implementation. Since there are three instances, if an error
the functionality performed by a Look-Up Table (LUT) or a occurred in one instance it will only affect the specific
routing cell between Combinatorial Logic Blocks (CLBs) to instance. The other two instances function properly. The
change, resulting in a functionality alteration. While the first outputs of three instances are multiplexed by the mux and an
situation may be recovered by a re-computation or accurate instance output is connected to the actual plant
application reset, the second one requires a reconfiguration output. The process of which instance output to be connected
of the FPGA. depends on the mux controller decision. There controller acts
The possibility of re-program the device has received a as a majority voter.
lot of attention and improvements have been introduced to Assume there is a bit error in instance A so that the
support such a feature at run-time also, i.e., dynamically. output differs from the actual one. Since the other two
Furthermore, advances in the FPGA technology have come instances, B and C, work properly, when the controller
to support re-configuration, at run-time, of only a portion of compares the three outputs the majority result can be
the device, thus reducing the time necessary to re-program considered as the error free actual output. Thus one of the B
the device and to avoid the necessity to halt the entire system and C instance outputs will be connected as the plant output.
[5], [6].
V. RESULTS
B. Triple Module Redundancy (TMR)
TMR is a common hardware redundancy technique for A. Logic triplication
achieving fault masking properties. As discussed in [7], it In implementation according to the described reliability
uses three replicas of the whole system as shown in the Fig.4 improving method first step undertook was triplicating the
and adds a voter that identifies the correct result among the basic code developed at initial stages. In Verilog HDL this
three on the basis of a majority vote. TMR is used to mitigate can be implemented by using a separate top module file. In
the effects of soft errors occurring in the memory elements the top module file three instances of the code were defined
storing temporary data used during computation, as well as according to the following syntax.
in those storing the configuration bit stream. The technique
may be applied at different levels of abstraction, from the rel #(.N(N)) rel1_A (
whole system to the single component. .reset_ins(reset),
.clk(clk),
.PROX_ins(PROX),

262

Authorized licensed use limited to: AMRITA VISHWA VIDYAPEETHAM AMRITA SCHOOL OF ENGINEERING. Downloaded on April 09,2023 at 08:27:06 UTC from IEEE Xplore. Restrictions apply.
 .HBTNS_ins(HBTNS),
.CBTNS_ins(CBTNS),
.INV1F_ins(INV1F_A),
.INV1R_ins(INV1R_A),
.BRAKE_ins(BRAKE_A)
);

Instance A

I/P Instance B MUX O/P

Instance C
MUX Controller

Figure 5. Proposed reliability improving method

Here „rel‟ is the file name used for the basic code
whereas „rel1_A‟ is one of the instance names. „N‟ is the
Figure 6. Resource usage before triplication
parameter from the basic code which is used to change the
number of floors of the elevator as desired.
After triplication of the code, the design was observed
using one of the Xilinx ISE tools to estimate resource usage
on FPGA tiles. It can be clearly seen that logic triplication
has increased the level of resource usage but still at a
manageable level due to design simplicity.
The results obtained before triplication and after
triplication are shown in Fig. 6 and Fig. 7 respectively.
B. Verification Methodology
To validate the proposed reliability improving method
three vectors were defined as output register values of three
instances. Since the basic code generated three outputs at
each module three number of 4 bit registers were defined as
the output of each instance. The Verilog syntax is given
below.

reg[3:0] machine_A;
reg[3:0] machine_B;
Figure 7. Resource usage for logic triplication
reg[3:0] machine_C;

Then at each of the registers, bit0 is assigned as the

inverter forward signal, bit1 as the inverter reverse signal, bit Then the process was carried out to check the output
2 as the Brake signal and 3rd bit was taken as a manual input register values of each module simultaneously and display if
to generate erroneous output value as shown in Fig. 8. Next, there is an error in those outputs while the system is working
according to the Verilog syntax shown three output vectors with another module. For that, firstly current working
from the instances A, B, and C were generated. module instance is kept at a register value.

always@* if(!fault_detect)
begin case(shift_reg)
machine_A[0] <= INV1F_A; 3'b001 : master_out <= machine_A;
machine_A[1] <= INV1R_A; 3'b010 : master_out <= machine_B;
machine_A[2] <= BRAKE_A; 3'b100 : master_out <= machine_C;
machine_A[3] <= 1; default: master_out <= machine_A;
end
Then the output is checked at real time and if there is an
error, the reg value is shifted to another module with an error
warning signal.
always@*

263

Authorized licensed use limited to: AMRITA VISHWA VIDYAPEETHAM AMRITA SCHOOL OF ENGINEERING. Downloaded on April 09,2023 at 08:27:06 UTC from IEEE Xplore. Restrictions apply.
 case(shift_reg) same time the output would be an erroneous one. Also if the
3'b001:fault_detect=(machine_A!=machine_B) plant failed to give an accurate input (e.g. sensor failure) the
&&(machine_A != machine_C); reliability of the elevator controller is disturbed. Thus this
research creates many fresh ideas in a broad area to develop
3'b010:fault_detect=(machine_B!=machine_A) and modify a reliable FPGA based reconfigurable elevator
&&(machine_B != machine_C); controller.

3'b100:fault_detect=(machine_C!=machine_A) ACKNOWLEDGMENT
&&(machine_C != machine_B); We are very appreciative of the encouragement and
support given us by many people throughout the research.
default: fault_detect = 1'b0; Especially we would like to thank Eng. Ajith
endcase Vidanapathirana from Kandos Chocolates Pvt Limited and
Eng. Asanga Senerath from Airport and Aviation Services
always@(posedge clk) Lanka Limited for helping us and sharing their knowledge
begin with us. We would like to extend our thanks to Eng.Asanga
if (fault_detect) Jayawardhana from Ceylon Biscuits Limited and
fault <= 1; // generate the warning signal Ms.Kanchana Amarasekara, instructor of the Department of
shift_reg <= {shift_reg[1:0],shift_reg[2]}; Electrical and Electronic Engineering for supporting us from
// shift the reg. value at an error the very beginning. We also acknowledge valuable support
end received from Electrical & Electronic Engineering
Department staff.
Error REFERENCES
generating Brake Reverse Forward
[1] Michael D.Ciletti, “Advanced digital design with the VERILOG
bit HDL”, Prentice-hall of India ltd, India
Figure 8. Instance output register [2] H.P.A.P. Jayawardana, H.W.K.M. Amarasekara, P.T.S.
Peelikumbura, W.A.K.C. Jayathilaka, S.G. Abeyaratne, S.D.
Dewasurendra, “ Design and implementation of a statechart based
reconfigurable elevator controller”, International Conference on
Finally the developed code was downloaded to Spartan 3AN Industrial and Information Systems - ICIIS , 2011 IEEE
FPGA for testing and verification. An input switch in the [3] ZHAO Yuhang, MA Muyan, “Implementation of six-layer automatic
development board was assigned to create an error manually elevator controller based on FPGA”, Wireless Communications
in the output bit vector. Also a LED light in the Networking and Mobile Computing (WiCOM), 2010 IEEE
development board was used as the fault indicator. When [4] Karl Schabas, Stephen D. Brown, “Using Logic Duplication to
Improve Performance in FPGAs”, University of Toronto, Toronto,
the plant is connected and run it can be clearly seen that the Canada
moment an error is injected to the working instance, it [5] Brian Pratt, Michael Caffrey, Paul Graham, Keith Morgan, Michael
switches to one of the error free instances, showing Wirthlin, “Improving FPGA Design Robustness with Partial TMR”,
successfully that the design is more reliable than before. Reliability Physics Symposium Proceedings, 2006 IEEE
[6] Cristiana Bolchini, Antonio Miele, Marco D. Santambrogio, “TMR
VI. CONCLUSION and Partial Dynamic Reconfiguration to mitigate SEU faults in
FPGAs”, International Symposium on Defect and Fault-Tolerance in
VLSI Systems-DFT '07, 2007 IEEE
We focused on implementation and verification of a [7] “XILINX Triple Module Redundancy Design Techniques for Virtex
controller for the elevator with basic functions in a FPGAs”, Application Note (Virtex Series)
reconfigurable structure and proposing a methodology to
improve the reliability of the controller. Since the
simulations could be done not only for the prototype elevator APPENDIX
with three floors, but for an elevator with „N‟ number of
The Verilog code developed for the principle operation
floors by simply changing a variable in the code, it was of an elevator with any number of floors is given below.
easier to develop the controller in a general concept.
The verification process which was carried out on a
Spartan 3AN FPGA to a prototype elevator with three floors Module chk2(reset,clk,PROX,HBTNS_U,HBTNS_D,
revealed modifications and developments to be done in later CBTNS,INV1F,INV1R,BRAKE,HLBTNS_D,HLBTNS_U,
work. Special attention needs to be paid to improvements in CLBTNS);
hardware circuits. In addition, further research can be done parameter N=3;
on developing the elevator algorithm for more functions with input clk;
increased efficiency and desirable aspects. input reset;
When considering reliability improving methodology the
controller multiplexes majority output of the instances as the input[N-1:0] PROX;
actual output. If an error occurred in two instances at the input[N-2:0] HBTNS_U;

264

Authorized licensed use limited to: AMRITA VISHWA VIDYAPEETHAM AMRITA SCHOOL OF ENGINEERING. Downloaded on April 09,2023 at 08:27:06 UTC from IEEE Xplore. Restrictions apply.
 input[N-2:0] HBTNS_D; if (!reset) begin
input[N-1:0]CBTNS; PROX_in<= PROX ;
output INV1F; if (PROX_in>0) begin
output INV1R; if (PROX_in==BTNS_in) begin
output BRAKE;
status<= 1;
output [N-2:0]HLBTNS_U;
end
output [N-2:0]HLBTNS_D;
else if (BTNS_in>PROX_in ) begin
output [N-1:0]CLBTNS;
reg [N-1:0] status; status<= 2;
integer i; end
reg[N-1:0]BTNS; else if (BTNS_in<PROX_in&&BTNS_in!=0)
reg[N-1:0]HBTNS_in; begin
reg[N-2:0]HBTNS_U_in; status<= 3;
reg[N-2:0]HBTNS_D_in; end
reg[N-1:0]CBTNS_in; else begin
reg[N-1:0]BTNS_in; status<=0;
reg[N-1:0]PROX_in; end
reg INV1F,INV1R,BRAKE; end
reg [N-2:0]HLBTNS_U; end
reg [N-2:0]HLBTNS_D; always @(posedge clk)
reg [N-1:0]CLBTNS;
if (!reset) begin
always @(posedge clk)
case(status)
if (!reset) begin
HBTNS_U_in=HBTNS_U;
1: begin
HBTNS_D_in=HBTNS_D; INV1F_ins <=0;
HBTNS_in = HBTNS_D_in*2 + HBTNS_U_in ; INV1R_ins <=0;
CBTNS_in = CBTNS ; BRAKE_ins<=0;
if(status==1) begin end
BTNS_in <=0; 2: begin
CLBTNS <=0; INV1F_ins <=1;
HLBTNS_D <=0; BRAKE_ins<=1;
HLBTNS_U <=0;
end
end
3: begin
else begin
INV1R_ins <=1;
BTNS_in<= BTNS;
end BRAKE_ins<=1;
if(HBTNS_in> 0 || CBTNS_in> 0 ) begin end
for (i = 0 ; i < N; i=i+1) begin default: begin
BTNS[i] <= HBTNS_in[i] | CBTNS_in[i] ; INV1F_ins <=0;
HLBTNS_U <= HBTNS_U_in; INV1R_ins <=0;
HLBTNS_D <= HBTNS_D_in ; BRAKE_ins<=0;
CLBTNS <= CBTNS_in; end
end end case
end end
end
end module
always @(posedge clk)

265

Authorized licensed use limited to: AMRITA VISHWA VIDYAPEETHAM AMRITA SCHOOL OF ENGINEERING. Downloaded on April 09,2023 at 08:27:06 UTC from IEEE Xplore. Restrictions apply.