Control Engineering Practice 64 (2017) 173–194

Contents lists available at ScienceDirect

Control Engineering Practice

journal homepage: www.elsevier.com/locate/conengprac

Transformation of GRAFCET to PLC code including hierarchical

structures
Robert Julius n, Max Schürenberg, Frank Schumacher, Alexander Fay
Helmut-Schmidt-University, Institute of Automation Technology, Holstenhofweg 85, 22043 Hamburg, Germany

art ic l e i nf o a b s t r a c t

Article history: GRAFCET is an advantageous modelling language for the specification of controllers in discrete event
Received 28 September 2016 systems. It allows for hierarchically structuring a control program's specification based on the elements
Received in revised form enclosing steps, partial-Grafcets and forcing orders. A method is already available for the automatic
23 March 2017
transformation of Grafcets1 into PLC code but this method cannot keep the hierarchical structures due to
Accepted 25 March 2017
limitations of the PLC language SFC. In this contribution a systematic approach to automatically trans-
form Grafcets into PLC code while retaining the hierarchical structures is described.
Keywords: & 2017 Elsevier Ltd. All rights reserved.
Modelling language
GRAFCET
Hierarchical structure
Control code
Programmable Logic Controller

1. Introduction

1.1. Engineering of programmable logic controllers today

The five programming languages Instruction List (IL), Ladder Diagram (LD), Function Block Diagram (FBD), Sequential Function
Chart (SFC) and Structured Text (ST) of the international standard IEC 61131-3 (IEC 61131-3, 2013) are today de-facto standard for the
engineering of programmable logic controllers (PLCs), which involves the following engineering steps: requirements engineering, spe-
cification, implementation, commissioning, operation and maintenance. Both engineers and technicians, e.g. field service personnel and
maintenance staff, are familiar with these programming languages since IEC 61131-3 is an integral part of the professional education of
control practitioners (Braun, Obermeier, & Vogel-Heuser, 2012; Vogel-Heuser et al., 2013). Hence the IEC 61131-3 standard can be con-
sidered state of the art and a substantial achievement of the automation engineering domain (Vyatkin, 2013).
In current practice in the manufacturing domain, where PLCs are mostly applied, the engineering steps “requirements en-
gineering” and “specification” are usually carried out only informally by means of sketches, spreadsheets and text documents. The
implementation of the control code is based on the manual interpretation of such informal documents (Frey & Litz). This is mainly
due to a lack of time and expertise (Johnson, 2007; Ljungkrantz, Akesson, Yuan, & Fabian, 2012) and often results in additional costs
caused by the erroneous interpretation of the textual requirements. The main advantages of formal specifications for control
design are the facilitation of automatic code generation, the ability to specify the program behaviour in a formal way for doc-
umentation as well as the reusability of the specifications independently from the system under development. The possibility to
verify the control code behaviour is another important aspect (Ljungkrantz et al., 2012). Automatic control code generation from
formal specifications reduces implementation effort and opens a way for a better acceptance of formal specifications for industrial
applications. Therefore formal specifications are an important research issue.

n
Corresponding author.
E-mail addresses: [email protected] (R. Julius), [email protected] (A. Fay).
1
“GRAFCET” (in capital letters) refers to the standard and the modelling language in general, whereas a “Grafcet” is a particular model, i.e. one control specification.

http://dx.doi.org/10.1016/j.conengprac.2017.03.012
0967-0661/& 2017 Elsevier Ltd. All rights reserved.
174 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

1.2. Related work

Model-driven development (MDD) has been proposed to automatically generate control code from formal design models (Thram-
boulidis and Frey, 2011; Lukman et al., 2013), but these methods and tools still lack acceptance in industrial practice of PLC programming
(Vogel-Heuser et al., 2014). The reason is twofold: on the one hand formal methods proposed in the literature are based on modelling
languages which are usually not familiar to the designated users (control practitioners) (Vogel-Heuser et al., 2014). On the other hand, most
model-driven approaches are not feasible in practice since they only allow performing modifications and revisions within the models to
keep consistency of code and models. However, in practice, PLC programmers implement required changes directly in the PLC code. As a
consequence, formal approaches are not well accepted in practice (Vogel-Heuser et al., 2014) so far. Below we summarize previous work
on modelling and code generation for the specification language GRAFCET defined in the IEC 60848 (IEC 60848, 2013) and offer a brief
insight into related research fields.
UML statecharts (OMG, 2015) are an established means of generating code from formal models and facilitate hierarchical structured
specifications. A suitable approach generating IEC 61131-3 control code from statechart is presented in Vogel-Heuser, Witsch, and Katzke
(2005) and Witsch and Vogel-Heuser (2011) and an introduction of using object-oriented extensions of IEC 61131-3 is given in Witsch and
Vogel-Heuser (2009) and Racchetti, Fantuzzi, Tacconi, and Bonfe (2014). Several approaches discuss the verification and model checking of
statechart and familiar state machines (Helke & Kammuller, 2016; Missal, Hirsch, & Hanisch, 2007). However, the approach presented in
this article does not focus on formal verification but the desirable coherence between specification and control program as well as a
readable and maintainable code. GRAFCET is superior to statecharts in that it is rooted in an IEC standard and based on Petri nets
(Provost, Roussel, & Faure, 2011b) and thus easily comprehensible by control engineers (Reisig, 2016). It also has recently become an
inherent part of the professional education of control technicians (Durey, 1997; Marichal and González, 2014). Hence, GRAFCET is well
suited for the specification of PLC programs.
The IEC 61499 (IEC 61499-1, 2012) defines an open architecture for distributed and embedded control with an event-based execution
order for program organization units (POUs). The program behaviour for sequence control within the single function blocks is defined by
using execution control charts (ECC) (Thramboulidis, 2013) or formal specification languages like Petri nets and will be implemented in an
IEC 61131-3 programmable language. Therefore automatic generation of control code from GRAFCET specifications can play a pivotal role
in the context of IEC 61499.
According to IEC 60848 GRAFCET is a powerful graphical modelling language for discrete event systems. GRAFCET aims to specify the
functional behaviour of sequential parts of a control program. Its hierarchical components (enclosing step, partial-Grafcets and forcing
orders) serve to structure a program's behaviour in a clear way and enable control of distributed parts within a single PLC. A hierarchical
structure in GRAFCET can be designed by partial-Grafcets which are enclosed in other Grafcets and by forcing the situations of a Grafcet's
steps from other parts of the Grafcet or even from separate Grafcets. The modelling features of GRAFCET have been formalized recently as a
basis for model-driven development (Schumacher, Schröck, & Fay, 2013.; Schumacher & Fay, 2013; Sogbohossou & Vianou, 2015; Gonzalez,
Marichal, & Hamilton, 2016). GRAFCET has been proposed both for code generation (Alvarez, Burgos, Sarachaga, & Estévez, Marcos, 2012)
and for conformance test purposes (Provost, Roussel, & Faure, 2011a). A survey on GRAFCET-related research can be found in Schumacher
and Fay (2014).
Several GRAFCET design tools are available and in use today, such as FluidSIM 5, SFCEDIT, OFT2 and WinErs. They allow to graphically
designing control specifications, but none of these tools can transform the specification into PLC code in an IEC 61131-3 programming
language.
In Schumacher and Fay (2014), an approach has been presented for the automatic generation of IEC 61131-3 compliant PLC code from
GRAFCET specifications. This approach is based on an exhaustive formal model of GRAFCET as Control Interpreted Petri nets (Schumacher
& Fay, 2014). The target language is Sequential Function Chart (SFC), one of the five PLC programming languages defined in IEC 61131-3.
SFC shows many structural similarities with GRAFCET, e.g. steps, transitions, actions, parallel and alternative branches, and therefore
seems to be a natural target language for code generation from GRAFCET.
However, the IEC 61131-3 standard does not offer possibilities in SFC to consider hierarchical structures in the way IEC 60848 does in
case of GRAFCET. Therefore, in the approach described in Schumacher and Fay (2014), a so-called “normalization” had been applied before
the SFC code generation. Devroey et al. (2014) surveys methods for flattening hierarchical structures in state machines. By means of
“normalization”, the hierarchical structures of a Grafcet are dissolved. The result of the “normalization” is one single Grafcet that can be
transformed into an equivalent IEC 61131-3 control program in SFC, using unambiguous transformation rules. By “normalization”, the
number of steps and transitions in the Grafcet increases, and so does the number of steps and transitions in the resulting SFC.
But the strength of GRAFCET is the possibility to hierarchically structure a control program. This facilitates the modelling of concurrent
behaviour and significantly increases the readability of the specification. Therefore, the fact that the hierarchical structures are removed in
the transformation approach described in Schumacher and Fay (2014) is disadvantageous, as it results in relatively large and difficult to
read SFC control programs. A more legible hierarchical structured control program enables changes directly in the PLC code during
commissioning and maintenance of software. This benefit is not present in a normalized SFC control program.
The authors’ main goal was therefore to develop a transformation approach that preserves the hierarchical structures specified in
GRAFCET during the generation of the IEC 61131-3 control code. This approach is described in this manuscript. To encourage the practical
use and acceptance of the approach, the concept of a software tool is presented which offers the basic infrastructure for an automatic
generation of control code, according to the IEC 61131-3 standard, even for hierarchical Grafcets.

