Formal Methods for Higher Reliability of the
Industrial Automation
FrantiSek Zezulka
Bmo University of Technology
Faculty of Electrical Engineering and Communication
Boietzchova 2,612 66 Bmo, Czech Republic
zezulka@feec.vutbr.cz
Pave1 KuEera
Bmo University of Technology
Faculty of Electrical Engineering and Communication
Boietgchova 2,612 66 Bmo, Czech Republic
kucera@feec.vutbr.cz
Abstract- Industrial communication plays an important
role in industrial measurement and control and
particularly in process automation due to trend of
decentralization of control systems. Process automation
generally includes many areas of engineering (HW,
SW, mechanical, chemical ...) therefore close
cooperation between them is necessary. But generally
engineers from different branches use different
descriptions and analyzing tools. Even the same areas
of engineering use different description tools. The
contribution show one of the possible ways how to solve
this problem - using Formal Method. This methodology
is demonstrated on a railway model. Model represents
a typical system of logic control with voltage inputs and
outputs, two different physical interfaces and serial
communication subsystems and two control systems.
Control architecture is designed as a fault tolerant
system 161, what is common in process automation.
Process variables are measured and controlled hy both
control systems (Masters). Two applications run inside
both Master. They ensure basic information exchange
between appropriate Master and Slave station. This
information exchange is based on developed protocol
FTCP (Fault Tolerant Control Protocol) providing
correct behaviour of the system if unexpected event is
-
occurred e.g. disjunction of the control bus, change of
the control signal due to EMI, failing of the control
element due to unexpected design error etc.
1 Introduction to the System Architecture
Complete architecture of the system is shown in Fig. 2. It
consists of 4 main parts:
1. Railway model - senres as physical interface between
human and designed control structure. Model has
approximately 70 inputs and outputs including
signals for switches and fast action sensors. Reader
can find detailed information in [4].
2. Slave Station. This part of the system plays the most
important rule. Slave station ensures interface
between Railway model and Master stations 1 and 2.
This Station also controls Railway model according
to the desired functions.
02003 IEEE
0-7803-7852-0/03/517.00
Zdenek Bradit
Bmo University of Technology
Faculty of Electrical Engineering and Communication
Boietzchova 2,612 66 Bmo, Czech Republic
bradac@feec.vutbr.cz
3. Master station 1 is a PC with RS 422 serial interface.
Station consists of WIN2K operating system,
executable control application (written in C++) and
serial line kernel driver (written in C).
4. Master station 2 is PLC (Siemens S7 300) linked with
Slave station via conventional data bus. Station
consists of discrete YO bus and master control
configuration (written in STL).
2 Goal of the Design
Main idea of the system is to realize a fault tolerant control
of the railway model [2]. Therefore two Master stations are
connected via diametrically different physical interfaces -
serial line (RS 422) and conventional parallel data bus
(app. 200 VO). Two applications run inside both Master.
They ensure basic information exchange between
appropriate Master and Slave station. This information
exchange is based on developed protocol FTCP (Fault
Tolerant Control Protocol) providing correct behaviour of
the system if unexpected event is occurred - e.g.
disjunction of the control bus, change of the control signal
due to EMC, failing of the control element due to
unexpected design error etc.
3 Control Protocol
FTCP is based on fixed information exchange between
Master and Slave station. Fig. 1 shows an example of
slave's response telegram.
Parameters of the physical layer:
Transmission medium: RS422
Baud rate: 57 600 kbps
Data format: Bbits, even parity, I STOP bit
Fig. 1: An example of the slave's response telegram.
891 IClT 2003 - Maribor, Slovenia

