The Journal of Systems and Software 166 (2020) 110575

Contents lists available at ScienceDirect

The Journal of Systems and Software

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

A classification framework for automated control code generation in

industrial automationR
Heiko Koziolek a,∗, Andreas Burger a, Marie Platenius-Mohr a, Raoul Jetley b
a
ABB Corporate Research Center Germany, Wallstadter Str. 59, D-68526 Ladenburg, Germany
b
ABB Corporate Research, Bhoruka Tech Park, ITPL Main Rd, Mahadevapura, Bengaluru, Karnataka 560048, India

a r t i c l e i n f o a b s t r a c t

Article history: Software development for the automation of industrial facilities (e.g., oil platforms, chemical plants,
Received 25 July 2019 power plants, etc.) involves implementing control logic, often in IEC 61131-3 programming languages.
Revised 10 February 2020
Developing safe and efficient program code is expensive and today still requires substantial manual ef-
Accepted 14 March 2020
fort. Researchers have thus proposed numerous approaches for automatic control logic generation in the
Available online 16 March 2020
last two decades, but a systematic, in-depth analysis of their capabilities and assumptions is missing.
Keywords: This paper proposes a novel classification framework for control logic generation approaches defining cri-
Software design and implementation teria derived from industry best practices. The framework is applied to compare and analyze 13 different
Industrial automation control logic generation approaches. Prominent findings include different categories of control logic gen-
Control engineering eration approaches, the challenge of dealing with iterative engineering processes, and the need for more
Model-driven development experimental validations in larger case studies.
Code generation
UML / SysML © 2020 Elsevier Inc. All rights reserved.

1. Introduction for such plants come from automation customers or engineering

contractors, who often provide mostly informal specifications. Con-
Software development for industrial automation appli- trol engineers of automation providers partially import these spec-
cations requires substantial design and implementation ef- ifications into engineering software tools and manually interpret
forts (Gutermuth, 2010). Besides various client-server applications them to implement the required control logic (Urbas et al., 2012).
for supervision and monitoring in this domain, time-critical control This process exhibits media discontinuities, where data is manu-
software runs on real-time controllers and manages complex pro- ally transformed between different formats. This may lead to data
duction processes of chemical plants, power plants, oil platforms, inconsistencies requiring time-consuming feedback loops with the
pulp and paper mills, or steel mills (Martin and Hale, 2010). Con- customer. Furthermore, control engineers often use low-level pro-
trol engineers often create this control software in programming gramming abstractions (Lukman et al., 2013) and execute repet-
languages according to IEC 61131-3, namely function block dia- itive implementation tasks because of missing reusable compo-
grams, structured text, sequential function charts, ladder diagrams, nents (Schmidberger et al., 2006). Manually written code needs to
or instruction lists (Tiegelkamp and John, 1995). The software ex- be tested thoroughly to ensure safe plant operation.
ecutes cyclically and computes control signals for actuators, such Due to the high engineering costs, practitioners and researchers
as valves, motors, or robots, based on periodically sampled sensor have sought methods and tools for automating control logic de-
signals as inputs (e.g., for temperature, flow, pressure, level, etc.). velopment (Vyatkin, 2013). Practitioners introduced bulk engi-
The software ensures efficient and safe execution of the production neering to semi-automatically deal with list-based specifications
process. The development of this software is embedded into a and created engineering libraries to bundle reusable functional-
larger engineering process that also covers hardware engineering, ity (Gutermuth, 2010). Researchers worked on higher-level model-
HMI development, and device configuration (Gutermuth, 2010). ing languages (e.g., applying UML or SysML for industrial automa-
Engineering industrial plants is an expensive process today and tion (Vogel-Heuser et al., 2005)) and proposed rule-based code
may require several person years for a mid-sized plant with several generation approaches (Drath et al., 2006). An overview of these
thousand I/O points (Gutermuth, 2010). Requirements and designs approaches is missing, which complicates identifying and select-
ing an appropriate approach or to identify research opportuni-
ties. Existing literature reviews in this area (Vyatkin, 2013; Luk-
R
Edited by Prof Doo-Hwan Bae. man et al., 2013; Yang et al., 2014; Liebel et al., 2014; Vogel-Heuser
∗
Corresponding author.
et al., 2015) usually do not focus on the aspect of automatic code
E-mail address: [email protected] (H. Koziolek).

https://doi.org/10.1016/j.jss.2020.110575
0164-1212/© 2020 Elsevier Inc. All rights reserved.
2 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

generation and rather provide coarse-grained descriptions of sev- is based on the Festo MPS PA Compact Workstation1 a minimal di-
eral selected approaches. They do not provide detailed classifica- dactic plant for educational purposes (Steinegger and Zoitl, 2012).
tion frameworks nor mirror existing approaches against require-
ments from practice. In this work, we aim to close this gap. 2.1. Inputs
The contribution of this paper is a classification framework
for automated code generation approaches for IEC 61131-3 con- The inputs used by engineers for control logic implementa-
trol logic. The classification framework defines categories and cri- tion vary across different application domains. According to ANSI
teria to evaluate such code generation approaches. This can help / ISA 5.06.01-20072 (Functional Requirements Documentation for
researchers and practitioners to compare different approaches re- Control Software Applications), a User Requirements Specification
garding their capabilities. Using the classification framework, this (URS) includes piping and instrumentation diagrams (P&IDs), an
paper analyzes 13 different code generation approaches from lit- instrument list, and process flow diagrams. From these artifacts, in-
erature in the last 15 years. This analysis identifies patterns and strument tag table (or I/O list), interlock matrix, sequence matrix,
commonalities between the approaches as well as research gaps. and Human Machine Interface (HMI) are developed. These artifacts
Based on findings from the comparison, this paper also discusses are used as the Functional Requirements Specification (FRS), which
implications and required future work. also pertains other aspects besides control logic. However, projects
The 13 approaches map into three different categories: rule- often do not strictly follow this guideline and provide other or al-
based engineering, higher-level programming, and higher-level ternative artifacts. The following paragraphs detail P&IDs, I/O lists,
programming using a plant structure as input. Approaches within logic diagrams, control narratives, and flow charts, because they
the same category use similar input specifications. Most ap- are the most important inputs specifically for designing and im-
proaches have been demonstrated on small lab examples so far, plementing the control logic.
some approaches were tested in student experiments. Challenges P&IDs: A P&ID provides a graphical overview of a plant seg-
for all approaches are missing support for standard input formats, ment. There can be hundreds of P&IDs to describe a larger plant.
iterative engineering processes, and dealing with natural language For control logic engineering, they provide an important overview
requirements. Recent standardization initiatives could improve the of a plant and show the connections between the different in-
situation, warranting further research and more extensive valida- struments besides some explicit control loops. Fig. 2 shows an
tions. exemplary P&ID for a process where two substances are mixed,
This paper is structured as follows. Section 2 recaps basics heated, and then pumped into another tank. The diagram includes
of control logic generation using a running example, sketches a two large tanks (column shapes T101, T102), a pump (large circle
generic transformation process, and surveys inputs available in with inner spike), a motor (circle labeled ’M’), valves (small tri-
practice. Section 3 describes the research methodology underly- angles), pipes (lines), and various instruments (circles), which are
ing this study, provides a short overview on the identified ap- typical P&ID elements. The instruments describe required temper-
proaches, and then proposes and explains our classification frame- ature / flow / pressure / level sensors, controllers, and actuators
work. Section 4 applies the classification framework to the 13 iden- (e.g., valves, heaters). There are different standards for the shapes
tified approaches and provides a detailed analysis of their inputs, (e.g., ISO 10628, ANSI/ISA 5.1) and identifications in P&IDs (e.g., IEC
transformations, and outputs. Section 5 discusses selected find- 62424/ISO 3511, ISO 14617-6, ANSI/ISA 5.1) (Sun, 2013).
ings from the comparison in Section 4 and sketches challenges Nowadays, engineers usually specify P&IDs with dedicated CAD
to be tackled in future work. Section 6 analyzes threats to valid- tools, such as AutoCAD P&ID3 SmartPlant P&ID4 COMOS P&ID5 or
ity of the present study, and Section 7 summarizes related work. OpenPlant P&ID6 . Additionally, generic drawing tools support P&ID
Section 8 concludes the paper. visual shapes (e.g., from ISO 10628), such as Visio7 Edraw8 or
Lucidchart9 . Common file formats are AutoCAD DWG for generic
2. Control logic generation: Basics and requirements drawings (binary) and the AutoCAD DXF interchange format (plain
text). Several tools also support exports of equipment and instru-
Control engineers design and implement control logic based on ment lists to Microsoft Excel tables. However, in today’s engineer-
customer requirements and design specifications as well as avail- ing projects P&IDs are often only available as PDF exports contain-
able control libraries and industrial standards (Gutermuth, 2010). ing bitmaps for control engineers. Typically, this is not a problem
This section provides an overview of the available customer inputs to date, as they are usually subject to manual interpretation.
in practice, requirements, methods, and tools for model transfor- For automatic control logic generation, such an input is how-
mation and code generation, as well as different types of outputs, ever problematic. To overcome the challenge of dealing with
in terms of the different control logic parts and storage formats. bitmaps or vector-graphics, there are proposals to perform opti-
Fig. 1 provides a generic process model for control logic genera- cal symbol and character recognition on the PDF files (Tan et al.,
tion, whose different elements will be detailed in the following. 2016; Arroyo et al., 2016). Additionally, the DEXPI initiative10 is
Section 2.1 describes the available inputs in detail, Section 2.2 ex- working on a common XML P&ID file format based on ISO 1592611 .
plains each of the six transformation steps starting with “Input The CAEX XML file format (IEC 6242412 ) as part of AutomationML
Validation”, and Section 2.3 provides concepts and examples for
outputs of the transformation. 1
https://bit.ly/2XWjmfk.
Today, the implementation of control logic in practice is usu- 2
https://www.isa.org/store/ansi/isa- 50601- 2007- functional- requirements-docum
ally only partially making use of code generation, for example by entation-for-control-software-applications/116719.
importing information from I/O lists to create signal variables for 3
https://www.autodesk.com/.
the control code (Gutermuth, 2010). As a result, the implementa- 4
https://hexagonppm.com/.
5
tion process still requires control engineers a significant amount of https://www.siemens.com/comos.
6
manual interpretation to translate the customer specifications into https://www.bentley.com/.
7
https://visio.microsoft.com/.
control algorithms, which makes this procedure time-consuming 8
https://www.edrawsoft.com/.
and error-prone. Approaches for control logic generation aim to in- 9
https://www.lucidchart.com/.
crease the amount of generated code, both to shorten implemen- 10
https://dexpi.org/.
tation time and to improve quality. This section uses a running ex- 11
http://15926.org/.
ample of a simple production process to illustrate the concepts. It 12
https://webstore.iec.ch/publication/25442.
 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575 3

Fig. 1. Generic control logic generation process: six transformation steps with numerous inputs and outputs.

Fig. 3. Running Example: IO List describing signal properties.

and I/O objects that then can be connected with function blocks
to form the whole control logic. Control engineers then need
write glue logic (e.g., recipes, interlocks) among them. In addi-
tion to I/O lists, there can be electrical plans according to IEC
60617 (Steinegger and Zoitl, 2012).
Fig. 2. Running Example: P&ID describing equipment and instruments.
Control Narratives (Gutermuth, 2010): These prose writings
describe the intended control algorithms in an informal way, usu-
ally in a Microsoft Word document or PDF file. They may re-
(IEC 6271413 ), can be coupled with additional P&ID libraries (e.g.,
fer to tag names from the I/O list and provide steps for the
PandIX Schüller and Epple (2012)). However, there are hardly any
startup/shutdown of a plant or setpoints for regulatory control as
commercial CAD tool P&ID exporters for CAEX (Drath and Inge-
well as alarm procedures. This notation is easy and fast to create.
brigtsen, 2018) available so far.
It also allows the engineering contractor to abstract from technical
I/O lists: Fig. 3 shows a simplified I/O list for the running ex-
specifics of the target automation system (e.g., available typical li-
ample. A complete I/O list may include thousands of signals. Each
braries), and thus enables control engineers to optimize the logic
row is dedicated to a single signal. There are many columns speci-
(e.g., by mapping the intended logic to vendor-specific typicals).
fying properties of signals (tag name, revision, service description,
Logic Diagrams: ISA5.2–1976 (Binary Control Logic Diagrams
location, value ranges, engineering units, alarm limits, typical as-
for Process Operations)14 provides guidelines to create diagrams
signment, wiring types, references to P&IDs, etc.). There are no in-
for binary interlock and sequencing systems for startup, operation,
dustry standards for these properties, but companies usually use
alarm, shutdown of equipment and processes. Input and output
guidelines or internal standards. I/O lists are also known as tag
signals can be connected via AND/OR/NOT gates, as well as sym-
lists, instrument or signal indices. Control engineers consider them
bols to express timing relations. This notation is already similar to
as one of the most important inputs and they are usually provided
the actual control logic and therefore comparably easy to translate
in the form of large tables (Gutermuth, 2010).
to it. Engineering contractors usually create logic diagrams with
In the context of control logic generation, I/O lists can be au-
CAD tools or generic drawing tools. The structure and format of the
tomatically imported into control engineering tools to create tags

13 14
https://webstore.iec.ch/publication/32339. https://goo.gl/VpfpD4.
4 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

to IEC 61131-3 may be possible, an additional modeling tool adds

complexity to the tool chain (Schumacher and Fay, 2014). Some
engineering contractors therefore directly use SFCs to specify
sequences.
Other Inputs: Additional inputs may assist control engineers in
designing and implementing control logic.
• Alarm Lists (Steinegger and Zoitl, 2012): specify alarm limits
and support writing control logic to handle alarms.
• Cause & Effect Matrices (C&Es) (Breyfogle III et al., 20 0 0;
Drath et al., 2006): provide a streamlined table to intercon-
nect signals, which enables generating interlocking control
code. They can be partially or fully provided from engineer-
ing contractors due to safety regulations (ISO 10418).
• Control Logic Libraries (Ljungkrantz and Akesson, 2007):
containing pre-specified function blocks that capture higher-
level domain knowledge.
• Legacy Control Code (Fay et al., 2001; Fay, 2003a): often
available in migration (brownfield) projects. They can some-
times be translated into the control code of the target au-
tomation system.
• Domain Specific Inputs: these include for example System
Control Diagrams (SCD) for NORSOK-compliant oil and gas
facilities (Drath and Ingebrigtsen, 2018), or Scientific Appa-
Fig. 4. Running Example: Recipe as flow charts.
ratus Makers Association (SAMA) logic drawings22 for power
generation plants.
used logic blocks may vary between different organizations, which
2.2. Transformations
can complicate the control logic generation.
Flow Charts: Sequential control flow or recipes can also be ex-
Transforming the available inputs into valid control logic output
pressed with ordinary flow charts15 . Fig. 4 shows a flow chart for
requires a number of steps (Fig. 1) as detailed in the following.
the running example plant in a notation similar to UML activity
Input Validation: Inputs for control logic generation require
diagrams. It consists of three phases. First, by opening valve 103.2,
consistency and completeness checks (Barth et al., 2012). Human
tank T102 is drained to transfer both substances in T101. Subse-
engineers specify these artifacts often in an incremental manner
quently, the reaction starts in phase 2. The valves 101.5 and 101.9
with multiple data exchanges between engineering contractor and
open. Afterwards, the heater E104 and the pump driven by NC101.8
automation provider. Therefore, the data may be incomplete and
start. Once the temperature reaches 70 ◦ Celsius, pump and heater
the different artifacts may be inconsistent. For example, the I/O
switch off and valve 101.5 closes. Finally, tank T101 is drained us-
list in Fig. 3 may be missing specified ranges or specific tag names
ing the pump in phase 3.
might be inconsistent with the P&ID. The P&ID may contain uncon-
A specific flow chart notation is GRAFCET (“GRAphe Fonctionnel
nected pipes or missing properties of certain instruments. Some-
de Commande Etapes/Transitions”, IEC 6048416 ). It is a standard-
times the utilized CAD tools already provide consistency and com-
ized graphical modeling language for designing controller behav-
pleteness checks, but in other cases input validation by the au-
ior (Schumacher and Fay, 2014). GRAFCET was developed in France
tomation provider is required. This is crucial for control logic gen-
in the late 1970s, where it gained some industry adoption, and was
eration, since the applied algorithms cannot reliably compensate
also integrated into the curriculum of control practitioners in Ger-
for invalid inputs in contrast to a human engineer.
many. IEC 61131-3 Sequential Function Charts (SFC) are based on
Pre-processing: Some input artifacts are subject to pre-
GRAFCET and are considered as one of its possible implementa-
processing, usually to simplify the later translation or to sup-
tions.
port different output formats. This may be implemented using
UML or SysML17 -based flow chart notations are rather
in-place model transformations (i.e., endogenous transformations)
uncommon for engineering contractors and control engi-
or mapping to intermediate models (i.e., exogenous transforma-
neers (Thramboulidis, 2004; Friedrich and Vogel-Heuser, 2007;
tions) (Mens and Van Gorp, 2006). For example, the P&ID in
Schumacher and Fay, 2014). Researchers have previously devel-
Fig. 2 could be enhanced with flow paths to simplify code gen-
oped several UML profiles for process automation (e.g., UML-
eration (Drath et al., 2006). A code generation approach can also
PA (Katzke and Vogel-Heuser, 2005)), but they never became
map heterogeneous input data artifacts to a common interme-
formal OMG specifications18 . CODESYS UML19 and TwinCAT3
diate model so that the code generation becomes less compli-
UML20 allow the specification of class and state diagrams, but
cated (Steinegger and Zoitl, 2012; Arroyo et al., 2016). Unstructured
are meant for control engineering programmers, not automation
data, such as Control Narratives, may require human labeling or
customers. ANSI/ISA-8821 provides a standard notation for recipes
annotations, so that text mining approaches can perform appro-
in batch applications. While a mapping from UML state diagrams
priate information retrieval. For example, a setpoint for the motor
controller of the running example could be obtained from a narra-
15
https://www.iso.org/standard/11955.html. tive via text mining and then later be used in code generation.
16
https://webstore.iec.ch/publication/36840. Translation: Additional exogenous transformations translate in-
17
https://sysml.org/. put artifacts conforming to specific meta-models to output artifacts
18
https://www.omg.org/spec/category/uml-profile. conforming to other meta-models (Mens and Van Gorp, 2006). In
19
https://store.codesys.com/codesys-uml.html.
20
https://www.beckhoff.com/english.asp?twincat/tf1910.htm.
21 22
https://www.isa.org/isa88/. https://automationforum.co/what- is- sama- diagram/
 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575 5