1.3. Outline of the article

Section 2 discusses the selection of a target language and a target POU for an automatic transformation approach. To our best
knowledge this is the first closer look at a suitable IEC 61131-3 target language for GRAFCET preserving hierarchical structures. Subse-
quently, in Section 3, a formal model of GRAFCET is defined that summarizes previous work in the field. This forms the foundation for a
GRAFCET transformation algorithm for sequential systems. Section 4 presents the complied transformation algorithm which transforms
Grafcets to PLC code in the IEC 61131-3 language ST including method-oriented elements. In this section a new set of transformation rules
 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 175

that map each element of Grafcet to a specific set of IEC 61131-3 code fragments are described. Section 5 is devoted to the prototypical
implementation of the computer-based transformation of Grafcets to ST. The prototype was developed as part of previous research and has
been adjusted for the new transformation concept. It assists the control practitioner in using GRAFCET for the specification of logic
controllers and offers an automatic generation of control code. The approach is illustrated by means of an application example. Section 6
provides a summary of the main results and concludes the paper by pointing out further research questions.

2. Transformation in consideration of hierarchy

2.1. Selection of a target POU structure

The general aim of this approach is to transform a GRAFCET specification into an IEC 61131-3 implementation. The latter term ‘IEC
61131-3 implementation’ needs to be specified before a transformation concept can be developed. The IEC 61131 concept of different POUs
offers a variety of possibilities to structure a control program hierarchically (IEC 61131-3, 2013). To keep the hierarchical structure of a
GRAFCET specification within an IEC 61131-3 implementation, each partial-Grafcet should be transformed into its own POU. The decision
which POU type is most suitable was based on the following considerations:

A POU of type function is not applicable because a function cannot save state information, which is an essential part of GRAFCET.

A program can only be called by its task, but not by any other POU. Because partial-Grafcets exchange information via the implicit links of
hierarchical elements, the resulting POUs need to be able to call each other. A workaround with the usage of different tasks and global
communication variables has been considered impractical, as it creates a significant overhead, and the number of tasks is limited in PLCs.

The remaining POUs of type function block and class both suit the needs of the transformation very well. They can save state information
and are able to call each other. With the provision of dedicated methods, these POUs are able to communicate with each other in a
convenient way. The usage of global communication variables is not necessary. However, although part of the latest version of the IEC
61131-3 standard, the POU class has not yet been implemented in any commercial IEC 61131-3 software development environment.
Thus, function blocks are considered as the IEC 61131-3 counterpart for partial-Grafcets.

2.2. Selection of a target language

2.2.1. Quality metrics

For the successful transformation of a hierarchical Grafcet into an IEC 61131-3 implementation, the selection of an appropriate
IEC 61131-3 programming language is crucial. In previous work a set of target languages was taken into account, but ignored, e.g.,
the preservation of hierarchical structures. Therefore we perform the programming language selection with closer scrutiny. The
following quality measures (Vogel-Heuser et al., 2014; Frey, 2002) have to be met to ensure practicability and acceptance of the
transformation concept:

Semantical equivalence
The target language should permit the implementation of an interpretation algorithm that shows the same dynamic behaviour on a PLC
as one would expect from the Grafcet specification. This aspect is called semantical equivalence (Huth and Ryan, 2004). The only
limitation is the system conflict between the event-based GRAFCET and the cyclic-sequential PLC system.

Portability
Although (IEC 61131-3, 2013) defines a global standard for the programming of PLC systems, it still provides room for interpretation and
has thus resulted in vendor dependent implementations. The transformation algorithm shall avoid such ambiguous structures to ensure
that the produced code can run on any PLC.

Readability
The specification of the control program on the one hand and its implementation and maintenance on the other hand are typically done
by different users, as stated in Section 1.1. It is common practice that minor changes are done directly in the code during commissioning
and maintenance. For this purpose, the automatically generated code has to be easily readable without knowledge of the
transformation algorithm. Ideally, the control flow of the automated system can be directly understood from looking at the control
program.

Maintainability
Small changes to the specified control flow (e.g., different actor trigger, additional checks etc.) shall also result in only small changes in
the code. Implicit relations between signals and variables should be avoided.

