See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/224909540

Statechart Based Modeling and Controller Implementation of Complex

Reactive Systems

Conference Paper · August 2011

DOI: 10.1109/ICIINFS.2011.6038120

CITATIONS READS

8 950

3 authors:

A.C. Vidanapathirana Shirley Devapriya Dewasurendra

UOP University of Peradeniya - retired
6 PUBLICATIONS 27 CITATIONS 48 PUBLICATIONS 132 CITATIONS

SEE PROFILE SEE PROFILE

Sunil Gamini Abeyratne

University of Peradeniya
98 PUBLICATIONS 394 CITATIONS

SEE PROFILE

All content following this page was uploaded by Sunil Gamini Abeyratne on 02 January 2015.

The user has requested enhancement of the downloaded file.

 Design and Implementation of a Statechart Based
Reconfigurable Elevator Controller
H.P.A.P. Jayawardana, Student Member, IEEE, H.W.K.M. Amarasekara, Student Member, IEEE,
P.T.S. Peelikumbura, W.A.K.C. Jayathilaka, S.G. Abeyaratne, Member, IEEE and S.D. Dewasurendra

Abstract- This paper presents a simple and clear method to with some specified inputs and outputs, can be implemented
design and implement a reconfigurable elevator controller using simply by changing a variable N corresponding to number of
an FPGA, which can be implemented for an elevator with any
(N) number of floors, with specified inputs and outputs. A model floors.
based design approach was followed. We started from a state When designing controls for any event driven, complex
chart model developed for a prototype elevator with three floors. reactive systems, development of a method for formal
Extension of the model for a variable number of floors was specification of the control at the initial stage facilitates easy
considered. Controller for the prototype system was implementation in later stages. Therefore such an approach is
implemented in ladder logic on a PLC and the limitations of that
approach with regard to re-configurability were identified: viz., essential in developing controls for a system like the elevator
in the extension of elevator controller for ‘N’ no of floors. Next which has a fairly large number of sensors and which needs
VHDL code was developed for a reconfigurable elevator to continuously react to several inputs. This becomes more
controller where, by changing a variable corresponding to the pronounced for systems with large numbers of floors, for the
required number of floors, the suitable code can be generated. added complexity. Therefore, this elevator controller was also
The controller thus generated can be implemented in an FPGA.
The method was successfully tested on a Xilinx Spartan 3AN developed using a model based design approach, in which a
FPGA. statechart model was developed for the prototype elevator at
the initial stage. A verification of the design can also be done
Index Terms- Elevator, FPGA, PLC, Reconfigurable, State at the development stage with this approach.
Chart, VHDL
The objectives of the research presented in the current
I. INTRODUCTION paper are:
1. Demonstrate the development of a statechart model for
In control and automation industry, Programmable Logic
the prototype elevator that permits extension of the model for
Controllers (PLCs) are commonly used to implement controls
‘N’ number of floors and simulate in MATLAB SIMULINK
for complex reactive systems, primarily because of their easy
STATEFLOW, to validate the architecture.
programming environments based on IEC-61131-3. However,
2. Implementation of a controller for the prototype system
they are meant for sequential event processing and not for
using a Programmable Logic Controller (PLC) and
hard real-time reactive environments which require parallel
development of a methodology to extend the controller for
processing capabilities. In contrast, Field Programmable Gate
any number of floors in a user friendly manner: using IEC-
Arrays (FPGAs), which are inherently parallel, can be used to
61131-3 languages.
develop controls for more complex systems with large
3. Validate the reconfigurable design process through
number of inputs and outputs. In addition to reconfigurability,
implementation of the reconfigurable controller using a
it consumes less power and it can provide comparatively low
FPGA in a convenient and user friendly approach: with
response times and flexibility in expansion of designs.
VHDL (IEC 61691) as the HDL.
This paper presents the work carried out to design and
implement a reconfigurable elevator controller, which can be
implemented for an elevator with any number of floors (N) in II. DEVELOPMENT OF PROPOSED STATECHART MODEL
a simple and user friendly manner. With this design, which A. Statechart Design
was implemented using a Field Programmable Gate Array a Following our model based design approach, at the initial
controller suitable for an elevator with any number of floors, stage we developed a state chart model for the prototype
elevator and simulated it with MATLAB SIMULINK
H.P.A.P. Jayawardana, H.W.K.M. Amarasekara, P.T.S. Peelikumbura,
and W.A.K.C. Jayathilaka are final year undergraduates in the Department of
STATEFLOW, which permitted us to verify the design at the
Electrical, Electronic Engineering, Faculty of Engineering, University of development stage, before going for costly and time
Peradeniya, Sri Lanka. consuming hardware implementation. With that simulation,
Dr. S.G. Abeyaratne is a Senior Lecturer in the department of Electrical,
which clearly indicates the state transitions of the system, it
Electronic Engineering, Faculty of Engineering, University of Peradeniya,
Sri Lanka was easy to identify the system behavior. Thereafter, we
Dr. S.D. Dewasurendra, MIMechE is a Senior Lecturer in the department investigated the extension of this model to ‘N’ no of floors so
of Computer Engineering, Faculty of Engineering, University of Peradeniya, that the behavior of such system could be understood clearly.
Sri Lanka.