such a documentation could also support testing and qualification

processes.
Backpropagation: Manual additions and changes to the gener-
ated code may need to get propagated back to the input artifacts.
This supports a shared understanding for the engineering contrac-
tor and control engineer and also serves documentation purposes
(i.e., to always have an up-to-date design and specification). For the
running example, changed tag names or alarm limits may need to
get translated back from the control code to the P&IDs or I/O lists.
This requirement suggests that the model transformation should
support some form of bidirectionality. The level of bidirectional-
ity is naturally higher for meta-models with higher similarity (e.g.,
flow charts and sequential function charts). In practice, such a re-
turn path from the control code back to the engineering contrac-
tor is rarely seen today because of the expensive manual over-
head. This practice often leads to outdated and inconsistent plan-
ning documents over the course of the plant life-cycle.
To implement the described transformation steps, there is a
plethora of method and tools for model-to-model (M2M) and
model-to-text transformations (M2T). Transformations can be im-
plemented with generic programming languages, such as Java, C++,
C# in case the input artifacts are available as object-oriented mod-
Fig. 5. Running Example: Sequential Function Chart (SFC). els. XML files may directly be mapped to other XML files us-
ing XSLT/XQuery. The OMG’s QVT (Query/View/Transformation) is
case of logic diagrams or flow charts (cf. Fig. 4) being used, this a standardized set of languages for model transformations, in-
involves an almost straightforward mapping to function block di- cluding imperative (QVT-O) and declarative (QVT-R) transforma-
agrams or sequential function charts (Fig. 5). In these cases, the tion languages. The Eclipse ecosystem includes a number of M2M-
underlying meta-models have a high similarity. transformations (Epsilon, Eclipse MMT) and M2T-transformations
Other input artifacts, such as P&IDs and control narratives, re- (Acceleo, JET, Xpand, Xtext), besides a common metamodel (Ecore)
quire specially prepared code generation rules stored in a knowl- and tools to create graphical editors. There are extensible IDEs for
edge base (Steinegger et al., 2016). Such rules can encode domain control logic code available (e.g., 4DIAC23 or Hardella24 based on
knowledge, e.g. referring to the running example “if the filling mbeddr25 ).
level of a tank (e.g., T101) is too high, then close a valve (e.g., via
YS103.2) connected to an inlet to the tank” (Drath et al., 2006). 2.3. Outputs
Rules may pertain different aspects of control logic, such as safety
interlocks, sequences, diagnostic routines, or optimizations. Rules Many commercial automation systems are still based on soft-
may be generic, domain-specific, or project-specific. Ideally, they ware development platforms mostly compliant to the IEC 61131-
are formulated in a domain-specific language familiar with the 3 specification (Otto and Hellmann, 2009) for programmable con-
control engineers (Krausser et al., 2011; Grüner et al., 2014b). trollers. This standard was originally published in 1993 and defines
Merging: The incremental nature of the engineering process, five programming languages: ladder diagrams (LD), function block
where partial input artifacts are exchanged multiple times between diagrams (FBD), sequential function charts (SFC), structured text
customers, engineering contractors, and automation providers in (ST) and instruction lists (IL). IEC 61,499 was published in 2005 as
successively higher refinement and completion states, makes a a partially backward-compatible enhancement of IEC 61131-3 with
one-shot translation impractical (Barth et al., 2012; Steinegger event-driven concepts, but has not gained widespread adoption in
et al., 2016). In the running example, an engineering contractor practice so far (Thramboulidis, 2013), although a number of aca-
may add new instrumentation to the P&ID and I/O list, e.g., a new demic approaches used it.
pressure sensor for one of the pipes, or change specific tagnames SFC: Fig. 5 shows an IEC 61131-3 SFC based on the recipe spec-
or alarm limits. Blindly overwriting code from former generation ification for the running example in Fig. 4. It includes four steps,
iterations may be problematic in case control engineers have al- which, in the tables on right-hand side, each trigger the setting
ready enhanced or optimized the code manually. Therefore, code (S) and resetting (R) of certain signals. The transitions between the
generation has to merge new additions from these refinements steps (black bars) are triggered by function blocks on the left-hand
into IEC 61131-3 code already generated in previous translations. side and involve simple timers and threshold conditions. This kind
The model transformation first needs to analyze the formerly gen- of control logic can be generated for example by mapping flow
erated code and properly merge the new additions. It also needs charts to SFCs or interpreting control narratives.
to protect manually written code and report any inconsistencies or FBD: Fig. 6 shows an IEC 61131-3 FBD for a number of inter-
incompleteness back to the control engineer. locks within the running example. On the left-hand side the di-
Documentation: A control engineer needs to understand the agram lists input signals, which trigger specific output signals on
model transformation process to be able to detect systematic er- the right-hand side. In this example, inputs and outputs are con-
rors and to speed up root cause analysis in case of code genera- nected by simple boolean (AND) and arithmetic (LE, less equal, GE,
tion errors. To support this requirement, a model transformation greater equal) function blocks as well as timers (TON/TOF).
can, for example, create a report of the code generation process, ST: Fig. 7 shows an IEC 61131-3 ST code snippet from
that provides a detailed list of the applied code generation rules the running example. The syntax of ST is similar to the Pas-
as well as any warnings and errors that may have occurred in the
process. Ideally, such a report allows directly accessing the erro- 23
https://www.eclipse.org/4diac/i.
neous input artifacts, affected rules or the code generation output 24
https://github.com/Hardella/ide61131.
to check. Besides creating more confidence of the control engineer, 25
http://mbeddr.com/.
6 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

generated and also process graphics can be partially generated out

of P&IDs (Schmitz and Epple, 2007; Doherr et al., 2013). Intermedi-
ate models for code generation may also be used during the plant
life cycle to create queries about the plant and to find root causes
of plant-wide disturbances (Yim et al., 2006).

3. Classification framework

3.1. Methodology

The objective of the present study is to classify research ap-

proaches for IEC 61131-3 code generation from the viewpoint of a
practicing control engineer. A detailed breakdown of each method’s
inputs and outputs helps to better understand the context the re-
searchers assumed and the method’s capabilities. The classification
supports identifying patterns between the approaches and to as-
sess their maturity levels.
We identified corresponding approaches using Google Scholar,
IEEE Digital Library, and ACM Library using the search term “61131
AND control AND code AND (generation OR transformation OR au-
tomatic OR automated OR model-driven)” (Kitchenham and Char-
Fig. 6. Running Example: Function Block Diagram (FBD). ters, 2007). The search initially identified 5350 works. From the
search results, we applied the following inclusion criteria to focus
on our research objective and viewpoint:
• IEC 61131-3 control code: Included approaches use at least
one of the five IEC 61131-3 languages as output to cover
a large range of commercial and open source control sys-
Fig. 7. Running Example: Structured Text (ST). tems. Excluded are approaches for example involving IEC
61499 (Hussain and Frey, 2006; Panjaitan and Frey, 2006;
cal programming language. It supports variable assignments, Thramboulidis and Buda, 2010; Thramboulidis, 2010), C-
if/case/for/while/repeat statements, as well as pointers and func- code, Simulink, or other PLC programming languages, be-
tion calls. The language also provides constructs to define func- cause they are either less widespread in practice or tackle
tion blocks as higher-level programming constructs. ST is often different application domains.
preferred for more complex mathematical computations in control • Code Generation: Included approaches provide concepts
logic. and possible implementations aiming at actual code gen-
Other outputs: Ladder diagrams are particularly popular in eration. Excluded are approaches that apply model trans-
North America, where many control engineers are not familiar formation on automation requirements for other purposes
with the IEC 61131-3 standard26 while FBD, ST, and SFCs are more (e.g., simulation (Barth and Fay, 2013; Arroyo et al., 2016),
popular in other parts of the world. ILs have been labeled ‘dep- test case generation (Suresh et al., 2019), asset manage-
recated’ in the latest release of the IEC 61131-3 specification. The ment (Schmidberger and Fay, 2007), loop performance as-
PLCopen association published the first XML formats for IEC 61131- sessment (Yim et al., 2006), HAZOP analysis (Fay et al.,
3 in 2005 Otto and Hellmann (2009), and has by now refined the 2009)). While additional transformation targets are helpful
specification as IEC 61131-10 PLCopen XML exchange format. to improve engineering, we limit the study to details of code
Today, control logic implementation is often based on instanti- generation as we aim at a deeper understanding of that pro-
ating template function blocks, so-called “typicals”, e.g., for valves, cess.
motors, from a function block library. A code generator can largely • Uses Inputs typically used in Practice: Included approaches
automate this task by exploiting properties in I/O lists which often rely on at least one of the inputs listed in Section 2, e.g.,
allow a one-to-one mapping of signals to typicals available in spe- I/O lists, P&IDs, flow charts. This excludes approaches requir-
cific libraries, also known as bulk engineering (Gutermuth, 2010). ing for example Petri Nets (Cutts and Rattigan, 1992; Jörns
Besides the initial variables for signals and the instantiated func- et al., 1995; Frey, 20 0 0; Music et al., 20 05) or timed au-
tion blocks, the control logic code consists of a number of dif- tomata (Wang et al., 2009) as input, which are not used in
ferent segments for different purposes (Guttel et al., 2008). These practice today.
include handling the nominal sequence (e.g., PID loops), alarms, • Journal/Conference publication: Included are peer-
startup/shutdown, asset monitoring, operations, diagnosis, inter- reviewed approaches published in a Journal or conference
locks, controller-to-controller communication and timeouts. Code proceedings. Approaches embedded into a commercial offer-
generation should address as many of these segments as possible ing may be highly relevant for practitioners (e.g., Simulink
to lower the manual implementation effort. PLC Coder, CODESYS UML (Tikhonov et al., 2014), TwinCAT3
Besides the control logic generation itself, a model transforma- UML), since they include commercial tooling and support.
tion tool chain for typical customer input artifacts can also be ex- However, they are excluded from the following classification
ploited for other purposes. The generation of simulation models to not favor a particular commercial vendor or because of
can support factory acceptance tests or plant modifications (Barth a lack of reliable information sources. Rivops AutoGen27
and Fay, 2013; Arroyo et al., 2016). Connections to HMIs may be generates control logic from an equipment list using Python
scripts, and most commercial DCS products offer similar
26
https://www.controleng.com/articles/iec- 61131- 3- whats- the- acceptance- rate- of
27
- this- control- programming- standard/. http://www.rivops.com/autogen
 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575 7

Fig. 9. Rule-based generation: high-level overview. The approaches extract informa-

tion from plant topology models and apply rule engines to generate control logic.

