Content uploaded by Doaa Soliman
Author content
All content in this area was uploaded by Doaa Soliman on Dec 15, 2015
Content may be subject to copyright.
Content uploaded by Doaa Soliman
Author content
All content in this area was uploaded by Doaa Soliman on Dec 15, 2015
Content may be subject to copyright.
Content uploaded by Doaa Soliman
Author content
All content in this area was uploaded by Doaa Soliman on Dec 15, 2015
Content may be subject to copyright.
Verification and Validation of Safety Applications based on PLCopen Safety Function Blocks
using Timed Automata in Uppaal
Doaa Soliman and Georg Frey
Chair of Automation, Saarland University
University Campus Building A5.1, 66123 Saarbrücken, Germany
(e-mail: doaa.soliman@aut.uni-saarland.de, georg.frey@aut.uni-saarland.de)
Abstract: Functional Safety is a major concern in the design of automation systems today. Many of those
systems are realized using PLCs programmed according to IEC 61131-3. PLCopen as IEC 61131 user
organization specified a set of software Function Blocks to be used in Safety Applications according to
IEC 61508 in 2006. The specification of Technical Committee 5 contains twenty Safety Function Blocks
(SFBs) as a library together with some specifications of their use. A second part issued in 2008
demonstrates the use of the defined SFBs in real applications. In the presented work, formal models for
the SFBs are derived from the semi-formal specification in the PLCopen documents. Those blocks are
verified using model checking and the accordance of their temporal behavior with the PLCopen
specification is further validated by simulation. The resulting library of formal models allows to build a
formal model of a given safety application – built from SFBs – and to verify its properties. This is
demonstrated using an example from the second part of the PLCopen specification.
Keywords: Safety Application, Timed Automata, PLC, Safety Function Block, IEC 61508, IEC61131-3
Verification and Validation, Model-Checking.
1. INTRODUCTION
Nowadays, PLCs are increasingly being used to implement
safety functions for safety critical systems. One of the
preferred languages in this area is Function Block Diagram
(FBD) according to IEC 61131-3. There are many research
projects in the field of verification and implementation of
function blocks libraries according to this standard e.g.
Völker and Krämer (2001) or Song et al. (2004). However,
safety issues are not addressed in IEC 61131-3, and PLC
programming software packages have only library function
blocks dealing in general with communication, mathematical
operations, logic, and so on. As a step for building safety
applications in IEC 61131-3 FBD according to IEC 61508,
PLCopen (2006) specifies a set of so-called Safety Function
Blocks (SFBs). Several manufacturers of IEC 61131
programming tools have already implemented libraries
according to this specification.
The main aim of the presented work is to ease the verification
of safety applications built up using the PLCopen SFBs in
one of the commercially available tools. To this end a
modular (function block oriented) approach is taken. For all
specified SFBs a corresponding formal model is built using
Timed Automata (TA). To verify a safety application, the
formal model of the application is derived by combining the
previously specified TA in the same structure as the original
SFBs are combined in the PLC software.
Before applications can be verified however, it has to be
assured that the formal models are actually describing the
behaviour of the SFBs correctly.
The description of SFBs by PLCopen contains three parts for
each SFB respectively:
1. A graphical description of the internal states and
behaviour using a state diagram.
2. A list of properties described in natural language.
3. Timing diagrams describing the temporal behaviour
for some specific scenarios.
In the presented approach the graphical description (1
st
part)
is translated into a TA in the language of the Uppaal tool. To
validate the temporal behaviour, simulations of the model are
performed and the results are compared to the timing
diagrams (3
rd
part). The list of textual properties (2
nd
part) is
formalized using temporal logic. By using model checking –
see e.g. Berard et al. (2001) – it is then verified that these
properties hold on the TA.
This paper is organized as follows: In the next section an
overview of the proposed approach to verify safety
applications is given. Section 3 describes the formalization of
SFBs in detail using an example from the PLCopen Library.
The use of the formalized SFBs for verification is
demonstrated in section 4, utilizing an example from
PLCopen (2008). The paper closes with a short summary and
an outlook on further work.
2. APPROACH TO VERIFY SAFETY APPLICATIONS
The presented approach is based on the development process
given in Fig.1. To build a safety application an engineer is
assumed to build his software using a library of SFBs that
was implemented according to the PLCopen specification. To
do so, the specification for the safety application is read and
interpreted by the engineer and the solution is implemented in
a PLC programming tool. Now it has to be verified that the
implemented application fulfils the original specification. To
this end in the presented work, the process described in the
shaded part of Fig. 1 is proposed. Following the structure
(interconnection of SFBs) of the implemented application a
formal model of the safety application is built from a library
of pre-formalized SFBs. On this model properties derived
from the original specification can be verified.
Lib. of imple-
mentedSFBs in
accordance with
PLCopen-Spec.
Lib. of formal-
izedSFBs in
accordance with
PLCopen-Spec.
Specification
of the Safety
Application
Implementation by
connecting SFBs to an
SFB-network in PLC-
Programming-Tool
Implemented
Safety
Application
Formalization of Safety
Application using
formalized SFBs
Formalized
Safety
Application
Verification
Formalization of
Properties to be
verified
Formalized
Properties
Fig. 1. Proposed development process for verified Safety
Applications using the PLCopen SFBs.
The main part of the presented work is to provide the library
of pre-formalized SFBs. This process is shown in the right
(shaded) part of Fig.2. Starting from the PLCopen
specification a library of SFBs is built using TA in the
Uppaal tool. It is then verified that those formal models are
actually conforming to the PLCopen specification. On the
other side (left part of Fig. 2) it is assumed that the
manufacturer of a programming tool starts from the same
specification and build a set of implemented SFBs. The
conformance of these SFBs to the PLCopen specification is
normally certified by some organization like TÜV. In the
following it is assumed that the implemented SFBs are
actually behaving like described in the PLCopen
specification.
The next section shows in detail how to build a validated and
verified SFB Library in accordance with PLCopen
specifications.
PLCopen SFB
Specification
Implementation of SFBs
in PLC-Programming-Tool
(by Tool-Provider)
Formalization of SFBs
using Timed Automata
in Uppaal
Library of SFBs in
PLC-Program-
ming-SW
Library of formal
SFBs in Uppaal
Certification Verification
Lib. of imple-
mentedSFBs in
accordance with
PLCopen-Spec.
Lib. of formal-
izedSFBs in
accordance with
PLCopen-Spec.
Fig. 2. Process of deriving the Safety Function Block
Libraries for implementation (left) and verification (right)
from the PLCopen specification.
3. CONSTRUCTING THE SAFETY FUNCTION BLOCK
LIBRARY FOR VERIFICATION
3.1 Formalization of SFBs in Uppaal
As described in Behrmann et al. (2004), Uppaal allows
analysis of networks of timed automata with binary
synchronization. It contains three main parts. First, timed
processes are described using a graphical editor. Second,
systems can be simulated by a graphical simulator. Finally,
reachability properties can be verified using the verifier.
To formalize an SFB, the process depicted in Fig. 3 is
followed. First of all the Input/Output variables of the SFB
are declared according to the interface description in the
PLCopen document. Then, the state diagram is transferred to
TA using the graphical editor of Uppaal. Depending on this
TA and the input sequence scenario extracted from the timing
diagram, a simulation is executed to validate the temporal
behaviour using the graphical simulator. Thereafter, the
textual properties are translated into Temporal Logic (TL)
formulae. Using the verifier, the properties of the safety
function can be verified. Actually, the use of symbolic model
checking in combination with TA would be sufficient to
verify the behaviour of the formalized SFBs. However, the
additional use of simulation is useful for two distinct reasons.
First of all, to validate specific scenarios presented in the
specification it is the more direct approach. Second, and
much more important, it allows users not familiar with formal
models to assess the results directly.
In the frame of the presented work, all twenty SFBs defined
by PLCopen have been formalized according to this
procedure. As an example, the following sub-section
describes the process in detail for the SFB SF_Equivalent.
Formalized
Properties
Formalization
in Timed
Automata
Properties
(Text)
Behavior:
Automaton
(Graphics)
Extraction of
Scenario Input
Sequence
Formalization
in Temporal
Logic
Formalized
Automaton
Simulation
Scenarios
Validation by
Simulation
Verification by Model
Checking
PLCopen SFB
Specification
Temporal
Behavior of
specific
Scenarios
(Timing
Diagrams)
Fig. 3. Detailed description of the process to build a verified
and validated formalized SFB.
3.2 Complete Description of one SFB: SF-Equivalent
The Input/Output variables declarations are shown in Fig. 4.
Moreover, an interface description (Name, Data Type, Initial
Value and Function) of every variable is tabled. A Textual
Functional description of the SFB is as follows:
“This function block converts two equivalent SAFEBOOL
inputs to one SAFEBOOL output with discrepancy time
monitoring. Both input Channels A and B are interdependent.
The function block output shows the result of the evaluation
of both channels. If one channel signal changes from TRUE
to FALSE the output immediately switches off (FALSE) for
safety reasons.”
The state diagram is shown in Fig. 5. The inputs are used as
transition guards and the outputs are updated according to the
state location. The Time input is assumed a clock.
Additionally the temporal behaviour of the SFB is described
for specific scenarios in a timing diagram (Fig. 6). Finally, a
description and output setting of every state are tabled. This
table defines the output variables’ values for each state in the
state diagram, and is used later in verification.
Fig. 4: SFB SF_Equivalent
Fig. 5. State diagram for SFB SF_Equivalent.
Fig. 6. Part of the timing diagram of SFB SF_Equivalent.
3.3 Formalization of SF-Equivalent
First of all, the Input/Output variables are declared as shown
in Fig. 7. These variables are declared globally to allow
sharing by other automata.
Fig. 7. Declarations of variables, clocks, and channels.
Second, state diagram of the SFB is graphically translated to
state transition automaton shown in Fig. 8. Additionally,
three automata of the Boolean input variables are constructed
to give the facility to vary these inputs while implementing
the simulation. The synchronisation between these processes
is achieved by shared variables (global declaration) and
message passing (channels), cf. Fig. 7.
As it appears in the state diagram of Fig. 5, the outgoing
transitions from every state are numbered according to
priorities where 0 is the highest priority. In translating the
state diagram of PLCopen in a TA in Uppaal the problem of
covering priorities arises. However this problem can be easily
solved by extending the transition condition of a low priority
condition with the negation of a high priority transition. A
detailed analysis performed for all SFBs shows that this
extension is not always necessary.
Prior to simulation, one should be sure that the output
variables vary correctly with every state location of the SFB
automaton. This can be achieved by querying about the value
of these variables in every state location using the verifier.
For example, in location Error3, both Ready and Error are
True and S_EquivalentOut is False. This liveness property is
converted to a CTL formula as follows:
SF_Equivalent.Error3-->(Ready_Eq)&(!S_EquivalentOut)& (Error_Eq)
The result of the verification assured this property and other
similar properties of all locations.
Using the automata (Fig. 8) simulation in Uppaal validated
the timing diagrams from the PLCopen specification (Fig. 6).
Fig. 9 shows the response of SF_Equivalent automaton to the
change in input automata synchronized by channels
(horizontal arrows).
Fig. 9. Simulation scenario for the timing diagram in Fig. 6.
Fig. 8. Uppaal Timed Automaton of SF_Equivalent.
After simulation, deadlock-freeness of the system is checked
with the property:
A[] not deadlock
Now, the accordance of the automaton to the textual
functional description is checked by verification. Taking a
part of this description mentioned above, for example, “If one
channel signal changes from TRUE to FALSE the output
immediately switches off (FALSE) for safety reasons”. A
corresponding CTL formula is derived:
A<> SF_Equivalent.Safety_Output_Enabled&((!A)|(!B)) imply
!S_EquivalentOut
This reachability property and all other textual properties are
satisfied assuring the functionality of the SFB TA.
4. VERIFICATION OF A SAFETY APPLICATION
The process described in Section 2 is now applied using the
models introduced in the previous section to an example
taken from the second part of the PLCopen specification.
There, for every example, a block diagram is available
showing the interconnection between SFBs and also showing
the safety inputs and outputs. A description of safety
functions and declaration of the used variables are also given.
Sometimes, additionally, a timing diagram is given.
In the following, the first example from this specification
“Emergency stop with safe stop & equivalent monitoring” is
used. Fig. 10 shows a solution for this problem implemented
in FBD by connecting SFBs directly or via simple logic
gates. This example uses the following safety functions:
• Issuing the emergency stop (via SF_EmergencyStop) or
interrupting the light beam in the light curtain (via
SF_ESPE) stops the drive in accordance with stop
category 1.
• The stop of the electrical drive within a predefined time
is monitored (via SF_SafeStop1).
• The Safe Status of the drive is indicated by the
S_Stopped variable, connected to the functional
application
• If the stop is performed by the Emergency Switch, a
manual reset is required (via SF_EmergencyStop)
• If a monitoring time violation is detected (via
SF_SafeStop1), manual error acknowledge is required to
allow a reset.
• The 2 channel connectors of the emergency stop are
monitored. An error is detected when both inputs do not
have the same status once the discrepancy time has
elapsed (via SF_EQUIVALENT)
• The functional stop in this example is performed as a
safe stop issued from the functional application. A restart
interlock for this stop is not necessary.
The Uppaal tool has the ability to import constructed TA and
combine them in a new system. Hence, the four SFB TA and
the required input TA are imported easily in one system. The
next step is to achieve the connection according to Fig. 10.
To avoid internal modification inside every SFB, the
connections are achieved by new TA. As shown in Fig. 10,
there are two direct connections from SF_Equivalent to
SF_EmergencyStop (C1,C2). And another two non-direct
connections from SF_EmergencyStop and SF_ESPE to
SF_SafeStop1 (C3,C4). Fig. 11 shows the four connections
TA.
Fig. 11. Timed processes for connections between SFBs.
Fig. 10. Safety application to be verified
.
Every conniction TA is constructed from one initial-urgent
location and tow self-loop-transitions (edges). The edges can
have discrete guards and arbitrary updates, but no guards
over clocks. As soon as the input (guards) of the connection
TA changes, the output (channels and shared variables) is
immediately issued without delay. The simulation (Fig. 12)
proved that the system is working as mentioned in PLCopen
Part 2. Some of the verified properties are as following:
Property 1: After the activation of SF_Equivalent and
SF_ESPE, the SF_SafeStop will keep activated.
E[] Active_Eq&Active_ESPE imply Ready_SS1
Property 2: Issuing the Emergency stop (via
SF_EmergencyStop) or interrupting the light beam in the
light curtain (via SF_ESPE) stops the drive in accordance to
stop category 1.
A<> ((!A)|(!B)|(!ESPE_In))& Acknowledge imply S_Stopped
A[] SF_SafeStop1.Drive_Stopped imply T<=MT
Both properties are verified, guaranteeing that the application
works as expected.
5. SUMMARY AND OUTLOOK
In this paper an approach for the verification of safety
applications built form PLCopen Safety Function Blocks
(SFBs) was presented and illustrated using an example. It has
to be made clear, that the presented approach relies on the
assumption that the implementation of the SFBs actually
follows the specification of PLCopen in all details. This
assumption is normally verified by certification of SFBs by
independent organizations like TÜV.
Future work in this project will concentrate on automating the
model building step. Based on the PLCopen XML
interchange format for PLC applications the formal model
will be built from the pre-defined automata automatically.
REFERENCES
Berard et al. (2001). Systems and Software Verification,
Model-Ckecking Techniques and Tools. Spriger,
Germany.
Gerd Behrmann, Alexandre David, Kim G. Larsen (2004). A
tutorial on Uppaal, Uppaal web site, Documentation,
Tutorials.
Myung Jun Song, Seo Ryong Koo, and Poong Hyun Seong
(2004). Development of a Verification Method for
Timed Function Blocks Using ESDT and SMV. IEEE
InternationalSymposium HASE’04.
Norbert Völker, Bernd J. Krämer (2001). Automated
verification of Function block-based industrial control
systems. Since of Computer, Volume 42, Pages 101-113.
PLCopen (2006). Part 1: Concepts and Function Blocks.
TC5, Safety Software Technical Specification,
Version1.0, PLCopen, Germany.
PLCopen (2008). Part 2: User Examples. TC5, Safety
Software Technical Specification, Version1.0, PLCopen,
Germany.
Fig. 12. Simulation scenario of the safety application.