978-1-61284-0035-4/11/$26.00 ©2011 IEEE

 In designing the state chart model for the prototype
elevator, we mainly identified four main components of it.
Considering those, we basically identify three orthogonal sub
states of the system namely; Inputs, Car and Lights. After
that, the total system was divided into sub states with AND or
OR decompositions, considering their behaviors as shown in
Fig.1. The relevant state transitions were applied with
appropriate conditions and simulated. State chart diagrams for
three main sub states with their state transitions are shown in
the Fig.2, Fig.3 and Fig.4.
Reference [1] clearly illustrates basics of the state chart.
Although methods of modeling elevators using state charts
are presented in recent work, the proposed method in this
paper has reduced number of states and the model is error
free as it is simulated with relevant transition conditions [2].

B. Extension of the Statechart Model

With the simulation of state chart model explained in
Fig 2. State Transitions of Input Sub State
section A, it was easy to identify the system behavior. In our
study on expansion of the model to an elevator with N no of
floors, we identified that the state configurations of Inputs
and Lights sub states only needed to be changed, while state
configuration of Car sub state could remain the same.
However, it was not possible to extend the simulation for N
no of floors. But, with this study we were able to identity how
the conditions for state transition should be adjusted and it
helps us to identify the logic behind expansion of the
controller.

III. HARDWARE FOR CONTROLLER IMPLEMENTATION

Prototype elevator, for which the controllers were
implemented, consists of 3 floors as shown in Fig 5. For any
controller used for this elevator gets inputs from 3 proximity
sensors, 2 limit switches, push button inputs (Hall Call
Buttons and Car Call Buttons) and 3 door position sensors.
To drive the elevator car it is needed to provide 2 control
outputs to main inverter as inputs to the inverter which can Fig 3: State Transitions of Car Sub State
drive the main induction motor to forward and reverse
direction. In the same time it is needed to release the electric
brake activating a solenoid to provide 3 control signals for
another inverter. Therefore each controller design was based
on the coordination of these inputs/ outputs.

Fig 4: State Transitions of Light Sub State

Fig 1: Division of Systems into States
 Fig 6: Ladder Diagrams for Forward Motion

P- Proximity Sensor Inputs

H-Hall Call Button Inputs
C-Car Call Button Inputs
D-Door Sensor Inputs
L-Limit Switch Inputs

Fig 5: Overview of the Prototype Elevator