A transformation approach that helps to ensure some of these quality metrics has been presented in (Frey, 2002, 2000) for the
transformation from Petri nets to the IEC 61131-3 programming language Instruction List: it follows a one-to-one correspondence between
every single element of the specification and its counterpart in the program code. The one-to-one correspondence allows an easy
interpretation of the produced code avoids implicit relations between variables and ensures that the user knows where to find those parts
of the code he or she needs to change. Therefore, this approach is also taken as a basic guideline for the transformation of Grafcets into IEC
61131-3 code.
The IEC 61131-3 standard (IEC 61131-3, 2013) specifies five programming languages. Three of them could quickly been disregarded as
target languages for the transformation of Grafcets, for the following reasons:

Instruction List
The transformation of Signal Interpreted Petri nets (SIPN) to an IEC 61131-3 implementation in Frey (2000) uses IL as a target language
(without further reasoning for this choice). However, the most recent version of the IEC 61131-3 norm states that, as an assembler-like
language, IL is outdated and that it will not be included in the next version of the standard (IEC 61131-3, 2013).
176 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

Ladder Diagram
LD resembles the wiring of relays and is thus ‘far away’ from an abstract control-flow language like GRAFCET. An LD implementation
would not fulfil the readability quality metric. Using flip-flops to represent the states in LD will improve the readability only marginally.
The main challenge is to handle the transient behaviour of the event-driven GRAFCET in a cyclic-sequential control program as well as
the different types of actions. Therefor a large number of standard trigger POUs and corresponding networks is required.

Function Block Diagram
To effectively model a control-flow given in GRAFCET, an FBD implementation would have to model states and transitions as function
blocks and connect them. Such an implementation would look similar to an SFC implementation (but with an overhead to keep track of
the active states), so SFC would be the better choice.

2.2.2. Sequential Function Charts

According to Bauer (2004) and Hellgren, Fabian, & Lennartson (2005), SFC and GRAFCET have significant similarities. Most work related
to the transformation of various discrete-event program specification languages to an IEC 61131-3 implementation focuses on SFC as a
target implementation language. The authors of (Klein, 2002) analyse the transformation of a SIPN model into an SFC implementation
program. They justify the choice of SFC with the syntactic similarity to SIPN, but also mention major differences that have to be considered
in the context of this work as well:

SFC does not have transient states. A state is always active for at least one PLC cycle.

There can be only one initial step in an SFC.

These are hindrances for a transformation from GRAFCET, because transient states and multiple initial steps are important features in
GRAFCET.
The lack of hierarchical elements in SFC is another obstacle for SFC as a target language. No method is known so far which allows
transforming a Grafcet including its hierarchical elements to SFC while preserving the Grafcet's hierarchical structure. In the approach
described in Schumacher and Fay (2014), hierarchical elements are included in the Grafcet, but all partial-Grafcets are merged into one
large Grafcet before the transformation is executed. The reason for this so-called ‘normalization’ is that the syntactical similarity between
GRAFCET and SFC is limited to elements of a Basic-Grafcet. There is no element in SFC that resembles the hierarchical elements macro-step,
enclosure, or forcing order, which can be considered as abbreviations. Therefore, their behaviour can also be modelled with the basic
elements. The impact of all hierarchical elements on the dynamic behaviour of a Grafcet can be traced back to the introduction of implicit
links and conditions. When trying to model the hierarchical elements of GRAFCET in SFC, these implicit links need to be uncovered and
explicitly modelled, which is illustrated using a simple example of a forcing order in Fig. 1.
Consider the Grafcet in Fig. 1a). From any current situation the forced Grafcet G1 evolves to the following situation sit ( t + 1)={5} on
activation of step s2 in GMain. An SFC that shall show similar behaviour needs to have corresponding additional transitions and links. The
partial-Grafcet G1 will stay in the situation sit ( t + x )={5} during the time x that s2 is active. Even when transition t13 is fireable, the active
forcing order suppresses its firing. All transitions in the corresponding SFC need to be extended so that they will not fire while the forcing
order is active. This is achieved by conjunction of the transition conditions of the forced Grafcet G1 and the negated status variable of s2 in
GMain.
Fig. 1b) shows the corresponding SFC implementation that preserves the hierarchical structuring of the Grafcet and implements the
implicit links. The resulting SFC is still easy to read because there are only a few additional links that are easy to handle. However, if the
Grafcet contains parallel branches, the number of implicit transitions increases greatly because of the necessity of combining all steps of
parallel branches.
Comparing the original Grafcet to its corresponding SFC, it becomes apparent that already quite simple Grafcets result in relatively
complicated SFC implementations. With respect to the quality metrics:

Fig. 1. Simple example for the transformation of forcing. a) Forcing in GRAFCET. b) Similar behaviour in SFC.
 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 177

Semantical equivalence
The lack of transient states in SFC is a major difference to the dynamic behaviour of Grafcet. This can, for example, result in undesired
behaviour of forcing orders. To overcome this, it would be necessary to limit the Grafcet design in a way that transient evolution cannot
happen (e.g. by enforcing mutually exclusive subsequent transitions).

Portability
The different execution orders and transition evaluation priorities of the different vendors make it impossible to guarantee that the
transformed code will behave the same on any hardware. This quality metrics is violated.

Readability
The SFC in Fig. 1 is a good example of how the usage of SFC violates this quality metrics. The additional elements required to implement
the implicit links of the hierarchical element result in a confusing and hard-to-read SFC.

Maintainability
Minor modifications include the variation of transitions conditions and actions. The transformation does not add redundancy or hidden
links between actions or transitions, so this quality metrics is met.

2.2.3. Structured Text

Structured Text is a Pascal-like high-level programming language. As such it includes loops, mathematical functions, iteration, and
conditional execution. Its higher abstraction level compared to IL offers better readability and more intuitive programming to today's users
that are usually familiar with at least one C-like language. The downside of compiled ST code is that it is generally slower than a direct
implementation in IL. However, due to fast execution times, this issue can be neglected in the context of modern PLC systems.
Although Instruction List is taken in Frey (2000) as a target language for transforming signal interpreted Petri nets into a IEC 61131-3
implementation, the general approach described in Frey (2000) can serve as a guideline for a transformation into any text-based pro-
gramming language, such as ST. Places, which correspond to steps in GRAFCET, are implemented as Boolean variables that indicate
whether a place is marked or unmarked. The program constantly evaluates all transitions as to if they are enabled and fireable. If so, the
Boolean variable of the preceding step is deactivated and the one of the succeeding step activated. This textual implementation of a
sequencer is a quite basic approach in PLC programming. In essence, such an implementation is a textual description of the Grafcet's
dynamic behaviour and enables the explicit modelling of the systems execution, which is implicit in SFC and cannot be altered. Such an
implementation in Structured Text requires a GRAFCET interpretation algorithm for sequential systems, which is defined in Section 3.2.
The discussion of the quality metrics shows why we favoured Structured Text as a target language for the transformation.