difficulty to construct robust, generic rule bases (i.e., appli-

cable for many projects) and the need for formalized in-
put artifacts so that the rules can be automatically applied.
These approaches correlate with the application domain pro-
Fig. 8. Map of Approaches (2005–2018): Arrows indicate citations. The approaches cess automation.
can be divided in three classes depending on whether they use a plant structure as 2. Higher-level Programming: These approaches
input and whether they use domain rules for code generation. [M4,M5,M6,M7,M8,M9,M10] require control engineers them-
selves to formalize requirements and design in a higher-level
modeling language (UML/SysML/GRAFCET) and then estab-
functionality (e.g., Simatic PCS7, Yokogawa Automation lish a mapping between the elements of the higher-level
Design Suite). DEIF PLC Link28 provides special model- language and IEC 61131-3 constructs. Early Petri Net-based
ing means for wind power applications and can produce approaches would also be in this class. The main benefit
PLCopen code. Actifsource Workbench29 and 4DIAC30 are is that the control engineers may be more productive us-
examples for IDEs that can generate control code, but are ing a high-level notation than directly IEC 61131-3. Draw-
also considered out of scope for this paper. backs are the limited amount of automation and the chal-
• Published after 2004: Included are papers less than 15 lenge to learn and maintain two different notations. These
years old to keep the classification concise, so that ap- approaches mainly originate from discrete manufacturing.
proaches from the 1990ths are neglected. We assume that 3. Higher-level Programming using Plant Structure: These
the conceptual contributions of these early approaches have hybrid approaches [M11,M12,M13] both take the plant struc-
influenced the design of the more recent approaches classi- ture into account and require control engineers to formal-
fied within this paper. ize additional requirements in higher-level languages, such
We applied a forward/backward reference search (Wohlin, 2014) as UML or SysML. They do not use rule-based generation.
on the identified approaches to increase literature coverage. We While these approaches may provide a richer starting point
combined multiple papers from the same authors if they referred by utilizing the plant structure, they inherit the same bene-
to the same approach (e.g., (Steinegger and Zoitl, 2012; Steineg- fits and drawbacks from the other higher-level programming
ger et al., 2016; 2017) or (Schumacher et al., 2013a; 2013b; Schu- approaches.
macher and Fay, 2014; Julius et al., 2017; 2019). Some of the ex-
cluded works will be discussed in Section 7. Fig. 9 provides a high-level overview of the rule-based genera-
tion approaches:
[M1] CAEX Transformer: This approach takes a P&ID encoded
3.2. Approaches Overview as a CAEX XML as input and first enhances the file with the LogIX
Model to group related equipment into lines. Afterwards it applies
Our survey contains 13 approaches from 2005 to 2018 (Fig. 8) a set of interlocking rules on the resulting model and generates a
within the inclusion criteria. In total they have been referenced by C&E matrix, which can be reviewed and enhanced by control engi-
other works 679 times. All approaches originate from European re- neers. From the resulting C&E matrix, a generator directly creates
searchers (only Lukman et al. (2013) has a co-author from the US). IEC 61131-3 ST or FBD code.
This corresponds to the observation from Section 2 that IEC 61131- [M2] Vienna Code Generator: The authors suggest to map var-
3 is more popular in Europe. ious requirements and design documents into a reference ontology
The approaches can be coarsely divided into three classes: based on CAEX. Using pre-defined rules from a knowledge base, an
inference engine generates instances of an IEC 61,131 ontology con-
1. Rule-based Generation based on Plant Structure: These
taining for example interlocking or diagnostic logic. A code gener-
approaches [M1,M2,M3] require control engineers to create
ator processes this ontology and produces 61131-3 code.
a knowledge base of rules that are later automatically ap-
[M3] ACPLT Rule Engine: An importer converts a CAEX plant
plied to formalized requirements and design documents to
structure XML file into a graph structure for the Neo4J31 graph
generate IEC 61131-3 code. The main benefits are the high
database. Using Cypher32 queries on the graph database allows to
degree of automation and the seamless integration into ex-
identify certain patterns in the plant structure and directly gener-
isting engineering workflows and tools. Drawbacks are the
ating FBD control logic or discovering flow paths. In this approach,

28
https://www.deif.de/wind- power/technology/plc- link- code- generation
29 31
http://www.actifsource.com/ https://neo4j.com/.
30 32
https://www.eclipse.org/4diac/ https://neo4j.com/developer/cypher-query-language/.
8 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

Fig. 11. Hybrid approaches: high-level overview. These approaches extract informa-
tion from plant topology models into higher-level programming models, let the en-
gineers complete the models, and then generate control logic.

The control engineer models a system using this notation and can
trigger a model-to-text transformation to get IEC 61131-3 ST.
[M10] MeiA Framework: This Eclipse-based framework pro-
vides multiple domain-specific modeling languages for signals and
phases, for use cases, and other constructs. While the framework
supports different types of analyses, it can also translate instances
of the model into PLCopen XML encoding IEC 61131-3 SFCs.
Finally, Fig. 11 shows three hybrid approaches that take the
plant structure into account and introduce a form of higher-level
Fig. 10. Higher-level programming: high-level overview. The approaches require an programming. None of these approaches however uses rule-based
upfront modeling in UML/SysML or similar notations, which are directly mapped to engineering:
control logic. [M11] SysML4IEC61131: The authors propose a CAEX2SysML
Transformator to import IEC 62424-compliant P&IDs into the
UML/SysML modeling tool Enterprise Architect33 . To reduce
the gap between CAEX and SysML, the authors propose the
the Cypher queries encode both domain specific rules and code
SysML4IEC61131 profile. The resulting SysML requirement diagrams
generation templates.
are semi-automatically refined with SysML block definition dia-
Fig. 10 shows the higher-level programming approaches, which
grams and can be transformed into PLCopenXML.
usually do not import any specifications, but require manual mod-
[M12] AUKOTON: The AUKOTON tooling takes P&IDs, IO lists
eling:
and C&E matrices as input and maps them into domain-specific
[M4] UML PA Translator: A control engineer uses Artisan Real-
AUKOTON models implemented using Ecore34 . Afterwards, control
Time Studio to model units of manufacturing equipment (e.g., a
engineers can refine the models further, before a PLCOpen Gener-
sorting facility) as UML classes, possibly enhanced by using the
ator processes them to produce IEC 61131-3 control logic.
UML-PA profile for process automation. Each method of a class is
[M13] Munich Code Generator: This approach performs an ob-
further specified via a UML state diagram. The approach proposes
ject recognition on P&IDs images. It tries to derive the plant hi-
a mapping of these models to IEC 61131 function blocks.
erachy from this operation and map certain patterns in the P&IDs
[M5] icsML: This approach requires engineers to create XML
to pre-specified ISA-88 compliant plant modules. A model-to-text
files modeling hardware and software resources, there is no CASE-
transformation finally produces IEC 61131 code for these modules.
tool support foreseen. Using XML stylesheets, the files are mapped
After briefly introducing each approach, the following will de-
into PLCopen XML and then into controller-specific languages.
fine detailed classification criteria to be able to compare the ap-
[M6] PLC-Statecharts: This more formal approach is focused
proaches better.
on providing adequate PLC semantics for UML statecharts. Eventu-
ally, the approach was implemented for the CODESYS framework,
3.3. Classification Criteria
where a UML class diagram and state diagram editor are provided.
The approach aims at a bi-directional mapping of the UML con-
Fig. 12 shows our classification criteria for the IEC 61131-3 code
structs and IEC 61131-3 code, so that ideally, the contol engineer
generation approaches. These criteria are defined based on artifacts
does not have to deal with 61131-3 code at all.
in practice (Section 2), an assumed comprehensive transformation
[M7] MAGICS: Instead of using UML, the authors of this
process (Fig. 1), and discussions with domain experts for processes
approach defined their own domain-specific modeling language
in oil and gas, chemical, and power generation applications. The in-
called ProcGraph. It includes entity diagrams and state transition
put classification was inspired by Steinegger and Zoitl (2012), while
diagrams and features an IEC 61131 code generator. The whole ap-
the output classification was inspired by Guttel et al. (2008). The
proach is accompanied by an Eclipse-based modeling tool that al-
following subsections will briefly explain each criterion.
low graphical editing of the models.
[M8] GRAFCET-Translator: This approach starts from a GRACET
(IEC 60484) specification of processes modeled using Microsoft Vi- 3.2.1. General Properties
sio and a specific stencil set. A transformer coverts the Visio file The General Properties cover high-level information to under-
into a Petri Net XML file (PNML), which is then normalized to cer- stand the context and maturity of each approach. The Publication
tain restricted constructs and finally mapped into PLCopen XML Venue states in which journal or conference the authors published
using 28 transformation rules.
[M9] SysML-AT Transformer: The authors define the SysML-AT 33
https://www.sparxsystems.de/.
notation to extend SysML requirements and parametric diagrams. 34
https://www.eclipse.org/modeling/emf/.
 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575 9

Fig. 12. Classification criteria for automated control logic generation approaches: inputs available in practice, transformation steps, types of output.

the main approach, where journal publications may indicate a If not directly available, a code generator could potentially synthe-
higher maturity. The Application Domain distinguishes between dis- size FB parameters using domain rules.
crete manufacturing and process automation, because different in- Sequences cover any kind of steps describing the control flow.
puts and constraints may be available in a given domain. A short These may for example refer to recipes in batch application or
description of each approach’s main Application Example helps the startup/shutdown or emergency procedures. When provided by a
reader to better understand an approach’s original context and the customer or engineering contractor, sequences may be specified
maturity of each approach. for example in control narrative, flow charts, or logic diagrams.
The Generation Approach summarizes the main translation idea. Boolean Logic may directly describe state-based control or inter-
The Tooling summary lists accompanying software tools includ- locks. Specifications may be available as logic diagrams, tables,
ing external libraries and framework. Finally, the Validation catego- control narratives, or C&E Matrices.
rizes how the authors evaluated their approach. This may poten- Approaches may consider formal specifications of the Plant
tially span from minimal examples executed by the authors them- Structure to generate control logic based on the encoded relation-
selves as a proof-of-concept up to multiple, heterogeneous real- ships between equipment and instruments. This may support gen-
world case studies carried out in independent studies to demon- eration of sequencing logic, interlocking logic, or diagnostic func-
strate actual cost and benefits. Ideally, the authors should charac- tions. Approaches could potentially exploit the topological struc-
terize how much manual work an approach saved or how large the ture for synthesizing start-up sequences if the material and infor-
fraction of generated code was in the analyzed cases. mation flow can be extracted unambiguously. Notations for plant
structures include P&ID, SCD, PFD, and building plans and with dif-
3.2.2. Inputs ferent levels of formalization (e.g., bitmap, vector-based drawing,
The second dimension of our classification framework are the object-oriented model with formal semantics).
inputs. These can be considered as the requirements for the con- Legacy code may be available as input for a code generator.
trol code. As there is no industry standard, we used different According to ARC (Forbes, 2018), only 35 percent of yearly dis-
sources for the input classification. Section 2 has surveyed the tributed control system projects revenues are for new construc-
available input artifacts in practice. Hästbacka et al. (2011) consider tions (greenfield), while the remaining 65 percent are for replace-
P&IDs and spreadlists (I/O lists, C&E lists) as inputs. Steinegger and ments, upgrades, or expansions (brownfield). Even in greenfield
Zoitl (2012) provided a list of different artifacts potentially in- projects, code from similar plants or factories may be available,
volved in code generation, which included P&IDs, recipes, electri- which could be partially reused. In brownfield projects, also legacy
cal plans, alarm lists, and logic diagrams. We also analyzed ABB- control logic code, potentially in a proprietary programming lan-
internal guidelines for inputs from customers. guage may be available. If an approach is able to deal with ex-
Our classification abstracts from particular artifacts and rather isting code, it can potentially also better support iterative devel-
distinguishes the approaches based the content in these artifacts. opment with multiple generations corresponding to the incremen-
This avoids overlaps (e.g., I/O signal references both in I/O lists tal availability of customer artifacts. In case of replacements, this
and P&IDs) as well as multiple kinds of artifacts for similar con- may involve translation of legacy control code (Fay, 2003b), while
tent (e.g., P&ID, SCD, PFD modeling the plant structure). Depending in case of upgrades, this may involve merging new code into exist-
on the particular application domain, an approach may be able to ing code (Steinegger et al., 2016).
generate more code if it takes more inputs into account. Finally, Domain Rules may allow a code generator to synthesize
The first kind of input are I/O signals, which may be specified control logic. These rules may encode interlocking concepts, nam-
in I/O lists, P&IDs, control narratives or other artifacts. They later ing conventions, safety standards, PID parameters, or other con-
form input and output signal references in the IEC 61131-3 con- cepts. They form a knowledge base, which is potentially applica-
trol code. Function Block (FB) Libraries with a list of typicals may ble across different projects and essentially turn the code genera-
be used to directly include higher-level domain concepts into the tor into an expert system for control logic engineering.
generated IEC 61131-3 code, which may potentially ease code gen-
eration significantly. Using type attributes for I/O signals from an 3.2.3. Transformation
I/O list, matching typicals can directly be instantiated by the code The third dimension of the classification pertains the Transfor-
generation, e.g., function blocks for motors or valves. mation process. The selected criteria map to the generic transfor-
FB Parameters may be available for example from detailed I/O mation process sketched in Section 2, which is based on a general
lists or control narratives, for example alarm limits, setpoints, or description of engineering processes (Gutermuth, 2010) as well as
tuning parameters. If available, the code generation can directly discussions with several domain experts.
copy them into the control logic. Typicals in control engineering Input Validation assesses whether an approach checks for com-
libraries can potential have more than 100 input and output pa- pleteness, validity, and consistency within and among the different
rameters, although many of these are often kept on default values. input artifacts. This is more relevant if an approach integrates
10 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

Table 1
Breakdown of different control logic segments: estimated fraction of source code and efforts.

Segment of Control Logic Description Estimated fraction of Estimated

total control code implemen-tation effort

Nominal 1) Instantiation of Typicals 30% 60%

Sequence 2) Parametrization of Typicals
3) Interconnection of Typicals
4) Definition of sequence control
Interlocks Protection functions combining two or more types of 20% 10%
equipment
Tags / I/O objects References to signals, IO objects 15% 1%
Alarms Hardware alarms for range violations, process alarms for 10% 1%
process range violations
Start-Up Initialization Sequences, may require operator interaction 5% 7%
Diagnosis For example Profibus DP Slave Device Diagnostics, 5% 5%
EtherCAT Diagnostics, etc.
Communication Peer to peer communication between controllers. 5% 5%
Restart / Reset Manual reset, or reset after energy failure, safe stop 2% 2%
Asset Monitoring Detect abnormal behavior, react upon error signals or 2% 1%
proactively search
Time-out Monitor whether time limits are exceeded 1% 1%
Operation and Automated population of OPC Servers for HMI stations n/a n/a
Monitoring
SUM 100% 100%