IV. CONTROLLER DEVELOPMENT WITH PLC Fig 7: Ladder for Overall System Forward Motion
A. Implementation of a controller for the prototype elevator
As most real time systems are commonly implemented B. Extension of the Controller for ‘N’ no of Floors
using PLCs, in the first stage of our work we tried to develop After implementation of the controller for prototype
the controller using a PLC. For that we used, elevator, we studied about extension of the controller for an
TWDLCDE40DRF Telemachanique PLC. Initially we tried elevator with any number of floors. For that we will consider
to develop a controller for the prototype elevator using ladder the following inputs;
diagrams. We identified that we have to basically develop ƒ Car Buttons : CCB0,CCB1,…CCB(N-1)
two kinds of ladder diagrams for the forward and reverse ƒ Hall Call Buttons:
motion of the elevator car, in addition to other features like HCB0U,HCB1D,HCB1U,…..,HCB(N-1)D
door and lights. ƒ Proximity Sensor Inputs:
To illustrate the logic behind that, let us consider the ladder PROX0,PROX1,…….,PROX(N-1)
diagrams we developed for the forward motion of the Similar to the way that we developed the ladders for
prototype elevator. As shown in Fig 6, we develop a separate prototype elevator, we have to basically consider forward and
rung for forward motion from floor0 to floor1, and another reverse motion of the car.
for forward motion from floor 0 to floor2 and floor1 to floor2. To illustrate the method for extension, let us again consider
According to the motion required by the passenger, a memory the forward motion. Similar to the method for prototype
bit is set and all those outputs are considered for overall elevator, two types of ladders has to be developed.
system forward motion of the car as shown in the ladder As shown in the Fig 8, a separate ladder diagram is needed
shown in Fig 7. Similarly, we have to develop sixteen rungs for the forward motion to (N-1) floor. In addition, (N-2) no
for the development of a controller for prototype elevator of ladder diagrams have to be drawn for the forward motion
with three floors. We programmed the PLC using the to floor 1,….,(N-2), as shown in Fig 9. At the same time,
developed ladder program and we successfully implemented overall system Ladder has to be edited as shown in Fig 10.
the controller.
 floors. We can accomplish that task in a simple way using an
FPGA. In addition to its reconfigurablity, FPGAs also
provide reduced response times and flexibility in expansion.

V. IMPLEMENTATION OF A RECONFIGURABLE
CONTROLLER FOR AN ELEVATOR WITH ‘N’ NO OF FLOORS

With PLC’s we have to use separate input/output cards

with increasing of no of input/outputs. The power
consumption is also considerably high when compared to
FPGA’s. Also programming a FPGA using VHDL or Verilog
is very descriptive and can be spread for a wider range of
Fig 8: Ladder Diagram for Forward Motion to (N-1) Floor concepts or logics in programming rather than trying the
For X= 1 to (N-2)
same logic in PLC’s using ladder diagrams or sequential
function charts. Therefore this program which is used for a
controller of an elevator with ‘N’ number of floors was
implemented using VHDL for an FPGA.
Our main aim was to obtain a program where we can
simply change the no of floors and achieve the required
performance: i.e., the program will automatically generate
inputs outputs. Fig 11 shows the logic behind the
corresponding code.
Unlike in the PLC, FPGAs have inputs/outputs that we can
even use as bit vectors in programming directly. We use this
property to develop the program.
Fig 9: (N-2) No of Ladder Diagrams for Forward Motion to Floor1,.., (N-2)
The logic behind this was input data vectors. In this
program we define data vectors containing bits equal to
number of floors: these vectors will be generated
automatically when the number of floors is given.
Eg.: If number of floors is 3 an input vector will be ‘000’
Here in this program we define three input data vectors as
follows;
Proximity sensor inputs
Car call button inputs
Hall call button inputs
PROX: in std_logic_vector (n-1 downto 0);
Fig 10: Ladder Diagram for Forward Motion
HCBTNS: in std_logic_vector (n-1 downto 0);
CCBTNS: in std_logic_vector (n-1 downto 0);
Even though, we can draw the ladder diagram Then we generate a common vector as a variable for hall
corresponding to a controller for an elevator with N no of call buttons and car call buttons using bitwise OR operation
floors using the explained method, as the no of floors since whatever the button inputs, it should be a calling
increases the ladder diagrams become more complex. command for the elevator car.
This is because, according to the explanation given above, variable BTNS: std_logic_vector (n-1 downto 0);
we need to draw more than 2N no of ladder diagrams for that. for i in 0 to n-1 loop
PLC ladder programming does not provide support to BTNS (i) := HCBTNS_in(i) or CCBTNS_in(i);
simplify the design in any clear way. Otherwise, we could end loop;
have developed a method to adjust the programs accordingly, Then what we took into account was the comparison of two
when the number of floors changes, as will be shown to be bit vectors because by comparing those two vectors we can
possible with FPGAs (in section V). Therefore, if we follow simply define the direction to the elevator car.
this method, we have to manually construct the ladder Eg.: Assume elevator car is at Floor 0 and then the
diagrams as explained above, draw them with the relevant proximity sensor input from floor no 0 is ‘1’ then the
software for the PLC and program the controllers proximity input data vector will be ‘001’.
individually, as required for each elevator with a particular When a person comes to Floor 2 and presses the hall call
number of floors. This May be very Difficult for an elevator button of floor 2 then hall call button input vector will be
with large no of floors. Therefore, we need to find a simple ‘100’ and car call button input vector will be ‘000’ and the
method to develop a controller for an elevator with ’N’ no of common vector will be (after OR operation) ‘100’ .Then we
 VI. RESULTS