Semantical equivalence
The possibility of implementing transient behaviour allows semantically equivalence between GRAFCET and the PLC implementation.
Furthermore, a GRAFCET interpretation algorithm for sequential systems can directly be implemented, including the possibility to
influence the evaluation order of elements.

Portability
Control code written in Structured Text is suitable for any type of PLC. There are still some limitations regarding the portability, but
these result mostly from different implementation stages of new IEC 61131-3 elements and data exchange formats, and are not of
conceptual nature. The way in which each system saves the information is not compatible. However, the concept is applicable to any
kind of PLC system that supports a defined import format and method-oriented properties.

Readability
A control program written in a textual language requires more effort to understand the program than a simple graphical representation.
However, the implicit links and additional elements required to model hierarchical behaviour are separated from the standard set of
methods.

Maintainability
To change a transition condition or an action's output behaviour, only one line in one method needs to be changed. This quality metrics is met.

ST is the only IEC 61131-3 language, that satisfies our expectations with respect to the quality metrics. The reduced readability of ST
compared to SFC can be compensated by using a smart function block shell. Therefore, ST has been chosen as the target language.

3. GRAFCET interpretation algorithm for sequential systems

3.1. Formal model of GRAFCET

To be able to transform a Grafcet into an IEC 61131-3 implementation, or in fact into any other representation, it is necessary to have a
formal model of the GRAFCET syntax. On that basis, a transformation algorithm is able to identify the GRAFCET elements and to transform
them. The main aspects of the formal definitions given in Schumacher and Fay (2014) are repeated here in terms of the following defi-
nitions, which are based on Provost, Roussel, and Faure (2011b) and are extended by the notions of enclosures and forcing orders. These
definitions will be used afterwards as a basis for the development of a GRAFCET interpretation algorithm for sequential systems:
A Grafcet G is a 4-tuple (IG, OG, CG, SInitG) where IG is the non-empty set of logic inputs, OG is the non-empty set of logic outputs, CG is
the set of GRAFCET charts and SInitG is the set of initial steps.
Macro-step expansions and enclosed partial-Grafcets are different from other GRAFCET charts in the way that they contain a set of
‘special steps’. Thus, the charts set is divided into the set CC of classical charts, the set CM of macro-step expansion charts and the set CE of
enclosed partial-Grafcets.

A classical chart c∈ CC is defined by a 4-tuple (m, S, T, A) where m is the name of the chart, S is the non-empty finite set of steps s (s∈c), T
is the finite set of transitions t (t∈c) and A is the finite set of actions a (a∈c).
178 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

A macro-step expansion chart cm∈ CM is defined by a 6-tuple (m, sI, sO, Soth, T, A) where m is the macro-step name, sI is the input step of
the expansion, sO is the output step of the expansion, Soth is the finite set of other steps s (s∈cm), T is the finite set of transitions t (t∈cm)
and A is the finite set of actions a (a∈cm).

An enclosed partial-Grafcet (or partial-Grafcet of enclosed steps) enc ∈ CE is defined by a 5-tuple (xm, Sact, Soth, T, A) where xm is the
name of the enclosure, Sact is the non-empty set of steps with an activation link sx (sx∈enc), Soth is the finite set of other steps s (s∈enc),
T is the finite set of transitions t (t∈enc) and A is the finite set of actions a (a∈enc).

The step sets are divided into the sets of normal steps Ss, the sets of macro-steps Sm and the sets of enclosures Se. All steps
s∈( Ss∪ Sm∪ Se) are 3-tuples (m, x, t) where m is the name of s, x is a boolean variable indicating if s is active or not and t is a timer variable
indicating the active duration of s.
Let S(cm) be the set of all steps of the macro-step expansion chart cm (S(cm) = {sI, sO} ∪ Soth ), S(enc) be the set of all steps of the enclosed
partial-Grafcet enc ( S(enc) = Senc∪ Soth ) and SG be the set of all steps s of the Grafcet.
A transition t∈ T of a chart c is defined by a 3-tuple (SB, SA, ECond(IG,SG)) where SB is the set of immediate predecessor steps of t
(before), SA is the set of immediate successor steps of t (after) and ECond(IG,SG) is a transition condition. It is a boolean expression of inputs
and step activity variables.
Let TG be the set of all transitions t of a Grafcet. The set of actions A is divided into the set AS of stored actions with a set of associated
outputs OS, the set AC of continuous actions with outputs OC and the set AF of forcing orders. The union of OS and OC forms the output set
OG of a Grafcet OG=OS∪ OC . Let AG be the set of all actions a of a Grafcet. Let AGS, AGC and AGF be the sets of all stored actions aS, all
continuous actions aC and all forcing orders aF of a Grafcet accordingly:

A continuous action aC∈ AC of a chart c is defined by a 3-tuple (s, o,ECond(IG,SG)) where s is the step to which the action is connected, o
is the output which is manipulated by the action and ECond(IG,SG) is a continuous action condition, consisting of a boolean expression
on inputs and step activity variables.

A stored action aS∈ AS of a chart c is defined by a 4-tuple (s, o, val, inst) where s is the step to which the action is connected, o is the
output which is allocated by the action, val is the value that is assigned to the output and inst is the instant when the allocation is done:
inst ∈ {StepActivation, StepDeactivation}.

A forcing order aF∈ AF of a chart c is a 4-tuple (s, c, op, sit) where s is the step to which the action is connected, c is the forced partial-
Grafcet from the set of classical charts ( c∈ CC ), op is the kind of forcing operation: op ∈ {Spec, Init , Current , Empty}, where Spec is a
specific situation of the forced partial-Grafcet, Init is the initial situation, Current is the current situation and Empty is the empty situation
where no step is active. sit is the set of steps s∈ S of the forced partial-Grafcet that marks the forced situation.

3.2. GRAFCET interpretation algorithm

The formal definition of GRAFCET in Schumacher and Fay (2014) results in an interpretation of each Grafcet as a CIPN. This approach is
based on David and Alla (2010), where a discussion of the similarity of GRAFCET and CIPN together with the Algebra of Events results in the
two following statements:

If a CIPN is interpreted as a Grafcet, it has exactly the same behaviour.

If a Grafcet is interpreted as a CIPN, it has exactly the same behaviour.

