Anda di halaman 1dari 7

On the automatic generation of timed automata models from ISA 5.

2 diagrams
Luiz Paulo de Assis Barbosa, Kyller Gorg onio,
Antonio Marcus Nogueira Lima, Angelo Perkusich
Federal University of Campina Grande
Embedded Systems and Pervasive Computing Lab.
Campina Grande, Paraba, Brazil
{luizpaulo,kyller,amnlima,perkusic}@dee.ufcg.edu.br
Leandro Dias da Silva
Paraba State University
Mathematics, Statistics and Computation Department
Campina Grande, Paraba, Brazil
leandro@dee.ufcg.edu.br
Abstract
Safety Instrumented Systems (SIS) are usually designed
to prevent accidents, avoid undesirable situations and
guarantee continuous operation of oil and gas production
systems. An interruption in the operation can be caused
by faults in sensors and/or actuators. Hence, SIS are usu-
ally integrated to the supervisory control system in order
to use the information from sensors to prevent such unde-
sirable situations. In this scenario, it is important to be
able to validate the SIS implementation against its spec-
ication in order to increase the reliability of the system.
In this work a technique to improve the dependability of
SIS is introduced. A method to obtain a timed automata
from a ISA 5.2 specication is presented and applied to a
case study provided by Petrobras (Brazilian oil company).
Finally, an approach to perform automatic testing of the
implementation using the generated model is discussed.
The method introduced here is based on the use of the Up-
paal model checker and the Uppaal-TRON testing tool.
1. Introduction
In the context of oil and gas operation it is necessary
to use safety systems to prevent accidents and undesirable
situations. The continuous operation of such systems is
essential to prevent accidents without interrupting the pro-
duction line. The operation interruption can be caused by
sensors and actuators fault, safety logic executors or it can
be related to errors in the execution logic. Moreover, un-
der some situations the developed systemcan behave in an
inadequate way due to system components dimensioning
errors.
Safety Instrumented Systems (SIS) [7, 8] are important
in the operation of oil and gas plants when executing auto-
matic procedures or under the intervention of human op-
erators. These systems are usually integrated to the super-
visory control system and use the information collected
fromsensors and, based on the process state, they use eld
devices to prevent undesirable situations.
In Figure 1 the development scenario for SIS is illus-
trated. Firstly the company generates a set of require-
ments that is given in form of cause/effect matrices and
some additional text explaining things not present in the
table. Then a third part software company produces the
ISA 5.2 binary logic diagrams [12] from the matrices to
conclude the specication. Once the specication is com-
pleted, the SIS can be developed using some of the IEC
61131-3 language [13], this is also done by a third part
company. Finally, the IEC program is compiled to run in
a certain Programmable Logic Controller (PLC). Observe
that the oil company has no formal guarantee that the nal
implementation corresponds to its original specication.
Even considering the fact that there is an important phase
of acceptance tests, the main guarantee that the code run-
ning in the PLC implements correctly the specication is
the trust in the companies developing intermediary arti-
facts.
Considering this scenario it is important to make use of
tools to validate the safety logic in operation or being de-
veloped. For example, it is interesting to dispose of testing
tools for that are able to automatically test if the control
system running behaves as expected.
In this work a technique to improve the dependability
of SIS is presented. The technique is based on the use
of timed automata [1] and a conformance testing tool for
timed automata in order to improve the quality of con-
trol programs running on PLCs. The approach consists
in the generation of timed automata model from the logic
Figure 1. PLC development process
diagrams in order to test its behavior against a real imple-
mentation. To achieve this, some tools are used:
1. Uppaal [3] for edition, simulation and verication
2. Uppaal-TRON [14] for automatic test cases genera-
tion and execution
3. An automatic generator of timed automata models
from ISA 5.2 specications developed by the authors
4. A TRON adapter to test a model against another
model also developed by the authors
The paper focus on the generation of such timed au-
tomata model and a case study provided by the Brazil-
ian oil company (Petrobras) was used to validate our tech-
nique. Additionally, some tools to automate this process
were developed.
The rest of the paper is organized as follows. In Sec-
tion 2 related work is discussed. In Section 3 the test-
ing technique introduced here is presented in more de-
tails. Section 4 describes the timed automata generation
procedure. Finally, the conclusions and future works are
discussed in Section 5 .
2. Related work
This section introduces existing approaches for mod-
eling control programs described using the IEC 61131-
3 languages. These approaches includes methods for the
verication of control programs described in:
1. Instruction list
2. Ladder diagrams
3. Function block diagrams
In [4] programs written in Instructions List (IL) are
translated into a communication automata that can be for-
mally veried. The formal semantics for a subset of the
IL language is proposed and a direct coding of this seman-
tics into a model checking tool and behavioral properties
are described in LTL. In [15] IL programs are modeled
as timed automata but only Boolean variables are consid-
ered. Also, in [10] a Petri net (PN) [18] semantics for IL
programs is presented, and a method to translate a PLC
controller into a PN model is described.
The automated verication of Ladder Diagrams (LD) is
proposed in [19]. The control programs are translated into
nite automata that can be veried sing the SMV model
checker [16]. Translation of LD programs in PNs is also
discussed in [9] with LD operators modeled by a PNstruc-
ture and the control specication is simulated with the PN.
In [17] safety and operability properties of PLCs are ver-
ied. The method consists of a system model, assertions,
and a model checker that veries if the system model sat-
ises the assertions.
In [2], Function Block Diagrams (FBD) are modeled
as High Level Timed Petri nets (HLTPN) [6] by a set of
tools called PLCTOOLS. It uses differential equations for
modeling the plant, FBDs for designing the controller and
HLTPN to validate the design and generate the source
code. A more detailed discussion about verication of
control programs can be found in [20].
Unlike the related work discussed above, this paper is
not focused on the formal verication of control programs.
The main motivation of the current work is to be able to
performautomatic test of a control program. More specif-
ically, the goal is to test a given control program imple-
mentation is correct with respect to its specication. The
specication, which is described by binary logic diagrams
according to the ISA 5.2 [12] document, is automatically
translated into a timed automata model that is described
using Uppaal [3]. Then, Uppaal-TRON [14] is used to
test if the execution traces of the implementation are in
conformance with the traces of the specication model.
3. Methodology
This work is bounded by the scenario illustrated in Fig-
ure 1, in which the development process of SIS is intro-
duced. In other words, the scope of our work is to improve
the dependability of the nal product without interfering
in the process itself.
As stated before, the main goal is to guarantee that
the control program running in a PLC behaves as speci-
ed. This scenario is illustrated in Figure 2. The inputs
for the technique are the specication of the control pro-
gram, its implementation and a description of the execu-
2
Figure 2. Methodology
tion environment. Firstly, a timed automata is extracted
from the specication. Secondly, another timed automata
is extracted from the PLC program. Observe that in the
generation of the timed models, the description of the en-
vironment should be considered. At the moment we con-
sider the environment to be more permissive as possible,
i.e. each input variable can assume any Boolean value
non-deterministically.
Note that in Figure 2 the original development process
is preserved. The actions indicated by the gray arcs are
in accordance with the scenario dened in Figure 1 and
the development of the control program is done as usual.
The actions of the testing methodology introduced here
are indicated by the black arcs. Specically, the gener-
ation of timed automata model for ISA 5.2 diagrams and
IEC 61131-3 programs are illustrated. Also, the test of the
control program against its specication is highlighted.
The automata generation has an intermediary step that
is the translation of the inputs to an XML representation.
By using the XML representation the technique is plat-
form independent. It is only necessary to export the input
diagrams for the correct XML schema. In the best case,
in which different manufacturers have their own imple-
mentation of a certain language (e.g. Ladder), it is only
necessary to implement the translation from the language
to the XML. In the worst case, in which is necessary to
support another language, it is also needed to implement
a new timed automata generator.
In this work, the input is given by an ISA 5.2 specica-
tion and some IEC 61131-3 implementation. They were
chosen due to the fact that they are the languages used at
Petrobras. However, the methodology is designed to be
easily extended.
After obtaining the timed automata models, the test-
ing tool TRON is used to validate the Implementation Un-
der Test (IUT) against the specication. More specically,
TRON is used to generate a set of traces using the spec-
ication automata that are used to test the IUT automata.
Each trace is formed by a sequence of input and output
events. Each input event in the trace generates an event to
the IUT in order to observe its response for a given stim-
uli. If the output from the IUT is in conformance with the
output from the specication then the test was successful.
Otherwise, the test fails.
Another possibility that needs to be explored is to di-
rectly test the implementation through the use of OLE for
Process Control (OPC). Directly testing the PLC has the
advantage that no errors were introduced during the trans-
formation step. Moreover, sometimes engineers modify
the machine code running into the PLC without modify-
ing the original FBD or Ladder program. Hence, the only
possible way to test the PLC against the specication is
through OPC. However, in this case it is not possible to
use logical time. Instead, real-time should be used and the
tests will take much more time to conclude.
3.1. Uppaal and TRON
Timed automata [1, 11] are nite state machines ex-
tended with clock variables. Uppaal [3] is an environment
for edition, simulation and verication of real-time sys-
tems modeled as a timed automata. In Uppaal a model
is given by a network of timed automata that is obtained
by combining one or more timed automata together. A
state is dened according the localities, the clock restric-
tions and the values of discrete variables, and every time
an action is executed, a new state is reached.
In the network, each automata can be executed alone or
synchronized with another automata. Such synchroniza-
tion occurs through the use of communication channels in
which of automata writes on the channel at the same time
3
the another reads from it. Broadcast channels are also al-
lowed. Verication is done using its own model checker,
and sub-set of the CTL temporal logic [5] used as speci-
cation language.
Uppaal-TRON [14], or simply TRON, is a Uppaal-
based tool used to perform conformance tests in timed
system. Test cases are generated and executed at the same
time event by event. TRON works as a replacement of the
environment of an IUT by generating events and monitor-
ing. The idea is that for a certain input, the IUT should
react as the specication.
TRON provides an Application Program Interface
(API) to allow communication between Uppaal timed
models and IUT, remember that the IUT can be a real im-
plementation. In this way, the developer needs to write
an adapter to communicate both artifacts using such API.
This is what makes possible to connect physical events
of the IUT with logical events of the timed automata.
Adapters can be build using UNIX standard I/O mecha-
nisms or TCP/IP sockets. Also, GNU C and Microsoft
Visual C APIs are available.
4 From ISA 5.2 to timed automata
ISA 5.2 is a standard that provides symbols for stan-
dard PLC functional blocks. The main symbols are the
logic AND, OR and NOT operators, SR ip-op with set
or reset priority, and time elements. The time elements are
Delay Initialization of output (DI), Delay Termination of
output (DT) and Pulse Output (PO).
The operation of the basic logic functions are trivial
and not explained here. The SR ip-op output exists if
S exists and do not exists if R exists. The priority in S
or R denes the output regardless the value of the other
input. The DI output exists if the input exists for at least
a given interval of time t and terminates when the input
terminates. The DT output exists immediately when the
input exists and terminates when the input has terminated
and has not again existed for time t. The output of PO
exists immediately when the input exists and terminates
after time t.
A typical specication of a control system is illus-
trated on Figure 3. The common elements used on binary
logic diagrams can be identied: OR, AND, SR ip-op,
DI (and respective time delay given by T1 and T2), in-
puts (HS), outputs (XA) and logical connectors to other
diagrams of the same control program (HEADER, SD-
GENERAL, etc.). In the generation method dened in
this work each SR ip-op and each temporized compo-
nent of the diagram (DIs, POs, DTs, etc.) are modeled
as a timed automata. The logical entities (OR, AND) are
modeled as guards of the timed automata of the ip-ops
and temporized components.
The binary logic diagram of Figure 3 models the logi-
cal sequence to accomplish the purge and activation of the
signal IGNITION PERMISSION for a certain type of in-
dustrial heater. The purge is accomplished always that a
general shutdown occurs (SD-GENERAL==true) or when
manually started (HS==true). Both conditions switches
the output of the SR ip-op to true, indicating that the
process of purge is in progress. If the purge process is not
interrupted, then it will nish after time T1.
Signals PURGE PERMISSION, SD-PURGE and IG-
NITION PERMISSION are used to avoid the beginning of
purge in a inadequate moment, to allow the purge to be
interrupted at any moment and to indicate its termination,
respectively. These signals act on the reset input of the
SR ip-op. If purge is concluded and the HEADER sig-
nal exists then the ignition permission is enabled. This
permission can be kept valid for a time T2 or it can be in-
terrupted at any moment by signal SD-PURGE. Observe
that some signals are connected to other diagrams which
are not displayed here.
In a PLC program the input is frozen in the beginning
of a scan cycle. All input variables are read and in the
end of the cycle all outputs are generated. In other words
changes on the input are only perceived by the PLC in the
beginning of the cycle, and output changes are passed to
the environment only at the end of the scan cycle.
Executing
Waiting
synchro!
update!
t=0,
CN=control()
read_input()
write_output()