A state chart model for the prototype elevator was
developed and simulated by applying suitable transition
conditions. Although, we could identify how it should be
extended for an elevator with ’N’ floors and how the relevant
transition conditions should be changed, we couldn’t extend
the simulation for that, as the software does not support
simulation of such a generalized model.
Limitations in implementing a complex system with large
number of inputs with conventional PLCs were illustrated
with the extension of developed PLC based elevator
controller.
A reconfigurable elevator controller, which can be
implemented for an elevator with ‘N’ number of floors with
defined specifications was designed and implemented using
an FPGA. It was simply achieved by changing a variable
corresponding to the required number of floors in the VHDL
code developed for the controller. In this research, we only
study about how the extension of basic movements of the
elevator can be extended for an elevator with ‘N’ floors. The
feasibility of the developed reconfigurable elevator controller
was successfully tested with the FPGA board.
In this approach we could identify three main stages,
designing the controller using state charts, using a PLC and
using a FPGA, going through some kind of verification
process in each stage: see [4] and [5] for some details in
verification of statechart based controllers.

VII. CONCLUSION
We could only simulate the state chart model that we have
developed for the prototype elevator. If the simulation can be
extended for ‘N’ no of floors, the controller development in
later stages may be very much easier. In addition, further
Fig 11. Logic of VHDL Code Development for reconfigurable Controller.
research can be done on formal verification of these models.
compare the proximity sensor input vector and common In our controller implementation with PLC and study on
vector for button inputs. feasibility for extension, we only tried it with Ladder
diagrams. But further research can be done on
Proximity sensor input vector – ‘001’ implementation of it using some other PLC programming
Proximity sensor input vector – ‘001’ languages such as Sequential Function Charts.(SFC).
Button input vector - ‘100’ In this research, we focus only on the extension of basic
In order to compare these vectors we convert these binary functions of the elevator with a reconfigurable controller. But,
vectors to integers and then compare the integer values if this is going to be implemented for a particular elevator
assigning them into variables which can be updated with the with some additional features the code has to be edited to suit
changing of proximity sensor input vector when moving the them, extending the method proposed in this paper for basic
elevator car. features.
B <= conv_integer (BTNS_in); This effort was mainly aimed for the design of the
P := conv_integer (PROX_in); controller when number of floors goes to ‘N’, but there is still
space for research on how hardware configurations and
Let’s go back to the example if the proximity sensor input limitations should be varied when the number of floors goes
vector is ‘001’ then P will be 1 and since button input vector to ‘N’.
is ‘100’ , B will be 4. Then we use the program and give the
output for moving forward in order to make P = B and to stop
the car.
 ACKNOWLEDGMENT HCBTNS_in := HCBTNS ;