The interpretation algorithm for a CIPN explicitly states that this algorithm could be a basis for transforming Grafcet into an IEC 61131-3
implementation. The algorithm gives respect to transient evolution and includes an evolution cycle that tries to find a stable marking.
However the CIPN interpretation algorithm is limited to a Basic Grafcet, i.e. a Grafcet without the hierarchical elements. Within the authors’
approach this interpretation algorithm is extended by the notion of the hierarchical elements macro-step, enclosure and forcing order. The
resulting GRAFCET interpretation algorithm (Annex 1) is the basis for the implementation of GRAFCET in an IEC 61131-3 code
environment.
Experimenting with different possible implementations for the execution algorithm, some interesting properties related to the execution
order of the different steps came across. It turns out that these properties apply to all execution models of step-transition systems and are
discussed in greater detail in Hellgren et al. (2005) on the example of SFCs. There are two main aspects of the execution of GRAFCET. One is
the evolution model, i.e. the firing of transitions and activation / deactivation of corresponding steps. The other is the activity model, i.e. the
execution of actions. Concerning the evolution model the authors of Hellgren et al. (2005) differentiate between the deferred transit evolution
model (DTE) and the immediate transit evolution model (ITE). In the DTE all transition conditions are evaluated first, afterwards all transitions
that were marked fireable fire one by one. The ITE evaluates a transition condition and immediately fires a transition if it is fireable before it
continues with the evaluation of the next transition. To model the behaviour of a Grafcet, where all transitions that are fireable fire at the same
time, the use of the DTE is appropriate. Otherwise, the firing of a transition t1 could remove the token from a predecessor step of another
transition t2. Thus, this transition would not be able to fire anymore, although it was supposed to fire together with t1.
Unlike Hellgren et al. (2005) we also consider transient evolution for our algorithm. During transient evolution the transitions only
"see" that step activity variables change, while all other variables remain unchanged. This is due to the fact that such an evolution has
theoretically no duration in GRAFCET. To achieve transient evolution we need to distinguish between the set of enabled transitions
EnTrans = t ∈ TG| t.ECond == true

and the set of fireable transitions

FireTrans = t ∈ EnTrans ∧ ∀ s ∈ t.SB| s.x = = true

Transitions are marked as enabled before an evolution cycle. During the evolution cycle, only the fireability of transitions is updated. The
activity models can be distinguished in a deferred action activity model (DAA) and an immediate action activity model (IAA). In
 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 179

correspondence to the evolution models the actions in the DAA are executed after all transitions have fired and all steps are activated /
deactivated. In the IAA, the execution of an action is directly linked to the activation / deactivation of a step. Since continuous actions in
GRAFCET are only executed once a stable marking has been reached, using the IAA for continuous actions, however, is not possible. In the
evolution cycle a stable marking has to be found first. On that basis the continuous actions can be executed one by one afterwards. For
stored actions both approaches are possible when using the DTE model. For the sake of simplicity, we decided to use the DAA model for
both stored and continuous actions. Note that these models and the resulting algorithms only consider the order of the different execution
steps of a GRAFCET interpretation. They do not include any information on the order in which the several sets of elements are evaluated
(e.g. the order in which transitions are checked for fireability).
An assumption underlying the handling of macro-step expansions is that the transition preceding a macro-step can only fire when the
exit step of the expansion is active. This can be achieved by including the exit step of the expansion to the set of preceding steps of the
transition. Extending the transition condition with a respective statement is not an option, since this only affects the enabling but not the
fireability of the transition. Though, this means that a macro-step expansion cannot be traversed entirely during transient evolution. The
same behaviour without this assumption can also be achieved via manipulating the transition condition on activation of the entry step and
exit step, similar to the forcing activities. This has in fact been done in the transformation prototype.

4. Transformation concept to ST

4.1. Function block shells

Following the approach of implementing the GRAFCET interpretation algorithm to ST, a boolean variable for every step and transition is
needed. To model the dynamic behaviour according to the GRAFCET interpretation algorithm for sequential systems, a standard set of
methods represents each step of the algorithm. To the best knowledge of the authors this transformation concept is the first to use the
target language ST for preservation of hierarchical structures and include method-oriented elements for GRAFCET. Annex 2 shows a
mapping of these methods to the algorithm steps with a short comment on the functionality. As described in the introduction, the general
objective of the transformation is to create a separate POU, i.e., a function block, for each partial-Grafcet. Irrespective of the type of Grafcet
chart, each function block consists of the set of standard methods in Annex 2. A function block that includes a set of methods with empty
bodies is called a shell in the context of this work (Fig. 2 and 3)
A function block has to provide an additional set of special methods that model the implicit links within the partial-Grafcet. For the
different types of partial-Grafcets, these additional methods are:
Classical chart. A classical chart can always be a forced Grafcet and thus needs to provide corresponding methods:

activateStateS*(): Necessary to activate steps of a forced situation. Since a forced Grafcet does not know about its possible forced si-
tuations, this method has to be provided for every step.

activateInitSituation(): Necessary to activate the initial situation (not known from the outside)

deactivateAllSteps(): First step in bringing the function block to the forced situation.

get/set forcedflag: Getter and setter for the forced flag that prevents transitions from firing.

Macro-step expansion:

activate(): Sets the active flag to true.

initializeAndStop(): Activates the entry step and sets the active flag to false so that no transitions fire and no actions execute anymore.

getFinishedFlag(): Returns true if the exit step of the macro-step expansion is active. This function has to be part of the fireability
condition that succeeds the macro-step.

Fig. 2. Main program coordinating a partial-Grafcet G1.

180 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

Fig. 3. Tools and file formats used during transformation.

Fig. 4. Activity diagram of the transformation program.

Enclosed partial-Grafcet:

activate(): Sets the active flag to true.

initializeAndStop(): Activates all enclosed steps and sets the active flag to false so that no transitions fire and no actions execute
anymore.

This method-oriented approach requires a coordinator that repeatedly calls the methods of the several function blocks, i.e. a Structured
Text representation of the GRAFCET interpretation algorithm. This program is called the main program in the context of this work. Fig. 4
shows the main program that coordinates one simple partial-Grafcet G1 and works as follows: The first query checks if the program has
been started during this cycle. It calls the storedActions() methods for all function blocks. Next is the evaluation of transition conditions. The
program calls all stateEvolution(), storedAction() and evaluateFirebleTransitions() methods for all function blocks repeatedly in a while-loop.
This will ensure a correct transient behaviour of the program. Finally, all continuous actions will be set depending on the actual situation of
the Grafcet.
 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 181

On the implementation level, the main program is the POU that is linked to the PLC task manager. An important aspect of the
transformation concept is the evaluation order of methods and elements. Since the PLC works in a sequential way and executes the
program line-by-line, the evaluation of GRAFCET elements depends on their position in the source code. When the design re-
strictions presented in the previous section are met, the evaluation order does not have an effect on the dynamic behaviour of the
Grafcet. Nevertheless, an execution order is needed that follows a defined rule to ensure transparent program behaviour. The
activation of steps of a forced situation depends on the ordering of steps in the forcing order, which is evaluated from left to right.
The execution order is also important for the main program. The order in which the methods of the different function blocks are
called has to follow a certain principle. The current approach uses the internal ordering of charts in the GRAFCET editor, since the
syntax does not include any priority measure as well. This aspect is picked up in the conclusion where a possible improvement of
the ordering of partial-Grafcets is discussed.