I Parallel I/O BUS
Optical isolation
SPYPSI module
Master 1
station
Fig 2 Arcbilechlre of the syslem
Header a code of the slave’s response telegram,
implicitly 55H.
DO lo D5 response data
CS checksum calculated as:
CS = Header @DO @DI 8 0 2 fBD3 @D4 @D5 (1)
4 Verification of the Design
System consists of hardware part (RS 422 drivers, PLC
interface, Parallel data BUS, SPI/PSI modules etc.) and
software part (Applications in CPUs of Slave station and
Masters stations). It is not difficult to describe, design,
analyze and verify electronic and software pad of the
system separately but then we have no guarantee about
implementation, validation and verification of the whole
system [I], [5]. One of appropriate ways to solve the
problem is to use the same prototyping tool (VHDL) for
the software and hardware part of the project.
To describe hardware part of the system by VHDL is
suitable. But if we accept above-mentioned consideration
then we must use VHDL for description of sofhvare
behaviour of the elements as well.
5 VHDL Communication Model
Running of the system is separated into two basic phases -
Initialization and Execution. During Initialization phase
Master station 1 or 2 tries to determine what Master station
will control the system. There are three possibilities -
Master 1 (I), Master 2 (IQ or both (111) control system at
the same time. During Execution phase appropriate Master
station(s) controls system. Header of message from Master
Station to the Slave station is an enumerate type:
type T-MFM is (STOP, INI, TAKE, HAND,
JOIN, REQ, DATA);
892
Conventional
U 0 bus
Slave
station
/
r
station
:ailway
model
STOP During Execution phase master blocks all drives.
This message is not allowed during Initialization
phase.
IN1 During Execution or Initialization phase master
invokeskestarts Initialization phase.
TAKE During Initialization phase master tries to take up
control. During Execution phase this message
invokes Initialization phase.
HAND During Initialization phase master offers control
to the second master. During Execution phase this
message invokes Initialization phase.
JOIN During Initialization phase master tries to
establish join control. During Execution phase
this message invokes Initialization phase.
REQ During Initialisation or Execution phase master
requests data from Slave Station.
DATA During Execution phase master sends data to the
Slave station. This message is not allowed during
Initialization phase.
Communication model is separated into two entities - rail
(behaviour of the Slave station) and test-rail (behaviour
of the Master station). Interface of the entity rail is shown
in Fig. 3; meaning of used signals/variables is explained in
Table 1.
Fig. 3: Interface of the rail entity.
 Table 1:List of signaVvariablesin the interface ofthe RAIL The paper was supported by Ministry of Education, Youth
and Sports by research intents JC MSM 262200012
IName IDirectio I Type I Notice Research of Information and Control Systems, JC MSM
262200022 Research of microelectronic systems and
T-RFM' Message from master 1 technologies, grants FRVS G1/1969/2002, FRVS
T-RFM* Message from master 2 G1/1967/2002, FRVS G1/1955/2002, FRVS
SRTM 1 T_RTM* Message to Master 1 G1/1961/2002. The research was also supported by FEEC,
T-RTM* Message to Master 1 Bmo University of Technology.
bit vector Action values
References
READ In bit-vector Measurementvalues
(47 downto 0)
[I] Douglas, B. P. "Doing Hard Time", Addison Wesley
* user defined types are explained in the Fig. 4. Longman, Inc. Massachusetts 1999, ISBN 0-201-
49837-5.
Entity rail has only one architecture. This architecture
implements slave's state machine in process 101. VHDL [2] Johnson, B.W ,Fault-tolerant microprocessor-based
implementation of this process is presented in Fig. 5a, Fig. systems", IEEE Micro, Vo1.4, No.6, Dec. 1984.
5b. [3] KuEera P., Zezuka F., Svtda M., Vrba R.: Executable
Entity test-rail stimulate entity rail by desired signals firom specification for Process Automation and
user-defined tile. Process of testing is out of scope of this Microelectronics, In: IEEE TC-ECBS and FE'
paper; therefore a list of this entity is not included. WG1O.l Joint Workshop on Formal Specifications of
Computer-Based Systems, Lund, SE, US, 2002, p.
6 Conclusion 91-98, ISBN 1-85769-169-5.
[4] KuEera P.: Fault tolerant design of control In
This paper presents a possibility how to describe s o h a r e IWCIT'OI . International Workshop Control F d
part of the communication system by the hardware Information Technology, IWCIT'OI Ostrava: VSB
description tool (VHDL). The effort is retumed by fact, Ostrava, 2001, s. 149-154, ISBN 80-7078-907-7.
that we can simulate and validate whole system by one [5] Craigen, D., Gerhari S., Ralston T., "An International
simulation tool as is unique. Complete description of Survey of Industrial Applications of Formal
created formal model is out of scope of this paper. In the Methods," Volume 1 Purpose, Approach, Analysis
case of interest, do not hesitate to contact author for and Conclusions; Volume 2 Case Studies NIST GCR
detailed information. And of course, our communication 931626, March 1993.
model is only the fust approximation of the reality because
many things had to be simplified or omitted. [6] MachPEek Z., Kotzian J., Srovnal V.: Digital Signal
Processors in real-time application for diagnostic. In:
Proceeding International Workshop IWCIT'03.
Acknowledgement Silesian University of Technology, Gliwice 2003,
ISBN 83-908409-7-9, pp.143-148
This paper is based on author's experiences with previous
work consisting of formal description of another system

,.
hme T MFM is (STOP. N. TAKE. HAND. IOW.. REO. DATA): ._
'ype T ~ M T Mis &.ROR, ION
DATA, ACK);
'ypeT-IOSTATE is (NONE, MIM2,M2MI,MIJOIN,M2IOIN,MICNTRL,
M2CNTRL, MIMZCNTRL);
subtype T-BYTE is bit-vector (7 downto 0);
constant ACKINI: bit-vector (47 downto 0) := X"AA0000000000";
constant ACKTAKE bit vector (47 downto 0) := XBB0000000000":
constant ACKHAND: bicvector(47 downto 0) := XCCOOOOOOOOOo'~;
constant ACKJOIN: bit-vector (47 dawnto 0) :=XDD0000000000";
constant ACKSTOP bit-vector (47 downto 0) := XEEOOOOW0000";
constant ACKDATA: bit-vector (47 downto 0) := X"FF0000000000";
type T_WM is
record
MESSAGE: 1-MFM
DATA: bit_veetar (3 I downto 0);
C R C T-BYTE;
end record;
'ype T-RTM is