multiple artifacts with possibly overlapping contents. Pre- tion of simple domain rules. Other types of control logic may make
processing ranges from manual interpretation and formalization of up only smaller parts of the overall code.
inputs to intermediate model transformations that translate the We included the creation of variables / instantiation of typicals as
inputs into other formats for rule application and/or simplified first criteria into our classification framework. Each approach sup-
code generation. ports this in some sense as it is required for IEC 61131-3 code. The
Most approaches employ an intermediate model that is either parameterization of typicals is another criterion normally requiring
manually specified or automatically created. The actual translation the use of a FB library. In our classification, it also includes alarms.
converts this intermediate model to IEC 61131-3 code (e.g., M2T We combined different kinds of sequential logic into a single cri-
transformation), for example by performing a direct mapping of terion, which comprises start-up, shutdown, as well as recipes
concepts (e.g., in case of logic diagrams) or by applying domains (called “Definition of sequence control” in Guttel et al. (2008)).
rules. In most practical cases, generated code would be subject to Safety functions and interlocking logic sum up all kinds of
merging with existing code, which must avoid overwriting manu- boolean logic, such as emergency procedures and resets. Diagnostic
ally specified code and creating duplicates. logic may gather data about the system and field devices and may
Providing an appropriate documentation of the transformation inform a human operator. Finally, we summed up all other types
process (e.g., with indication of applied rules or issues in the input of logic from Table 1 in Other Logic. For each of these classifica-
artifacts) is essential for practical adoption and acceptance by con- tion criteria, we identified whether it was explicitly supported by
trol engineers. Finally, propagation of manual changes or additions the approach and which IEC 61131-3 language was used. It should
to the control logic back to the inputs is an important feature to be noted that using IEC 61131-3 code generation, each approach
keep the plant specification up to date (Jamro and Rzonca, 2018; could potentially support each type of output, but the output clas-
Julius et al., 2019). sification helps to better understand on which particular content
an approach focused.
3.2.4. Outputs
Our classification framework considers the Outputs of the code 4. Comparison of approaches
generation both in terms of the format (i.e., which IEC 61131-
3 language) and the contents (i.e., what parts of control logic. Using the classification from Fig. 12, the following compares the
Guttel et al. (2008) provided a detailed breakdown of the differ- approaches. Each subsection deals with one of the four parts of
ent aspects of PLC functions, categorizing more than 20 different the classification and uses a table to provide an overview to what
functions. We deemed this categorization too detailed for our clas- extent the approaches meet the criteria.
sification scheme, and thus selected a number of functions and
let multiple domain experts from our company rank their esti- 4.1. Comparison of General Properties
mated implementation effort. Table 1 shows the consolidated re-
sult. While the results are difficult to generalize and may vary a Table 2 lists the approaches’ general properties. The publication
lot between different projects, the numbers at least give notion of venues are mainly journals and conferences on software/system en-
higher importance, which is sufficient for the creation of a classifi- gineering as well as automation and manufacturing.
cation scheme. Since IEC 61131-3 logic is not specific for any application, each
Table 1 shows that the nominal sequence requires the most ef- approach is applicable in any application domain. However, most
forts implementation wise, although the amount of control code of the surveyed approaches originate either from a discrete man-
may be low. Especially interconnecting typicals and definition of ufacturing setting or a process automation setting, which leads to
sequence control requires efforts for interpreting different inputs different inputs, constraints, and assumptions. An indicator is the
and designing an appropriate control strategy. Interlocks represent main application example of each approach. These are predomi-
a significant portion of the control logic, but are comparably easy nantly small-scale lab automation systems or didactic plants. MAG-
to implement, since they may either be already fully specified by ICS [M7] and Vienna Code Generator [M2] use application exam-
customers due to safety regulations or require the manual applica- ples based on sub-segments of real-world plants.
 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575 11

Table 2
General Comparison: most approaches originate either from discrete manufacturing or process automation. There are diverse generation approaches, validations are often
performed using simple examples.
Approach Venue Application Domain Application Example Generation Approach Tooling Validation
[M1] (CAEX IEEE Conf. on Process Automation Generic plant unit (1 Matching rules from a Tool prototype Authors applied own
Transformer) Computer Aided (example for chemical) tank, 1 motor, 3 knowledge base processing CAEX files approach, single
Control Systems valves) sample case
Design
[M2] (Vienna Code IEEE Int. Conf. On Process Automation SMS Simag AG Hot Translation of ISA-88 Unnamed tool Authors applied own
Generator) Emerging Technologies (examples for hot Rolling Mill, FESTO recipes, generation prototype (logi.CAD, approach, two
and Factory rolling mill, chemical) Compact Workstation based on safety rules Apache Jena, Protege, industryderived case
Automation didactic plant (2 tanks, JAXB) studies
4 valves, 1 pump)
[M3] (ACPLT Rule IEEE International Process Automation Minimal plant (1 Matching rules Unnamed tool Authors applied own
Engineering) Conference on (example for chemical) pump, 1 valve) (defined as graph prototype based on approach, single
Industrial Informatics database queries) Neo4J, Cypher sample case
[M4] (UML PA IEEE Int. Conf. on Discrete Manufacturing Lab prototype for a Mapping UML to IEC Tool prototype using Authors applied own
Translator) Control and / Process Automation sorting facility 61131- 3 Artisan Realtime approach, single
Automation Studio sample case, discussed
with industry experts
[M5] (icsML) Springer Journal on Discrete Automation No specific application Translation of a XML schemas and Authors sketched
Advanced example, only generic selfdefined stylesheets provided mapping to two
Manufacturing XML templates XML-schema to commercial IEC
Technology 61131-3 61131-3 runtimes
[M6] (PLC-Statecharts) Elsevier IFAC Discrete Manufacturing Lab example involving Translation of UML CODESYS UML Student experiment
Proceedings error handling routine statecharts to IEC with 30 participants,
for a pneumatic 61131-3 ST informal reasoning
cylinder
[M7] (MAGICS) Elsevier Journal of Process Automation Grinding Titanium Translation of an ProcGraph Eclipse Authors applied own
Control Engineering Dioxide in Slovenia (50 extended finite state tooling (EMF / GMF / approach, single
Practice devices, 400 signals) machine + ST, manually oAW / Mitsubishi GX industryderived case
derived from P&ID IEC Developer, study (68% of code
CODESYS) generated)
[M8] Elsevier Journal of Discrete Manufacturing Plant for checking 28 transformation GRAFCET Editor & Authors applied own
(GRAFCET-Translator) Control Engineering / Process Automation electromech. parts rules from GRACET to Translator approach, single
Practice (conveyor belt, rotary 61131-3 industryderived case
table,100 signals) study
[M9] (SysML-AT Elsevier Journal on Discrete Manufacturing Laboratory Pick & Model-to-text Unnamed tool Student experiment
Transformer) Mechatronics Place Unit (stamp, transformation using prototype for with 36 participants,
crane, stack, sorter) MOFM2T SysML-AT hypotheses testing
[M10] (MeiA IEEE Transactions on Discrete Manufacturing SMC FMS-200 training PLCopen converter Eclipse-based MeiA Developers applied the
Framework) Automation Science Mechatronic Station framework (M2T tooling approach in 15
and Engineering (Conveyor + Actuators) transformation) projects with about 50
I/O signals each
[M11] SciRes Journal on Discrete Manufacturing FESTO Modular Translation of SysML SysML4IEC61131 No implementation,
(SysML4IEC61131) Software Engineering / Process Automation ProductionSystem block diagrams to Profile, only conceptual
and Applications 61131-3 via SysML SysML2IEC61131 approach described
Profile Translator, MARTE
Profile(not
implemented)
[M12] (AUKOTON) Elsevier Journal of Process Automation Lab example for a Translation of P&IDs, UML AP Tool (Eclipse, Authors applied own
Systems and Software (example for chemical) water treatment plant IO Lists, C&E matrices Topcased, SmartQVT), approach, single
segment into an intermediate includes importers for sample case, discussed
UML model, IEC61131 CAEX and IO lists with industry experts
FBD
[M13] (Munich Code IEEE International Process Automation myJoghurt lab-scale P&ID image C++ prototype using Authors applied own
Generator) Systems Engineering CPPS demonstrator recognition, module SQLite, RI-CAD, approach, single
Symposium (pump, filling, heating, identification and CODESYS, TIAPortal sample case
mixing units) matching from library,
then M2T
transformation
Legend: Rule-based Engineering approaches, Higher-level Programming approaches, Higher-level Programming using Plant Structure

The generation approaches are either based on matching pany 3S. All other tools remain in a proof-of-concept maturity and
domain-specific rules on specifications provided as inputs, or map- are not openly available for independent testing.
ping a higher-level notation into IEC 61131-3. For the latter, sev- For validation, most authors apply their own approach on a
eral approaches employ a model-to-text transformation. The Mu- single example. This provides an initial proof-of-concept valida-
nich Code Generator [M13] aims at a generation by a mapping to tion, but does not qualify an approach for practical use. Whether
pre-specified modules, although it also foresees manually specify- practitioners could repeat a published approach independently or
ing the control logic for modules that are not yet provided in a whether the approach runs into scalability, maintenance, or ro-
library. bustness issues remains unclear. For PLC-statecharts (Witsch et al.,
The tooling is tightly connected to the generation approach. 2010) and SysML-AT Transformer (Vogel-Heuser et al., 2014), the
Several approaches use UML modeling tools and extend them researchers carried out experiments with around 30 students each
with prototypical enhancements. AUKOTON [M12], MAGICS [M7], and showed that a higher-level programming language can lead to
and MeiA [M10] make extensive use of the Eclipse modeling higher productivity. The MeiA approach (Alvarez et al., 2018) has
framework and provide Ecore models besides graphical editors been applied by a number of developers in 15 simple, experimen-
and model-to-text transformations. Only CODESYS UML from PLC- tal projects (approx. 50 I/O signals), but the documented validation
Statecharts [M16] is available as a commercial offering by the com- results are difficult to interpret.
12 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

Researchers have tested rule-based generation approaches only approach [M7] provides self-defined state transition diagrams and
using small rule bases that cover minimal aspects, but are insuf- state dependency diagrams that the control engineer models.
ficient for practical application. Large rule bases may lead to in- The GRACET translator [M8] is centered around the GRAFCET
consistencies, overlaps, and scalability issues. Larger experiments, notation (IEC 604848) for specifying sequences. The approach pro-
pilot projects, and applications to entire projects would be needed vides formal semantics for GRAFCET enclosing steps, forcing or-
to facilitate technology transfer. The code generation as such is sel- ders and time constraints, and is thus able to utilize the full
dom measured or precisely characterized. Only the MAGICS ap- GRAFCET notation in code generation. A number of student ex-
proach (Lukman et al., 2013) states that 80 KByte of executable periments (Vogel-Heuser, 2014) suggest that UML-based modeling
control logic had been generated from higher-level constructs, can be more productive than directly writing IEC 61131-3 code, if
which was 68 percent of the overall code. well integrated into an IEC 61131-3 development environment with
round-trip functionality. Challenges for adopting such approaches
in industry are developer training, work processes, and integration
4.2. Comparison of Inputs with legacy code. Approaches processing P&IDs often do not deal
with sequential specifications explicitly, but instead focus on logic
The surveyed approaches based their code generation on a directly derived from the P&ID.
range of different inputs (Table 3). Boolean logic may be used for interlocks, emergency shutdowns,
The approaches take information to define I/O signals and con- but also model sequences. While logic diagrams are often avail-
trol variables either from natural language specifications or use able in practice as requirements, only the Vienna Code Genera-
structured customer inputs, such as P&IDs. Higher-level program- tor [M2] discusses processing them, but provides no implementa-
ming approaches require the control engineer to model the re- tion. AUKOTON [M12] can import C&E matrices that express inter-
quired signal references, for example using class diagrams. Rule- locks as a special kind of boolean logic and turn them into control
based engineering approaches as well as hybrid approaches instead logic. Tools are available to transform C&E matrices directly into
derive the signal references from CAEX representations of P&IDs IEC 61131-3 control logic [M1].
diagrams. Only the AUKOTON [M12] explicitly imports Excel-based Approaches in process automation usually take the plant struc-
I/O lists which are often available in practice. SysML4IEC61131 ture or topology into account as a P&ID [M1,M2,M3,M11,M12,M13].
[M11] uses a combination of transforming a CAEX-based P&ID The CAEX Transformer [M1] uses the connections between equip-
to SysML and then manually adding requirements to the ment an instruments in P&IDs to apply rules to generate inter-
model. locking logic. The SysML4IEC61131 approach [M11] extracts pro-
Function block libraries are another important ingredient for cess control engineering (PCE) requests, control functions, and
code generation. The SysML4IEC61131 approach [M11] intends loops from P&IDs and maps them to SysML requirements dia-
to integrate different kinds of unspecified FB libraries. AUKO- grams. AUKOTON [M12] follows a similar approach and maps PCE
TON [M12] uses a self-defined DCS library, and the Vienna Code requests in P&IDs to UML class diagrams stereotyped as Automa-
Generator [M2] created two libraries with one and two function tion Requirements. The Vienna Code Generator [M2] uses CAEX
blocks respectively, specifically for diagnostics. The Munich Code and PandIX as inputs and extracts PCE requests, signal connections
Generator [M13] relies on a library of pre-defined process modules needed for interlocks, and PCE control functions to group multi-
according to ISA-88, but details remain to be specified in a given ple signals. Schüller and Epple (2012) showed prototypically how
project. Other approaches do not deal with function block libraries, PandIX P&IDs could be extracted from a native XML-export of CO-
although integration should be fairly easy. The used libraries may MOS P&ID.
determine on what abstraction level the control engineer and the MAGICS [M7] in turn requires the control engineer to manually
code generation can work. Highly aggregated function blocks as in interpret the P&ID and formulate the contents in the ProcGraph
[M13] may reduce the required manual work significantly, since it notation. The Munich Code Generator imports P&IDs as SVG35 files
only requires to connect a few large blocks, instead of creating a to perform image recognition in order to identify modules that can
detailed low level specification. However, function block libraries be mapped to higher-level function blocks.
are often domain-specific or even project-specific. Higher-level programming approaches often originate from dis-
Function block parameters may pertain configuration parameters, crete manufacturing scenarios without an explicitly modeled plant
alarm ranges, set points, and other values, which could be de- structure. They foresee modeling structures using UML class dia-
rived from information provided by the customer or also based grams. In this context, Grüner et al. (2014a) proposed so-called
on experience in similar projects. Most approaches seem to ne- product flow diagrams (PFDs) as a notation analog to P&IDs but
glect that these parameters could be derived from customer spec- for discrete manufacturing scenarios.
ifications or using domain rules. In AUKOTON [M12], ranges and Except for the Vienna code generator [M2], none of the ap-
setpoints can be taken from the I/O list, while the Vienna code proaches takes existing, potentially proprietary legacy control code
generator provides a concept to retrieve parameters using electri- into account for the code generation. This could feed a direct trans-
cal plans. Higher-level programming approaches require the user lation into low-level IEC 61131-3 control logic (Fay, 2003a), but
to set these parameters in UML classes that are later mapped to could also require mapping existing higher-level function block li-
function blocks. braries. There are numerous commercial offerings to migrate con-
Multiple approaches use notations based on UML statecharts to trol logic between control systems of different vendors (e.g., mi-
model sequences due to the similarities with IEC 61131-3 SFCs. The grations to Emerson Delta V36 to Siemens SIMATIC PCS737 to ABB
UML PA Translator [M4] uses UML state charts enhanced with the 800xA38 ). Legacy code could also be available as IEC 61131-3 in
UML PA profile and maps them with included variables to SFCs. ic- a migration project, then the goal of code generation would be
sML [M5] provides an XML schema for software resources that can to seamlessly integrate with the existing code. [M2] considers
express sequences. PLC-statecharts [M6] enhance UML statecharts this case explicitly, as it adds interlocking logic to already existing
with user-defined priorities for transitions. Due to IEC 61131-3’s
cyclic nature, these statecharts cannot be triggered by events, and 35
https://www.w3.org/TR/SVG2/.
the approach introduces behavioral semantics as in polling real- 36
https://bit.ly/2U6HxSx.
time systems. The Vienna code generator [M2] may use recipes be- 37
https://sie.ag/2VAZNoE.
ing available in a notation conforming to ISA-88, while the MAGICS 38
https://bit.ly/2UPzWvY.
Table 3
Comparison of the Inputs of each approach: most approaches support only specific inputs, some of them require manual modeling of customer requirements.

H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575
Approach I/O Signals FB Libraries FB Parameters Sequences Boolean Logic Plant Structure Legacy code Domain Rules
[M1] (CAEX Instruments from CAEX n/a n/a n/a n/a P&ID in CAEX (IEC n/a Interlocking rules
Transformer) (IEC 62424) 62424) + self-defined logistics (XML)
model called LogIX
[M2] (Vienna Code Instruments from CAEX, 61131-3 lib for Profibus Instruments from CAEX, Recipes (ISA-88)∗ Logic Diagrams (ISAS5.2), P&ID in CAEX (IEC PLCopen (XML)
Generator) elec. plans (EN DP / EtherCAT elec. plans (EN C&E Diagrams (ISO 62424) + PandIX / IEC 62424 exported from Interlocking + diagnotic
60617) + IEC 81346 Diagnostics 60617) + IEC 81,346 10418) based Ecore Model Rockwell RSLogix rules (SPARQL)
50 0 0
[M3] (ACPLT Rule P&ID in CAEX n/a n/a n/a n/a P&ID in CAEX (IEC n/a Interlocking rules
Engineering) (IEC62424) + PandIX 62424) + PandIX (Cypher)
[M4] (UML PA Attributes in Class n/a n/a Activity Diagrams, n/a n/a n/a n/a
Translator) Diagrams State Charts
[M5] (icsML) XML schema for software n/a n/a XML schema for XML schema for software n/a (XML schema for n/a n/a
resources software resources resources controllers and I/O devices)
[M6] Attributes in Class n/a n/a PLC-statecharts n/a n/a n/a n/a
(PLC-Statecharts) Diagrams
[M7] (MAGICS) Signal List (manually n/a Signal List (manually ProcGraph State Safety Requirements P&ID diagram (manually n/a n/a
processed)∗ included) Transition Diagrams, processed)
Functional
Specification
[M8] Variables in Grafcet (IEC n/a n/a Grafcet (IEC 60848), Grafcet (IEC 60848), n/a n/a n/a
(GRAFCET-Translator) 60848) Control Interpreted Control Interpreted Petri
Petri Net Net
[M9] (SysML-AT SysML Parametric n/a SysML Parametric SysML Parametric n/a n/a n/a n/a
Transformer) Diagram + SysML AT Diagram + SysML AT Diagram + SysML AT
Profile Profile Profile
[M10] (MeiA Part of MeiA model n/a Part of MeiA model Design Organization Design Organization n/a n/a n/a
Framework) Units (DOU) derived Units (DOU) derived
from MeiA model from MeiA model
[M11] Instruments from CAEX Undefined standard / SysML Requirement n/a SysML Requirement P&ID in CAEX format n/a n/a
(SysML4IEC61131) (IEC 62424), SysML domain-/ projectspecific Diagram Diagrams for interlocks / (IEC62424)
Requirement Diagram libraries (PLCopenXML) safety and security
requirements
[M12] (AUKOTON) I/O List (Excel) AUKOTON DCS Library I/O List (Excel) n/a C&E Matrix (Excel) P&ID in CAEX format n/a n/a
(IEC62424)
[M13] (Munich Code Instruments recognized Self-defined Process n/a From module n/a P&ID as SVG file n/a n/a
Generator) from P&ID Module library with references
ISA-88 compliant recognized in P&ID
modules
Legend: Rule-based Engineering approaches, Higher-level Programming approaches, Higher-level Programming using Plant Structure

13
14 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

PLC code and uses an interlock redundancy elimination mechanism ships among them. The ProcGraph [M3] domain specific language
based on the Z3 theorem prover. proposes entity diagrams, state transition diagrams, and state de-
Three approaches use Domain rules in order to generate inter- pendency diagrams to specify structural and behavioral informa-
locking or diagnostic logic ( [M1,M2,M3]). Other areas for apply- tion and ultimately an easy mapping to IEC 61131-3 FBD and ST.
ing domain rules (e.g., generating alarms, startup/shutdown se- The MeiA framework [M10] uses four different models: MeiA_MM
quences, recipes, etc.) may be more complicated and remain un- (e.g., phases, steps, signals), UseCase_MM (e.g., actor, use case,
explored. The CAEX Translator [M1] directly encodes these rules NonFuncReq), GEMMA_MM (e.g., state, line, operation), and De-
in XML (Schmidberger and Fay, 2007), while the Vienna code sign_MM (i.e., the intermediate modeling layer of AutomationML,
generator [M2] uses SPARQL queries, and the ACPLT Rule Engi- which includes GRAFCET and SFC elements).
neering [M3] executes Cypher queries on Neo4J graph databases. Approaches operating on a plant structure often use the CAEX
Krausser et al. (2011) proposed to use directly IEC 61131-3 to for- format as a common syntactical container and add additional infor-
mulate such rules, so that control engineers can work with a fa- mation, such as the LogIX logistics model [M1] to identify equip-
miliar notation. ment between two junction points, or the PandIX model for PCE
In summary, UML/SysML-based approaches put much of the re- requests [M2,M3]. [M11] sketches a CAEX2SysML transformation
quirements formalization workload on the control engineer, who and a manual addition of requirements by the control engineer.
models requirements and design in UML or SysML. In other ap- The ACPLT Rule Engineering [M3] proposes converting CAEX-based
proaches, which are mostly from process automation, the control P&IDs into a Neo4J graph notation, so that a graph query language
engineer may already work with semi-formal or formalized re- can be used to process the model during translation. The Munich
quirements and derive a design and implementation. code generator [M13] uses a tree-based model to express the plant
Regarding completeness of input artifacts, the Vienna code gen- hierarchy extracted from P&IDs.
erator [M2] provides the most holistic view, addressing all of the The GRAFCET Translator [M8] requires the control engineer to
input elements of our classification. However, the approach does model sequences in GRAFCET using a self-defined shape library for
not provide tooling to process these inputs automatically, but in- Microsoft Visio. The GRAFCET Translator can then convert the Vi-
stead assumes that an appropriate CAEX model is already available sio XML format into the Petri Net Markup Language (PNML), which
from these artifacts. includes a normalization of the model. Besides code generation,
the PLC-Statecharts approach [M8] provides a mapping to UPPAAL
4.3. Comparison of Transformations timed automata to enable model checking.
Although all approaches produce IEC 61131-3 code, their inter-
Table 4 compares different aspects of the model transforma- mediate processings vary a lot. This is caused by different inputs
tions. None of the surveyed approaches explicitly deals with input but also by different focuses regarding the code generation (e.g.,
validations, except icsML [M5] which executes syntax checks on the interlocks, state-based behavior). Augmenting standardized nota-
used XML models. Several approaches assume a valid, i.e., consis- tions, such as UML or CAEX, for intermediate models can utilize
tent and syntactically correct CAEX files as input. Other approaches the abstractions developed and accepted by a standardization body
require a formalization of unstructured inputs by the control engi- in a formal process, which can foster tool support and developer
neer, which then implicitly includes an input validation performed training. There is also potential to combine or link different no-
during manual interpretation. Syntax, semantic, and plausibility tations into a comprehensive approach, e.g., plant structures and
checks on individual artifacts could be tackled by the CAD tools behavioral notations, as for example shown in AutomationML. On-
creating them. Consistency checks between different artifacts may tological notations may lend themselves to a reuse of existing in-
be facilitated by mapping them into a common representation, e.g., ference engines to support code generation.
a database, graph, ontology, or CAEX file, so that the mapping logic In most approaches, the actual translation of the intermediate
could also ensure consistency. model to IEC 61131-3 constructs is rather straightforward. Func-
The surveyed approaches show a wide range of pre-processings tion blocks expressed in UML are mapped to IEC 61131-3 func-
and intermediate models. Several approaches require a manual tion blocks, states in state charts are mapped to steps in SFCs.
modeling of requirements and designs in UML [M4,M6,M12], The GRAFCET Translator [M8] applies 28 transformation rules to
SysML [M9,M11], or other proprietary notations, such as ic- map GRAFCET to SFCs. There are also M2T transformations to
sML [M5], ProcGraph [M7], and MeiA [M10]. UML/SysML models ST [M6,M7,M10]. Other approaches use a rule engine to apply
are augmented using profiles, such as UML PA (Vogel-Heuser et al., domain-specific rules on the intermediate models and generate
2005), SysML4IEC61131 (Thramboulidis and Frey, 2011), UML the code out of these rules [M1,M2]. The ACPLT Rule Engineering
AP (Hästbacka et al., 2011), and SysML AT (Vogel-Heuser et al., approach applies the Cypher graph query language to apply such
2014). rules [M3].
UML PA [M4] adds time constraints on an architectural level, Merging generated code into existing code is only considered
timed state charts, as well as ports, capsules, protocols, and roles by the Vienna Code Generator [M2]. Dealing with generated and
from the UML-RT profile. Furthermore, it uses special object di- hand-written code in parallel is not discussed by any of the ap-
agrams to express mappings between hardware and software. proaches. None of the approaches lays special emphasis on docu-
SysML4IEC61131 [M11] follows a slightly different approach and menting the code generation process, so that the control engineer
is closely modelled after IEC 61131-3 concepts, such as Controller, receives useful feedback on how the inputs were processed. An im-
PLC, Application, POU, Program, Task, and Physical I/O. AUKO- plicit assumption is that the control engineer inspects the gener-
TON [M12] consists of four subprofiles for requirements (e.g., in- ated code and continues working with it.
strumentation requirements), automation concepts (e.g., control Backpropagation is also rarely considered by the approaches, al-
loop, PID algorithm), devices and resources (e.g., EDDL, FDT), and though PLC-Statecharts [M6] assumes a bidirectional mapping be-
distribution and concurrency (e.g., distributed components and tween UML and FBDs, so that the control engineer can ideally only
concurrency mechanisms). SysML-AT [M9] adds function block in- work on the level of UML diagrams. The authors of the GRAFCET-
stances, classifiers, flows, and restrictions to SysML to allow an eas- Translator (Julius et al., 2019) discuss concepts for bidirectional
ier mapping to IEC 61131-3 ST. None of these profiles has been transformations between GRAFCET and SFCs. However, backpropa-
applied outside of the respective authors’ own work so far. ic- gating, for example, tag names changes or parameter updates into
sML [M5] uses XML to describe hardware, software, and relation- the requirements specifications is not considered so far.
Table 4
Comparison of Model Transformations: all approaches use an intermediate representation before generating code. Support for merging, documentation, and backpropagation is limited.
Approach Input Validation Pre-processing Intermediate Model Translation Merging Documentation Backpropagation
[M1] (CAEX Transformer) n/a (assumes valid CAEX Augmentation with flow CAEX (IEC 62424) Applying XML n/a n/a n/a

H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575
files as input) path using LOGIX model enhanced with LOGIX interlocking rules to
line model generate a C&E Matrix,
then FBD/ST
[M2] (Vienna Code n/a (assumes valid CAEX Mapping inputs to CAEX (IEC Applying rules from a Importer for existing n/a n/a
Generator) and other files as input) reference ontology 62424) + PandIX model knowledge base to create control logic code to
(based on CAEX) FBD (SPARQL queries) reference ontology
[M3] (ACPLT Rule n/a (assumes valid CAEX Translation of CAEX into Self-defined graph Applying rules encoded n/a n/a n/a
Engineering) files as input) Graph (neo4J) notation as Cypher graph queries
to generate FBD
[M4] (UML PA n/a Manual modelling of UML for Process Direct translation of state n/a n/a n/a
Translator) UML class diagrams and Automation profile (UML charts to SFC
state charts PA)
[M5] (icsML) Applying rules on XML Manual modeling of icsML including XML stylesheet to map n/a n/a n/a
models (syntax checks) hardware, software in hardware, software, and to PLCopen XML, then
XML relationsships ISaGRAF and Simatic
[M6] (PLC-Statecharts) n/a Manual modelling of UPPAAL timed automata Direct translation of state n/a n/a Bidirectional mapping
UML class diagrams and charts to ST between FB and UML
state charts class diagrams
[M7] (MAGICS) n/a (manual re-modeling Creation of ProcGraph ProcGraph DSML (Entity Mapping to ProcGraph n/a n/a n/a
of input artifacts) model, writing of ST Diag., State Trans. Diag., elements to FBD, copying
statements State Depend. Diag.) ST statements
[M8] n/a Transform Visio to PNML, GRAFCET in Applying 28 n/a n/a Multiple concepts for
(GRAFCET-Translator) normalize PNML file PNML(ISO/IEC15909-2) transformation rules round-trip engineering
from GRAFCET to SFC discussed
[M9] (SysML-AT n/a (assumes valid SysML Manual modeling of SysML Parametric MOFM2 T / OCL n/a n/a (generated code to n/a
Transformer) Requirements diagrams) SysML Parametric Diagram + SysML-AT transformation into ST be reviewed by
Diagrams profile developer)
[M10] (MeiA Framework) n/a Manual modeling of MeiA model IML to PLCOpen XML n/a n/a n/a
MeiA model (signal/phases), Use Case Generation for SFCs
Model, GEMMA model,
AML IML
[M11] (SysML4IEC61131) n/a (assumes valid CAEX CAEX2SysML SysML requirements SysML2IEC61131 Model n/a n/a n/a
files as input) transformation, add diagram + proposed Transformer
requirements SysML4IEC61131 profile
[M12] (AUKOTON) n/a (inputs are not Manually adding UML AP Direct mapping of UML n/a n/a n/a
validated before requirements for profile(Requirements, AP to FBD, use of
automated import) feedback control Aut. Concepts, Devices, platform-specific profiles
Distribution)
[M13] (Munich Code n/a Object recognition on Tree-based Mapping to Process n/a n/a n/a
Generator) P&ID, connection representation of plant Module library, M2T to
analysis, module hierarchy (C+/SQLite) PLCopen
recognition
Legend: Rule-based Engineering approaches, Higher-level Programming approaches, Higher-level Programming using Plant Structure

15
16 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

4.4. Comparison of Outputs verging. Selecting an approach for a particular project mainly de-
pends on the available inputs and the expected outputs.
Table 5 summarizes the outputs produced by the surveyed ap- Rule-based generation approaches try to limit manual cod-
proaches. Several approaches create signal references by a direct ing efforts, by letting control engineers encode simple engineer-
mapping from UML class diagrams, or derived from P&IDs. Only ing tasks into a rule base. The aim is not to create a higher-
AUKOTON [M12] imports an I/O list for signal creation. The Vienna level programming interface, but rather to avoid manual coding as
Code generator [M2] instantiates diagnostic typicals into FBDs from much as possible by automating simple, repetitive tasks. The ap-
a library. The Munich Code Generator [M13] instantiates typicals proaches demonstrated rule-based engineering only on simple ex-
for process modules from a library. There are no common standard amples, scalability and robustness remains unexplored. Expert sys-
libraries used by the approaches for code generation. Some ven- tems based on rules are known to become brittle if facing unfa-
dors may consider their function block libraries as differentiator miliar settings (Wiriyacoonkasem and Esterline, 20 0 0), so a more
and competitive advantage. Domain- or project-specific typicals are thorough investigation is needed to better assess the usefulness of
discussed [M3,M11], but not demonstrated in any of the surveyed rule-based engineering.
code generations. Approaches based on higher-level programming languages, such
A few proposals discuss the parametrization of typicals. as UML or SysML intend to make manual coding more produc-
SysML4IEC61131 [M11] intends to incorporate timing constrains us- tive, in terms of understandability and quality by utilizing object-
ing the UML MARTE profile, but remains vague on details. AUKO- oriented concepts and raising the abstraction level. They include
TON [M12] parameterizes instantiated function blocks with ranges, automated code generation as a translation to a lower-level no-
alarm limits, and engineering units taken from an I/O list. The Vi- tation, but rather treat it as a side-effect while the focus is on
enna code generator [M2] takes parameters for diagnostic func- providing an adequate higher-level notation. Accordingly, the eval-
tions from hardware configuration files into account. Due to the uations of such approaches focus on programming efficiency and
heterogeneous inputs and different generation approaches, there user satisfaction and do not differentiate between manually writ-
is no consensus on this element of code generation. Mechanisms ten and generated code. They implicitly assume that all code can
to map information on parameter values to domain- or project- be expressed in the higher-level notation and that a bidirectional
specific typicals could improve code generation. mapping to the lower-level IEC 61131-3 notation is possible.
Most of the approaches express sequential logic for recipes and Although the classes of surveyed approaches have different
start-up sequences as SFCs or ST. A few of them use FBDs, but goals, they do not exclude each other and could be combined. To
no approach generates LL or IL. As data format, most approaches some extent, this is demonstrated by the hybrid approaches that
use PLCOpenXML TC6, which some of them map to vendor-specific take a plant structure into account to generate a UML/SysML-based
formats. For example, icsML [M5] creates an ISaGRAF XML repre- structure model, which then can be manually enhanced in a mod-
sentation and a Siemens STEP7 representation from PLCopenXML. eling tool.
MAGICS [M7] generates code for Mitsubishi PLCs. The Vienna code The scope of the academic research was focused on the three
generator [M2] creates RSLogix50 0 0 code for Rockwell controllers. different classes of approaches shown in the survey. In practice,
The approaches express safety functions and interlocking logic there are additional methods for lowering control engineering ef-
mostly as FBDs, some also use SFCs and ST. The CAEX trans- forts, which are hardly investigated by the surveyed approaches:
former [M1] first produces a C&E matrix for interlocking logic,
• Copying Code: Often, individual engineers simply copy and
which can be manually adapted and extended. The final matrix can
adapt code from former projects to speed up programming.
then be converted into either FBD or ST for an ABB controller.
Methods could be developed to recommend similar former
Most of the other functions of control logic (Guttel et al.,
source code or to support creating reusable engineering li-
2008) are not explicitly considered by the approaches. The Vi-
braries based on analyzing engineering artifacts of similar
enna code generator produces FBDs for diagnostic logic, and the
projects, which requires extensive domain knowledge.
SysML4IEC61131 approach considers timing properties. The SysML-
• Engineering Libraries: Engineers create engineering libraries
AT transformer [M9] considers control logic for controller-to-
encoding higher-level functionality in reusable function blocks.
controller communication.
This works well in application domains with limited cus-
tomized functionality, e.g, steel making or aluminium smelting,
4.5. Comparison Summary but is harder for other domains, such as chemical plants, that
often exhibit an amount of specialized functionality.
The previous subsections have shown that the identified ap- • Modular Automation: As a more coarse-grained approach to
proaches cannot be directly compared in terms of efficiency, qual- control logic reuse, engineers segment a production process
ity, or expressiveness, because they require different kinds of in- into smaller package units, which independent subcontractors
puts, apply different kinds of transformations, and generate dif- build together with an included automation. The engineering
ferent kinds of outputs. Also their tooling is often not or no configuration of these package units follows the NAMUR Mod-
longer available for independent replication studies or benchmark- ule Type Packages (MTP) (Bernshausen et al., 2016). Besides
ing. Nevertheless, the survey allowed a categorization into 1) rule- standardized hardware connectors, each unit provides a mod-
based engineering approaches, 2) higher-level programming ap- ule type package that serves as module description and input
proaches, and 3) higher-level programming approaches using a to system-wide engineering tools. An orchestrating, supervising
plant structure. The next section will interpret and analyze the sur- control system can then provide high-level commands to each
vey findings further. unit (e.g., start, stop) and use the modules to execute specific
recipes.
5. Discussion The Munich code generator included in this sur-
vey (Koltun et al., 2018) is potentially applicable for Modular
This section discusses multiple observations and analyzes of the Automation, since it works with higher-level ISA-88 based module
surveyed approaches. descriptions similar to NAMUR MTP. However, the challenges for
Heterogeneous Research Scopes Although all surveyed approaches automatic code generation change significantly in case of modular
produce IEC 61131-3 code, their individual goals and scopes are di- engineering. Because the modules are too small to be concise, they
 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575