4.2. Transformation rules

The aim is to develop a new one-to-one correspondence transformation approach according to the identified target language ST. The current
approach is limited to a unidirectional transformation from GRAFCET to IEC 61131-3, although the final concept could also be applied to a
bidirectional approach. For any GRAFCET element, e.g., a transition, there is a corresponding set of Structured Text elements that is included in
the control program. These pairs of GRAFCET elements and Structured Text fragments are called transformation rules. If, e.g., the transformation
algorithm detects a GRAFCET transition t1 with the condition cond, predecessor state s1 and successor state s2 in a partial-Grafcet,

it creates the boolean variables t1 for the evaluation of the transition condition and ft1 for the evaluation of the fireability of the
transition. It adds these to the interface of the function block.

it adds the line t1=cond; to the method evaluateTransitions() of the function block.

it adds the line ft 1≔ t1AND s1; to the method evaluateFireableTransitions()of the function block.

it adds the block below to the method stateEvolution()of the function block.

IF ft1 THEN
stableState:¼ false;
S1: ¼ 0;
S2: ¼ 1;
END_IF
The transformation rules for all GRAFCET elements, except event-based and time-dependent elements, are defined in Annex 3. Time-
dependent and event-based elements can be included into the approach following the method described by the authors in Schumacher
and Fay (2013).

5. Tool support

5.1. Process steps of the transformation

The starting point of the transformation concept is a GRAFCET specification, available in an open file format. This specification is used to
construct a GRAFCET meta-model that can be analyzed by the transformation algorithm. The next step is the transformation itself: For
each partial-Grafcet in the specification, a function-block shell is created in a Structured Text meta-model. Afterwards, the algorithm reads
each GRAFCET element and fills the function-block shells according to the transformation rules. The finalization of the transformation
process is the creation of an IEC 61131-3 control program in Structured Text.

5.2. Prototypical implementation of the transformation concept

The work on this article includes the development of a prototypical transformation program that serves as a proof-of-concept for the
preceding considerations. Fig. 5 shows the different tools and file formats used during the transformation process.
Referred to our investigations in 2013, all known GRAFCET editors use proprietary file formats to store the information about the
designed Grafcets. A new editor had to be designed that stores the GRAFCET information in a standardized open file format. Part of
the work presented in Schumacher and Fay (2014) was the development of a GRAFCET-editor based on Microsoft Visio (MS Visio),
which complied best with the requirements. To integrate the automatically generated ST-code into the IEC 61131-3 software de-
velopment environment, a comprehensive and vendor-independent interface is needed. PLCopenXML (PLCopen TC6, 2009) is a data
exchange format provided by the PLCopen organization which meets these requirements. The PLCopenXML schema maps the
structure of an IEC 61131-3 program or POU into a corresponding XML tree. It consists of a set of attributes like name and type of
POU, an interface that contains the declaration of all variables and a body. This structure is following the current standard of
software development tools rather than strictly following the norm. For the declaration of simple function blocks in the ST lan-
guage, the IEC 61131-3 suggests one coherent code block that includes a variable declaration block in the beginning, followed by
the function block's body.
The transformation program is structured into three main classes. The class XMLReader reads the GRAFCET information from
the Visio XML-file and stores the GRAFCET meta-model. During the transfer, the elements in the internal object model are sorted
according to their position on the Grafcet to ensure predictive behaviour. Its counterpart is the class PLCOpenXMLWriter that takes
the IEC61131-3 meta-model and creates a PLCOpenXML file. The application of the transformation rules is part of the converter
class. For each partial-Grafcet in the GRAFCET meta-model, it reads and transforms all transitions, steps and actions element by
element according to their position in the object lists. Depending on the characteristics of the elements (e.g., a transition that is
182 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

Fig. 5. Example of a Grafcet.

followed by a standard step vs. a transition followed by a macro-step), the respective transformation rules are applied. Fig. 4 shows
an activity-diagram that illustrates an extract of the control flow.
To ensure correct functionality of the approach described in this work, the test of the prototype has to follow two main goals:

Simulate the produced IEC 61131-3 Structured Text code and check the dynamic behaviour against the GRAFCET specification (check if
the concept is right).

Check if the transformation program fulfils the transformation rules (check if the transformation is done right).

Since all GRAFCET elements are read and transformed separately, checking the correct application of the transformation rules
means finding a test case that contains a combination of GRAFCET elements such that each transformation rule is applied at
least once. The transformation rules are independent from each other, so if this test succeeds, the second test goal can be
considered achieved. Referring to the activity diagram, the aim is to find a test case so that the transformation program tra-
verses each branch of the diagram at least once. The transformation rules for some elements depend on the type of the partial-
Grafcet to which they belong. Thus, a comprehensive test case needs to contain a combination of all these elements in all types
of partial-Grafcets. All tests performed on the transformation program were successful, i.e., all transformation rules were ap-
plied correctly.
The only manual task that needs to be done in the transformation process is the creation of a configuration inside CODESYS (CODESYS).
CODESYS offers an integrated Soft-PLC, named CODESYS Win Control V3, that emulates an industrial controller under Windows. A con-
figuration that makes use of this Soft-PLC is the default setting in CODESYS. Using this configuration, it was possible to read the Visio-XML
files, transform them into PLCopenXML files and import these into the CODESYS software development. The resulting control programs
can be executed without any further manual modifications. To test the dynamic behaviour of the transformed code, these simulation
capabilities were used with the given set of test cases.
The focus of this part of the test was on the following aspects:

Transient state evolution during one execution cycle

Evaluation of stored actions and skipping of continuous actions during one execution cycle

Correct activation / deactivation of partial-Grafcets with their corresponding hierarchical elements

Correct state of the program on start of the application

Using the integrated debugger and running the generated program cycle by cycle, the state and output of the program for selected
 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 183

Table 1
Test cases for the Grafcet example in Fig. 5.

Cycle Active Inputs INT1 INT 2 Active Steps Active Outputs AO_2

0 - 3 6 1 - 0
1 DI_1 3 6 2, M1, 12 DO_14 0
2 DI_2, DI_15 3 6 3, M1, S1, 7 - 3
3 DI_10 3 6 3, M1, S1, 8 - 3
4 DI_11 3 6 3, M1, S1, 6 - 1
5 DI_3 3 6 4 - 1

input sequences was compared to the theoretical results of the underlying Grafcet according to the evolution rules defined in IEC 60848
(2013). All tests for the current implementation scope of the program were successful, i.e., the state of the program was equal to the
calculated Grafcet situation. As part of our ongoing research, aiming at the enhancement of the research results presented in this article, an
integrated software tool will be developed based on a model-driven approach and implemented in an open source tool.