CCBTNS_in := CCBTNS ;
We acknowledge with gratitude the Peradeniya University
for i in 0 to n-1 loop
Research Grant RG/2006/32/E awarded by University of
BTNS(i) := HCBTNS_in(i) or CCBTNS_in(i);
Peradeniya as seed money for building the elevator system,
end loop;
the help received from Electrical & Electronic Engineering
BTNS_in := BTNS;
staff and Sub-warden of Ramanathan Hall of Residence, the
B <= conv_integer(BTNS_in);
numerous helps extended by colleagues from CECB and
end if;
Schneider Electric Co. Ltd. We also acknowledge valuable
end if;
discussions with PhD student Mr. A.C. Vidanapathirana who
if status=1 then
works on formal verification/validation of the elevator control
B<=0;
system.
end if;
REFERENCES end process;
process(clk,PROX)
[1] D. Harel,” Statecharts: A Visual Formalism for Complex Systems”, variable PROX_in:std_logic_vector (n-1 downto 0);
Science of Computer Programming, vol. 8, (3), pp.231-274, 1987.
[2] Y-S. Huang, S-L. Chung, and M-D. Jeng ,”Modeling and Control of variable P:integer range 0 to 100 ;
Elevators by Statecharts”, Asian Journal of Control,Vol. 6, No. 2, pp. begin
242-252, June 2004 if (clk'event and clk='1') then
[3] V. A. Pedroni, “Circuit Design With VHDL”, MIT Press Cambridge,
2004 if PROX>0 then
[4] P. Bhaduri and S. Ramesh, “Model checking of statechart models: PROX_in := PROX ;
survey and research directions”, ArXiv Computer Science e-prints, July P := conv_integer(PROX_in);
2004.
[5] D. Dewasurendra, “Statecharts for Reconfigurable Modular Control of if (P=B) then
Complex Reactive Systems: a new formal verification methodology”, status<= 1;
in Proceedings of ICIIS 2006, Peradeniya, Sri Lanka, August 2006. elsif (B>P and B/=0)then
status <= 2;
APPENDIX elsif (B<P and B/=0) then
status <= 3;
Total VHDL program developed for an elevator with ‘N’ no else
of floors is as follows. status <=0;
end if;
entity n_floor is end if;
generic (n : integer := 3); end if;
port( end process;
PROX:in std_logic_vector(n-1 downto 0); process(clk)
HCBTNS:in std_logic_vector(n-1 downto 0); begin
CCBTNS:in std_logic_vector(n-1 downto 0); if clk'event and clk='1' then
INV1F : out std_logic; case status is
INV1R : out std_logic; when 1 =>
BRAKE : out std_logic; INV1F <='0';
clk : in std_logic); INV1R <='0';
end n_floor; BRAKE <='0';
when 2 =>
architecture Behavioral of n_floor is INV1F <='1';
signal status : integer range 0 to 20; BRAKE <='1';
signal B : integer range 0 to 100 ; when 3 =>
begin INV1R <='1';
BRAKE <='1';
process(clk,HCBTNS,CCBTNS) when others =>
variable BTNS:std_logic_vector(n-1 downto 0); INV1F <='0';
variable HCBTNS_in:std_logic_vector(n-1 downto 0); INV1R <='0';
variable CCBTNS_in:std_logic_vector(n-1 downto 0); BRAKE <='0';
variable BTNS_in:std_logic_vector(n-1 downto 0); end case;
begin end if;
if (clk'event and clk='1') then end process;
if ( HCBTNS > 0 or CCBTNS > 0 ) then end Behavioral;

View publication stats