Table 5
Comparison of Transformation Outputs: all approaches produce IEC 61131-3 SFC, FBD, and ST. Primary focus is on sequential logic and interlocking logic.
Approach Creation of Variables / Signal Parametrization of Typicals Sequential Logic (incl. Safety Functions and Diagnostic Logic (e.g., Other Logic (e.g., asset
References + Instantiation of (incl. set points, alarm limits, recipes, start-Up, shutdown, Interlocking Logic (incl. reset, process/system diagnosis, monitoring, controller
Typicals PID parameters) ...) emergency stop, etc.) field devices) communication, etc.)
[M1] (CAEX Transformer) n/a (implicitly extracted from n/a n/a Cause&Effect Matrix n/a n/a
CAEX) converted to 61131-3 ST, FBD
(ABB)
[M2] (Vienna Code Yes, from self-defined Yes, some parameters from IEC 61131-3 SFC (PLCopen IEC 61131-3 FBD (PLCopen IEC 61131-3 FBD (PLCopen n/a
Generator) Profibus + Ethercat Diagnotics hardware config file XML) XML) XML)
FB Lib
[M3] (ACPLT Rule Yes, via Cypher query. Yes, queries refer to function IEC 61131-3 FBD n/a n/a n/a
Engineering) block types.
[M4] (UML PA Yes, from UML class diagram Possible from UML class IEC 61131-3 SFC, ST n/a n/a n/a
Translator) diagram
[M5] (icsML) Yes, from XML file. n/a IEC 61131-3 ST n/a n/a n/a
(PLCOpenXML)
[M6] (PLC-Statecharts) Yes, from UML class diagram Possible from UML class IEC 61131-3 ST (CoDeSys) n/a n/a n/a
diagram
[M7] (MAGICS) n/a (interpretation of P&ID, n/a IEC 61131-3 SFC, ST (PLCopen IEC 61131-3 SFC, ST (PLCopen n/a n/a
creation of ProcGraph model) XML) XML)
[M8] n/a (implicitly extracted from Possible using time IEC 61131-3 SFC, ST (PLCopen IEC 61131-3 SFC, ST (PLCopen n/a n/a
(GRAFCET-Translator) GRAFCET) constraints XML) XML)
[M9] (SysML-AT Yes, generation of FB based n/a IEC 61131-3 ST n/a n/a Controller to Controller
Transformer) on SysML model Communication
[M10] (MeiA Framework) Yes, signal references n/a IEC 61131-3 SFC (PLCopen n/a n/a n/a
manually created in Meia XML)
model
[M11](SysML4IEC61131) n/a (possible via SysML Via OMG MARTE profile IEC 61131-3 SFC, FBD IEC 61131-3 FBD (PLCopen n/a Timing properties via OMG
Stereotypes) (PLCopen XML) XML) MARTE profile
[M12](AUKOTON) Yes, by mapping IO list to Parameters taken from IO n/a IEC 61131-3 FBD (PLCopen n/a n/a
AUKOTON DCS Library List XML)
[M13](Munich Code Yes, instantiating predefined n/a IEC 61131-3 ST n/a n/a n/a
Generator) process modules (PLCopenXML)
Legend: Rule-based Engineering approaches, Higher-level Programming approaches, Higher-level Programming using Plant Structure