5.3. Application example

An application example shall show how the system was tested for equivalent dynamic behaviour.
Consider the Grafcet example in Fig. 5. The global Grafcet GMain includes a macro-step and an enclosure, with M1 and X3/G2 as the
corresponding partial-Grafcets. Table 1 shows the test cases that were used to compare the dynamic behaviour of the IEC 61131-3 program
to the manually calculated results for the Grafcet. The initial situation is given by the initial step s1 in GMain and arbitrary chosen default
values for the numeric input variables INT1, INT2 and the numeric output variable AO_2. All other Boolean input and output signals are
false by default (Cycle 0). In Cycle 1, transient behaviour can be observed. The activation of the input DI_1 leads to the firing of transition t1
and the activation of the steps s2 and sM1. The latter activates the macro-step expansion and thus step sE1. Because transition t22 is fireable,
it fires immediately, deactivates step sE1 and activates step s12. Step sE1 has thus been part of an unstable situation.
Comprehensive information about the succeeding iterations can be derived from Table 1. In cycle 2, the activation of the enclosure
3 activates the corresponding partial-Grafcet with the enclosed step s7. The stored action associated to step s7 sets AO_2 to 3. The de-
activation of step s12 also deactivates the output DO_14 of the corresponding continuous action.
While cycle 3 is a normal evolution step, cycle 4 leads to transient evolution again. When transition t15 fires transition t11 will fire
immediately because it has been enabled all the time. The resulting activation of step s6 leads to the execution of the corresponding stored
action which sets AO_2 to 1. In cycle 5, transition t3 can fire because step s3 and sM1 are enabled and the macro-step expansion of M1 has
reached the exit step sS1. After the firing, all steps of the enclosed partial-Grafcet X3/G2 and the macro-step expansion M1 are inactive.
Nevertheless, the outputs that have been manipulated by stored actions in one of these partial-Grafcets before keep their current value.
The test cases with the input sequence of table above resulted in the same dynamic behaviour of the transformed IEC 61131-3 im-
plementation as it was calculated in the table.
Annex 4 shows an excerpt of the IEC 61131-3 control program after transformation of the Grafcet given in Fig. 5.

6. Summary and outlook

Within this article, the authors have presented an automated generation approach of PLC code from a GRAFCET specification, with ST as
the target control programming language. The resulting control program preserves the initial hierarchical structure of the Grafcet without
the need for normalization, as was required in previous approaches. An interpretation algorithm for GRAFCET on sequential systems has
been extended by the notion of hierarchical elements to allow an unambiguous interpretation of GRAFCET elements and dependencies. A
prototypical implementation of the transformation concept allowed to successfully test the resulting control programs against the initial
GRAFCET specification. The approach has been validated by a comparison of the structure, content and behaviour of the automatically
generated code with code which had been implemented manually by human PLC programmers, based only on the GRAFCET specification.
The validation has first been carried out for each single transformation rule (see Annex 3) and for each step of the algorithm (see Annex
1 and Annex 2). Finally, larger examples of control programs, which control a machine or a manufacturing cell, have been used for the
validation. The automatically generated PLC program and the program created by the human PLC programmer have shown the same
behaviour.
In their further work, the authors intend to include time dependencies into the transformation algorithms. A formal method already
exists, as presented in Schumacher and Fay (2013, 2014). Furthermore, the authors will exploit a model-driven approach in an open-source
framework.
Concerning the prototypical implementation, an important aspect is the evaluation order of GRAFCET elements in the trans-
formed Structured Text code. The current approach uses implicit information, mainly the relative positions of the GRAFCET ele-
ments on the chart. It would be desirable to be able to define an explicit ordering within the GRAFCET editor, e.g., by introducing
priority information.
184 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

Annex 1. GRAFCET interpretation algorithm

R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 185
186 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194
 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 187

Annex 2. List of methods corresponding to the steps of the Grafcet interpretation algorithm for the implementation of Grafcet inter-
pretation algorithm with IEC 61131-3 Structured Text methods
188 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

Annex 3. Transformation rules

The transformation is based on one-to-one correspondence of Grafcet-elements to Structured Text code fragments. The following table
represents these transformation rules. After initializing and creating the code shells, each Grafcet-element is analysed and the corre-
sponding code fragments are added to the specific position in the shell which is tagged in green. The transformation rules of certain
Grafcet elements depend on the type of their partial-Grafcet. A basic set of transformation rules applies to all types of partial-Grafcets. The
transformation rules given in the following tables apply in addition to the set of basic rules. If a transformation rule for an element differs
from the set of basic rules, it is marked with &overwrite. Note that the IEC 61131-3 suggests to write Structured Text constructs in capital
letters, which has not been done here for the sake of readability (Table 2,3,4 and 5).
 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 189

Table 2
Basic Transformation Rules.
190 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

Table 2 (continued )
 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 191

Table 2 (continued )
192 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

Table 3
Additional Transformation Rules in a Classical Chart.

Table 4
Additional Transformation Rules in an Enclosed Grafcet.
 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194 193

Table 5
Additional Transformation Rule in a Macro-step Expansion.

Annex 4. Generated code of the application example

See Fig. 6

Fig. 6. Excerpt of the IEC 61131-3 control program after transformation of the Grafcet given in Fig. 5.
194 R. Julius et al. / Control Engineering Practice 64 (2017) 173–194

References