end record:

Fig 4 List of the defmcd types.

893
architecturerail ofrail is
signal EBMI, EBM2 : boolean :=false; -- Error flag of Master 1 and 2 BUS
shared variable STATE: T-IOSTATE; -- State of Slave station
shared variable L-ACTION: bit-vector (31 downto 0);
shared variable RTMI: T-RTM; --Temporal message lo Master I
shared variable RTMZ T-RM: --Temporal message lo Master 2

begin
101: process(RFM1 ,EBMI)-- Process ensues infomation exchange between Master 1 Station and Slave station

iG not EBM 1) then

caseRFMI.MESSAGE is
when MI => R G L M E S S A G E := ACK;
RTMI.CRC := CRC(ACKIN1);
RTMI.DATA := ACKlNI;
state :=NONE;
when REO => RTMI.MESSAGE :=DATA:
RTMl.CRC := CRC(READ);
RTMI .DATA := READ;
when TAKE => if (STATE = NONE or STATE = M?.MI) then
state := MICNTRL,
RTMIMESSAGE := A C K
RTMI.CRC := CRC(ACKTAKE);
RTMI.DATA := ACKTAKE;
else state :=NONE
end if:
when HAND => if(STATE = NONE) then
state :=MIM2;
RTMI.MESSAGE := ACK;
RTMI.CRC := CRCIACKHAND):
RTMI.DATA := ACKHAND;
else state :=NONE;
end is
when JOW => if (STATE = MJOIN) then
state := MIM2CNTF.L;
RTM1.MESSAGE := ACK;
RTMICRC := CRC(ACKJ0N);
RTMI.DATA := ACKJOM,
else RTM2.MESSAGE :=JOIN;
state := MI JOIN,
end if;
when othen => assert true
report "Muter 1 incorrect action during initialization"
severity error;
end case; --Master I message sewice
+se
assert true
report "MASTER 1 BUS ERROR
severity e m r ;
end if; -- Branch JOIN
else
i f ( EBMI ) then stltc :=NONE;
else

Fig Sa: VHDL implcmenution

894
 case STATE is
whenMlCNTRL=>caseRFMI.MESSAGEis
when STOP => L-ACTION := XOOOOOOOO";
RTMl .MESSAGE := ACK;
R T M K R C := CRC(ACKST0PY
TMl D A T A '=PICKS'

lMI.DATA :=ACKlNI;
state :=NONE:
when TAKE I HAND I JOIN => state :=NONE:
n h c n K t Q - i K I M 1 MESS.40E=Df\1A;
RTMI CRC CRC(KEAD],
~

RTMI DATA - Rt.\U;

u l r n DAT.\ -> 1. .AC'TIOU - RF\II DATA,
RThll.WESSAGE = A C K ,
K T h l I CRC .- CRCII\CKDATA).
RTMI.DATA := A C ~ D A T A ; ' '
when others => msert me
report "IMFMaster 1 - ACTION
Se"Crity error;
end case;
when MZCNTRL => usen true
report "Master 2 has not access right."
severiw error:
whcnMIM2CN&=>if(RFMI.DATA= RFM2.DATA)lhen
L-ACTION := RFMl .DATA;
KTM2.MESSAGE := ACK;
RTMl .MESSAGE := ACK;
RTM2.CRC := CRC(ACKDATA);
R T M K R C :=CR(
:= CRCfACKDATA):
RTM2.DATA := ACKDATA; '.
RTMI .DATA := ACKDATA:
else
assert uue
report "Maslerl b Master2 - ACTION
severity note;
end i t
when others => assert true
report "incorrect STATE during ACTION"
severity failure;
end case;--State machine
end if; -ERROR decision
end i t --Main decision
endpmess 101;
-
-- process 102 definition has the same StNCNre like 101 and is omitted

EBMl<= m e when RFMl .CRC I= CRC(RFMI .DATA) else

false;
EBM2 <= tlue when RFM2.CRC I= CRC(RFM2.DATA) else
falsc;
ACTION <= L-ACTION;
SRTMl <=RTMI:
SRTM2 <= R T M i
ST <= STATE;
end rail;

Fig 5b: Continue of VHDL implementation.

895