17
18 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

usually do not include a large amount of IEC 61131-3 logic. Thus, research into cross-tool data consistency and completeness checks
the benefit of code generation for each module provider is rather may be valuable.
limited. Module providers can rather exploit economies of scale Dealing with Natural Language Requirements Another finding of
if they produce their firmly defined modules in large quantities, the survey is that none of the approaches is able to process infor-
each time reusing the same control logic. mal customer requirements. As Section 2 showed, part of the cus-
Based on the survey findings, it seems unlikely that there ever tomer requirements are often formulated using informal language
will be an all-accompanying approach for automatic code genera- in user requirement documents or control narratives. Additionally,
tion in industrial automation. The different approaches may work P&IDs or logic diagrams may contain annotations in prose writing,
well in specific domains, but not in others, depending on how which may provide important information for control logic engi-
standardized the processes are. Combining approaches that exploit neering.
plant topology models, execute code generation rules, and rely on Requiring customers and engineering contractors to fully use
higher-level programming to some extent is possible and should formal requirements specifications may be unrealistic. However,
be investigated in future research. Rule-based engineering can re- there is a large body of literature on text mining (Feldman and
duce the amount of trivial, repetitive implementation tasks, while Sanger, 2007) and information retrieval (Baeza-Yates et al., 2011),
higher-level programming can reduce efforts for implementing re- which have been applied on informal requirements in other appli-
quired custom control logic. cation domains.
Iterative Code Generation As user requirements usually be- Gelhausen and Tichy (2007) propose to annotate require-
come available in several iterations, code generation cannot as- ment documents using a purpose-built language, so that they
sume a one-shot translation of the inputs. The survey has shown can be transformed into UML diagrams. Deeptimahanti and
that many approaches work with the assumption of a one-shot Babar (2009) propose a tool to generate UML models from nat-
translation and thus may be misaligned with practice. Some ural language requirements by identifying classes and stereo-
approaches assume that the generated IEC 61131-3 code may types. The tool implements a set of syntactic reconstruction
not be altered manually (Vogel-Heuser et al., 2005), others al- rules to process complex requirements into simple requirements.
low a bidirectional mapping between UML/SysML notations and Le et al. (2013) present a system for synthesizing smartphone au-
IEC 61131-3 (Witsch et al., 2010). The Vienna code genera- tomation scripts from domain-specific natural language descrip-
tor (Steinegger et al., 2017) first imports and analyzes existing con- tions. System components and their partial dataflow relations are
trol logic before adding generated code in an informed manner. inferred from the natural language description using a specialized
Best practices for model-driven software development (Voelter parser. Tichy et al. (2015) presents nlrpBENCH, a benchmark con-
and Bettin, 2004; Stahl et al., 2006) suggest to separate generated sisting of over 50 requirements documents to train model extrac-
and non-generated code, for example in different files, so that an tion and text correction approaches. Chalkidis et al. (2017) describe
iterative development is supported. A code generator can then eas- and experimentally compare several contract element extraction
ily overwrite files with generated code in a re-engineering scenario methods that use manually written rules and linear classifiers (lo-
without affecting manually written code. There are different meth- gistic regression, support vector machines) with hand-crafted fea-
ods for joining generated and non-generated code, including inter- tures, word embeddings, and part-of-speech tag embeddings.
faces, design patterns (e.g., factory, strategy, bridge), and template Most of these approaches still work on rather simple require-
methods, which are specific for object-oriented programming lan- ments texts that are sometimes heavily constrained or annotated
guages. For IEC 61131-3 code generated and non-generated code to allow processing. If texts are constrained into semi-formal lan-
may for example be arranged in different diagrams. During manual guage, the customer benefit of creating such requirements fast and
IEC 61131-3 coding, the control engineer needs to take care not to with limited special expertise may be invalidated. If pre-annotation
contradict the generated control logic. of the text requires too much effort, control engineers would likely
Versioning and file comparison tools are another means for fall back to manual interpretation, which in addition may be more
merging generated and manually written code during iterative robust. Practical problems, such as local languages, ambiguities in
code generation. This often works almost automated in case of the requirements, and non-standard terminology may complicate
additive actions, but may require manual intervention in case of natural language processing approaches further. However, the lim-
changes to existing code. None of the surveyed approaches dis- its for text mining in this context are still not well understood.
cusses these possibilities though. Standardized File Formats Both the rule-based approaches and
Input Data Validation Validation of customer inputs is often a higher-level programming approaches using the plant structure in
time-consuming problem in practice, which may require multiple this survey rely on standardized input file formats. However, in
feedback cycles between engineering contractor and automation practice, the file formats are often not yet readily available. As de-
vendor. Most of the surveyed approaches do not deal with this is- scribed in Section 2, many artifacts from customers are still ex-
sue beyond syntactical XML checks or assuming that a prior map- changed on paper or as unstructured PDF-files that complicate au-
ping to AutomationML/CAEX produced well-formed inputs. tomated processing (Arroyo et al., 2016). This has multiple reasons
In practice, there are different methods to address this is- as detailed in the following.
sue. Engineering contractors can use a common database, such as In some cases (e.g., for P&ID diagrams) there is a lack of stan-
SmartPlant Instrumentation39 to assure consistency of instrument dardized formats so far, or a lack of adoption of existing formats
indices. Additionally, they can utilize advanced CAD tools that al- from the software vendors. Smart P&IDs with an database under-
low validations of diagrams. But this approach is challenged if mul- lying the drawing capturing properties of instruments and equip-
tiple subcontractors are involved in the engineering (Drath and ment are still uncommon, the AutoCAD DWG format is often used
Barth, 2011). There are also engineering platforms, such as CO- for convenience, since it is also used for many other types of draw-
MOS40 EPlan41 or EBase42 which may support automation ven- ings and is supported by many general purpose drawing tools. The
dors in consistency and completeness checks. Nevertheless, more DEXPI initiative is working on an ISO15926-based exchange format
for P&IDs. AutomationML (IEC 62714) is gaining more support, but
39 remains far from broad industry adoption (Drath and Ingebrigt-
https://hexagonppm.com/.
40
https://www.siemens.com/comos. sen, 2018). There is no agreed format for I/O lists, but companies
41
https://www.eplan.de/. often work with specific guidelines. GRAFCET is a standardized no-
42
https://www.aucotec.com/. tation, but suffered from a missing agreed file format and tool-
 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575 19

ing, and it is known only in specific regions (Schumacher et al., • Non-Representative Selection of Approaches: Section 3 has
2013a). documented the used search facilities, search terms, and
Furthermore, some automation customers or engineering con- inclusion criteria of this paper. Excluding approaches gen-
tractors are concerned about losing intellectual property if spec- erating IEC 61499 control logic as well as other program-
ifications are exchanged in object-oriented and standardized no- ming languages is a threat to the representativeness of
tations. They fear that production processes may be more likely the survey, but was decided for conciseness and practical-
replicated by competitors if the files are easier to distribute and ity (Thramboulidis, 2013).
process. These concerns need to be addressed in a manner that • Irrelevant Classification Criteria: The classification criteria
does not complicate automated code generation, e.g., filtering or depicted in Fig. 12 are derived from the inputs required in
obfuscating certain IP sensitive specifications or enforcing confi- practice, the necessary transformation steps for a working
dentiality using processes. code generation, and the typical outputs of such approaches.
Another factor is the high heterogeneity of application domains, We used external references (Steinegger and Zoitl, 2012;
engineering workflows, and information models. The CAEX stan- Guttel et al., 2008) to make these criteria representative,
dard (IEC 62464) acknowledged this fact explicitly and separated more relevant, and reduce subjective author bias. We also
syntactic standardization (in XML) from semantic standardization contacted domain experts and reviewed numerous customer
(using role class libraries). This allows to syntactically treat engi- requirements specifications to get a deeper understanding of
neering artifacts in a uniform way, even if the semantics are under- the inputs available in practice.
stood only partially. Drath and Barth (2011) developed additional • Incorrect Analysis of Approaches: We were not able to test
concepts concepts reqarding tool interoperability and data owner- the approaches by executing their tooling on self-defined
ship on top of CAEX. Such concepts have so far been applied only cases. For almost all of the approaches, the tooling was not
in company-internal settings (e.g., Daimler (Burlein et al., 2018), readily available for reproduction. Thus, the analysis of the
ABB (Bihani and Drath, 2017)) for the exchange of engineering approaches is purely based on literature review.
data, but not across different organizations (Biffl et al., 2017). • Author Bias: The authors of this survey are affiliated with
Nevertheless, numerous customer organizations, such as NA- an automation company that provides commercial products
MUR, OPAF, DEXPI are pushing for more standards and their adop- for industrial automation. This may lead to a bias towards
tion, which may prove beneficial for automated code generation the contexts and perspectives of the authors. However, none
approaches directly processing customer artifacts. of the surveyed approaches is currently used by the authors’
Cost/Benefits of Code Generation The survey did not find any company, therefore assuring a level of objectivity.
cost/benefit studies for automated code generation in industrial
automation. Return on investment for IEC 61131-3 code generation 7. Related work
is not yet well validated and remains vague. Setting up a tool chain
for code generation may be costly and require a series of multiple Related Surveys Although there is no classification and compar-
similar projects to actually pay off. Control engineers need to cre- ison of IEC 61131-3 control logic generation in literature, there are
ate importers for their engineering tools, set up knowledge bases, several publications providing overviews of different model-driven
and elicit domain rules. They may need to train developers in mod- approaches and code generators for industrial automation appli-
ified UML/SysML versions. Whether the code generation is robust cations. Vyatkin’s state-of-the-art review of software engineering
and reliable in a realistic project is not well investigated. in industrial automation (Vyatkin, 2013) summarizes several ap-
While several experiments (Vogel-Heuser, 2014; Obermeier proaches for model-driven engineering according to the OMG stan-
et al., 2015) have demonstrated that control engineers can be more dards MDA, UML, and MOF. This coarsely maps to the higher-level
productive using a UML-based notation, it remains unclear if this programming approaches from our survey, but also includes ap-
benefit outweighs the drawback of introducing an additional UML proaches dealing with IEC 61499 control logic. The paper does not
tool. Control engineers may be bound to the engineering tools their deal with ruled-based code generation approaches and describes
employer provides for a commercial system, which may make it its included approaches on a higher abstraction level.
hard to introduce additional external tools. The survey by Yang et al. (2014) is also broader and less de-
It is unclear how much code can be generated, and how much tailed than our survey, reviewing MATLAB Simulink, SCADE, Open-
code is better created manually. For example, complex multicas- RTM, and IEC 61499 engineering concepts and tools. Vogel-
cading logic involving sophisticated algorithms may require human Heuser et al. (2015) describe general challenges and research di-
expertise for the foreseeable future and might be difficult to gen- rections for software development for automated production sys-
erate automatically. An elaborated code generation approach may tems. They point out that round-trip engineering, tool integration,
make the application implementation intransparent for control en- tool usability, and education are major challenges for model-driven
gineers, who might lose confidence in the generation if it proves engineering in industrial automation. They also list a number of
unreliable. UML/SysML related approaches, however without classifying them.
Benefits regarding higher code quality or saved time in relation Lukman et al. (2013) provided a short state-of-the-art anal-
to the overall engineering time lack hard evidence. Case studies ysis of process control engineering approaches, without includ-
need to be carried out with industry to better characterize cost ing rule-based approaches. They also included IEC 61499 ap-
and benefits of code generation considering different application proaches as well as approaches not generating classical control
domains and their constraints. logic. They attributed the limited industry adoption of these ap-
proaches to a “lack of automatic PLC code generation, lack of de-
velopment process definition and guidelines, and non-existent or
immature tools support, besides the use of device-centric abstrac-
6. Threats to validity tions”. Liebel et al. (2014) assessed the state-of-practice regard-
ing model-driven engineering for embedded systems, but did not
The comparison of code generation methods in this paper specifically deal with IEC 61131 control logic.
aimed to analyze the prerequisites and capabilities of the all rel- Related but Excluded Approaches Several related approaches have
evant published methods. The following threats to validity of this been excluded for different reasons. FUJABA (Schäfer et al., 2004)
survey have been explicitly considered and addressed: is an integrated tool environment, where Siemens PLC code can be
20 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

generated from SDL block diagrams, UML class diagrams, and UML quality attributes, such as performance or specification coverage.
behavior diagrams. This approach has been developed more than Most approaches remain in a proof-of-concept maturity.
15 years ago. The FAVA approach (Fay et al., 2015) translates SysML The classification framework in this paper can benefit practi-
requirements diagrams and manually specified models to Continu- tioners and researchers. Practitioners get a condensed state-of-the-
ous Function Charts that can be loaded into many PLCs. art review for code generation in industrial automation and can
Researchers have proposed several IEC 61499 approaches thus faster assess the benefits and drawbacks of each approach.
involving code generation, but none of them were devel- Although practitioners cannot apply most approaches directly in
oped into a robust tooling. Hussain and Frey (2006) gen- real projects due to the likely mismatch of available inputs and im-
erate IEC 61499 FB networks and test cases out of UML mature tool support, they can evaluate the potential of code gen-
use case, component, sequence, activity, and state diagrams. eration independently and work towards using the standard file
Panjaitan and Frey (2006) map UML and component diagrams formats suggested by the approaches. Researchers get a blueprint
to IEC 61499 FB networks. Thramboulidis and Buda (2010); to better compare and categorize existing and future approaches.
Thramboulidis (2010) propose the 3+1 SysML model to generate Research challenges derived from the comparison revolve around
IEC 61499 code. Wenger et al. (2009) propose a converter to trans- powerful and robust knowledge bases for rule-based engineering,
form IEC 61131-3 control logic into IEC 61499 logic to be able to processing natural language requirements, and supporting iterative
utilize its additional features. Dai and Vyatkin (2009) discuss mi- engineering processes with input validation, bi-directional transfor-
grating distributed IEC 61131-3 PLC code to IEC 61499 function mations, and code merging. Combinations of rule-based engineer-
blocks and illustrate three different migration methods on a con- ing approaches and higher-level programming approaches should
veyor belt system. be investigated.
Yang et al. (2017) propose a method to transform IEC 61850 Upon a maturation of the surveyed approaches, a benchmark
system configuration language (SCL) specifications into logical con- for automatic IEC 61131-3 code generation should be developed
nections in an IEC 61499 substation automation control appli- to better compare their capabilities and give out research chal-
cation. This involves creating an ontology from the specifica- lenges to extend the code generation capabilities. Such a bench-
tions in the Web Ontology Language (OWL), which is then trans- mark should include representative inputs artifacts available in
formed into logical connections of IEC 61499 function blocks practice in different file formats. It could include natural language
using the enhanced Semantic Web Rule Language (eSWRL). requirements to test text mining approaches. Benchmark scores
Voinov et al. (2017) created an automatic HMI generator for this could be defined for specification coverage, efficiency, and user-
method. Furthermore, the authors extended the approach to use friendliness. Such a benchmark would need to be maintained peri-
restricted natural language (RNL) using Boilerplate models as in- odically and be updated with new community challenges.
put (Yang et al., 2020). While this overall method was demon- In the future, control logic generation approaches may pro-
strated for smart grid systems, the mechanisms behind it could be duce IEC 61499 control logic or other programming languages
transferred to other domains as well. and interface with approaches for Modular Automation (NAMUR
Furthermore, several older code generation approaches use MTP (Bernshausen et al., 2016)), if these languages and initiatives
formal modeling notations, such as Petri nets or timed au- achieve a higher market penetration. User studies should be con-
tomata. Cutts and Rattigan (1992) propose a PLC code generation ducted to assess control logic generation approaches. Criteria or
method with Petri Net-based modeling techniques for a three- specific project contexts should be defined to help practitioners
stage manufacturing system. Jörns et al. (1995) introduced sig- to decide for or against code generation given certain project con-
nal interpreted Petri nets and translated them to LD or IL code. straints.
Frey (20 0 0) propose a PLC code generation approach by arrang-
ing code fragments which directly correspond to Petri net ele- Declaration of Competing Interest
ments. Thieme and Hanisch (2002) present a modeling formalism
to generate modular control logic using IEC 61131 functions blocks. The authors declare that they have no known competing finan-
Music et al. (2005) apply real-time petri nets to generate control cial interests or personal relationships that could have appeared to
logic implementations. Sacha (2005) proposes a formalization for influence the work reported in this paper.
transformations of timed finite state machines into PLC control
code. Endsley et al. (2006) generate control logic for a conveyor CRediT authorship contribution statement
system out of finite state machines but do not specifically aim at
IEC 61131-3 code. Flordal et al. (2007) generate executable inter- Heiko Koziolek: Conceptualization, Methodology, Writing -
locking policies implemented in PLC programming languages for original draft, Visualization, Supervision. Andreas Burger: Con-
industrial robot cells. Bergert et al. (2007) generate IEC 61131 SFCs ceptualization, Investigation, Writing - review & editing. Marie
from Pert charts encoded in XML. Wang et al. (2009) use timed Platenius-Mohr: Conceptualization, Investigation, Writing - review
automata and create an automated translation into LD. & editing. Raoul Jetley: Conceptualization, Investigation, Writing -
review & editing.

References
8. Conclusions
Alvarez, M.L., Sarachaga, I., Burgos, A., Estévez, E., Marcos, M., 2018. A methodolog-
This paper classified 13 control logic generation approaches for ical approach to model-driven design and development of automation systems.
IEEE Trans. Autom. Sci. Eng. 15 (1), 67–79.
IEC 61131-3 programming languages. Automating the task of soft-
Arroyo, E., Hoernicke, M., Rodríguez, P., Fay, A., 2016. Automatic derivation of qual-
ware implementation for real-time controllers in industrial au- itative plant simulation models from legacy piping and instrumentation dia-
tomation could result in a significant cost reduction for the engi- grams. Comput. Chem. Eng. 92, 112–132.
Baeza-Yates, R., Ribeiro, B.d.A.N., et al., 2011. Modern information retrieval. New
neering process of industrial plants. The classification criteria used
York: ACM Press; Harlow, England: Addison-Wesley,.
in this paper originate from the customer specifications available in Barth, M., Drath, R., Fay, A., Zimmer, F., Eckert, K., 2012. Evaluation of the openness
practice (inputs), an idealized model transformation process, and of automation tools for interoperability in engineering tool chains. In: Proceed-
the typical outputs of control logic formats and kinds. The analy- ings of 2012 IEEE 17th International Conference on Emerging Technologies &
Factory Automation (ETFA 2012). IEEE, pp. 1–8.
sis of the 13 approaches showed that they have different goals and Barth, M., Fay, A., 2013. Automated generation of simulation models for control code
follow different patterns, which complicates direct comparisons for tests. Control Eng. Pract. 21 (2), 218–230.
 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575 21

Bergert, M., Diedrich, C., Kiefer, J., Bar, T., 2007. Automated PLC software generation Hästbacka, D., Vepsäläinen, T., Kuikka, S., 2011. Model-driven development of indus-
based on standardized digital process information. In: 2007 IEEE Conference on trial process control applications. J. Syst. Softw. 84 (7), 1100–1113.
Emerging Technologies and Factory Automation (EFTA 2007). IEEE, pp. 352–359. Hussain, T., Frey, G., 2006. UML-based development process for IEC 61499 with au-
Bernshausen, J., Haller, A., Holm, T., Hoernicke, M., Obst, M., Ladiges, J., 2016. Namur tomatic test-case generation. In: 2006 IEEE Conference on Emerging Technolo-
modul type package–Definition. atp magazin 58 (01–02), 72–81. gies and Factory Automation. IEEE, pp. 1277–1284.
Biffl, S., Mordinyi, R., Steininger, H., Winkler, D., 2017. Integrationsplattform Für An- Jamro, M., Rzonca, D., 2018. Agile and hierarchical round-trip engineering of IEC
lagenmodellorientiertes Engineering. In: Handbuch Industrie 4.0 Bd. 2. Springer, 61131-3 control software. Comput. Ind. 96, 1–9.
pp. 189–212. Jörns, C., Litz, L., Bergold, S., 1995. Automatische erzeugung von SPS-Programmen
Bihani, P., Drath, R., 2017. Concept for automationml-based interoperability between auf der basis von petri-Netzen. Automatisierungstechnische Praxis 37 (3), 10–14.
multiple independent engineering tools without semantic harmonization: Ex- Julius, R., Fink, V., Uelzen, S., Fay, A., 2019. Konzept zur bidirektionalen transforma-
periences with automationml. In: 2017 22nd IEEE International Conference on tion zwischen GRAFCET-Spezifikationen und IEC 61131-3 steuerungscode. at-Au-
Emerging Technologies and Factory Automation (ETFA). IEEE, pp. 1–8. tomatisierungstechnik 67 (3), 208–217.
Breyfogle III, F.W., Cupello, J.M., Meadows, B., 20 0 0. Managing six sigma: A practical Julius, R., Schürenberg, M., Schumacher, F., Fay, A., 2017. Transformation of GRAFCET
guide to understanding, assessing, and implementing the strategy that yields to PLC code including hierarchical structures. Control Eng. Pract. 64, 173–194.
bottom-line success. John Wiley & Sons. Katzke, U., Vogel-Heuser, B., 2005. UML-PA As an engineering model for distributed
Burlein, J., Rassl, M., Schmidt, N., 2018. Introducing AutomationML in a heteroge- process automation. IFAC Proceed. 38 (1), 129–134.
neous software tool landscape - a success story, 5th AutomationML User Con- Kitchenham, B., Charters, S., 2007. Guidelines for performing systematic literature
ference, 2018. https://bit.ly/2LOfN4p. reviews in software engineering. Technical Report. Technical report, Ver. 2.3
Chalkidis, I., Androutsopoulos, I., Michos, A., 2017. Extracting Contract Elements. In: EBSE Technical Report. EBSE.
Proceedings of the 16th Edition of the International Conference on Articial In- Koltun, G., Kolter, M., Vogel-Heuser, B., 2018. Automated Generation of Modular PLC
telligence and Law. ACM, New York, NY, USA, pp. 19–28. doi:10.1145/3086512. Control Software from P&ID Diagrams in Process Industry. In: 2018 IEEE Inter-
3086515. national Systems Engineering Symposium (ISSE). IEEE, pp. 1–8.
Cutts, G., Rattigan, S., 1992. Using Petri nets to develop programs for PLC systems. Krausser, T., Quirós, G., Epple, U., 2011. An IEC-61131-based rule system for
In: International Conference on Application and Theory of Petri Nets. Springer, integrated automation engineering: Concept and case study. In: 2011 9th
pp. 368–372. IEEE International Conference on Industrial Informatics. IEEE, pp. 539–
Dai, W.W., Vyatkin, V., 2009. A case study on migration from iec 61131 plc to iec 544.
61499 function block control. In: 2009 7th IEEE International Conference on In- Le, V., Gulwani, S., Su, Z., 2013. SmartSynth: Synthesizing Smartphone Automation
dustrial Informatics. IEEE, pp. 79–84. Scripts from Natural Language. In: Proceeding of the 11th Annual International
Deeptimahanti, D.K., Babar, M.A., 2009. An Automated Tool for Generating UML Conference on Mobile Systems, Applications, and Services. ACM, New York, NY,
Models from Natural Language Requirements. In: Proceedings of the 2009 USA, pp. 193–206. doi:10.1145/2462456.2464443.
IEEE/ACM International Conference on Automated Software Engineering. IEEE Liebel, G., Marko, N., Tichy, M., Leitner, A., Hansson, J., 2014. Assessing the
Computer Society, Washington, DC, USA, pp. 680–682. doi:10.1109/ASE.2009.48. state-of-practice of model-based engineering in the embedded systems domain.
Doherr, F., Urbas, L., Drumm, O., Franze, V., 2013. Bedienbilder auf Knopfdruck. atp In: International Conference on Model Driven Engineering Languages and Sys-
magazin 53 (11), 30–39. tems. Springer, pp. 166–182.
Drath, R., Barth, M., 2011. Concept for interoperability between independent engi- Ljungkrantz, O., Akesson, K., 2007. A study of industrial logic control programming
neering tools of heterogeneous disciplines. In: ETFA2011. IEEE, pp. 1–8. using library components. In: 2007 IEEE International Conference on Automa-
Drath, R., Fay, A., Schmidberger, T., 2006. Computer-aided design and implementa- tion Science and Engineering. IEEE, pp. 117–122.
tion of interlock control code. In: IEEE Conference on Computer Aided Control Lukman, T., Godena, G., Gray, J., Heričko, M., Strmčnik, S., 2013. Model-driven engi-
System Design. IEEE, pp. 2653–2658. neering of process control software–beyond device-centric abstractions. Control
Drath, R., Ingebrigtsen, I., 2018. Digitalization of the IEC PAS 63131 Standard with Eng. Pract. 21 (8), 1078–1096.
AutomationML. In: 2018 IEEE 23rd International Conference on Emerging Tech- Martin, P., Hale, G., 2010. Automation made easy: everything you wanted to know
nologies and Factory Automation (ETFA), 1, pp. 901–909. doi:10.1109/ETFA.2018. about automation and need to ask. Int. Soc. Autom.
8502458. Mens, T., Van Gorp, P., 2006. A taxonomy of model transformation. Electron. Notes
Endsley, E., Almeida, E., Tilbury, D., 2006. Modular finite state machines: develop- Theor. Comput. Sci. 152, 125–142.
ment and application to reconfigurable manufacturing cell controller genera- Music, G., Gradisar, D., Matko, D., 2005. IEC 61131-3 compliant control code genera-
tion. Control Eng. Pract. 14 (10), 1127–1142. tion from discrete event models. In: Proceedings of the 2005 IEEE International
Fay, A., 2003. A knowledge-based system to translate control system applications. Symposium on, Mediterrean Conference on Control and Automation Intelligent
Eng. Appl. Artif. Intell. 16 (5–6), 567–577. Control, 2005.. IEEE, pp. 346–351.
Fay, A., 2003. A knowledge-based system to translate control system applications. Obermeier, M., Braun, S., Vogel-Heuser, B., 2015. A model-driven approach on objec-
Eng. Appl. Artif. Intell. 16 (5–6), 567–577. t-oriented PLC programming for manufacturing systems with regard to usability.
Fay, A., Drath, R., Bort, P., 2001. Design and implementation of a Java-based indus- IEEE Trans. Ind. Inf. 11 (3), 790–800.
trial control system configuration tool. In: ETFA 2001. 8th International Confer- Otto, A., Hellmann, K., 2009. IEC 61131: A general overview and emerging trends.
ence on Emerging Technologies and Factory Automation. Proceedings (Cat. No. IEEE Ind. Electron. Mag. 3 (4), 27–31.
01TH8597), 2. IEEE, pp. 553–558. Panjaitan, S., Frey, G., 2006. Combination of UML modeling and the IEC 61499 func-
Fay, A., Schmidberger, T., Scherf, T., 2009. Knowledge-based support of HAZOP stud- tion block concept for the development of distributed automation systems. In:
ies using a CAEX plant model. Inside Funct. Saf. 2009 (2), 5–15. 2006 IEEE Conference on Emerging Technologies and Factory Automation. IEEE,
Fay, A., Vogel-Heuser, B., Frank, T., Eckert, K., Hadlich, T., Diedrich, C., 2015. En- pp. 766–773.
hancing a model-based engineering approach for distributed manufacturing au- Sacha, K., 2005. Automatic code generation for PLC controllers. In: International
tomation systems with characteristics and design patterns. J. Syst. Softw. 101, Conference on Computer Safety, Reliability, and Security. Springer, pp. 303–
221–235. 316.
Feldman, R., Sanger, J., 2007. The text mining handbook: Advanced approaches in Schäfer, W., Wagner, R., Gausemeier, J., Eckes, R., 2004. An EngineerâS Workstation
analyzing unstructured data. Cambridge university press. to Support Integrated Development of Flexible Production Control Systems. In:
Flordal, H., Fabian, M., Åkesson, K., Spensieri, D., 2007. Automatic model generation Integration of Software Specification Techniques for Applications in Engineering.
and PLC-code implementation for interlocking policies in industrial robot cells. Springer, pp. 48–68.
Control Eng. Pract. 15 (11), 1416–1426. Schmidberger, T., Fay, A., 2007. A rule format for industrial plant information rea-
Forbes, H., Clayton, D., 2018. Distributed Control Systems Global Market 2017– soning. In: 2007 IEEE Conference on Emerging Technologies and Factory Au-
2022. ARC Market Analysis, ARC Advisory Group, https://www.arcweb.com/ tomation (EFTA 2007). IEEE, pp. 360–367.
market-studies/distributed-control-systems. Schmidberger, T., Horch, A., Fay, A., Drath, R., Breitenecker, F., Troch, I., 2006. Rule
Frey, G., 20 0 0. Automatic implementation of Petri net based control algorithms on based engineering of asset management system functionality. 5th Vienna Sym-
PLC. In: Proceedings of the 20 0 0 American Control Conference. ACC (IEEE Cat. posium on Mathematical Modelling, 8.
No. 00CH36334), 4. IEEE, pp. 2819–2823. Schmitz, S., Epple, U., 2007. Automated engineering of human machine interfaces.
Friedrich, D., Vogel-Heuser, B., 2007. Benefit of system modeling in automation and In: VDI/VDE Gesellschaft Mess-und Automatisierungstechnik, pp. 127–138.
control education. In: 2007 American Control Conference. IEEE, pp. 2497–2502. Schüller, A., Epple, U., 2012. PandIX – Exchanging P&I diagram model data. In: Pro-
Gelhausen, T., Tichy, W.F., 2007. Thematic role based generation of UML models from ceedings of 2012 IEEE 17th International Conference on Emerging Technologies
real world requirements. In: International Conference on Semantic Computing Factory Automation (ETFA 2012), pp. 1–8. doi:10.1109/ETFA.2012.6489537.
(ICSC 2007). IEEE, pp. 282–289. Schumacher, F., Fay, A., 2014. Formal representation of GRAFCET to automatically
Grüner, S., Weber, P., Epple, U., 2014. A model for discrete product flows in man- generate control code. Control Eng. Pract. 33, 84–93.
ufacturing plants. In: Proceedings of the 2014 IEEE Emerging Technology and Schumacher, F., Schröck, S., Fay, A., 2013. Tool support for an automatic transfor-
Factory Automation (ETFA). IEEE, pp. 1–8. mation of GRAFCET specifications into IEC 61131-3 control code. In: 2013 IEEE
Grüner, S., Weber, P., Epple, U., 2014. Rule-based engineering using declarative graph 18th Conference on Emerging Technologies & Factory Automation (ETFA). IEEE,
database queries. In: 2014 12th IEEE International Conference on Industrial In- pp. 1–4.
formatics (INDIN). IEEE, pp. 274–279. Schumacher, F., Schröck, S., Fay, A., 2013. Transforming hierarchical concepts of
Gutermuth, G., 2010. Collaborative Process Automation Systems. ISA, pp. 156–182. GRAFCET into a suitable Petri net formalism. IFAC Proceed. 46 (9), 295–
Guttel, K., Weber, P., Fay, A., 2008. Automatic generation of PLC code beyond the 300.
nominal sequence. In: 2008 IEEE International Conference on Emerging Tech- Stahl, T., Voelter, M., Czarnecki, K., 2006. Model-driven software development: Tech-
nologies and Factory Automation. IEEE, pp. 1277–1284. nology, engineering, management. John Wiley & Sons, Inc.
22 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575

Steinegger, M., Melik-Merkumians, M., Schitter, G., 2017. Ontology-based framework Yang, C., Dubinin, V., Vyatkin, V., 2020. Automatic generation of control flow from
for the generation of interlock code with redundancy elimination. In: Proc. 22nd requirements for distributed smart grid automation control. IEEE Trans. Ind. Inf.
IEEE International Conference on Emerging Technologies and Factory Automa- 16 (1), 403–413. doi:10.1109/TII.2019.2930772.
tion (ETFA). IEEE, pp. 1–5. Yang, C.-H., Vyatkin, V., Pang, C., 2014. Model-driven development of control soft-
Steinegger, M., Melik-Merkumians, M., Zajc, J., Schitter, G., 2016. Automatic genera- ware for distributed automation: a survey and an approach. IEEE Trans. Syst.
tion of diagnostic handling code for decentralized PLC-based control architec- Man Cybernet. 44 (3), 292–305.
tures. In: Proc. IEEE 21st International Conference on Emerging Technologies Yim, S.Y., Ananthakumar, H.G., Benabbas, L., Horch, A., Drath, R., Thornhill, N.F.,
and Factory Automation (ETFA). IEEE, pp. 1–8. 2006. Using process topology in plant-wide control loop performance assess-
Steinegger, M., Zoitl, A., 2012. Automated code generation for programmable logic ment. Comput. Chem. Eng. 31 (2), 86–99.
controllers based on knowledge acquisition from engineering artifacts: Concept Alvarez, M.L., Sarachaga, I., Burgos, A., Estevez, E., Marcos, M., 2018. A methodolog-
and case study. In: Proceedings of 2012 IEEE 17th International Conference on ical approach to model-driven design and development of automation systems.
Emerging Technologies & Factory Automation (ETFA 2012). IEEE, pp. 1–8. IEEE Trans. Autom. Sci. Eng. 15, 67–79.
Sun, Q., 2013. A method for generating process topology-based causal models. Aalto Drath, R., Fay, A., Schmidberger, T., 2006. Computer-aided design and implementa-
University School of Chemical Technology. tion of interlock control code, in: IEEE conference on computer aided control
Suresh, V.P., Chakrabarti, S., Jetley, R., 2019. Automated Test Case Generation for Pro- system design. IEEE 2653–2658.
grammable Logic Controller Code. In: Proceedings of the 12th Innovations on Estevez, E., Marcos, M., Orive, D., 2007. Automatic generation of plc automation
Software Engineering Conference (formerly known as India Software Engineer- projects from component-based models. The Int. J. Adv. Manuf. Technol. 35,
ing Conference). ACM, p. 29. 527–540.
Tan, W.C., Chen, I.-M., Tan, H.K., 2016. Automated identification of components in Grüner, S., Weber, P., Epple, U., 2014. Rule-based engineering using declarative graph
raster piping and instrumentation diagram with minimal pre-processing. In: database queries, in: 2014 12th IEEE international conference on industrial in-
2016 IEEE International Conference on Automation Science and Engineering formatics (INDIN). IEEE 274–279.
(CASE). IEEE, pp. 1301–1306. Hästbacka, D., Vepsäläinen, T., Kuikka, S., 2011. Model-driven development of indus-
Thieme, J., Hanisch, H.-M., 2002. Model-based generation of modular plc code using trial process control applications. J. Syst. Softw. 84, 1100–1113.
iec61131 function blocks. In: Proceedings of the International Symposium on Koltun, G., Kolter, M., Vogel-Heuser, B., 2018. Automated Generation of Modular PLC
Industrial Electronics, 1, pp. 199–204. Control Software from P&ID Diagrams in Process Industry. In: 2018 IEEE Inter-
Thramboulidis, K., 2010. The 3+ 1 SysML view-model in model integrated mecha- national Systems Engineering Symposium (ISSE). IEEE, pp. 1–8.
tronics. J. Softw. Eng. Applic. 3 (02), 109. Lukman, T., Godena, G., Gray, J., Hericko, M., Strmcnik, S., 2013. Model-driven engi-
Thramboulidis, K., 2013. IEC 61499 Vs. 61131: a Comparison based on mispercep- neering of process control software - beyond device-centric abstractions. Con-
tions. arXiv:1303.4761. https://arxiv.org/ftp/arxiv/papers/1303/1303.4761.pdf. trol Eng. Pract. 21, 1078–1096.
Thramboulidis, K., Buda, A., 2010. 3+ 1 SysML view model for IEC61499 Function Schumacher, F., Schröck, S., Fay, A., 2013. Tool Support for an Automatic Transfor-
Block control systems. In: 2010 8th IEEE International Conference on Industrial mation of GRAFCET Specifications into Iec 61131-3 Control Code. In: 2013 IEEE
Informatics. IEEE, pp. 175–180. 18th Conference on Emerging Technologies & Factory Automation (ETFA). IEEE,
Thramboulidis, K., Frey, G., 2011. An MDD process for IEC 61131-based industrial pp. 1–4. F. Schumacher, S. Schröck, A. Fay, Transforming hierarchical concepts
automation systems. In: ETFA2011. IEEE, pp. 1–8. of GRAFCET into a suitable petri net formalism, IFAC Proceedings Volumes 46
Thramboulidis, K.C., 2004. Using UML in control and automation: a model driven (2013) 295–300. F. Schumacher, A. Fay, Formal representation of GRAFCET to au-
approach. In: 2nd IEEE International Conference on Industrial Informatics, 2004. tomatically generate control code, Control Engineering Practice 33 (2014) 84–93.
INDIN’04. IEEE, pp. 587–593. R. Julius, M. Schürenberg, F. Schumacher, A. Fay, Transformation of GRAFCET PLC
Tichy, W.F., Landhäußer, M., Körner, S.J., 2015. nlrpBENCH: a benchmark for natu- code including hierarchical structures, Control Engineering Practice 64 (2017)
ral language requirements processing. Multikonferenz Software Engineering & 173–194
Management 2015. Gesellschaft für Informatik eV. Steinegger, M., Zoitl, A., 2012. Automated Code Generation for Programmable Logic
Tiegelkamp, M., John, K.-H., 1995. IEC 61131-3: Programming industrial Automation Controllers Based on Knowledge Acquisition from Engineering Artifacts: Con-
Systems. Springer. cept and Case Study. In: Proc. of 2012 IEEE 17th International Conference on
Tikhonov, D., Schütz, D., Ulewicz, S., Vogel-Heuser, B., 2014. Towards industrial ap- Emerging Technologies & Factory Automation (ETFA 2012). IEEE, pp. 1–8. M.
plication of model-driven platform-independent PLC programming using UML. Steinegger, M. Melik-Merkumians, J. Zajc, G. Schitter, Automatic generation of
In: IECON 2014-40th Annual Conference of the IEEE Industrial Electronics Soci- diagnostic handling code for decentralized plc-based control architectures, in:
ety. IEEE, pp. 2638–2644. Proc. IEEE 21st International Conference on Emerging Technologies and Factory
Urbas, L., Krause, A., Ziegler, J., 2012. Process Control Systems Engineering. Olden- Automation (ETFA), IEEE, 2016, pp. 1–8. M. Steinegger, M. Melik-Merkumians,
bourg Industrieverlag GmbH Munich. G. Schitter, Ontology-based framework for the generation of interlock code with
Voelter, M., Bettin, J., 2004. Patterns for Model-Driven Software-Development. In: redundancy elimination, in: Proc. 22nd IEEE International Conference on Emerg-
EuroPLoP, pp. 525–560. ing Technologies and Factory Automation (ETFA), IEEE, 2017, pp. 1–5
Vogel-Heuser, B., 2014. Usability experiments to evaluate UML/SysML-based model Thramboulidis, K., Frey, G., 2011. An MDD Process for IEC 61131-Based Industrial
driven software engineering notations for logic control in manufacturing au- Automation Systems. In: ETFA2011. IEEE, pp. 1–8.
tomation. J. Softw. Eng. Applic. 7 (11), 943. Vogel-Heuser, B., Schütz, D., Frank, T., Legat, C., 2014. Model-driven engineering of
Vogel-Heuser, B., Fay, A., Schaefer, I., Tichy, M., 2015. Evolution of software in au- manufacturing automation software projects - a sysML-based approach. Mecha-
tomated production systems: challenges and research directions. J. Syst. Softw. tronics 24, 883–897.
110, 54–84. Vogel-Heuser, B., Witsch, D., Katzke, U., 2005. Automatic Code Generation from a
Vogel-Heuser, B., Schütz, D., Frank, T., Legat, C., 2014. Model-driven engineering of UML Model to IEC 61131-3 and System Configuration Tools. In: 2005 Interna-
manufacturing automation software projects–A sysML-based approach. Mecha- tional Conference on Control and Automation, volume 2. IEEE, pp. 1034–1039.
tronics 24 (7), 883–897. Witsch, D., Vogel-Heuser, B., 2009. Close Integration between UML and IEC 61131-3:
Vogel-Heuser, B., Witsch, D., Katzke, U., 2005. Automatic code generation from a New Possibilities through Object-oriented Extensions. In: 2009 IEEE Conference
UML model to IEC 61131-3 and system configuration tools. In: 2005 Interna- on Emerging Technologies & Factory Automation. IEEE, pp. 1–6. D. Witsch, M.
tional Conference on Control and Automation, 2. IEEE, pp. 1034–1039. Ricken, B. Kormann, B. Vogel-Heuser, PLC-Statecharts: An approach to integrate
Voinov, A., Yang, C., Vyatkin, V., 2017. Automatic generation of function block UML statecharts in open-loop control engineering, in: 2010 8th IEEE Interna-
systems implementing hmi for energy distribution automation. In: 2017 IEEE tional Conference on Industrial Informatics, IEEE, 2010, pp. 915–920. D. Witsch,
15th International Conference on Industrial Informatics (INDIN), pp. 706–713. B. Vogel-Heuser, PLC-Statecharts: An approach to integrate UML-statecharts in
doi:10.1109/INDIN.2017.8104859. open-loop control engineering - Aspects on behavioral semantics and mod-
Vyatkin, V., 2013. Software engineering in industrial automation: state-of-the-art re- el-checking, IFAC Proceedings Volumes 44 (2011) 7866–7872
view. IEEE Trans. Ind. Inf. 9 (3), 1234–1249.
Wang, R., Gu, M., Song, X., Wan, H., 2009. Formal specification and code generation Heiko Koziolek is a Senior Principal Scientist at ABB Corporate Research in Laden-
of programable logic controllers. In: 2009 14th IEEE International Conference on burg, Germany. He leads research projects on software architectures for industrial
Engineering of Complex Computer Systems. IEEE, pp. 102–109. process control and coordinated different projects on sustainable architectures. He
Wenger, M., Zoitl, A., Sunder, C., Steininger, H., 2009. Transformation of iec 61131-3 studied computer science at the Carl von Ossietzky University of Oldenburg and
to iec 61499 based on a model driven development approach. In: 2009 7th IEEE obtained a PhD in software engineering in 2008. His research is concerned with
International Conference on Industrial Informatics. IEEE, pp. 715–720. performance prediction for software systems as well as analyzing software main-
Wiriyacoonkasem, S., Esterline, A.C., 20 0 0. Adaptive learning expert systems. In: tainability. He serves on the program committee of leading conferences on software
Proceedings of the IEEE SoutheastCon 20 0 0.Preparing for The New Millen- engineering (ICSE) and software architecture (ICSA) and as an Associate Editor for
nium’(Cat. No. 00CH37105). IEEE, pp. 445–448. Elsevier ”Journal of Systems and Software”.
Witsch, D., Ricken, M., Kormann, B., Vogel-Heuser, B., 2010. PLC-statecharts: an ap-
proach to integrate umlstatecharts in open-loop control engineering. In: 2010
8th IEEE International Conference on Industrial Informatics. IEEE, pp. 915–920. Andreas Burger is a Research Team Manager at ABB Corporate Research in Laden-
Wohlin, C., 2014. Guidelines for snowballing in systematic literature studies and a burg, Germany. He leads research projects on software architecture and software
replication in software engineering. In: Proceedings of the 18th international product lines in industrial automation. He studied computer science at the Univer-
conference on evaluation and assessment in software engineering. Citeseer, sity of Tbingen, Germany, and graduated with a PhD in 2015 while working for
p. 38. Forschungszentrum Informatik (FZI) in Karlsruhe, Germany. He has experience in
Yang, C., Dubinin, V., Vyatkin, V., 2017. Ontology driven approach to generate dis- embedded system development and the automotive domain.
tributed automation control from substation automation design. IEEE Trans. Ind.
Inf. 13 (2), 668–679. doi:10.1109/TII.2016.2634095.
 H. Koziolek, A. Burger and M. Platenius-Mohr et al. / The Journal of Systems and Software 166 (2020) 110575 23

Marie Platenius-Mohr is a Scientist at ABB Corporate Research in Ladenburg, Ger- Raoul Jetley is a Senior Principal Scientist at ABB Corporate Research in Bangalore,
many. She is conducting research in the industrial automation domain. Her re- India. He leads cross-center research projects to improve the efficiency of indus-
search interests are software architecture, information modeling, internet-of-things, trial power systems and software. He studied computer science at the University
and model-driven development. She studied computer science at the University of of Mumbai and North Carolina State University and graduated with a PhD in 2006.
Paderborn, Germany, and graduated with a PhD in 2016. Afterwards, she worked He has developed program analysis tools for industrial automation systems and has
as a PostDoc in the Collaborative Research Center On-the-Fly Computing and joined more than 15 years of experience in industry and academic environments.
ABB in 2018.