Alvarez, M. L, Burgos, A., Sarachaga, I., Estévez, E., & Marcos, M. (2012). GEMMA based approach for generating PLCopen automation projects. In Proceedings of IFAC conference
on embedded systems, computational intelligence and telematics in control, Wuerzburg, 03.-05.04.2012.
Bauer, N., et al. (2004). A unifying semantics for sequential function charts (Lecture notes in computer science) In: David Hutchison (Ed.), Integration of software specification
techniques for applications in engineering (pp. 400–418). Berlin, Heidelberg: Springer Berlin Heidelberg.
Braun, S., Obermeier, M., & Vogel-Heuser, B. (2012). Usability challenges in the design workflow of reusable PLC software for machine and plant automation. In Proceedings of
the 9th international multi-conference on Systems, Signals and Devices (SSD).
CODESYS. 〈http://www.codesys.com/〉 (Last access: 19 January 2016).
David, R., & Alla, H. (2010). Discrete, continuous and hybrid Petri nets. Berlin: Springer.
Devroey, X., Perrouin, G., Cordy, M., Legay, A., Schobbens, P. Y., & Heymans, P. (2014). State machine flattening: mapping study and assessment. CoRRabs/1403.5398.
Durey, A. (1997). Transforming engineering concepts for technical and vocational teacher education in France In: M. J. de Vries, & A. Tamir (Eds.), Shaping concepts of
technology (pp. 181–201). Dordrecht: Springer Netherlands.
Frey, G. & Litz, L. (2000). Formal methods in plc programming. In: Proceedings of Tagungsband "IEEE international conference on systems, man, and cybernetics" (S. pp. 2431–
2436). Nashville (USA), 08.-11.10.2000.
Frey, G. (2000). Automatic Implementation of Petri net based Control Algorithms on PLC. In: Proceedings of American control conference, Chicago, 28.-30.06.2000.
Frey, G. (2000). Software Quality in Logic Controller Programming. In: Proceedings IEEE SMC , Tunisia, 06.-09.10.2002.
Gonzalez, E., Marichal, R., & Hamilton, A. (2016). Ontology-based approach to Basic Grafcet formalization. Journal of the Chinese Institute of Engineers. , http://dx.doi.org/
10.1080/02533839.2016.1215939.
Helke, S., & Kammuller, F. (2016). Verification of statecharts using data abstraction. International Journal of Advanced Computer Science and Applications, 7(1).
Hellgren, A., Fabian, M., & Lennartson, B. (2005). On the execution of sequential function charts. Control Engineering Practice, 13(10), 1283–1293.
Huth, M., & Ryan, M. (2004). Logic in computer science: modelling and reasoning about systems. Cambridge University Press.
IEC 60848 (2013). GRAFCET, specification language for sequential function charts (3rd ed.).
IEC 61131-3 (2013). Programmable controllers—Part 3: programming languages (3rd ed.).
IEC 61499-1 (2012). Function Blocks - Part 1: Architecture (2rd ed.).
Johnson, T. L. (2007). Improving automation software dependability: A role for formal methods? In: Control Engineering Practice, 15(11), 1403–1415.
Klein, S., et al. (2002) Controller design for an FMS using Signal Interpreted Petri Nets and SFC: validation of both descriptions via model-checking. In Proceedings of American
control conference. Alaska, USA, 08.-10.05.2002.
Ljungkrantz, O., Akesson, K., Yuan, C., & Fabian, M. (2012). Towards industrial formal specification of programmable safety systems. IEEE Transactions on Control Systems
Technology, 20(6), 1567–1574.
Lukman, T., Godena, G., Gray, J., Hericko, M., & Strmcnik, S. (2013). Model-driven engineering of process control software – beyond device-centric abstractions. Control
Engineering Practice, 21(8), 1078–1096.
Marichal, R. L., & González, E. J. (2014). ULLSIMGRAF: An educational tool with syntax control for Grafcet notation. Computer Applications in Engineering Education, 22,
669–677.
Missal, D., Hirsch, M., & Hanisch, H. -M. (2007). Hierarchical distributed controllers – design and verification. In Proceedings of 2007 IEEE Conference on Emerging Technologies
and Factory Automation (EFTA 2007) (pp. 657–664). Patras, 2007.
OMG - Object Management Group (2015). Unified modelling language specification, superstructure, (V2.5). 〈http://www.omg.org/spec/UML/2.5/PDF〉.
Provost, J., Roussel, J.-M., & Faure, J.-M. (2011a). Translating Grafcet specifications into Mealy machines for conformance test purposes. Control Engineering Practice, 19(9),
947–957.
Provost, J., Roussel, J. -M., & Faure, J. -M. (2011b). A formal semantics for Grafcet specifications. In Proceedings of Automation Science and Engineering (CASE), Italy, 24.-
27.08.2011.
Racchetti, L., Fantuzzi, C., Tacconi, L., & Bonfe, M. (2014). The PLC UML State-chart design pattern. Emerging Technology and Factory Automation (ETFA) (pp. 1–4), 1–4.
Reisig, W. (2016). Understanding Petri nets: modelling techniques, analysis methods, case studies. Berlin, s.l.: Springer Berlin (Softcover reprint of the original 1st ed. 2013).
Schumacher, F., & Fay, A. (2014). Formal representation of GRAFCET to automatically generate control code. Control Engineering Practice, 33, 84–93. http://dx.doi.org/10.1016/j.
conengprac.2014.09.008.
Schumacher, F. & Fay, A. (2013). Transforming time constraints of a GRAFCET graph into a suitable Petri net formalism. In Proceedings of IEEE Int. Conf. Industrial Technology
(ICIT). Cape Town, South Africa, 22.-25. Februar 2013.
Schumacher, F., Schröck, S., & Fay, A. (2013). Transforming hierarchical concepts of GRAFCET into a suitable Petri net formalism. In Proceedings of IFAC symposium on
Manufacturing Modelling, Management and Control (MIM). Saint Petersburg, Russia, 19.-21.06.2013.
Sogbohossou, M., & Vianou, A. (2015). Formal modelling of Grafcets with time Petri nets. IEEE Transactions on Control Systems Technology, 23(5).
PLCopen TC6 (2009). XML Formats for IEC 61131-3, Version 2.01-Official Release.
Thramboulidis, K. (2013). IEC 61499 as an enabler of distributed and intelligent automation: a state-of-the-art review—a different view. Journal of Engineering (pp. 1–9), 1–9.
Thramboulidis, K., & Frey, G. (2011). Towards a model-driven IEC 61131-based development process in industrial automation. Journal of Software Engineering and Applications,
4(4), 217–226.
Vogel-Heuser, B., Obermeier, M., Braun, S., Sommer, K., Jobst, F., & Schweizer, K. (2013). Evaluation of a UML-based versus an IEC 61131-3-based software engineering
approach for teaching PLC programming. IEEE Transactions on Education, 56(3), 329–335.
Vogel-Heuser, B., Diedrich, Ch, Fay, A., Jeschke, S., Kowalewski, S., Wollschlaeger, M., & Göhner, P. (2014). Challenges for software engineering in automation. Journal of
Software Engineering and Applications(no. 7), 440–451. http://dx.doi.org/10.4236/jsea.2014.75041.
Vogel-Heuser{C}, B., {C}Witsch, {C}D., & Katzke, U.{C} (2005). Automatic code generation from a UML model to JEC 61131-3 and system configuration tools. In Proceedings of
2005. ICCA '05. International conference on control and automation (S. pp. 1034–1039). vol. 2.
Vyatkin, V. (2013). Software engineering in industrial automation: state-of-the-art review. IEEE Transactions on Industrial Informatics, 9(3), 1234–1249.
Witsch, D. & Vogel-Heuser, B. (2009). Close integration between UML and IEC 61131-3: New possibilities through object-oriented extensions. In Proceedings of 2009 IEEE
conference on emerging technologies & factory automation (S. pp. 1–6). Mallorca.
Witsch, D. & Vogel-Heuser, B. (2011). PLC-statecharts: an approach to integrate UML-statecharts in open-loop control engineering – aspects on behavioural semantics and
model-checking. In Proceedings of the 18th IFAC world congress (S. pp. 7866–7872). Milano (Italy), August 28 -September 2, 2011.