CN==false &&
t<tscan
CN==false
CN=false,
Figure 4. Modeling the PLC scan cycle
On Figure 4 the timed automata model for the scan cy-
cle is introduced. The locality labeled Waiting models the
moment just before the beginning of the next scan cycle
and just after the end of the previous cycle. After the oc-
currence of the only event enabled, the input variables are
read. This is done by the function read input().
Once the cycle begins, the timed automata obtained
from the specication is executed until the scan time
(tscan) expires (t<tscan). Since the model deals with log-
ical time instead of real time, there is a trick to calculate
the time t. Note the synchronization channel (synchro)
associated to the event. This is because each component
is modeled as an independent automata that execute syn-
chronized through a broadcast channel. At each step a
control function is executed to determine if the output gen-
erated by each component had change in the current scan
cycle according to its input. If this is true (CN=true), then
the network should execute again. Otherwise the time is
reset, the output is generated and a new set of input vari-
ables is generated.
The iteration described above occurs at most n time,
4
S
R
AND
OR
DI
T1
S
R
DI
T2
OR
HS
OR
HEADER
XA
XA
SDIGNITION
XA
running
Purge
finished
Purge permission
Ignition
PERMISSION
IGNITION
SDGENERAL
PERMISSION
PURGE
SDPURGE
Figure 3. Binary logic diagram for the purge sequence of a heater
update?
update?
varX=true
varX=false
Figure 5. Input variables
where n is the number of automata in the network, i.e. the
number of ip-ops and timed components of the diagram
modeled as an automata. This is necessary to guarantee
the termination of the scan cycle. Observe that at each
step a signal propagates from the input of an element to
its output. Therefore, a modication of the output is only
perceived by a subsequent element at the next iteration on
the same scan cycle. On the worst case, a signal takes at
most n iterations to propagate fromthe input to the output.
In Figure 5 the timed automata for the generation of a
single input variable is illustrated. The execution of this
automata is synchronized by the update only to avoid the
state space explosion, and the new value of the variable is
obtained non-deterministically.
synchro?
synchro?
set==1 &&
reset==true
reset==false
output=true
output=false
Figure 6. Set-Reset ip-op
The Set-Reset ip-ops with priority on the reset are
modeled by the automata of Figure 6. Observe that all
events are synchronized with the rest of the automata net-
work through the channel synchro. The logic output exists
as soon as the input set true and the input reset is false The
output ceases existing as soon as the input reset is true.
The Delay Initiation (DI) of outputs component is
modeled by the timed automata shown in Figure 7. When
the input switches to true the clock c is reset, this is ex-
pressed on the time invariant in the model. If the inputs
stays true for as long as the timer species then the out-
put automatically switches to true, this is expressed by
the time invariant of the locality, until the input is false
again. Observe that all events, except the event triggered
by the timer, which consumes no time, are synchronized
by channel synchro, this is because this event should occur
exactly in the moment that c equals timer.
c=0
synchro?
synchro?
c<=timer
synchro?
input==true
input==false
input==false
output=false
c==timer
input==true &&
output=true, c=0
Figure 7. Delay initiation of outputs (DI)
In Figure 8 the Delay Termination (DT) of outputs
component is presented. When the input switches to true
the output also does it. Therefore, if the input goes to false
the clock c is reset and if the input keeps the value until c
equals timer then the output goes to false too.
The Pulse Output (PO) component is given by the au-
tomata in Figure 9. When the input switches to true then
the output also switches and stays true until the timer ex-
pires.
The generation of the timed automata network for a
given ISA 5.2 diagram consists in the identication of
each element of the diagram and its instantiation as one
of the automata introduced above. For this, it is necessary
to label each internal signal of the diagram and replaces
the inputs/outputs strings in the automata templates for the
proper signal string name. Each signal should be declared
5
synchro?
c<=timer
output=true
output=false
c<=timer
input==true
input==true &&
input==false
c=0
synchro?
c==timer
Figure 8. Delay termination of outputs (DT)
c<=timer
synchro?
c==timer
output=true, c=0
output=false
input==true
Figure 9. Pulse output (PO)
as a global variable and the connection between the au-
tomata is solved by the labels of the signals.
4.1 Validation
After obtaining the timed automata for the specica-
tion of the control system, it is possible to use the Uppaal
model checker to verify if some properties are satised or
not. For instance, on may want to check if there is a dead-
lock in the system. This can easily be done by entering
the CTL formula A[] not deadlock in the model checker.
Besides the fact that Uppaal can verify reachability,
safety and liveness properties, it is not on the scope of this
work to perform model checking. Instead, automatic test-
ing is chosen in order to be able to validate the control sys-
tem implementation that will execute on the plant. More-
over, tests can avoid the state explosion problem, which is
easily encountered when model checking timed systems.
Tests are well known to be not exhaustive. However, in
the context of this project, the main goal is to improve the
validation process of control systems. Usually, a control
system is accepted by the user after a factory acceptance
stage. This is done in the production plan by a group of
engineers generating events to the system and observing
its behavior. If the system fail to pass the factory accep-
tance stage, then the developers should correct the errors
and return to the factory for more tests. By being able to
perform automatic tests off the factory, the developer can
detect errors before the factory acceptance stage.
Automatic testing is performed using the Uppaal-
TRON tool, a testing tool based on the Uppaal engine
suited for black-box conformance testing of timed sys-
tems. TRON is used to connect a Uppaal timed automata
model to some implementation. An API is provided in or-
der to do it. The TRON engine generates inputs that are to
both the specication model and to the IUT. If the output
of both sides are in conformance, then we say the the IUT
passed the test.
In this way, the TRON is used to connect a SIS that
runs on a PLC through OPC to its implementation model
and detect error during the development of the system.
Another possibility to perform automatic testing is to
obtain another model fromthe SIS implementation. In this
case, TRON is used to test the specication model against
another timed model obtained from the implementation.
However, in this case the test stage is done by generating a
set of traces from the specication model and then testing
the implementation model against those traces.
5 Conclusions
In this work a method to perform automatic testing of
Safety Instrumented Systems (SIS) is introduced. The rst
step is to obtain a timed automata model from the speci-
cation in the ISA 5.2 standard. Then, two approaches can
be applied:
1. To connect the SIS implementation running on a PLC
to the timed automata model through the use of OPC
and the TRON testing tool.
2. To generate another timed automata fromthe SIS im-
plementation in FBD, as dened in the IEC-6113-3
standard, and use TRON to connect both models.
An automatic translation of ISA 5.2 specications into
timed automata is done according to the guidelines of Sec-
tion 4. Therefore, a process is dened to help Petrobras to
validate the conguration implementation. To meet this
goal a scenario has been dened.
Observe that this test technique does not interfere in the
development process of the SIS. However, it is of great
value for the developers to nd errors in the product they
are working on. Also, the same technique can be used to
directly test the implementation through the use of OLE
for Process Control (OPC). This will allow to test PLCs
that are not properly documented.
The generation of timed automata models from the a
SIS implementation in Ladder or FBD languages is under
development. Also, it is necessary to be able to perform
test of the real implementation through OPC.
The main advantage of the method presented here is
to potentially minimize the required interaction between
engineers and developers during the factory acceptance
stage. By consequence, the quality of the software de-
livered increases.
References
[1] R. Alur and D. L. Dill. A theory of timed automata. The-
oretical Computer Science, 126(2):183235, 1994.
6
[2] L. Baresi, M. Mauri, A. Monti, and M. Pezz` e. PLCTools:
Design, formal validation, and code generation for pro-
grammable controllers. In Proceedings of the IEEE Con-
ference on System, Man, and Cybernetics, volume 4, pages
24372442, Los Alamitos, CA, USA, 2000. IEEE Com-
puter Society.
[3] G. Behrmann, A. David, and K. G. Larsen. A tutorial
on UPPAAL. In M. Bernardo and F. Corradini, editors,
Formal Methods for the Design of Real-Time Systems:
4th International School on Formal Methods for the De-
sign of Computer, Communication, and Software Systems,
SFM-RT 2004, number 3185 in LNCS, pages 200236.
SpringerVerlag, Sept. 2004.
[4] G. Canet, S. Coufn, J.-J. Lesage, A. Petit, and Ph. Sch-
noebelen. Towards the automatic verication of PLC pro-
grams written in Instruction List. In Proceedings of the
IEEE International Conference on Systems, Man and Cy-
bernetics (SMC 2000), pages 24492454, Nashville, Ten-
nessee, USA, Oct. 2000. Argos Press.
[5] E. A. Emerson. Temporal and modal logic. In Handbook
of Theoretical Computer Science, volume B, chapter 16,
pages 9951072. Elsevier Science Publisher B.V., 1990.
[6] C. Ghezzi, D. Mandrioli, S. Morasca, and M. Pezz` e. A
unied high-level petri net formalism for time-critical sys-
tems. IEEE Trans. Software Eng., 17(2):160172, 1991.
[7] W. M. Goble and H. Cheddie. Safety Instrumented Systems
Verication Practical Probabilistic Calculations. ISA,
2005.
[8] P. Gruhn and H. L. Cheddie. Safety Instrumented Sys-
tems: Design, Analysis, and Justication. ISA, 2nd edi-
tion, 2006.
[9] I. Hatono, K. Baba, M. Umano, and H. Tamura. Au-
tomatic generation of fault detection models for pro-
grammable controller based manufacturing systems using
complementary- places petri nets. In Preprints 13th IFAC
Congress, pages 301306, July 1996.
[10] M. Heiner and T. Menzel. A petri net semantics for the
PLC language instruction list. In Proc. IEE Workshop
on Discrete Event Systems (WODES98), pages 161165,
Cagliari, Italy, Aug. 1998.
[11] J. E. Hopcroft and J. D. Hullman. Introduction to Au-
tomata Theory, Languages and Computation. Addison-
Wesley, 1979.
[12] The Instrumentation, Systems, and Automation Society.
Binary Logic Diagrams for Process Operations, ISA 5.2-
1976 (R1992) edition, July 1992.
[13] K.-H. John and M. Tiegelkamp. IEC 61131-03: Program-
ming Industrial Automation Systems. Springer-Verlag,
Berlin, Germany, 2001.
[14] K. G. Larsen, M. Mikucionis, B. Nielsen, and A. Skou.
Testing real-time embedded software using uppaal-tron:
an industrial case study. In EMSOFT 05: Proceedings of
the 5th ACM international conference on Embedded soft-
ware, pages 299306, New York, NY, USA, 2005. ACM
Press.
[15] A. Mader and H. Wupper. Timed automaton models for
simple programmable logic controllers. In Proceedings of
Euromicro Conference on Real-Time Systems, York, UK,
June 1999.
[16] K. L. McMillan. The SMV System: for SMV ver-
sion 2.5.4, Nov. 2000. Available from: http://www-
2.cs.cmu.edu/modelcheck/smv/smvmanual.ps.gz.
[17] I. Moon. Modeling programmable logic controllers for
logic verication. IEEE Control Systems Magazine,
14(2):5359, 1994.
[18] T. Murata. Petri nets: Properties, analysis and applica-
tions. Proceedings of the IEEE, 77(4):541580, Apr. 1989.
[19] O. Rossi and Ph. Schnoebelen. Formal modeling of timed
function blocks for the automatic verication of Ladder
Diagram programs. In S. Engell, S. Kowalewski, and
J. Zaytoon, editors, Proceedings of the 4th International
Conference on Automation of Mixed Processes: Hybrid
Dynamic Systems (ADPM 2000), pages 177182, Dort-
mund, Germany, Sept. 2000. Shaker Verlag.
[20] M. B. Younis and G. Frey. Formalization of existing plc
programs: A survey. In Proceedings of the IEEE/IMACS
Multiconfrence on Computational Engineering in Systems
Applications (CESA 2003), Lille, France, July 2003.
7

Anda mungkin juga menyukai