A Classification Framework for Automated Control Code Generation

in Industrial Automation
Heiko Kozioleka , Andreas Burgera , Marie Platenius-Mohra and Raoul Jetleyb
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

ARTICLE INFO ABSTRACT

Keywords: Software development for the automation of industrial facilities (e.g., oil platforms, chemical plants,
Software Design and Implementation power plants, etc.) involves implementing control logic, often in IEC 61131-3 programming lan-
Industrial Automation guages. Developing safe and efficient program code is expensive and today still requires substantial
Control Engineering manual effort. Researchers have thus proposed numerous approaches for automatic control logic gen-
Model-driven Development eration in the last two decades, but a systematic, in-depth analysis of their capabilities and assumptions
Code Generation is missing. This paper proposes a novel classification framework for control logic generation ap-
UML / SysML proaches defining criteria derived from industry best practices. The framework is applied to compare
and analyze 13 different control logic generation approaches. Prominent findings include different
categories of control logic generation approaches, the challenge of dealing with iterative engineering
processes, and the need for more experimental validations in larger case studies.

1. Introduction tasks because of missing reusable components [6]. Manu-

ally written code needs to be tested thoroughly to ensure safe
Software development for industrial automation appli-
plant operation.
cations requires substantial design and implementation ef- Due to the high engineering costs, practitioners and re-
forts [1]. Besides various client-server applications for su- searchers have sought methods and tools for automating con-
pervision and monitoring in this domain, time-critical con- trol logic development [7]. Practitioners introduced bulk en-
trol software runs on real-time controllers and manages com- gineering to semi-automatically deal with list-based specifi-
plex production processes of chemical plants, power plants,
cations and created engineering libraries to bundle reusable
oil platforms, pulp and paper mills, or steel mills [2]. Con-
functionality [1]. Researchers worked on higher-level mod-
trol engineers often create this control software in program- eling languages (e.g., applying UML or SysML for industrial
ming languages according to IEC 61131-3, namely function automation [8]) and proposed rule-based code generation
block diagrams, structured text, sequential function charts, approaches [9]. An overview of these approaches is missing,
ladder diagrams, or instruction lists [3]. The software exe- which complicates identifying and selecting an appropriate
cutes cyclically and computes control signals for actuators,
approach or to identify research opportunities. Existing lit-
such as valves, motors, or robots, based on periodically sam-
erature reviews in this area [7, 5, 10, 11, 12] usually do not
pled sensor signals as inputs (e.g., for temperature, flow, focus on the aspect of automatic code generation and rather
pressure, level, etc.). The software ensures efficient and safe provide coarse-grained descriptions of several selected ap-
execution of the production process. The development of proaches. They do not provide detailed classification frame-
this software is embedded into a larger engineering process
works nor mirror existing approaches against requirements
that also covers hardware engineering, HMI development,
from practice. In this work, we aim to close this gap.
and device configuration [1]. The contribution of this paper is a classification frame-
Engineering industrial plants is an expensive process to- work for automated code generation approaches for IEC
day and may require several person years for a mid-sized 61131-3 control logic. The classification framework de-
plant with several thousand I/O points [1]. Requirements fines categories and criteria to evaluate such code genera-
and designs for such plants come from automation cus-
tion approaches. This can help researchers and practition-
tomers or engineering contractors, who often provide mostly
ers to compare different approaches regarding their capabili-
informal specifications. Control engineers of automation ties. Using the classification framework, this paper analyzes
providers partially import these specifications into engineer- 13 different code generation approaches from literature in
ing software tools and manually interpret them to implement the last 15 years. This analysis identifies patterns and com-
the required control logic [4]. This process exhibits media monalities between the approaches as well as research gaps.
discontinuities, where data is manually transformed between
Based on findings from the comparison, this paper also dis-
different formats. This may lead to data inconsistencies re-
cusses implications and required future work.
quiring time-consuming feedback loops with the customer. The 13 approaches map into three different categories:
Furthermore, control engineers often use low-level program- rule-based engineering, higher-level programming, and
ming abstractions [5] and execute repetitive implementation higher-level programming using a plant structure as input.
heiko.koziolek@de.abb.com (H. Koziolek) Approaches within the same category use similar input spec-
ORCID (s): ifications. Most approaches have been demonstrated on

Koziolek et al.: Preprint submitted to Elsevier Page 1 of 26

 Classication Framework 61131 Logic Generation

small lab examples so far, some approaches were tested in 2.1 Inputs
student experiments. Challenges for all approaches are miss- The inputs used by engineers for control logic imple-
ing support for standard input formats, iterative engineering mentation vary across different application domains. Ac-
processes, and dealing with natural language requirements. cording to ANSI / ISA 5.06.01-20072 (Functional Require-
Recent standardization initiatives could improve the situa- ments Documentation for Control Software Applications),
tion, warranting further research and more extensive valida- a User Requirements Specification (URS) includes piping
tions. and instrumentation diagrams (P&IDs), an instrument list,
This paper is structured as follows. Section 2 recaps and process flow diagrams. From these artifacts, instrument
basics of control logic generation using a running exam- tag table (or I/O list), interlock matrix, sequence matrix, and
ple, sketches a generic transformation process, and surveys Human Machine Interface (HMI) are developed. These ar-
inputs available in practice. Section 3 describes the re- tifacts are used as the Functional Requirements Specifica-
search methodology underlying this study, provides a short tion (FRS), which also pertains other aspects besides con-
overview on the identified approaches, and then proposes trol logic. However, projects often do not strictly follow this
and explains our classification framework. Section 4 applies guideline and provide other or alternative artifacts. The fol-
the classification framework to the 13 identified approaches lowing paragraphs detail P&IDs, I/O lists, logic diagrams,
and provides a detailed analysis of their inputs, transforma- control narratives, and flow charts, because they are the most
tions, and outputs. Section 5 discusses selected findings important inputs specifically for designing and implement-
from the comparison in Section 4 and sketches challenges ing the control logic.
to be tackled in future work. Section 6 analyzes threats to P&IDs: A P&ID provides a graphical overview of a
validity of the present study, and Section 7 summarizes re- plant segment. There can be hundreds of P&IDs to describe
lated work. Section 8 concludes the paper. a larger plant. For control logic engineering, they provide an
important overview of a plant and show the connections be-
tween the different instruments besides some explicit control
2. Control Logic Generation: Basics and loops. Fig. 2 shows an exemplary P&ID for a process where
Requirements two substances are mixed, heated, and then pumped into an-
Control engineers design and implement control logic other tank. The diagram includes two large tanks (column
based on customer requirements and design specifications shapes T101, T102), a pump (large circle with inner spike),
as well as available control libraries and industrial stan- a motor (circle labeled ’M’), valves (small triangles), pipes
dards [1]. This section provides an overview of the avail- (lines), and various instruments (circles), which are typical
able customer inputs in practice, requirements, methods, and P&ID elements. The instruments describe required temper-
tools for model transformation and code generation, as well ature / flow / pressure / level sensors, controllers, and actua-
as different types of outputs, in terms of the different control tors (e.g., valves, heaters). There are different standards for
logic parts and storage formats. Fig. 1 provides a generic the shapes (e.g., ISO 10628, ANSI/ISA 5.1) and identifica-
process model for control logic generation, whose different tions in P&IDs (e.g., IEC 62424/ISO 3511, ISO 14617-6,
elements will be detailed in the following. Section 2 de- ANSI/ISA 5.1) [14].
scribes the available inputs in detail, Section 2 explains each Nowadays, engineers usually specify P&IDs with ded-
of the six transformation steps starting with “Input Valida- icated CAD tools, such as AutoCAD P&ID3 , SmartPlant
tion”, and Section 2 provides concepts and examples for out- P&ID4 , COMOS P&ID5 , or OpenPlant P&ID6 . Addition-
puts of the transformation. ally, generic drawing tools support P&ID visual shapes (e.g.,
Today, the implementation of control logic in practice from ISO 10628), such as Visio7 , Edraw8 , or Lucidchart9 .
is usually only partially making use of code generation, for Common file formats are AutoCAD DWG for generic draw-
example by importing information from I/O lists to cre- ings (binary) and the AutoCAD DXF interchange format
ate signal variables for the control code [1]. As a result, (plain text). Several tools also support exports of equipment
the implementation process still requires control engineers and instrument lists to Microsoft Excel tables. However, in
a significant amount of manual interpretation to translate today’s engineering projects P&IDs are often only available
the customer specifications into control algorithms, which as PDF exports containing bitmaps for control engineers.
makes this procedure time-consuming and error-prone. Ap- Typically, this is not a problem to date, as they are usually
proaches for control logic generation aim to increase the subject to manual interpretation.
amount of generated code, both to shorten implementation For automatic control logic generation, such an input is
time and to improve quality. This section uses a running 2 https://www.isa.org/store/ansi/isa-50601-2007-functional-
example of a simple production process to illustrate the con- requirements-documentation-for-control-software-applications/116719
cepts. It is based on the Festo MPS PA Compact Worksta- 3 https://www.autodesk.com/

tion1 , a minimal didactic plant for educational purposes [13]. 4 https://hexagonppm.com/

5 https://www.siemens.com/comos
1 https://bit.ly/2XWjmfk 6 https://www.bentley.com/
7 https://visio.microsoft.com/
8 https://www.edrawsoft.com/
9 https://www.lucidchart.com/

Koziolek et al.: Preprint submitted to Elsevier Page 2 of 26

 Classication Framework 61131 Logic Generation

Transformation
Inputs Outputs
Validation Knowledge Control
Rules Base Libraries
P&IDs IEC 61131-3
I/O Lists SFC, FBD, ST, IL, LD
Control Narratives
Logic Diagrams (1) Input (2) Pre- (3) (control loops,
(4) Merging
Flow Charts Validation Processing Translation sequences, interlocks,
Alarm Lists alarms, timeouts,
Cause&Effect Matrices diagnostics, …)
... Validation
Reports (5) Documen-
tation

Legend
Activity Control Flow
Generation
(6) Backpropagation Reports
Artifact Artifact Flow

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

LI UC NC Basic Point Data I/O Data HMI Data Operating Data

102.1 101.7 101.8
M
P-9 P-10 P-12 Point Range Range Engin. Alarm Alarm Controller
Tag Number Service Location P&ID … Type Signal Type … Min Max Unit … Low High Algorithm …
YS LS101.1 T101 Level P-12001 1234 AI 4-20 mA 0 100 % 20 80 PID ideal
103.1 TI101.2 T101 Temp. P-12001 1234 AI 4-20 mA 15 95 °C 20 85 PID std
P-3 P-8 LS101.3 T101 Level P-12001 1234 AI 4-20 mA 0 100 % 20 80 PID ideal
LAS101.4 T101 Level P-12001 1234 AI 4-20 mA 0 100 % 20 80 PID ideal
V-2 LAS+ YS101.5 Inlet T101 Valve P-12002 1234 DO 24 VDC - - - - - -
101.4 FI101.6 Flowmeter P-8 P-12001 1234 PI Pulse 0 100 m³/h - - -
P-11 UC101.7 Pump Motor P-12003 1234 DO 24 VDC - - - - - PID std
YS YS NC101.8 Pump Motor P-12003 1234 DO 24 VDC - - - - - PID std
103.2 101.5 YS101.9 Outlet T101 Valve P-12004 1234 DO 24 VDC - - - - - -
P-1 P-2 P-5 P-7 LI102.1 T102 Level P-12005 1234 AI 4-20 mA 0 100 % 10 90 PID ideal
FI LS102.2 T102 Level P-12005 1234 AI 4-20 mA 0 100 % 10 90 PID ideal
V-1 V-4
LS- LS+ 101.6 YS103.1 Inlet T102 Valve P-12006 1234 DO 24 VDC 0 100 % - - -
102.2 101.1 YS103.2 Inlet T101 Valve P-12007 1234 DO 24 VDC 0 100 % - - -
E104 Heater T101 P-12005 1234 DO 24 VDC 0 100 % - - PID std
T102
Figure 3: Running Example: IO List describing signal proper-
TI YS
101.2 101.9

LS-
P-4 P-6 ties.
E104 V-3
101.3
T101

Figure 2: Running Example: P&ID describing equipment and neering units, alarm limits, typical assignment, wiring types,
instruments. references to P&IDs, etc.). There are no industry standards
for these properties, but companies usually use guidelines or
internal standards. I/O lists are also known as tag lists, in-
however problematic. To overcome the challenge of dealing strument or signal indices. Control engineers consider them
with bitmaps or vector-graphics, there are proposals to per- as one of the most important inputs and they are usually pro-
form optical symbol and character recognition on the PDF vided in the form of large tables [1].
files [15, 16]. Additionally, the DEXPI initiative10 is work- In the context of control logic generation, I/O lists can
ing on a common XML P&ID file format based on ISO be automatically imported into control engineering tools to
1592611 . The CAEX XML file format (IEC 6242412 ) as part create tags and I/O objects that then can be connected with
of AutomationML (IEC 6271413 ), can be coupled with ad- function blocks to form the whole control logic. Control en-
ditional P&ID libraries (e.g., PandIX [17]). However, there gineers then need write glue logic (e.g., recipes, interlocks)
are hardly any commercial CAD tool P&ID exporters for among them. In addition to I/O lists, there can be electrical
CAEX [18] available so far. plans according to IEC 60617 [13].
I/O lists: Fig. 3 shows a simplified I/O list for the run- Control Narratives [1]: These prose writings describe
ning example. A complete I/O list may include thousands of the intended control algorithms in an informal way, usually
signals. Each row is dedicated to a single signal. There are in a Microsoft Word document or PDF file. They may re-
many columns specifying properties of signals (tag name, fer to tag names from the I/O list and provide steps for the
revision, service description, location, value ranges, engi- startup/shutdown of a plant or setpoints for regulatory con-
10 https://dexpi.org/
trol as well as alarm procedures. This notation is easy and
11 http://15926.org/ fast to create. It also allows the engineering contractor to ab-
12 https://webstore.iec.ch/publication/25442 stract from technical specifics of the target automation sys-
13 https://webstore.iec.ch/publication/32339 tem (e.g., available typical libraries), and thus enables con-

Koziolek et al.: Preprint submitted to Elsevier Page 3 of 26

 Classication Framework 61131 Logic Generation

Recipe UML or SysML17 -based flow chart notations are rather

1) Drain T102 2) Reaction 3) Drain T101 uncommon for engineering contractors and control engi-
neers [20, 21, 19]. Researchers have previously developed
several UML profiles for process automation (e.g., UML-
open YS101.5
and YS101.9 open YS103.1 PA [22]), but they never became formal OMG specifica-
open YS103.2
Wait 2 sec
Wait 2 sec tions18 . CODESYS UML19 and TwinCAT3 UML20 allow
switch on E104 the specification of class and state diagrams, but are meant
and NC101.8 switch on
Level = 0% Temp NC101.8 for control engineering programmers, not automation cus-
tomers. ANSI/ISA-8821 provides a standard notation for
> 70°C
switch off E104 Level = 0%
and NC101.8
Wait 2 sec close YS103.1 and
recipes in batch applications. While a mapping from UML
close YS103.2
switch off NC101.8 state diagrams to IEC 61131-3 may be possible, an addi-
close YS101.5 Wait 2 sec
tional modeling tool adds complexity to the tool chain [19].
Some engineering contractors therefore directly use SFCs to
Phase

specify sequences.
Other Inputs: Additional inputs may assist control en-
Figure 4: Running Example: Recipe as ow charts. gineers in designing and implementing control logic.
• Alarm Lists [13]: specify alarm limits and support
trol engineers to optimize the logic (e.g., by mapping the writing control logic to handle alarms.
intended logic to vendor-specific typicals). • Cause & Effect Matrices (C&Es) [23, 9]: provide a
Logic Diagrams: ISA5.2-1976 (Binary Control Logic streamlined table to interconnect signals, which en-
Diagrams for Process Operations)14 provides guidelines to ables generating interlocking control code. They can
create diagrams for binary interlock and sequencing systems be partially or fully provided from engineering con-
for startup, operation, alarm, shutdown of equipment and tractors due to safety regulations (ISO 10418).
processes. Input and output signals can be connected via
AND/OR/NOT gates, as well as symbols to express timing • Control Logic Libraries [24]: containing pre-specified
relations. This notation is already similar to the actual con- function blocks that capture higher-level domain
trol logic and therefore comparably easy to translate to it. knowledge.
Engineering contractors usually create logic diagrams with
CAD tools or generic drawing tools. The structure and for- • Legacy Control Code [25, 26]: often available in mi-
mat of the used logic blocks may vary between different or- gration (brownfield) projects. They can sometimes be
ganizations, which can complicate the control logic genera- translated into the control code of the target automa-
tion. tion system.
Flow Charts: Sequential control flow or recipes can also • Domain Specific Inputs: these include for exam-
be expressed with ordinary flow charts15 . Fig. 4 shows a flow ple System Control Diagrams (SCD) for NORSOK-
chart for the running example plant in a notation similar to compliant oil and gas facilities [18], or Scientific
UML activity diagrams. It consists of three phases. First, Apparatus Makers Association (SAMA) logic draw-
by opening valve 103.2, tank T102 is drained to transfer ings22 for power generation plants.
both substances in T101. Subsequently, the reaction starts
in phase 2. The valves 101.5 and 101.9 open. Afterwards, 2.2 Transformations
the heater E104 and the pump driven by NC101.8 start. Once Transforming the available inputs into valid control logic
the temperature reaches 70 degree Celsius, pump and heater output requires a number of steps (Fig. 1) as detailed in the
switch off and valve 101.5 closes. Finally, tank T101 is following.
drained using the pump in phase 3. Input Validation: Inputs for control logic generation re-
A specific flow chart notation is GRAFCET (“GRAphe quire consistency and completeness checks [27]. Human en-
Fonctionnel de Commande Etapes/Transitions”, IEC gineers specify these artifacts often in an incremental man-
6048416 ). It is a standardized graphical modeling language ner with multiple data exchanges between engineering con-
for designing controller behavior [19]. GRAFCET was tractor and automation provider. Therefore, the data may be
developed in France in the late 1970s, where it gained some incomplete and the different artifacts may be inconsistent.
industry adoption, and was also integrated into the cur- For example, the I/O list in Fig. 3 may be missing specified
riculum of control practitioners in Germany. IEC 61131-3 ranges or specific tag names might be inconsistent with the
Sequential Function Charts (SFC) are based on GRAFCET
17 https://sysml.org/
and are considered as one of its possible implementations. 18 https://www.omg.org/spec/category/uml-profile
14 https://goo.gl/VpfpD4 19 https://store.codesys.com/codesys-uml.html
15 https://www.iso.org/standard/11955.html 20 https://www.beckhoff.com/english.asp?twincat/tf1910.htm
16 https://webstore.iec.ch/publication/36840 21 https://www.isa.org/isa88/
22 https://automationforum.co/what-is-sama-diagram/

Koziolek et al.: Preprint submitted to Elsevier Page 4 of 26

 Classication Framework 61131 Logic Generation

P&ID. The P&ID may contain unconnected pipes or miss- formation first needs to analyze the formerly generated code
ing properties of certain instruments. Sometimes the utilized and properly merge the new additions. It also needs to pro-
CAD tools already provide consistency and completeness tect manually written code and report any inconsistencies or
checks, but in other cases input validation by the automation incompleteness back to the control engineer.
provider is required. This is crucial for control logic gener- Documentation: A control engineer needs to under-
ation, since the applied algorithms cannot reliably compen- stand the model transformation process to be able to detect
sate for invalid inputs in contrast to a human engineer. systematic errors and to speed up root cause analysis in case
Pre-processing: Some input artifacts are subject to pre- of code generation errors. To support this requirement, a
processing, usually to simplify the later translation or to sup- model transformation can, for example, create a report of the
port different output formats. This may be implemented us- code generation process, that provides a detailed list of the
ing in-place model transformations (i.e., endogenous trans- applied code generation rules as well as any warnings and
formations) or mapping to intermediate models (i.e., ex- errors that may have occurred in the process. Ideally, such a
ogenous transformations) [28]. For example, the P&ID in report allows directly accessing the erroneous input artifacts,
Fig. 2 could be enhanced with flow paths to simplify code affected rules or the code generation output to check. Be-
generation [9]. A code generation approach can also map sides creating more confidence of the control engineer, such
heterogeneous input data artifacts to a common intermedi- a documentation could also support testing and qualification
ate model so that the code generation becomes less com- processes.
plicated [13, 16]. Unstructured data, such as Control Nar- Backpropagation: Manual additions and changes to the
ratives, may require human labeling or annotations, so that generated code may need to get propagated back to the in-
text mining approaches can perform appropriate information put artifacts. This supports a shared understanding for the
retrieval. For example, a setpoint for the motor controller of engineering contractor and control engineer and also serves
the running example could be obtained from a narrative via documentation purposes (i.e., to always have an up-to-date
text mining and then later be used in code generation. design and specification). For the running example, changed
Translation: Additional exogenous transformations tag names or alarm limits may need to get translated back
translate input artifacts conforming to specific meta-models from the control code to the P&IDs or I/O lists. This require-
to output artifacts conforming to other meta-models [28]. In ment suggests that the model transformation should support
case of logic diagrams or flow charts (cf. Fig. 4) being used, some form of bidirectionality. The level of bidirectionality is
this involves an almost straightforward mapping to function naturally higher for meta-models with higher similarity (e.g.,
block diagrams or sequential function charts (Fig. 5). In flow charts and sequential function charts). In practice, such
these cases, the underlying meta-models have a high simi- a return path from the control code back to the engineering
larity. contractor is rarely seen today because of the expensive man-
Other input artifacts, such as P&IDs and control narra- ual overhead. This practice often leads to outdated and in-
tives, require specially prepared code generation rules stored consistent planning documents over the course of the plant
in a knowledge base [29]. Such rules can encode domain life-cycle.
knowledge, e.g. referring to the running example “if the To implement the described transformation steps, there
filling level of a tank (e.g., T101) is too high, then close is a plethora of method and tools for model-to-model (M2M)
a valve (e.g., via YS103.2) connected to an inlet to the and model-to-text transformations (M2T). Transformations
tank” [9]. Rules may pertain different aspects of control can be implemented with generic programming languages,
logic, such as safety interlocks, sequences, diagnostic rou- such as Java, C++, C# in case the input artifacts are avail-
tines, or optimizations. Rules may be generic, domain- able as object-oriented models. XML files may directly
specific, or project-specific. Ideally, they are formulated in be mapped to other XML files using XSLT/XQuery. The
a domain-specific language familiar with the control engi- OMG’s QVT (Query/View/Transformation) is a standard-
neers [30, 31]. ized set of languages for model transformations, including
Merging: The incremental nature of the engineering imperative (QVT-O) and declarative (QVT-R) transforma-
process, where partial input artifacts are exchanged multi- tion languages. The Eclipse ecosystem includes a num-
ple times between customers, engineering contractors, and ber of M2M-transformations (Epsilon, Eclipse MMT) and
automation providers in successively higher refinement and M2T-transformations (Acceleo, JET, Xpand, Xtext), besides
completion states, makes a one-shot translation impracti- a common metamodel (Ecore) and tools to create graphi-
cal [27, 29]. In the running example, an engineering contrac- cal editors. There are extensible IDEs for control logic code
tor may add new instrumentation to the P&ID and I/O list, available (e.g., 4DIAC23 or Hardella24 based on mbeddr25 ).
e.g., a new pressure sensor for one of the pipes, or change
specific tagnames or alarm limits. Blindly overwriting code 2.3 Outputs
from former generation iterations may be problematic in case Many commercial automation systems are still based
control engineers have already enhanced or optimized the on software development platforms mostly compliant to
code manually. Therefore, code generation has to merge new 23 https://www.eclipse.org/4diac/i
additions from these refinements into IEC 61131-3 code al- 24 https://github.com/Hardella/ide61131
ready generated in previous translations. The model trans- 25 http://mbeddr.com/

Koziolek et al.: Preprint submitted to Elsevier Page 5 of 26

recipe Classication Frameworkinterlocks
61131 Logic Generation
AND
S V104_Open_var
TON0 Step0 P101_ON_var IN1 OUT O_P101_ON
S V109_Open_var AND
TON IN2
S Start_Timer I_LS_101_3 IN1 OUT IN3 O_P101_ctrlMode
Start_Timer IN Q IN2
AND
I_FI_101_6 LE
PT ET IN1 OUT
IN1 OUT
IN2
T#3s 0.7 IN2
TON0
S P101_ON_var
Step1 TON
S E104_ON_var
O_P101_ON IN Q
GE R Start_Timer PT ET AND
T#2s
I_TI_101_2 IN1 OUT IN1 OUT
IN2 TOF0
IN2 O_YS_103_1_open
IN3 TOF AND
70
R P101_ON_var IN Q IN1 OUT O_YS_103_1_open
Step2 O_P101_ON
R E104_ON_var LE
T#2s PT ET IN2
TON1
S Start_Timer 90 IN1 OUT
TON IN2
I_LI_102_1
Start_Timer IN Q
V103_1_open_var
PT ET
T#2s AND
R V104_Open_var E104_ON_var IN1 OUT O_E104_ON
Step3
R Start_Timer IN2
I_LS_101_3
GE IN3
I_TI_101_2 IN1 OUT
Step0 120 IN2

Figure 5: Running Example: Sequential Function Chart (SFC). Figure 6: Running Example: Function Block Diagram (FBD).

I F I_TI_101_2 >= 70 THEN (* t e m p e r a t u r e > 70 d e g r e e s *)

the IEC 61131-3 specification [32] for programmable con- P_101_ON_VAR := FALSE ; (* s t o p pump * )
(* stop heat exchanger *)
trollers. This standard was originally published in 1993 E_104_ON_VAR := FALSE ;
CMD_TMR( IN := 2 . 0 ) ; (* wait f o r 2 seconds *)
and defines five programming languages: ladder diagrams END_IF ;

(LD), function block diagrams (FBD), sequential function

charts (SFC), structured text (ST) and instruction lists (IL). Figure 7: Running Example: Structured Text (ST).
IEC 61499 was published in 2005 as a partially backward-
compatible enhancement of IEC 61131-3 with event-driven
concepts, but has not gained widespread adoption in practice familiar with the IEC 61131-3 standard26 , while FBD, ST,
so far [33], although a number of academic approaches used and SFCs are more popular in other parts of the world. ILs
it. have been labeled ‘deprecated’ in the latest release of the
SFC: Fig. 5 shows an IEC 61131-3 SFC based on the IEC 61131-3 specification. The PLCopen association pub-
recipe specification for the running example in Fig. 4. It in- lished the first XML formats for IEC 61131-3 in 2005 [32],
cludes four steps, which, in the tables on right-hand side, and has by now refined the specification as IEC 61131-10
each trigger the setting (S) and resetting (R) of certain sig- PLCopen XML exchange format.
nals. The transitions between the steps (black bars) are trig- Today, control logic implementation is often based on
gered by function blocks on the left-hand side and involve instantiating template function blocks, so-called “typicals”,
simple timers and threshold conditions. This kind of control e.g., for valves, motors, from a function block library. A
logic can be generated for example by mapping flow charts code generator can largely automate this task by exploiting
to SFCs or interpreting control narratives. properties in I/O lists which often allow a one-to-one map-
FBD: Fig. 6 shows an IEC 61131-3 FBD for a number of ping of signals to typicals available in specific libraries, also
interlocks within the running example. On the left-hand side known as bulk engineering [1]. Besides the initial variables
the diagram lists input signals, which trigger specific output for signals and the instantiated function blocks, the control
signals on the right-hand side. In this example, inputs and logic code
Seite: 1 consists of a number of different segments for dif-
outputs are connected by simple boolean (AND) and arith- ferent purposes [34]. These include handling the nominal
metic (LE, less equal, GE, greater equal) function blocks as sequence (e.g., PID loops), alarms, startup/shutdown, asset
well as timers (TON/TOF). monitoring, operations, diagnosis, interlocks, controller-to-
ST: Fig. 7 shows an IEC 61131-3 ST code snippet from controller communication and timeouts. Code generation
the running example. The syntax of ST is similar to the should address as many of these segments as possible to
Pascal programming language. It supports variable assign- lower the manual implementation effort.
ments, if/case/for/while/repeat statements, as well as point- Besides the control logic generation itself, a model trans-
ers and function calls. The language also provides constructs formation tool chain for typical customer input artifacts can
to define function blocks as higher-level programming con- also be exploited for other purposes. The generation of sim-
structs. ST is often preferred for more complex mathemati- ulation models can support factory acceptance tests or plant
cal computations in control logic. modifications [35, 16]. Connections to HMIs may be gen-
Other outputs: Ladder diagrams are particularly popu- 26 https://www.controleng.com/articles/iec-61131-3-whats-the-
lar in North America, where many control engineers are not acceptance-rate-of-this-control-programming-standard/

Seite:
Koziolek et1al.: Preprint submitted to Elsevier Page 6 of 26
 Classication Framework 61131 Logic Generation

erated and also process graphics can be partially generated tooling and support. However, they are excluded
out of P&IDs [36, 37]. Intermediate models for code gener- from the following classification to not favor a par-
ation may also be used during the plant life cycle to create ticular commercial vendor or because of a lack of re-
queries about the plant and to find root causes of plant-wide liable information sources. Rivops AutoGen27 gener-
disturbances [38]. ates control logic from an equipment list using Python
scripts, and most commercial DCS products offer sim-
ilar functionality (e.g., Simatic PCS7, Yokogawa Au-
3. Classification Framework tomation Design Suite). DEIF PLC Link28 provides
3.1 Methodology special modeling means for wind power applications
The objective of the present study is to classify research and can produce PLCopen code. Actifsource Work-
approaches for IEC 61131-3 code generation from the view- bench29 and 4DIAC30 are examples for IDEs that can
point of a practicing control engineer. A detailed breakdown generate control code, but are also considered out of
of each method’s inputs and outputs helps to better under- scope for this paper.
stand the context the researchers assumed and the method’s
capabilities. The classification supports identifying patterns • Published after 2004: Included are papers less than
between the approaches and to assess their maturity levels. 15 years old to keep the classification concise, so that
We identified corresponding approaches using Google approaches from the 1990ths are neglected. We as-
Scholar, IEEE Digital Library, and ACM Library using the sume that the conceptual contributions of these early
search term “61131 AND control AND code AND (gener- approaches have influenced the design of the more re-
ation OR transformation OR automatic OR automated OR cent approaches classified within this paper.
model-driven)” [39]. The search initially identified 5350 We applied a forward/backward reference search [53]
works. From the search results, we applied the following in- on the identified approaches to increase literature cover-
clusion criteria to focus on our research objective and view- age. We combined multiple papers from the same authors
point: if they referred to the same approach (e.g., [13, 29, 54] or
• IEC 61131-3 control code: Included approaches use [55, 56, 19, 57, 58]. Some of the excluded works will be
at least one of the five IEC 61131-3 languages as out- discussed in Section 7.
put to cover a large range of commercial and open
source control systems. Excluded are approaches 3.2 Approaches Overview
for example involving IEC 61499 [40, 41, 42, 43], Our survey contains 13 approaches from 2005-2018
C-code, Simulink, or other PLC programming lan- (Fig. 8) within the inclusion criteria. In total they have been
guages, because they are either less widespread in referenced by other works 679 times. All approaches origi-
practice or tackle different application domains. nate from European researchers (only Lukman et al. [5] has a
co-author from the US). This corresponds to the observation
• Code Generation: Included approaches provide con- from Section 2 that IEC 61131-3 is more popular in Europe.
cepts and possible implementations aiming at actual The approaches can be coarsely divided into three
code generation. Excluded are approaches that ap- classes:
ply model transformation on automation requirements
1. Rule-based Generation based on Plant Structure:
for other purposes (e.g., simulation [35, 16], test case
These approaches [M1,M2,M3] require control en-
generation [44], asset management [45], loop per-
gineers to create a knowledge base of rules that are
formance assessment [38], HAZOP analysis [46]).
later automatically applied to formalized requirements
While additional transformation targets are helpful to
and design documents to generate IEC 61131-3 code.
improve engineering, we limit the study to details of
The main benefits are the high degree of automation
code generation as we aim at a deeper understanding
and the seamless integration into existing engineering
of that process.
workflows and tools. Drawbacks are the difficulty to
• Uses Inputs typically used in Practice: Included construct robust, generic rule bases (i.e., applicable
approaches rely on at least one of the inputs listed for many projects) and the need for formalized input
in Section 2, e.g., I/O lists, P&IDs, flow charts. artifacts so that the rules can be automatically applied.
This excludes approaches requiring for example Petri These approaches correlate with the application do-
Nets [47, 48, 49, 50] or timed automata [51] as input, main process automation.
which are not used in practice today. 2. Higher-level Programming: These ap-
proaches [M4,M5,M6,M7,M8,M9,M10] require
• Journal/Conference publication: Included are peer-
27 http://www.rivops.com/autogen
reviewed approaches published in a Journal or confer- 28 https://www.deif.de/wind-power/technology/plc-link-code-
ence proceedings. Approaches embedded into a com- generation
mercial offering may be highly relevant for practition- 29 http://www.actifsource.com/

ers (e.g., Simulink PLC Coder, CODESYS UML [52], 30 https://www.eclipse.org/4diac/

TwinCAT3 UML), since they include commercial

Koziolek et al.: Preprint submitted to Elsevier Page 7 of 26

 Classication Framework 61131 Logic Generation
Rule-based CAEX Transformer
Higher-level Programming Higher-level
Engineering based on Interlock
using Plant Structure Programming CAEX LogIX Model CAEX+ C&E IEC61131-3
Plant Structure Generator
P&ID Enhancer LogIX Matrix Generator
(Rule Base)
2005 [M4]
UML PA Translator Vienna Code Generator
2006 [M1] CAEX
Translator CAEX, Reference Inference 61131
Interontology IEC 61131-3
2007 [M5] Recipe Ontology Engine Ontology
Mapping Code Generator
icsML (Rule Base)
2008

2009 ACPLT Rule Engine

[M6] Neo4J Graph-query FBD ctrl
2010 CAEX CAEX
PLC- DB based Rule logic ACPLT Runtime
[M11] [M12] StateCharts Importers
2011 Engine
[M2] SysML4IEC61131 AUKOTON
2012 Vienna Code
2013
Generator [M7] Figure 9: Rule-based generation: high-level overview. The
2014
[M3]
ACPLT Rule [M8]
MAGICS
approaches extract information from plant topology models
2015 Engineering GRACET
Translator
[M9]
SysML AT and apply rule engines to generate control logic.
Transformer
2016

2017
UML PA Translator
2018 [M13] [M10] UML class/activity/
Munich Code Generator MeiA Framework Artisan Real- state diagrams IEC 61131-3 SFC
2019
Time Studio + UML PA profile Transformator

Figure 8: Map of Approaches (2005-2018): Arrows indicate icsML

citations. The approaches can be divided in three classes de- XML Files for XML Stylesheet

pending on whether they use a plant structure as input and

XML Editor SW/HW resources mapping to
PLCOpen XML
whether they use domain rules for code generation. PLC-Statecharts
UML class / state
diagrams IEC 61131-3
CODESYS UML
+ UML AP profile Mapper

control engineers themselves to formalize require- MAGICS

ProcGraph Entity
ments and design in a higher-level modeling language ProcGraph IDE
Diagrams / State IEC 61131

(UML/SysML/GRAFCET) and then establish a

Transtition Diagrams Code Generator

mapping between the elements of the higher-level GRAFCET-Translator

language and IEC 61131-3 constructs. Early Petri GRAFCET

/ Visio
GRAFCET2PNML PNML
file
GRAFCET PNML
file
PNML2PLCopen
Transformator Normalization Transformator
Net-based approaches would also be in this class.
The main benefit is that the control engineers may SysML-AT Transformer
M2T
be more productive using a high-level notation than SysML Editor
SysML-AT Diagrams
Transformation

directly IEC 61131-3. Drawbacks are the limited (MOF2M2T)

amount of automation and the challenge to learn and MeiA Framework

MeiA model, Use case

maintain two different notations. These approaches MeiA Tool

model, GEMMA
model, AML IML
PLCopen
Converter
mainly originate from discrete manufacturing.
3. Higher-level Programming using Plant Structure: Figure 10: Higher-level programming: high-level overview.
These hybrid approaches [M11,M12,M13] both take The approaches require an upfront modeling in UML/SysML
the plant structure into account and require con- or similar notations, which are directly mapped to control logic.
trol engineers to formalize additional requirements in
higher-level languages, such as UML or SysML. They
do not use rule-based generation. While these ap- knowledge base, an inference engine generates instances of
proaches may provide a richer starting point by utiliz- an IEC 61131 ontology containing for example interlocking
ing the plant structure, they inherit the same benefits or diagnostic logic. A code generator processes this ontol-
and drawbacks from the other higher-level program- ogy and produces 61131-3 code.
ming approaches. [M3] ACPLT Rule Engine: An importer converts a CAEX
plant structure XML file into a graph structure for the
Fig. 9 provides a high-level overview of the rule-based
Neo4J31 graph database. Using Cypher32 queries on the
generation approaches:
graph database allows to identify certain patterns in the plant
[M1] CAEX Transformer: This approach takes a P&ID
structure and directly generating FBD control logic or dis-
encoded as a CAEX XML as input and first enhances the
covering flow paths. In this approach, the Cypher queries
file with the LogIX Model to group related equipment into
encode both domain specific rules and code generation tem-
lines. Afterwards it applies a set of interlocking rules on the
plates.
resulting model and generates a C&E matrix, which can be
Fig. 10 shows the higher-level programming approaches,
reviewed and enhanced by control engineers. From the re-
which usually do not import any specifications, but require
sulting C&E matrix, a generator directly creates IEC 61131-
manual modeling:
3 ST or FBD code.
[M4] UML PA Translator: A control engineer uses Artisan
[M2] Vienna Code Generator: The authors suggest to map
various requirements and design documents into a reference 31 https://neo4j.com/
32 https://neo4j.com/developer/cypher-query-language/
ontology based on CAEX. Using pre-defined rules from a

Koziolek et al.: Preprint submitted to Elsevier Page 8 of 26

 Classication Framework 61131 Logic Generation

Real-Time Studio to model units of manufacturing equip- SysML4IEC61131

Enterprise
ment (e.g., a sorting facility) as UML classes, possibly en- CAEX
P&ID
CAEX2SysML
Transformator
SysML
PCE Req Architect SysML SysML2IEC61131
Transfomer
hanced by using the UML-PA profile for process automation. (+ manual work)

Each method of a class is further specified via a UML state

AUKOTON
Aukoton UML AP Tool Aukoton
CAEX,
diagram. The approach proposes a mapping of these models
CAEX/XML Model Model PLCOpen
XLS (Eclipse-based)
Importers (Ecore) (Ecore) Generator
(+manual work)
to IEC 61131 function blocks.
[M5] icsML: This approach requires engineers to create
Munich Code Generator

P&ID Plant Process Module ISA-88 M2T

XML files modeling hardware and software resources, there
Object
image Hierarchy Recognition Modules
Recognition Transformation
(+manual work)
is no CASE-tool support foreseen. Using XML stylesheets,
the files are mapped into PLCopen XML and then into Figure 11: Hybrid approaches: high-level overview. These ap-
controller-specific languages. proaches extract information from plant topology models into
[M6] PLC-Statecharts: This more formal approach is fo- higher-level programming models, let the engineers complete
cused on providing adequate PLC semantics for UML state- the models, and then generate control logic.
charts. Eventually, the approach was implemented for the
CODESYS framework, where a UML class diagram and
state diagram editor are provided. The approach aims at a bi- [M12] AUKOTON: The AUKOTON tooling takes P&IDs,
directional mapping of the UML constructs and IEC 61131- IO lists and C&E matrices as input and maps them into
3 code, so that ideally, the contol engineer does not have to domain-specific AUKOTON models implemented using
deal with 61131-3 code at all. Ecore34 . Afterwards, control engineers can refine the
[M7] MAGICS: Instead of using UML, the authors of models further, before a PLCOpen Generator processes
this approach defined their own domain-specific modeling them to produce IEC 61131-3 control logic.
language called ProcGraph. It includes entity diagrams [M13] Munich Code Generator: This approach performs
and state transition diagrams and features an IEC 61131 an object recognition on P&IDs images. It tries to derive
code generator. The whole approach is accompanied by an the plant hierachy from this operation and map certain
Eclipse-based modeling tool that allow graphical editing of patterns in the P&IDs to pre-specified ISA-88 compliant
the models. plant modules. A model-to-text transformation finally
[M8] GRAFCET-Translator: This approach starts from produces IEC 61131 code for these modules.
a GRACET (IEC 60484) specification of processes mod- After briefly introducing each approach, the following
eled using Microsoft Visio and a specific stencil set. A will define detailed classification criteria to be able to com-
transformer coverts the Visio file into a Petri Net XML file pare the approaches better.
(PNML), which is then normalized to certain restricted con-
structs and finally mapped into PLCopen XML using 28 3.3 Classification Criteria
transformation rules. Fig. 12 shows our classification criteria for the IEC
[M9] SysML-AT Transformer: The authors define the 61131-3 code generation approaches. These criteria are de-
SysML-AT notation to extend SysML requirements and fined based on artifacts in practice (Section 2), an assumed
parametric diagrams. The control engineer models a system comprehensive transformation process (Fig. 1), and discus-
using this notation and can trigger a model-to-text transfor- sions with domain experts for processes in oil and gas, chem-
mation to get IEC 61131-3 ST. ical, and power generation applications. The input classifi-
[M10] MeiA Framework: This Eclipse-based framework cation was inspired by Steinegger and Zoitl [13], while the
provides multiple domain-specific modeling languages for output classification was inspired by Guttel et al. [34]. The
signals and phases, for use cases, and other constructs. following subsections will briefly explain each criterion.
While the framework supports different types of analyses, it
can also translate instances of the model into PLCopen XML 3.2.1 General Properties
encoding IEC 61131-3 SFCs. The General Properties cover high-level information to
Finally, Fig. 11 shows three hybrid approaches that understand the context and maturity of each approach. The
take the plant structure into account and introduce a form Publication Venue states in which journal or conference the
of higher-level programming. None of these approaches authors published the main approach, where journal pub-
however uses rule-based engineering: lications may indicate a higher maturity. The Application
[M11] SysML4IEC61131: The authors propose a Domain distinguishes between discrete manufacturing and
CAEX2SysML Transformator to import IEC 62424- process automation, because different inputs and constraints
compliant P&IDs into the UML/SysML modeling tool may be available in a given domain. A short description of
Enterprise Architect33 . To reduce the gap between CAEX each approach’s main Application Example helps the reader
and SysML, the authors propose the SysML4IEC61131 to better understand an approach’s original context and the
profile. The resulting SysML requirement diagrams are maturity of each approach.
semi-automatically refined with SysML block definition The Generation Approach summarizes the main trans-
diagrams and can be transformed into PLCopenXML. lation idea. The Tooling summary lists accompanying soft-
34 https://www.eclipse.org/modeling/emf/
33 https://www.sparxsystems.de/

Koziolek et al.: Preprint submitted to Elsevier Page 9 of 26

 Classication Framework 61131 Logic Generation

Control Logic Generation Methods

General Properties Inputs Transformation Outputs

Publication Venue I/O Signals Input Validation Creation of Variables
Application Domain FB Libraries Pre-processing Parametrization of Typicals
Application Example FB Parameters Intermediate Model Sequential Logic
Target Projects Sequences Translation Safety Functions and
Generation Approach
Plant Structure Merging Interlocking Logic
Tooling
Boolean Logic Documentation Diagnostic Logic
Validation
Legacy code Backpropagation Other Logic
Domain Rules

Figure 12: Classication criteria for automated control logic generation approaches: inputs available in practice, transformation
steps, types of output

ware tools including external libraries and framework. Fi- its, setpoints, or tuning parameters. If available, the code
nally, the Validation categorizes how the authors evaluated generation can directly copy them into the control logic.
their approach. This may potentially span from minimal ex- Typicals in control engineering libraries can potential have
amples executed by the authors themselves as a proof-of- more than 100 input and output parameters, although many
concept up to multiple, heterogeneous real-world case stud- of these are often kept on default values. If not directly avail-
ies carried out in independent studies to demonstrate actual able, a code generator could potentially synthesize FB pa-
cost and benefits. Ideally, the authors should characterize rameters using domain rules.
how much manual work an approach saved or how large the Sequences cover any kind of steps describing the con-
fraction of generated code was in the analyzed cases. trol flow. These may for example refer to recipes in batch
application or startup/shutdown or emergency procedures.
3.2.2 Inputs When provided by a customer or engineering contractor, se-
The second dimension of our classification framework quences may be specified for example in control narrative,
are the inputs. These can be considered as the requirements flow charts, or logic diagrams. Boolean Logic may directly
for the control code. As there is no industry standard, we describe state-based control or interlocks. Specifications
used different sources for the input classification. Section 2 may be available as logic diagrams, tables, control narra-
has surveyed the available input artifacts in practice. Häst- tives, or C&E Matrices.
backa et al. [59] consider P&IDs and spreadlists (I/O lists, Approaches may consider formal specifications of the
C&E lists) as inputs. Steinegger and Zoitl [13] provided a Plant Structure to generate control logic based on the en-
list of different artifacts potentially involved in code genera- coded relationships between equipment and instruments.
tion, which included P&IDs, recipes, electrical plans, alarm This may support generation of sequencing logic, interlock-
lists, and logic diagrams. We also analyzed ABB-internal ing logic, or diagnostic functions. Approaches could poten-
guidelines for inputs from customers. tially exploit the topological structure for synthesizing start-
Our classification abstracts from particular artifacts and up sequences if the material and information flow can be
rather distinguishes the approaches based the content in extracted unambiguously. Notations for plant structures in-
these artifacts. This avoids overlaps (e.g., I/O signal refer- clude P&ID, SCD, PFD, and building plans and with differ-
ences both in I/O lists and P&IDs) as well as multiple kinds ent levels of formalization (e.g., bitmap, vector-based draw-
of artifacts for similar content (e.g., P&ID, SCD, PFD mod- ing, object-oriented model with formal semantics).
eling the plant structure). Depending on the particular ap- Legacy code may be available as input for a code gen-
plication domain, an approach may be able to generate more erator. According to ARC [60], only 35 percent of yearly
code if it takes more inputs into account. distributed control system projects revenues are for new
The first kind of input are I/O signals, which may be constructions (greenfield), while the remaining 65 percent
specified in I/O lists, P&IDs, control narratives or other ar- are for replacements, upgrades, or expansions (brownfield).
tifacts. They later form input and output signal references Even in greenfield projects, code from similar plants or fac-
in the IEC 61131-3 control code. Function Block (FB) Li- tories may be available, which could be partially reused. In
braries with a list of typicals may be used to directly include brownfield projects, also legacy control logic code, poten-
higher-level domain concepts into the generated IEC 61131- tially in a proprietary programming language may be avail-
3 code, which may potentially ease code generation signifi- able. If an approach is able to deal with existing code, it can
cantly. Using type attributes for I/O signals from an I/O list, potentially also better support iterative development with
matching typicals can directly be instantiated by the code multiple generations corresponding to the incremental avail-
generation, e.g., function blocks for motors or valves. ability of customer artifacts. In case of replacements, this
FB Parameters may be available for example from de- may involve translation of legacy control code [61], while in
tailed I/O lists or control narratives, for example alarm lim- case of upgrades, this may involve merging new code into

Koziolek et al.: Preprint submitted to Elsevier Page 10 of 26

 Classication Framework 61131 Logic Generation

existing code [29]. Segment of Estimated Estimated

Control fraction of total implemen-tation
Finally, Domain Rules may allow a code generator to Logic Description control code effort
synthesize control logic. These rules may encode interlock- Nominal 1) Instantiation of Typicals 30% 60%
Sequence 2) Parametrization of Typicals
ing concepts, naming conventions, safety standards, PID pa- 3) Interconnection of Typicals
rameters, or other concepts. They form a knowledge base, 4) Definition of sequence control
Interlocks Protection functions combining two or 20% 10%
which is potentially applicable across different projects and more types of equipment
essentially turn the code generator into an expert system for
control logic engineering. Tags / I/O References to signals, IO objects 15% 1%
objects

3.2.3 Transformation Alarms Hardware alarms for range violations, 10% 1%

process alarms for process range
The third dimension of the classification pertains the violations
Transformation process. The selected criteria map to Start-Up Initialization Sequences, may require 5% 7%
the generic transformation process sketched in Section 2, operator interaction

which is based on a general description of engineering pro- Shutdown Shutdown sequences, also emergency 5% 7%
cesses [1] as well as discussions with several domain experts. shutdowns

Input Validation assesses whether an approach checks Diagnosis For example Profibus DP Slave Device 5% 5%
for completeness, validity, and consistency within and Diagnostics, EtherCAT Diagnostics, etc.

among the different input artifacts. This is more relevant if Commu- Peer to peer communication between 5% 5%
an approach integrates multiple artifacts with possibly over- nication controllers.

lapping contents. Pre-processing ranges from manual inter- Restart / Manual reset, or reset after energy 2% 2%
pretation and formalization of inputs to intermediate model Reset failure, safe stop
transformations that translate the inputs into other formats Asset Detect abnormal behavior, react upon 2% 1%
for rule application and/or simplified code generation. Monitoring error signals or proactively search
Most approaches employ an intermediate model that is
Time-out Monitor whether time limits are 1% 1%
either manually specified or automatically created. The ac- exceeded
tual translation converts this intermediate model to IEC
Operation Automated population of OPC Servers n/a n/a
61131-3 code (e.g., M2T transformation), for example by and for HMI stations
performing a direct mapping of concepts (e.g., in case of Monitoring
SUM 100% 100%
logic diagrams) or by applying domains rules. In most prac-
tical cases, generated code would be subject to merging with Table 1
existing code, which must avoid overwriting manually spec- Breakdown of dierent control logic segments: estimated frac-
ified code and creating duplicates. tion of source code and eorts.
Providing an appropriate documentation of the transfor-
mation process (e.g., with indication of applied rules or is-
control code may be low. Especially interconnecting typicals
sues in the input artifacts) is essential for practical adoption
and definition of sequence control requires efforts for inter-
and acceptance by control engineers. Finally, propagation of
preting different inputs and designing an appropriate control
manual changes or additions to the control logic back to the
strategy. Interlocks represent a significant portion of the con-
inputs is an important feature to keep the plant specification
trol logic, but are comparably easy to implement, since they
up to date [62, 58].
may either be already fully specified by customers due to
3.2.4 Outputs safety regulations or require the manual application of sim-
Our classification framework considers the Outputs of ple domain rules. Other types of control logic may make up
the code generation both in terms of the format (i.e., which only smaller parts of the overall code.
IEC 61131-3 language) and the contents (i.e., what parts of We included the creation of variables / instantiation of
control logic. Guttel et al. [34] provided a detailed break- typicals as first criteria into our classification framework.
down of the different aspects of PLC functions, categorizing Each approach supports this in some sense as it is required
more than 20 different functions. We deemed this catego- for IEC 61131-3 code. The parameterization of typicals
rization too detailed for our classification scheme, and thus is another criterion normally requiring the use of a FB li-
selected a number of functions and let multiple domain ex- brary. In our classification, it also includes alarms. We com-
perts from our company rank their estimated implementation bined different kinds of sequential logic into a single crite-
effort. Table 1 shows the consolidated result. While the re- rion, which comprises start-up, shutdown, as well as recipes
sults are difficult to generalize and may vary a lot between (called “Definition of sequence control” in Guttel et al. [34]).
different projects, the numbers at least give notion of higher Safety functions and interlocking logic sum up all kinds
importance, which is sufficient for the creation of a classifi- of boolean logic, such as emergency procedures and re-
cation scheme. sets. Diagnostic logic may gather data about the system
Table 1 shows that the nominal sequence requires the and field devices and may inform a human operator. Fi-
most efforts implementation wise, although the amount of nally, we summed up all other types of logic from Tab. 1
in Other Logic. For each of these classification criteria,

Koziolek et al.: Preprint submitted to Elsevier Page 11 of 26

 Classication Framework 61131 Logic Generation

we identified whether it was explicitly supported by the ap- has been applied by a number of developers in 15 simple,
proach and which IEC 61131-3 language was used. It should experimental projects (approx. 50 I/O signals), but the doc-
be noted that using IEC 61131-3 code generation, each ap- umented validation results are difficult to interpret.
proach could potentially support each type of output, but the Researchers have tested rule-based generation ap-
output classification helps to better understand on which par- proaches only using small rule bases that cover minimal as-
ticular content an approach focused. pects, but are insufficient for practical application. Large
rule bases may lead to inconsistencies, overlaps, and scal-
ability issues. Larger experiments, pilot projects, and ap-
4. Comparison of Approaches
plications to entire projects would be needed to facilitate
Using the classification from Figure 12, the following technology transfer. The code generation as such is seldom
compares the approaches. Each subsection deals with one of measured or precisely characterized. Only the MAGICS ap-
the four parts of the classification and uses a table to provide proach [5] states that 80 KByte of executable control logic
an overview to what extent the approaches meet the criteria. had been generated from higher-level constructs, which was
68 percent of the overall code.
4.1 Comparison of General Properties
Tab. 2 lists the approaches’ general properties. The pub- 4.2 Comparison of Inputs
lication venues are mainly journals and conferences on soft- The surveyed approaches based their code generation on
ware/system engineering as well as automation and manu- a range of different inputs (Tab. 3).
facturing. The approaches take information to define I/O signals
Since IEC 61131-3 logic is not specific for any appli- and control variables either from natural language specifi-
cation, each approach is applicable in any application do- cations or use structured customer inputs, such as P&IDs.
main. However, most of the surveyed approaches originate Higher-level programming approaches require the control
either from a discrete manufacturing setting or a process au- engineer to model the required signal references, for ex-
tomation setting, which leads to different inputs, constraints, ample using class diagrams. Rule-based engineering ap-
and assumptions. An indicator is the main application exam- proaches as well as hybrid approaches instead derive the
ple of each approach. These are predominantly small-scale signal references from CAEX representations of P&IDs di-
lab automation systems or didactic plants. MAGICS [M7] agrams. Only the AUKOTON [M12] explicitly imports
and Vienna Code Generator [M2] use application examples Excel-based I/O lists which are often available in practice.
based on sub-segments of real-world plants. SysML4IEC61131 [M11] uses a combination of transform-
The generation approaches are either based on match- ing a CAEX-based P&ID to SysML and then manually
ing domain-specific rules on specifications provided as in- adding requirements to the model.
puts, or mapping a higher-level notation into IEC 61131- Function block libraries are another important ingre-
3. For the latter, several approaches employ a model-to-text dient for code generation. The SysML4IEC61131 ap-
transformation. The Munich Code Generator [M13] aims proach [M11] intends to integrate different kinds of unspec-
at a generation by a mapping to pre-specified modules, al- ified FB libraries. AUKOTON [M12] uses a self-defined
though it also foresees manually specifying the control logic DCS library, and the Vienna Code Generator [M2] cre-
for modules that are not yet provided in a library. ated two libraries with one and two function blocks respec-
The tooling is tightly connected to the generation ap- tively, specifically for diagnostics. The Munich Code Gen-
proach. Several approaches use UML modeling tools and erator [M13] relies on a library of pre-defined process mod-
extend them with prototypical enhancements. AUKO- ules according to ISA-88, but details remain to be specified
TON [M12], MAGICS [M7], and MeiA [M10] make ex- in a given project. Other approaches do not deal with func-
tensive use of the Eclipse modeling framework and pro- tion block libraries, although integration should be fairly
vide Ecore models besides graphical editors and model-to- easy. The used libraries may determine on what abstraction
text transformations. Only CODESYS UML from PLC- level the control engineer and the code generation can work.
Statecharts [M16] is available as a commercial offering by Highly aggregated function blocks as in [M13] may reduce
the company 3S. All other tools remain in a proof-of-concept the required manual work significantly, since it only requires
maturity and are not openly available for independent test- to connect a few large blocks, instead of creating a detailed
ing. low level specification. However, function block libraries
For validation, most authors apply their own approach on are often domain-specific or even project-specific.
a single example. This provides an initial proof-of-concept Function block parameters may pertain configuration pa-
validation, but does not qualify an approach for practical use. rameters, alarm ranges, set points, and other values, which
Whether practitioners could repeat a published approach could be derived from information provided by the customer
independently or whether the approach runs into scalabil- or also based on experience in similar projects. Most ap-
ity, maintenance, or robustness issues remains unclear. For proaches seem to neglect that these parameters could be de-
PLC-statecharts [63] and SysML-AT Transformer [64], the rived from customer specifications or using domain rules. In
researchers carried out experiments with around 30 students AUKOTON [M12], ranges and setpoints can be taken from
each and showed that a higher-level programming language the I/O list, while the Vienna code generator provides a con-
can lead to higher productivity. The MeiA approach [65]

Koziolek et al.: Preprint submitted to Elsevier Page 12 of 26

 Classication Framework 61131 Logic Generation
Approach Venue Application Domain Application Example Generation Approach Tooling Validation
[M1] IEEE Conf. on Computer Process Automation Generic plant unit (1 tank, Matching rules from a Tool prototype processing Authors applied own
(CAEX Transformer) Aided Control Systems (example for chemical) 1 motor, 3 valves) knowledge base CAEX files approach, single sample
Design case

[M2] IEEE Int. Conf. On Emerging Process Automation SMS Simag AG Hot Rolling Translation of ISA-88 Unnamed tool prototype Authors applied own
(Vienna Code Generator) Technologies and Factory (examples for hot rolling Mill , FESTO Compact recipes, generation based (logi.CAD, Apache Jena, approach, two industry-
Automation mill, chemical) Workstation didactic plant on safety rules Protege, JAXB) derived case studies
(2 tanks, 4 valves, 1 pump)
[M3] IEEE International Process Automation Minimal plant (1 pump, 1 Matching rules (defined as Unnamed tool prototype Authors applied own
(ACPLT Rule Engineering) Conference on Industrial (example for chemical) valve) graph database queries) based on Neo4J, Cypher approach, single sample
Informatics case

[M4] IEEE Int. Conf. on Control Discrete Manufacturing / Lab prototype for a sorting Mapping UML to IEC 61131- Tool prototype using Authors applied own
(UML PA Translator) and Automation Process Automation facility 3 Artisan Realtime Studio approach, single sample
case, discussed with
industry experts
[M5] Springer Journal on Discrete Automation No specific application Translation of a self- XML schemas and Authors sketched mapping
(icsML) Advanced Manufacturing example, only generic XML defined XML-schema to stylesheets provided to two commercial IEC
Technology templates 61131-3 61131-3 runtimes

[M6] Elsevier IFAC Proceedings Discrete Manufacturing Lab example involving error Translation of UML CODESYS UML Student experiment with
(PLC-Statecharts) handling routine for a statecharts to IEC 61131-3 30 participants, informal
pneumatic cylinder ST reasoning

[M7] Elsevier Journal of Control Process Automation Grinding Titanium Dioxide Translation of an extended ProcGraph Eclipse tooling Authors applied own
(MAGICS) Engineering Practice in Slovenia (50 devices, 400 finite state machine + ST, (EMF / GMF / oAW / approach, single industry-
signals) manually derived from Mitsubishi GX IEC derived case study (68% of
P&ID Developer, CODESYS) code generated)
[M8] Elsevier Journal of Control Discrete Manufacturing / Plant for checking 28 transformation rules GRAFCET Editor & Authors applied own
(GRAFCET-Translator) Engineering Practice Process Automation electromech. parts from GRACET to 61131-3 Translator approach, single industry-
(conveyor belt, rotary derived case study
table,100 signals)
[M9] Elsevier Journal on Discrete Manufacturing Laboratory Pick & Place Model-to-text Unnamed tool prototype Student experiment with
(SysML-AT Transformer) Mechatronics Unit (stamp, crane, stack, transformation using for SysML-AT 36 participants, hypotheses
sorter) MOFM2T testing

[M10] IEEE Transactions on Discrete Manufacturing SMC FMS-200 training PLCopen converter Eclipse-based MeiA tooling Developers applied the
(MeiA Framework) Automation Science and Mechatronic Station framework (M2T approach in 15 projects
Engineering (Conveyor + Actuators) transformation) with about 50 I/O signals
each
[M11] SciRes Journal on Software Discrete Manufacturing / FESTO Modular Production Translation of SysML block SysML4IEC61131 Profile, No implementation, only
(SysML4IEC61131) Engineering and Process Automation System diagrams to 61131-3 via SysML2IEC61131 conceptual approach
Applications SysML Profile Translator, MARTE Profile described
(not implemented)
[M12] Elsevier Journal of Systems Process Automation Lab example for a water Translation of P&IDs, IO UML AP Tool (Eclipse, Authors applied own
(AUKOTON) and Software (example for chemical) treatment plant segment Lists, C&E matrices into an Topcased, SmartQVT), approach, single sample
intermediate UML model, includes importers for CAEX case, discussed with
IEC61131 FBD and IO lists industry experts
[M13] IEEE International Systems Process Automation myJoghurt lab-scale CPPS P&ID image recognition, C++ prototype using SQLite, Authors applied own
(Munich Code Generator) Engineering Symposium demonstrator (pump, module identification and RI-CAD, CODESYS, TIA- approach, single sample
filling, heating, mixing matching from library, then Portal case
units) M2T transformation
Legend: n Rule-based Engineering approaches, n Higher-level Programming approaches, n Higher-level Programming using Plant Structure

Table 2
General Comparison: most approaches originate either from discrete manufacturing or pro-
cess automation. There are diverse generation approaches, validations are often performed
using simple examples.

cept to retrieve parameters using electrical plans. Higher- conforming to ISA-88, while the MAGICS approach [M7]
level programming approaches require the user to set these provides self-defined state transition diagrams and state de-
parameters in UML classes that are later mapped to function pendency diagrams that the control engineer models.
blocks. The GRACET translator [M8] is centered around the
Multiple approaches use notations based on UML state- GRAFCET notation (IEC 604848) for specifying sequences.
charts to model sequences due to the similarities with IEC The approach provides formal semantics for GRAFCET en-
61131-3 SFCs. The UML PA Translator [M4] uses UML closing steps, forcing orders and time constraints, and is thus
state charts enhanced with the UML PA profile and maps able to utilize the full GRAFCET notation in code gener-
them with included variables to SFCs. icsML [M5] pro- ation. A number of student experiments [66] suggest that
vides an XML schema for software resources that can ex- UML-based modeling can be more productive than directly
press sequences. PLC-statecharts [M6] enhance UML stat- writing IEC 61131-3 code, if well integrated into an IEC
echarts with user-defined priorities for transitions. Due to 61131-3 development environment with round-trip func-
IEC 61131-3’s cyclic nature, these statecharts cannot be trig- tionality. Challenges for adopting such approaches in indus-
gered by events, and the approach introduces behavioral se- try are developer training, work processes, and integration
mantics as in polling real-time systems. The Vienna code with legacy code. Approaches processing P&IDs often do
generator [M2] may use recipes being available in a notation not deal with sequential specifications explicitly, but instead

Koziolek et al.: Preprint submitted to Elsevier Page 13 of 26

 Classication Framework 61131 Logic Generation
Approach I/O Signals FB Libraries FB Parameters Sequences Boolean Logic Plant Structure Legacy code Domain Rules
[M1] Instruments from n/a n/a n/a n/a P&ID in CAEX (IEC n/a Interlocking rules
(CAEX Transformer) CAEX (IEC 62424) 62424) + self-defined (XML)
logistics model called
LogIX

[M2] Instruments from 61131-3 lib for Instruments from Recipes (ISA-88)* Logic Diagrams (ISA- P&ID in CAEX (IEC PLCopen (XML) Interlocking +
(Vienna Code Generator) CAEX, elec. plans (EN Profibus DP / CAEX, elec. plans (EN S5.2), C&E Diagrams 62424) + PandIX / IEC exported from diagnotic rules
60617) + IEC 81346 EtherCAT Diagnostics 60617) + IEC 81346 (ISO 10418) 62424 based Ecore Rockwell RSLogix (SPARQL)
Model 5000

[M3] P&ID in CAEX (IEC n/a n/a n/a n/a P&ID in CAEX (IEC n/a Interlocking rules
(ACPLT Rule Engineering) 62424) + PandIX 62424) + PandIX (Cypher)

[M4] Attributes in Class n/a n/a Activity Diagrams, n/a n/a n/a n/a
(UML PA Translator) Diagrams State Charts

[M5] XML schema for n/a n/a XML schema for XML schema for n/a (XML schema for n/a n/a
(icsML) software resources software resources software 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] Signal List (manually n/a Signal List (manually ProcGraph State Safety Requirements P&ID diagram n/a n/a
(MAGICS) processed) included) Transition Diagrams, (manually processed)
Functional
Specification

[M8] Variables in Grafcet n/a n/a Grafcet (IEC 60848), Grafcet (IEC 60848), n/a n/a n/a
(GRAFCET-Translator) (IEC 60848) Control Interpreted Control Interpreted
Petri Net Petri Net

[M9] SysML Parametric n/a SysML Parametric SysML Parametric n/a n/a n/a n/a
(SysML-AT Transformer) Diagram + SysML AT Diagram + SysML AT Diagram + SysML AT
Profile Profile Profile

[M10] Part of MeiA model n/a Part of MeiA model Design Organization Design Organization n/a n/a n/a
(MeiA Framework) Units (DOU) derived Units (DOU) derived
from MeiA model from MeiA model

[M11] Instruments from Undefined standard / SysML Requirement n/a SysML Requirement P&ID in CAEX format n/a n/a
(SysML4IEC61131) CAEX (IEC 62424), domain-/ project- Diagram Diagrams for (IEC62424)
SysML Requirement specific libraries interlocks / safety
Diagram (PLCopenXML) and security
requirements
[M12] I/O List (Excel) AUKOTON DCS I/O List (Excel) n/a C&E Matrix (Excel) P&ID in CAEX format n/a n/a
(AUKOTON) Library (IEC62424)

[M13] Instruments Self-defined Process n/a From module n/a P&ID as SVG file n/a n/a
(Munich Code Generator) recognized from Module library with references
P&ID ISA-88 compliant recognized in P&ID
modules

Legend: n Rule-based Engineering approaches, n Higher-level Programming approaches, n Higher-level Programming using Plant Structure

Table 3
Comparison of the Inputs of each approach: most approaches support only specic inputs,
some of them require manual modeling of customer requirements.

focus on logic directly derived from the P&ID. are available to transform C&E matrices directly into IEC
Boolean logic may be used for interlocks, emergency 61131-3 control logic [M1].
shutdowns, but also model sequences. While logic diagrams Approaches in process automation usually take
are often available in practice as requirements, only the Vi- the plant structure or topology into account as a
enna Code Generator [M2] discusses processing them, but P&ID [M1,M2,M3,M11,M12,M13]. The CAEX Trans-
provides no implementation. AUKOTON [M12] can im- former [M1] uses the connections between equipment an
port C&E matrices that express interlocks as a special kind instruments in P&IDs to apply rules to generate interlocking
of boolean logic and turn them into control logic. Tools logic. The SysML4IEC61131 approach [M11] extracts

Koziolek et al.: Preprint submitted to Elsevier Page 14 of 26

 Classication Framework 61131 Logic Generation

process control engineering (PCE) requests, control func- SysML. In other approaches, which are mostly from pro-
tions, and loops from P&IDs and maps them to SysML cess automation, the control engineer may already work with
requirements diagrams. AUKOTON [M12] follows a semi-formal or formalized requirements and derive a design
similar approach and maps PCE requests in P&IDs to UML and implementation.
class diagrams stereotyped as Automation Requirements. Regarding completeness of input artifacts, the Vienna
The Vienna Code Generator [M2] uses CAEX and PandIX code generator [M2] provides the most holistic view, ad-
as inputs and extracts PCE requests, signal connections dressing all of the input elements of our classification. How-
needed for interlocks, and PCE control functions to group ever, the approach does not provide tooling to process these
multiple signals. Schüller and Epple [17] showed prototyp- inputs automatically, but instead assumes that an appropriate
ically how PandIX P&IDs could be extracted from a native CAEX model is already available from these artifacts.
XML-export of COMOS P&ID.
MAGICS [M7] in turn requires the control engineer to 4.3 Comparison of Transformations
manually interpret the P&ID and formulate the contents in None of the surveyed approaches explicitly deals with in-
the ProcGraph notation. The Munich Code Generator im- put validations, except icsML [M5] which executes syntax
ports P&IDs as SVG35 files to perform image recognition in checks on the used XML models. Several approaches as-
order to identify modules that can be mapped to higher-level sume a valid, i.e., consistent and syntactically correct CAEX
function blocks. files as input. Other approaches require a formalization of
Higher-level programming approaches often originate unstructured inputs by the control engineer, which then im-
from discrete manufacturing scenarios without an explicitly plicitly includes an input validation performed during man-
modeled plant structure. They foresee modeling structures ual interpretation. Syntax, semantic, and plausibility checks
using UML class diagrams. In this context, Grüner et al. on individual artifacts could be tackled by the CAD tools
[67] proposed so-called product flow diagrams (PFDs) as a creating them. Consistency checks between different arti-
notation analog to P&IDs but for discrete manufacturing sce- facts may be facilitated by mapping them into a common
narios. representation, e.g., a database, graph, ontology, or CAEX
Except for the Vienna code generator [M2], none of file, so that the mapping logic could also ensure consistency.
the approaches takes existing, potentially proprietary legacy The surveyed approaches show a wide range of pre-
control code into account for the code generation. This could processings and intermediate models. Several approaches
feed a direct translation into low-level IEC 61131-3 control require a manual modeling of requirements and designs in
logic [26], but could also require mapping existing higher- UML [M4,M6,M12], SysML [M9,M11], or other propri-
level function block libraries. There are numerous com- etary notations, such as icsML [M5], ProcGraph [M7], and
mercial offerings to migrate control logic between control MeiA [M10]. UML/SysML models are augmented using
systems of different vendors (e.g., migrations to Emerson profiles, such as UML PA [8], SysML4IEC61131 [68], UML
Delta V36 , to Siemens SIMATIC PCS737 , to ABB 800xA38 ). AP [59], and SysML AT [64].
Legacy code could also be available as IEC 61131-3 in a mi- UML PA [M4] adds time constraints on an architec-
gration project, then the goal of code generation would be to tural level, timed state charts, as well as ports, capsules,
seamlessly integrate with the existing code. [M2] considers protocols, and roles from the UML-RT profile. Further-
this case explicitly, as it adds interlocking logic to already more, it uses special object diagrams to express mappings
existing PLC code and uses an interlock redundancy elimi- between hardware and software. SysML4IEC61131 [M11]
nation mechanism based on the Z3 theorem prover. follows a slightly different approach and is closely mod-
Three approaches use Domain rules in order to generate elled after IEC 61131-3 concepts, such as Controller,
interlocking or diagnostic logic ( [M1,M2,M3]). Other ar- PLC, Application, POU, Program, Task, and Physical I/O.
eas for applying domain rules (e.g., generating alarms, star- AUKOTON [M12] consists of four subprofiles for require-
tup/shutdown sequences, recipes, etc.) may be more compli- ments (e.g., instrumentation requirements), automation con-
cated and remain unexplored. The CAEX Translator [M1] cepts (e.g., control loop, PID algorithm), devices and re-
directly encodes these rules in XML [45], while the Vienna sources (e.g., EDDL, FDT), and distribution and concur-
code generator [M2] uses SPARQL queries, and the ACPLT rency (e.g., distributed components and concurrency mech-
Rule Engineering [M3] executes Cypher queries on Neo4J anisms). SysML-AT [M9] adds function block instances,
graph databases. Krausser et al. [30] proposed to use di- classifiers, flows, and restrictions to SysML to allow an eas-
rectly IEC 61131-3 to formulate such rules, so that control ier mapping to IEC 61131-3 ST. None of these profiles has
engineers can work with a familiar notation. been applied outside of the respective authors’ own work so
In summary, UML/SysML-based approaches put much far.
of the requirements formalization workload on the control icsML [M5] uses XML to describe hardware, software,
engineer, who models requirements and design in UML or and relationships among them. The ProcGraph [M3] do-
35 https://www.w3.org/TR/SVG2/
main specific language proposes entity diagrams, state tran-
36 https://bit.ly/2U6HxSx sition diagrams, and state dependency diagrams to specify
37 https://sie.ag/2VAZNoE structural and behavioral information and ultimately an easy
38 https://bit.ly/2UPzWvY mapping to IEC 61131-3 FBD and ST. The MeiA frame-

Koziolek et al.: Preprint submitted to Elsevier Page 15 of 26

 Classication Framework 61131 Logic Generation
Approach Input Validation Pre-processing Intermediate Model Translation Merging Documentation Backpropagation
[M1] n/a (assumes valid CAEX Augmentation with flow CAEX (IEC 62424) Applying XML n/a n/a n/a
(CAEX Transformer) files as input) path using LOGIX model enhanced with LOGIX interlocking rules to
line model generate a C&E Matrix,
then FBD/ST
[M2] n/a (assumes valid CAEX Mapping inputs to CAEX (IEC 62424) + Applying rules from a Importer for existing n/a n/a
(Vienna Code Generator) and other files as input) reference ontology PandIX model knowledge base to control logic code to
(based on CAEX) create FBD (SPARQL reference ontology
queries)
[M3] n/a (assumes valid CAEX Translation of CAEX into Self-defined graph Applying rules encoded n/a n/a n/a
(ACPLT Rule Engineering) files as input) Graph (neo4J) notation as Cypher graph queries
to generate FBD

[M4] n/a Manual modelling of UML for Process Direct translation of n/a n/a n/a
(UML PA Translator) UML class diagrams and Automation profile (UML state charts to SFC
state charts PA)

[M5] Applying rules on XML Manual modeling of icsML including XML stylesheet to map n/a n/a n/a
(icsML) models (syntax checks) hardware, software in hardware, software, and to PLCopen XML, then
XML relationsships ISaGRAF and Simatic

[M6] n/a Manual modelling of UPPAAL timed automata Direct translation of n/a n/a Bidirectional mapping
(PLC-Statecharts) UML class diagrams and state charts to ST between FB and UML
state charts class diagrams

[M7] n/a (manual re-modeling Creation of ProcGraph ProcGraph DSML (Entity Mapping to ProcGraph n/a n/a n/a
(MAGICS) of input artifacts) model, writing of ST Diag., State Trans. Diag., elements to FBD,
statements State Depend. Diag.) copying ST statements

[M8] n/a Transform Visio to GRAFCET in PNML Applying 28 n/a n/a Multiple concepts for
(GRAFCET-Translator) PNML, normalize PNML (ISO/IEC15909-2) transformation rules round-trip engineering
file from GRAFCET to SFC discussed

[M9] n/a (assumes valid Manual modeling of SysML Parametric MOFM2T / OCL n/a n/a (generated code to n/a
(SysML-AT Transformer) SysML Requirements SysML Parametric Diagram + SysML-AT transformation into ST be reviewed by
diagrams) Diagrams profile developer)

[M10] n/a Manual modeling of MeiA model IML to PLCOpen XML n/a n/a n/a
(MeiA Framework) MeiA model (signal/phases), Use Generation for SFCs
Case Model, GEMMA
model, AML IML
[M11] n/a (assumes valid CAEX CAEX2SysML SysML requirements SysML2IEC61131 Model n/a n/a n/a
(SysML4IEC61131) files as input) transformation, add diagram + proposed Transformer
requirements SysML4IEC61131 profile

[M12] n/a (inputs are not Manually adding UML AP profile Direct mapping of UML n/a n/a n/a
(AUKOTON) validated before requirements for (Requirements, Aut. AP to FBD, use of
automated import) feedback control Concepts, Devices, platform-specific profiles
Distribution)
[M13] n/a Object recognition on Tree-based Mapping to Process n/a n/a n/a
(Munich Code Generator) P&ID, connection representation of plant Module library, M2T to
analysis, module hierarchy (C++/SQLite) PLCopen
recognition
Legend: n Rule-based Engineering approaches, n Higher-level Programming approaches, n Higher-level Programming using Plant Structure

Table 4
Comparison of Model Transformations: all approaches use an intermediate representation
before generating code. Support for merging, documentation, and backpropagation is
limited.

work [M10] uses four different models: MeiA_MM (e.g., from P&IDs.
phases, steps, signals), UseCase_MM (e.g., actor, use case, The GRAFCET Translator [M8] requires the control en-
NonFuncReq), GEMMA_MM (e.g., state, line, operation), gineer to model sequences in GRAFCET using a self-defined
and Design_MM (i.e., the intermediate modeling layer of shape library for Microsoft Visio. The GRAFCET Transla-
AutomationML, which includes GRAFCET and SFC ele- tor can then convert the Visio XML format into the Petri Net
ments). Markup Language (PNML), which includes a normalization
Approaches operating on a plant structure often use of the model. Besides code generation, the PLC-Statecharts
the CAEX format as a common syntactical container and approach [M8] provides a mapping to UPPAAL timed au-
add additional information, such as the LogIX logistics tomata to enable model checking.
model [M1] to identify equipment between two junction Although all approaches produce IEC 61131-3 code,
points, or the PandIX model for PCE requests [M2,M3]. their intermediate processings vary a lot. This is caused
[M11] sketches a CAEX2SysML transformation and a by different inputs but also by different focuses regarding
manual addition of requirements by the control engineer. the code generation (e.g., interlocks, state-based behavior).
The ACPLT Rule Engineering [M3] proposes converting Augmenting standardized notations, such as UML or CAEX,
CAEX-based P&IDs into a Neo4J graph notation, so that for intermediate models can utilize the abstractions devel-
a graph query language can be used to process the model oped and accepted by a standardization body in a formal pro-
during translation. The Munich code generator [M13] uses cess, which can foster tool support and developer training.
a tree-based model to express the plant hierarchy extracted There is also potential to combine or link different notations

Koziolek et al.: Preprint submitted to Elsevier Page 16 of 26

 Classication Framework 61131 Logic Generation

into a comprehensive approach, e.g., plant structures and be- geneous inputs and different generation approaches, there is
havioral notations, as for example shown in AutomationML. no consensus on this element of code generation. Mecha-
Ontological notations may lend themselves to a reuse of ex- nisms to map information on parameter values to domain-
isting inference engines to support code generation. or project-specific typicals could improve code generation.
In most approaches, the actual translation of the inter- Most of the approaches express sequential logic for
mediate model to IEC 61131-3 constructs is rather straight- recipes and start-up sequences as SFCs or ST. A few of them
forward. Function blocks expressed in UML are mapped use FBDs, but no approach generates LL or IL. As data for-
to IEC 61131-3 function blocks, states in state charts are mat, most approaches use PLCOpenXML TC6, which some
mapped to steps in SFCs. The GRAFCET Translator [M8] of them map to vendor-specific formats. For example, ic-
applies 28 transformation rules to map GRAFCET to SFCs. sML [M5] creates an ISaGRAF XML representation and a
There are also M2T transformations to ST [M6,M7,M10]. Siemens STEP7 representation from PLCopenXML. MAG-
Other approaches use a rule engine to apply domain-specific ICS [M7] generates code for Mitsubishi PLCs. The Vienna
rules on the intermediate models and generate the code out code generator [M2] creates RSLogix5000 code for Rock-
of these rules [M1,M2]. The ACPLT Rule Engineering ap- well controllers.
proach applies the Cypher graph query language to apply The approaches express safety functions and interlock-
such rules [M3]. ing logic mostly as FBDs, some also use SFCs and ST. The
Merging generated code into existing code is only con- CAEX transformer [M1] first produces a C&E matrix for
sidered by the Vienna Code Generator [M2]. Dealing with interlocking logic, which can be manually adapted and ex-
generated and hand-written code in parallel is not discussed tended. The final matrix can then be converted into either
by any of the approaches. None of the approaches lays spe- FBD or ST for an ABB controller.
cial emphasis on documenting the code generation process, Most of the other functions of control logic [34] are
so that the control engineer receives useful feedback on how not explicitly considered by the approaches. The Vienna
the inputs were processed. An implicit assumption is that the code generator produces FBDs for diagnostic logic, and
control engineer inspects the generated code and continues the SysML4IEC61131 approach considers timing proper-
working with it. ties. The SysML-AT transformer [M9] considers control
Backpropagation is also rarely considered by the ap- logic for controller-to-controller communication.
proaches, although PLC-Statecharts [M6] assumes a bidi-
rectional mapping between UML and FBDs, so that the con- 4.5 Comparison Summary
trol engineer can ideally only work on the level of UML The previous subsections have shown that the identified
diagrams. The authors of the GRAFCET-Translator [58] approaches cannot be directly compared in terms of effi-
discuss concepts for bidirectional transformations between ciency, quality, or expressiveness, because they require dif-
GRAFCET and SFCs. However, backpropagating, for ex- ferent kinds of inputs, apply different kinds of transforma-
ample, tag names changes or parameter updates into the re- tions, and generate different kinds of outputs. Also their
quirements specifications is not considered so far. tooling is often not or no longer available for independent
replication studies or benchmarking. Nevertheless, the sur-
4.4 Comparison of Outputs vey allowed a categorization into 1) rule-based engineering
Tab. 5 summarizes the outputs produced by the surveyed approaches, 2) higher-level programming approaches, and
approaches. Several approaches create signal references by 3) higher-level programming approaches using a plant struc-
a direct mapping from UML class diagrams, or derived from ture. The next section will interpret and analyze the survey
P&IDs. Only AUKOTON [M12] imports an I/O list for sig- findings further.
nal creation. The Vienna Code generator [M2] instantiates
diagnostic typicals into FBDs from a library. The Munich
Code Generator [M13] instantiates typicals for process mod- 5. Discussion
ules from a library. There are no common standard libraries This section discusses multiple observations and ana-
used by the approaches for code generation. Some vendors lyzes of the surveyed approaches.
may consider their function block libraries as differentiator
and competitive advantage. Domain- or project-specific typ- Heterogeneous Research Scopes Although all surveyed
icals are discussed [M3,M11], but not demonstrated in any approaches produce IEC 61131-3 code, their individual
of the surveyed code generations. goals and scopes are diverging. Selecting an approach for
A few proposals discuss the parametrization of typi- a particular project mainly depends on the available inputs
cals. SysML4IEC61131 [M11] intends to incorporate tim- and the expected outputs.
ing constrains using the UML MARTE profile, but remains Rule-based generation approaches try to limit manual
vague on details. AUKOTON [M12] parameterizes instan- coding efforts, by letting control engineers encode simple
tiated function blocks with ranges, alarm limits, and engi- engineering tasks into a rule base. The aim is not to cre-
neering units taken from an I/O list. The Vienna code gen- ate a higher-level programming interface, but rather to avoid
erator [M2] takes parameters for diagnostic functions from manual coding as much as possible by automating simple,
hardware configuration files into account. Due to the hetero- repetitive tasks. The approaches demonstrated rule-based

Koziolek et al.: Preprint submitted to Elsevier Page 17 of 26

 Classication Framework 61131 Logic Generation
Parametrization of Sequential Logic Safety Functions and Other Logic
Creation of Variables / Typicals (incl. set points, (incl. recipes, start-Up, Interlocking Logic Diagnostic Logic (e.g., asset monitoring,
Signal References + alarm limits, PID shutdown, ...) (incl. reset, emergency (e.g., process/system controller
Approach Instantiation of Typicals parameters) stop, etc.) diagnosis, field devices) communication, etc.)
[M1] n/a (implicitly extracted n/a n/a Cause&Effect Matrix n/a n/a
(CAEX Transformer) from CAEX) converted to 61131-3 ST,
FBD (ABB)
[M2] Yes, from self-defined Yes, some parameters IEC 61131-3 SFC IEC 61131-3 FBD IEC 61131-3 FBD n/a
(Vienna Code Generator) Profibus + Ethercat from hardware config (PLCopen XML) (PLCopen XML) (PLCopen XML)
Diagnotics FB Lib file
[M3] Yes, via Cypher query. Yes, queries refer to IEC 61131-3 FBD n/a n/a n/a
(ACPLT Rule Engineering) function block types.

[M4] Yes, from UML class Possible from UML class IEC 61131-3 SFC, ST n/a n/a n/a
(UML PA Translator) diagram diagram

[M5] Yes, from XML file. n/a IEC 61131-3 ST n/a n/a n/a
(icsML) (PLCOpenXML)

[M6] Yes, from UML class Possible from UML class IEC 61131-3 ST n/a n/a n/a
(PLC-Statecharts) diagram diagram (CoDeSys)

[M7] n/a ( interpretation of n/a IEC 61131-3 SFC, ST IEC 61131-3 SFC, ST n/a n/a
(MAGICS) P&ID, creation of (PLCopen XML) (PLCopen XML)
ProcGraph model)
[M8] n/a (implicitly extracted Possible using time IEC 61131-3 SFC, ST IEC 61131-3 SFC, ST n/a n/a
(GRAFCET-Translator) from GRAFCET) constraints (PLCopen XML) (PLCopen XML)

[M9] Yes, generation of FB n/a IEC 61131-3 ST n/a n/a Controller to Controller
(SysML-AT Transformer) based on SysML model Communication

[M10] Yes, signal references n/a IEC 61131-3 SFC n/a n/a n/a
(MeiA Framework) manually created in (PLCopen XML)
Meia model
[M11] n/a (possible via SysML Via OMG MARTE profile IEC 61131-3 SFC, FBD IEC 61131-3 FBD n/a Timing properties via
(SysML4IEC61131) Stereotypes) (PLCopen XML) (PLCopen XML) OMG MARTE profile

[M12] Yes, by mapping IO list to Parameters taken from n/a IEC 61131-3 FBD n/a n/a
(AUKOTON) AUKOTON DCS Library IO List (PLCopen XML)

[M13] Yes, instantiating n/a IEC 61131-3 ST n/a n/a n/a

(Munich Code Generator) predefined process (PLCopenXML)
modules
Legend: n Rule-based Engineering approaches, n Higher-level Programming approaches, n Higher-level Programming using Plant Structure

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.

engineering only on simple examples, scalability and robust- combined. To some extent, this is demonstrated by the hy-
ness remains unexplored. Expert systems based on rules are brid approaches that take a plant structure into account to
known to become brittle if facing unfamiliar settings [69], generate a UML/SysML-based structure model, which then
so a more thorough investigation is needed to better assess can be manually enhanced in a modeling tool.
the usefulness of rule-based engineering. The scope of the academic research was focused on the
Approaches based on higher-level programming lan- three different classes of approaches shown in the survey.
guages, such as UML or SysML intend to make manual In practice, there are additional methods for lowering con-
coding more productive, in terms of understandability and trol engineering efforts, which are hardly investigated by the
quality by utilizing object-oriented concepts and raising the surveyed approaches:
abstraction level. They include automated code generation
as a translation to a lower-level notation, but rather treat it • Copying Code: Often, individual engineers simply
as a side-effect while the focus is on providing an adequate copy and adapt code from former projects to speed up
higher-level notation. Accordingly, the evaluations of such programming. Methods could be developed to recom-
approaches focus on programming efficiency and user sat- mend similar former source code or to support cre-
isfaction and do not differentiate between manually written ating reusable engineering libraries based on analyz-
and generated code. They implicitly assume that all code ing engineering artifacts of similar projects, which re-
can be expressed in the higher-level notation and that a bidi- quires extensive domain knowledge.
rectional mapping to the lower-level IEC 61131-3 notation
• Engineering Libraries: Engineers create engineer-
is possible.
ing libraries encoding higher-level functionality in
Although the classes of surveyed approaches have dif-
reusable function blocks. This works well in appli-
ferent goals, they do not exclude each other and could be
cation domains with limited customized functionality,

Koziolek et al.: Preprint submitted to Elsevier Page 18 of 26

 Classication Framework 61131 Logic Generation

e.g, steel making or aluminium smelting, but is harder easily overwrite files with generated code in a re-engineering
for other domains, such as chemical plants, that often scenario without affecting manually written code. There are
exhibit an amount of specialized functionality. different methods for joining generated and non-generated
code, including interfaces, design patterns (e.g., factory,
• Modular Automation: As a more coarse-grained ap- strategy, bridge), and template methods, which are spe-
proach to control logic reuse, engineers segment a pro- cific for object-oriented programming languages. For IEC
duction process into smaller package units, which in- 61131-3 code generated and non-generated code may for ex-
dependent subcontractors build together with an in- ample be arranged in different diagrams. During manual
cluded automation. The engineering configuration IEC 61131-3 coding, the control engineer needs to take care
of these package units follows the NAMUR Mod- not to contradict the generated control logic.
ule Type Packages (MTP) [70]. Besides standard- Versioning and file comparison tools are another means
ized hardware connectors, each unit provides a mod- for merging generated and manually written code during it-
ule type package that serves as module description and erative code generation. This often works almost automated
input to system-wide engineering tools. An orches- in case of additive actions, but may require manual inter-
trating, supervising control system can then provide vention in case of changes to existing code. None of the
high-level commands to each unit (e.g., start, stop) and surveyed approaches discusses these possibilities though.
use the modules to execute specific recipes.
Input Data Validation Validation of customer inputs is
The Munich code generator included in this survey [71] often a time-consuming problem in practice, which may re-
is potentially applicable for Modular Automation, since it quire multiple feedback cycles between engineering contrac-
works with higher-level ISA-88 based module descriptions tor and automation vendor. Most of the surveyed approaches
similar to NAMUR MTP. However, the challenges for auto- do not deal with this issue beyond syntactical XML checks
matic code generation change significantly in case of mod- or assuming that a prior mapping to AutomationML/CAEX
ular engineering. Because the modules are too small to be produced well-formed inputs.
concise, they usually do not include a large amount of IEC In practice, there are different methods to address this
61131-3 logic. Thus, the benefit of code generation for each issue. Engineering contractors can use a common database,
module provider is rather limited. Module providers can such as SmartPlant Instrumentation39 , to assure consistency
rather exploit economies of scale if they produce their firmly of instrument indices. Additionally, they can utilize ad-
defined modules in large quantities, each time reusing the vanced CAD tools that allow validations of diagrams. But
same control logic. this approach is challenged if multiple subcontractors are in-
Based on the survey findings, it seems unlikely that there volved in the engineering [74]. There are also engineering
ever will be an all-accompanying approach for automatic platforms, such as COMOS40 , EPlan41 , or EBase42 , which
code generation in industrial automation. The different ap- may support automation vendors in consistency and com-
proaches may work well in specific domains, but not in oth- pleteness checks. Nevertheless, more research into cross-
ers, depending on how standardized the processes are. Com- tool data consistency and completeness checks may be valu-
bining approaches that exploit plant topology models, ex- able.
ecute code generation rules, and rely on higher-level pro-
gramming to some extent is possible and should be investi- Dealing with Natural Language Requirements Another
gated in future research. Rule-based engineering can reduce finding of the survey is that none of the approaches is able
the amount of trivial, repetitive implementation tasks, while to process informal customer requirements. As Section 2
higher-level programming can reduce efforts for implement- showed, part of the customer requirements are often for-
ing required custom control logic. mulated using informal language in user requirement doc-
uments or control narratives. Additionally, P&IDs or logic
Iterative Code Generation As user requirements usually diagrams may contain annotations in prose writing, which
become available in several iterations, code generation can- may provide important information for control logic engi-
not assume a one-shot translation of the inputs. The survey neering.
has shown that many approaches work with the assumption Requiring customers and engineering contractors to fully
of a one-shot translation and thus may be misaligned with use formal requirements specifications may be unrealistic.
practice. Some approaches assume that the generated IEC However, there is a large body of literature on text min-
61131-3 code may not be altered manually [8], others allow a ing [75] and information retrieval [76], which have been ap-
bidirectional mapping between UML/SysML notations and plied on informal requirements in other application domains.
IEC 61131-3 [63]. The Vienna code generator [54] first im- Gelhausen and Tichy [77] propose to annotate require-
ports and analyzes existing control logic before adding gen- ment documents using a purpose-built language, so that they
erated code in an informed manner. can be transformed into UML diagrams. Deeptimahanti and
Best practices for model-driven software develop-
39 https://hexagonppm.com/
ment [72, 73] suggest to separate generated and non- 40 https://www.siemens.com/comos
generated code, for example in different files, so that an iter- 41 https://www.eplan.de/
ative development is supported. A code generator can then 42 https://www.aucotec.com/

Koziolek et al.: Preprint submitted to Elsevier Page 19 of 26

 Classication Framework 61131 Logic Generation

Babar [78] propose a tool to generate UML models from nat- erty if specifications are exchanged in object-oriented and
ural language requirements by identifying classes and stereo- standardized notations. They fear that production processes
types. The tool implements a set of syntactic reconstruc- may be more likely replicated by competitors if the files are
tion rules to process complex requirements into simple re- easier to distribute and process. These concerns need to be
quirements. Le et al. [79] present a system for synthesizing addressed in a manner that does not complicate automated
smartphone automation scripts from domain-specific nat- code generation, e.g., filtering or obfuscating certain IP sen-
ural language descriptions. System components and their sitive specifications or enforcing confidentiality using pro-
partial dataflow relations are inferred from the natural lan- cesses.
guage description using a specialized parser. Tichy et al. Another factor is the high heterogeneity of application
[80] presents nlrpBENCH, a benchmark consisting of over domains, engineering workflows, and information models.
50 requirements documents to train model extraction and The CAEX standard (IEC 62464) acknowledged this fact
text correction approaches. Chalkidis et al. [81] describe and explicitly and separated syntactic standardization (in XML)
experimentally compare several contract element extraction from semantic standardization (using role class libraries).
methods that use manually written rules and linear classifiers This allows to syntactically treat engineering artifacts in a
(logistic regression, support vector machines) with hand- uniform way, even if the semantics are understood only par-
crafted features, word embeddings, and part-of-speech tag tially. Drath and Barth [74] developed additional concepts
embeddings. concepts reqarding tool interoperability and data ownership
Most of these approaches still work on rather simple re- on top of CAEX. Such concepts have so far been applied only
quirements texts that are sometimes heavily constrained or in company-internal settings (e.g., Daimler [82], ABB [83])
annotated to allow processing. If texts are constrained into for the exchange of engineering data, but not across different
semi-formal language, the customer benefit of creating such organizations [84].
requirements fast and with limited special expertise may be Nevertheless, numerous customer organizations, such as
invalidated. If pre-annotation of the text requires too much NAMUR, OPAF, DEXPI are pushing for more standards and
effort, control engineers would likely fall back to manual in- their adoption, which may prove beneficial for automated
terpretation, which in addition may be more robust. Practi- code generation approaches directly processing customer ar-
cal problems, such as local languages, ambiguities in the re- tifacts.
quirements, and non-standard terminology may complicate
natural language processing approaches further. However, Cost/Benefits of Code Generation The survey did not
the limits for text mining in this context are still not well un- find any cost/benefit studies for automated code generation
derstood. in industrial automation. Return on investment for IEC
61131-3 code generation is not yet well validated and re-
Standardized File Formats Both the rule-based ap- mains vague. Setting up a tool chain for code generation may
proaches and higher-level programming approaches using be costly and require a series of multiple similar projects to
the plant structure in this survey rely on standardized input actually pay off. Control engineers need to create importers
file formats. However, in practice, the file formats are often for their engineering tools, set up knowledge bases, and elicit
not yet readily available. As described in Section 2, many domain rules. They may need to train developers in modi-
artifacts from customers are still exchanged on paper or as fied UML/SysML versions. Whether the code generation is
unstructured PDF-files that complicate automated process- robust and reliable in a realistic project is not well investi-
ing [16]. This has multiple reasons as detailed in the follow- gated.
ing. While several experiments [66, 85] have demonstrated
In some cases (e.g., for P&ID diagrams) there is a lack that control engineers can be more productive using a UML-
of standardized formats so far, or a lack of adoption of exist- based notation, it remains unclear if this benefit outweighs
ing formats from the software vendors. Smart P&IDs with the drawback of introducing an additional UML tool. Con-
an database underlying the drawing capturing properties of trol engineers may be bound to the engineering tools their
instruments and equipment are still uncommon, the Auto- employer provides for a commercial system, which may
CAD DWG format is often used for convenience, since it is make it hard to introduce additional external tools.
also used for many other types of drawings and is supported It is unclear how much code can be generated, and
by many general purpose drawing tools. The DEXPI ini- how much code is better created manually. For example,
tiative is working on an ISO15926-based exchange format complex multicascading logic involving sophisticated algo-
for P&IDs. AutomationML (IEC 62714) is gaining more rithms may require human expertise for the foreseeable fu-
support, but remains far from broad industry adoption [18]. ture and might be difficult to generate automatically. An
There is no agreed format for I/O lists, but companies often elaborated code generation approach may make the appli-
work with specific guidelines. GRAFCET is a standardized cation implementation intransparent for control engineers,
notation, but suffered from a missing agreed file format and who might lose confidence in the generation if it proves un-
tooling, and it is known only in specific regions [55]. reliable.
Furthermore, some automation customers or engineer- Benefits regarding higher code quality or saved time in
ing contractors are concerned about losing intellectual prop- relation to the overall engineering time lack hard evidence.

Koziolek et al.: Preprint submitted to Elsevier Page 20 of 26

 Classication Framework 61131 Logic Generation

Case studies need to be carried out with industry to better dealing with IEC 61499 control logic. The paper does not
characterize cost and benefits of code generation considering deal with ruled-based code generation approaches and de-
different application domains and their constraints. scribes its included approaches on a higher abstraction level.
The survey by Yang et al. [10] is also broader and less
detailed than our survey, reviewing MATLAB Simulink,
6. Threats to Validity SCADE, OpenRTM, and IEC 61499 engineering concepts
The comparison of code generation methods in this pa- and tools. Vogel-Heuser et al. [12] describe general chal-
per aimed to analyze the prerequisites and capabilities of the lenges and research directions for software development for
all relevant published methods. The following threats to va- automated production systems. They point out that round-
lidity of this survey have been explicitly considered and ad- trip engineering, tool integration, tool usability, and edu-
dressed: cation are major challenges for model-driven engineering
in industrial automation. They also list a number of UM-
• Non-Representative Selection of Approaches: Sec- L/SysML related approaches, however without classifying
tion 3 has documented the used search facilities, them.
search terms, and inclusion criteria of this paper. Lukman et al. [5] provided a short state-of-the-art analy-
Excluding approaches generating IEC 61499 control sis of process control engineering approaches, without in-
logic as well as other programming languages is a cluding rule-based approaches. They also included IEC
threat to the representativeness of the survey, but was 61499 approaches as well as approaches not generating clas-
decided for conciseness and practicality [33]. sical control logic. They attributed the limited industry
• Irrelevant Classification Criteria: The classifica- adoption of these approaches to a “lack of automatic PLC
tion criteria depicted in Fig. 12 are derived from the code generation, lack of development process definition and
inputs required in practice, the necessary transforma- guidelines, and non-existent or immature tools support, be-
tion steps for a working code generation, and the typ- sides the use of device-centric abstractions”. Liebel et al.
ical outputs of such approaches. We used external [11] assessed the state-of-practice regarding model-driven
references [13, 34] to make these criteria representa- engineering for embedded systems, but did not specifically
tive, more relevant, and reduce subjective author bias. deal with IEC 61131 control logic.
We also contacted domain experts and reviewed nu-
Related but Excluded Approaches Several related ap-
merous customer requirements specifications to get a
proaches have been excluded for different reasons. FU-
deeper understanding of the inputs available in prac-
JABA [86] is an integrated tool environment, where Siemens
tice.
PLC code can be generated from SDL block diagrams, UML
• Incorrect Analysis of Approaches: We were not able class diagrams, and UML behavior diagrams. This approach
to test the approaches by executing their tooling on has been developed more than 15 years ago. The FAVA
self-defined cases. For almost all of the approaches, approach [87] translates SysML requirements diagrams and
the tooling was not readily available for reproduction. manually specified models to Continuous Function Charts
Thus, the analysis of the approaches is purely based that can be loaded into many PLCs.
on literature review. Researchers have proposed several IEC 61499 ap-
proaches involving code generation, but none of them were
• Author Bias: The authors of this survey are affiliated developed into a robust tooling. Hussain and Frey [40] gen-
with an automation company that provides commer- erate IEC 61499 FB networks and test cases out of UML
cial products for industrial automation. This may lead use case, component, sequence, activity, and state diagrams.
to a bias towards the contexts and perspectives of the Panjaitan and Frey [41] map UML and component dia-
authors. However, none of the surveyed approaches grams to IEC 61499 FB networks. Thramboulidis and Buda
is currently used by the authors’ company, therefore [42], Thramboulidis [43] propose the 3+1 SysML model
assuring a level of objectivity. to generate IEC 61499 code. Wenger et al. [88] propose a
converter to transform IEC 61131-3 control logic into IEC
61499 logic to be able to utilize its additional features. Dai
7. Related Work
and Vyatkin [89] discuss migrating distributed IEC 61131-3
Related Surveys Although there is no classification and PLC code to IEC 61499 function blocks and illustrate three
comparison of IEC 61131-3 control logic generation in lit- different migration methods on a conveyor belt system.
erature, there are several publications providing overviews Yang et al. [90] propose a method to transform IEC
of different model-driven approaches and code generators 61850 system configuration language (SCL) specifications
for industrial automation applications. Vyatkin’s state-of- into logical connections in an IEC 61499 substation automa-
the-art review of software engineering in industrial automa- tion control application. This involves creating an ontol-
tion [7] summarizes several approaches for model-driven en- ogy from the specifications in the Web Ontology Language
gineering according to the OMG standards MDA, UML, and (OWL), which is then transformed into logical connections
MOF. This coarsely maps to the higher-level programming of IEC 61499 function blocks using the enhanced Semantic
approaches from our survey, but also includes approaches

Koziolek et al.: Preprint submitted to Elsevier Page 21 of 26

 Classication Framework 61131 Logic Generation

Web Rule Language (eSWRL). Voinov et al. [91] created an for rule-based engineering, processing natural language re-
automatic HMI generator for this method. Furthermore, the quirements, and supporting iterative engineering processes
authors extended the approach to use restricted natural lan- with input validation, bi-directional transformations, and
guage (RNL) using Boilerplate models as input [92]. While code merging. Combinations of rule-based engineering ap-
this overall method was demonstrated for smart grid sys- proaches and higher-level programming approaches should
tems, the mechanisms behind it could be transferred to other be investigated.
domains as well. Upon a maturation of the surveyed approaches, a bench-
Furthermore, several older code generation approaches mark for automatic IEC 61131-3 code generation should be
use formal modeling notations, such as Petri nets or timed developed to better compare their capabilities and give out
automata. Cutts and Rattigan [47] propose a PLC code gen- research challenges to extend the code generation capabil-
eration method with Petri Net-based modeling techniques ities. Such a benchmark should include representative in-
for a three-stage manufacturing system. Jörns et al. [48] in- puts artifacts available in practice in different file formats.
troduced signal interpreted Petri nets and translated them to It could include natural language requirements to test text
LD or IL code. Frey [49] propose a PLC code generation mining approaches. Benchmark scores could be defined
approach by arranging code fragments which directly cor- for specification coverage, efficiency, and user-friendliness.
respond to Petri net elements. Thieme and Hanisch [93] Such a benchmark would need to be maintained periodically
present a modeling formalism to generate modular control and be updated with new community challenges.
logic using IEC 61131 functions blocks. Music et al. [50] ap- In the future, control logic generation approaches may
ply real-time petri nets to generate control logic implemen- produce IEC 61499 control logic or other programming lan-
tations. Sacha [94] proposes a formalization for transforma- guages and interface with approaches for Modular Automa-
tions of timed finite state machines into PLC control code. tion (NAMUR MTP [70]), if these languages and initiatives
Endsley et al. [95] generate control logic for a conveyor sys- achieve a higher market penetration. User studies should
tem out of finite state machines but do not specifically aim be conducted to assess control logic generation approaches.
at IEC 61131-3 code. Flordal et al. [96] generate executable Criteria or specific project contexts should be defined to help
interlocking policies implemented in PLC programming lan- practitioners to decide for or against code generation given
guages for industrial robot cells. Bergert et al. [97] generate certain project constraints.
IEC 61131 SFCs from Pert charts encoded in XML. [51] use
timed automata and create an automated translation into LD.
References
[1] G. Gutermuth, Collaborative Process Automation Systems, ISA,
8. Conclusions 2010, pp. 156–182.
This paper classified 13 control logic generation ap- [2] P. Martin, G. Hale, Automation Made Easy: Everything You Wanted
proaches for IEC 61131-3 programming languages. Au- to Know about Automation and Need to Ask, International Society of
tomating the task of software implementation for real-time Automation, 2010.
controllers in industrial automation could result in a signifi- [3] M. Tiegelkamp, K.-H. John, IEC 61131-3: Programming industrial
cant cost reduction for the engineering process of industrial automation systems, Springer, 1995.
plants. The classification criteria used in this paper origi- [4] L. Urbas, A. Krause, J. Ziegler, Process control systems engineering,
nate from the customer specifications available in practice Oldenbourg Industrieverlag GmbH Munich, 2012.
(inputs), an idealized model transformation process, and the [5] T. Lukman, G. Godena, J. Gray, M. Heričko, S. Strmčnik, Model-
typical outputs of control logic formats and kinds. The anal- driven engineering of process control software–beyond device-centric
ysis of the 13 approaches showed that they have different abstractions, Control Engineering Practice 21 (2013) 1078–1096.
goals and follow different patterns, which complicates direct [6] T. Schmidberger, A. Horch, A. Fay, R. Drath, F. Breitenecker,
comparisons for quality attributes, such as performance or I. Troch, Rule based engineering of asset management system func-
specification coverage. Most approaches remain in a proof- tionality, in: 5th Vienna Symposium on Mathematical Modelling,
volume 8, 2006.
of-concept maturity.
The classification framework in this paper can bene- [7] V. Vyatkin, Software engineering in industrial automation: State-of-
fit practitioners and researchers. Practitioners get a con- the-art review, IEEE Transactions on Industrial Informatics 9 (2013)
1234–1249.
densed state-of-the-art review for code generation in indus-
trial automation and can thus faster assess the benefits and [8] B. Vogel-Heuser, D. Witsch, U. Katzke, Automatic code generation
drawbacks of each approach. Although practitioners cannot from a UML model to IEC 61131-3 and system configuration tools,
in: 2005 International Conference on Control and Automation, vol-
apply most approaches directly in real projects due to the ume 2, IEEE, 2005, pp. 1034–1039.
likely mismatch of available inputs and immature tool sup-
port, they can evaluate the potential of code generation inde- [9] R. Drath, A. Fay, T. Schmidberger, Computer-aided design and im-
plementation of interlock control code, in: IEEE Conference on Com-
pendently and work towards using the standard file formats puter Aided Control System Design, IEEE, 2006, pp. 2653–2658.
suggested by the approaches. Researchers get a blueprint
[10] C.-H. Yang, V. Vyatkin, C. Pang, Model-driven development of con-
to better compare and categorize existing and future ap-
trol software for distributed automation: a survey and an approach,
proaches. Research challenges derived from the compar- IEEE Transactions on Systems, Man, and Cybernetics: Systems 44
ison revolve around powerful and robust knowledge bases (2014) 292–305.

Koziolek et al.: Preprint submitted to Elsevier Page 22 of 26

 Classication Framework 61131 Logic Generation

[11] G. Liebel, N. Marko, M. Tichy, A. Leitner, J. Hansson, Assessing the [27] M. Barth, R. Drath, A. Fay, F. Zimmer, K. Eckert, Evaluation of
state-of-practice of model-based engineering in the embedded sys- the openness of automation tools for interoperability in engineering
tems domain, in: International Conference on Model Driven Engi- tool chains, in: Proceedings of 2012 IEEE 17th International Confer-
neering Languages and Systems, Springer, 2014, pp. 166–182. ence on Emerging Technologies & Factory Automation (ETFA 2012),
IEEE, 2012, pp. 1–8.
[12] B. Vogel-Heuser, A. Fay, I. Schaefer, M. Tichy, Evolution of software
in automated production systems: Challenges and research directions, [28] T. Mens, P. Van Gorp, A taxonomy of model transformation, Elec-
Journal of Systems and Software 110 (2015) 54–84. tronic Notes in Theoretical Computer Science 152 (2006) 125–142.

[13] M. Steinegger, A. Zoitl, Automated code generation for pro- [29] M. Steinegger, M. Melik-Merkumians, J. Zajc, G. Schitter, Automatic
grammable logic controllers based on knowledge acquisition from generation of diagnostic handling code for decentralized PLC-based
engineering artifacts: Concept and case study, in: Proceedings of control architectures, in: Proc. IEEE 21st International Conference
2012 IEEE 17th International Conference on Emerging Technologies on Emerging Technologies and Factory Automation (ETFA), IEEE,
& Factory Automation (ETFA 2012), IEEE, 2012, pp. 1–8. 2016, pp. 1–8.

[14] Q. Sun, A method for generating process topology-based causal mod- [30] T. Krausser, G. Quirós, U. Epple, An IEC-61131-based rule system
els, Master’s thesis, Aalto University School of Chemical Technology, for integrated automation engineering: Concept and case study, in:
2013. 2011 9th IEEE International Conference on Industrial Informatics,
IEEE, 2011, pp. 539–544.
[15] W. C. Tan, I.-M. Chen, H. K. Tan, Automated identification of com-
[31] S. Grüner, P. Weber, U. Epple, Rule-based engineering using declar-
ponents in raster piping and instrumentation diagram with minimal
ative graph database queries, in: 2014 12th IEEE International Con-
pre-processing, in: 2016 IEEE International Conference on Automa-
ference on Industrial Informatics (INDIN), IEEE, 2014, pp. 274–279.
tion Science and Engineering (CASE), IEEE, 2016, pp. 1301–1306.
[32] A. Otto, K. Hellmann, IEC 61131: A general overview and emerging
[16] E. Arroyo, M. Hoernicke, P. Rodríguez, A. Fay, Automatic derivation
trends, IEEE Industrial Electronics Magazine 3 (2009) 27–31.
of qualitative plant simulation models from legacy piping and instru-
mentation diagrams, Computers & Chemical Engineering 92 (2016) [33] K. Thramboulidis, IEC 61499 vs. 61131: A Comparison Based on
112–132. Misperceptions, arXiv preprint arXiv:1303.4761 (2013).
[17] A. Schüller, U. Epple, PandIX – Exchanging P&I diagram model [34] K. Guttel, P. Weber, A. Fay, Automatic generation of PLC code be-
data, in: Proceedings of 2012 IEEE 17th International Conference on yond the nominal sequence, in: 2008 IEEE International Conference
Emerging Technologies Factory Automation (ETFA 2012), 2012, pp. on Emerging Technologies and Factory Automation, IEEE, 2008, pp.
1–8. doi:10.1109/ETFA.2012.6489537. 1277–1284.

[18] R. Drath, I. Ingebrigtsen, Digitalization of the IEC PAS 63131 Stan- [35] M. Barth, A. Fay, Automated generation of simulation models for
dard with AutomationML, in: 2018 IEEE 23rd International Con- control code tests, Control Engineering Practice 21 (2013) 218–230.
ference on Emerging Technologies and Factory Automation (ETFA),
volume 1, 2018, pp. 901–909. doi:10.1109/ETFA.2018.8502458. [36] S. Schmitz, U. Epple, Automated engineering of human machine
interfaces, in: VDI/VDE Gesellschaft Mess-und Automatisierung-
[19] F. Schumacher, A. Fay, Formal representation of GRAFCET to au- stechnik, 2007, pp. 127–138.
tomatically generate control code, Control Engineering Practice 33
(2014) 84–93. [37] F. Doherr, L. Urbas, O. Drumm, V. Franze, Bedienbilder auf Knopf-
druck, atp magazin 53 (2013) 30–39.
[20] K. C. Thramboulidis, Using UML in control and automation: a model
[38] S. Y. Yim, H. G. Ananthakumar, L. Benabbas, A. Horch, R. Drath,
driven approach, in: 2nd IEEE International Conference on Industrial
N. F. Thornhill, Using process topology in plant-wide control loop
Informatics, 2004. INDIN’04, IEEE, 2004, pp. 587–593.
performance assessment, Computers & Chemical Engineering 31
[21] D. Friedrich, B. Vogel-Heuser, Benefit of system modeling in automa- (2006) 86–99.
tion and control education, in: 2007 American Control Conference, [39] B. Kitchenham, S. Charters, Guidelines for performing systematic lit-
IEEE, 2007, pp. 2497–2502. erature reviews in software engineering, Technical Report, Technical
report, Ver. 2.3 EBSE Technical Report. EBSE, 2007.
[22] U. Katzke, B. Vogel-Heuser, UML-PA as an engineering model
for distributed process automation, IFAC Proceedings Volumes 38 [40] T. Hussain, G. Frey, UML-based development process for IEC 61499
(2005) 129–134. with automatic test-case generation, in: 2006 IEEE Conference on
Emerging Technologies and Factory Automation, IEEE, 2006, pp.
[23] F. W. Breyfogle III, J. M. Cupello, B. Meadows, Managing six sigma:
1277–1284.
A practical guide to understanding, assessing, and implementing the
strategy that yields bottom-line success, John Wiley & Sons, 2000. [41] S. Panjaitan, G. Frey, Combination of UML modeling and the IEC
61499 function block concept for the development of distributed au-
[24] O. Ljungkrantz, K. Akesson, A study of industrial logic control pro- tomation systems, in: 2006 IEEE Conference on Emerging Technolo-
gramming using library components, in: 2007 IEEE International gies and Factory Automation, IEEE, 2006, pp. 766–773.
Conference on Automation Science and Engineering, IEEE, 2007, pp.
117–122. [42] K. Thramboulidis, A. Buda, 3+ 1 SysML view model for IEC61499
Function Block control systems, in: 2010 8th IEEE International Con-
[25] A. Fay, R. Drath, P. Bort, Design and implementation of a Java-based ference on Industrial Informatics, IEEE, 2010, pp. 175–180.
industrial control system configuration tool, in: ETFA 2001. 8th In-
ternational Conference on Emerging Technologies and Factory Au- [43] K. Thramboulidis, The 3+ 1 SysML view-model in model integrated
tomation. Proceedings (Cat. No. 01TH8597), volume 2, IEEE, 2001, mechatronics, Journal of Software Engineering and Applications 3
pp. 553–558. (2010) 109.

[26] A. Fay, A knowledge-based system to translate control system appli- [44] V. P. Suresh, S. Chakrabarti, R. Jetley, Automated Test Case Gen-
cations, Engineering Applications of Artificial Intelligence 16 (2003) eration for Programmable Logic Controller Code, in: Proceed-
567–577. ings of the 12th Innovations on Software Engineering Conference
(formerly known as India Software Engineering Conference), ACM,
2019, p. 29.

Koziolek et al.: Preprint submitted to Elsevier Page 23 of 26

 Classication Framework 61131 Logic Generation

[45] T. Schmidberger, A. Fay, A rule format for industrial plant informa- [62] M. Jamro, D. Rzonca, Agile and hierarchical round-trip engineering
tion reasoning, in: 2007 IEEE Conference on Emerging Technologies of IEC 61131-3 control software, Computers in Industry 96 (2018)
and Factory Automation (EFTA 2007), IEEE, 2007, pp. 360–367. 1–9.

[46] A. Fay, T. Schmidberger, T. Scherf, Knowledge-based support of HA- [63] D. Witsch, M. Ricken, B. Kormann, B. Vogel-Heuser, PLC-
ZOP studies using a CAEX plant model, Inside Functional Safety statecharts: An approach to integrate umlstatecharts in open-loop
2009 (2009) 5–15. control engineering, in: 2010 8th IEEE International Conference on
Industrial Informatics, IEEE, 2010, pp. 915–920.
[47] G. Cutts, S. Rattigan, Using Petri nets to develop programs for PLC
systems, in: International Conference on Application and Theory of [64] B. Vogel-Heuser, D. Schütz, T. Frank, C. Legat, Model-driven en-
Petri Nets, Springer, 1992, pp. 368–372. gineering of manufacturing automation software projects–A SysML-
based approach, Mechatronics 24 (2014) 883–897.
[48] C. Jörns, L. Litz, S. Bergold, Automatische Erzeugung von SPS-
Programmen auf der Basis von Petri-Netzen, Automatisierungstech- [65] M. L. Alvarez, I. Sarachaga, A. Burgos, E. Estévez, M. Marcos, A
nische Praxis 37 (1995) 10–14. methodological approach to model-driven design and development of
automation systems, IEEE Transactions on Automation Science and
[49] G. Frey, Automatic implementation of Petri net based control algo- Engineering 15 (2018) 67–79.
rithms on PLC, in: Proceedings of the 2000 American Control Con-
ference. ACC (IEEE Cat. No. 00CH36334), volume 4, IEEE, 2000, [66] B. Vogel-Heuser, Usability experiments to evaluate UML/SysML-
pp. 2819–2823. based model driven software engineering notations for logic control
in manufacturing automation, Journal of Software Engineering and
[50] G. Music, D. Gradisar, D. Matko, IEC 61131-3 compliant control
Applications 7 (2014) 943.
code generation from discrete event models, in: Proceedings of the
2005 IEEE International Symposium on, Mediterrean Conference on [67] S. Grüner, P. Weber, U. Epple, A model for discrete product flows in
Control and Automation Intelligent Control, 2005., IEEE, 2005, pp. manufacturing plants, in: Proceedings of the 2014 IEEE Emerging
346–351. Technology and Factory Automation (ETFA), IEEE, 2014, pp. 1–8.
[51] R. Wang, M. Gu, X. Song, H. Wan, Formal specification and code [68] K. Thramboulidis, G. Frey, An MDD process for IEC 61131-based
generation of programable logic controllers, in: 2009 14th IEEE In- industrial automation systems, in: ETFA2011, IEEE, 2011, pp. 1–8.
ternational Conference on Engineering of Complex Computer Sys-
tems, IEEE, 2009, pp. 102–109. [69] S. Wiriyacoonkasem, A. C. Esterline, Adaptive learning expert sys-
tems, in: Proceedings of the IEEE SoutheastCon 2000.’Preparing for
[52] D. Tikhonov, D. Schütz, S. Ulewicz, B. Vogel-Heuser, Towards in- The New Millennium’(Cat. No. 00CH37105), IEEE, 2000, pp. 445–
dustrial application of model-driven platform-independent PLC pro- 448.
gramming using UML, in: IECON 2014-40th Annual Conference of
the IEEE Industrial Electronics Society, IEEE, 2014, pp. 2638–2644. [70] J. Bernshausen, A. Haller, T. Holm, M. Hoernicke, M. Obst, J. Ladi-
ges, Namur Modul Type Package–Definition, atp magazin 58 (2016)
[53] C. Wohlin, Guidelines for snowballing in systematic literature studies
72–81.
and a replication in software engineering, in: Proceedings of the 18th
international conference on evaluation and assessment in software en- [71] G. Koltun, M. Kolter, B. Vogel-Heuser, Automated Generation of
gineering, Citeseer, 2014, p. 38. Modular PLC Control Software from P&ID Diagrams in Process In-
dustry, in: 2018 IEEE International Systems Engineering Symposium
[54] M. Steinegger, M. Melik-Merkumians, G. Schitter, Ontology-based
(ISSE), IEEE, 2018, pp. 1–8.
framework for the generation of interlock code with redundancy elim-
ination, in: Proc. 22nd IEEE International Conference on Emerging [72] M. Voelter, J. Bettin, Patterns for Model-Driven Software-
Technologies and Factory Automation (ETFA), IEEE, 2017, pp. 1–5. Development, in: EuroPLoP, 2004, pp. 525–560.
[55] F. Schumacher, S. Schröck, A. Fay, Tool support for an automatic
[73] T. Stahl, M. Voelter, K. Czarnecki, Model-driven software develop-
transformation of GRAFCET specifications into IEC 61131-3 control
ment: technology, engineering, management, John Wiley & Sons,
code, in: 2013 IEEE 18th Conference on Emerging Technologies &
Inc., 2006.
Factory Automation (ETFA), IEEE, 2013, pp. 1–4.
[74] R. Drath, M. Barth, Concept for interoperability between independent
[56] F. Schumacher, S. Schröck, A. Fay, Transforming hierarchical con-
engineering tools of heterogeneous disciplines, in: ETFA2011, IEEE,
cepts of GRAFCET into a suitable Petri net formalism, IFAC Pro-
2011, pp. 1–8.
ceedings Volumes 46 (2013) 295–300.
[75] R. Feldman, J. Sanger, The text mining handbook: advanced ap-
[57] R. Julius, M. Schürenberg, F. Schumacher, A. Fay, Transformation
proaches in analyzing unstructured data, Cambridge university press,
of GRAFCET to PLC code including hierarchical structures, Control
2007.
Engineering Practice 64 (2017) 173–194.

[58] R. Julius, V. Fink, S. Uelzen, A. Fay, Konzept zur bidirek- [76] R. Baeza-Yates, B. d. A. N. Ribeiro, et al., Modern information re-
tionalen Transformation zwischen GRAFCET-Spezifikationen und trieval, New York: ACM Press; Harlow, England: Addison-Wesley,,
IEC 61131-3 Steuerungscode, at-Automatisierungstechnik 67 (2019) 2011.
208–217.
[77] T. Gelhausen, W. F. Tichy, Thematic role based generation of UML
[59] D. Hästbacka, T. Vepsäläinen, S. Kuikka, Model-driven development models from real world requirements, in: International Conference
of industrial process control applications, Journal of Systems and on Semantic Computing (ICSC 2007), IEEE, 2007, pp. 282–289.
Software 84 (2011) 1100–1113.
[78] D. K. Deeptimahanti, M. A. Babar, An Automated Tool for Generat-
[60] C. D. A. A. G. Forbes, H., Distributed Control Systems Global Market ing UML Models from Natural Language Requirements, in: Proceed-
2017-2022, ARC Market Analysis, 2018. URL: https://www.arcweb. ings of the 2009 IEEE/ACM International Conference on Automated
com/market-studies/distributed-control-systems. Software Engineering, ASE ’09, IEEE Computer Society, Washing-
ton, DC, USA, 2009, pp. 680–682. URL: https://doi.org/10.1109/
[61] A. Fay, A knowledge-based system to translate control system appli- ASE.2009.48. doi:10.1109/ASE.2009.48.
cations, Engineering Applications of Artificial Intelligence 16 (2003)
567–577.

Koziolek et al.: Preprint submitted to Elsevier Page 24 of 26

 Classication Framework 61131 Logic Generation

[79] V. Le, S. Gulwani, Z. Su, SmartSynth: Synthesizing Smartphone Au- [94] K. Sacha, Automatic code generation for PLC controllers, in: In-
tomation Scripts from Natural Language, in: Proceeding of the 11th ternational Conference on Computer Safety, Reliability, and Security,
Annual International Conference on Mobile Systems, Applications, Springer, 2005, pp. 303–316.
and Services, MobiSys ’13, ACM, New York, NY, USA, 2013, pp.
193–206. URL: http://doi.acm.org/10.1145/2462456.2464443. doi:10. [95] E. Endsley, E. Almeida, D. Tilbury, Modular finite state machines:
1145/2462456.2464443. Development and application to reconfigurable manufacturing cell
controller generation, Control Engineering Practice 14 (2006) 1127–
[80] W. F. Tichy, M. Landhäußer, S. J. Körner, nlrpBENCH: a bench- 1142.
mark for natural language requirements processing, in: Multikon-
ferenz Software Engineering & Management 2015, Gesellschaft für [96] H. Flordal, M. Fabian, K. Åkesson, D. Spensieri, Automatic model
Informatik eV, 2015. generation and PLC-code implementation for interlocking policies in
industrial robot cells, Control Engineering Practice 15 (2007) 1416–
[81] I. Chalkidis, I. Androutsopoulos, A. Michos, Extracting Contract 1426.
Elements, in: Proceedings of the 16th Edition of the International
Conference on Articial Intelligence and Law, ICAIL ’17, ACM, New [97] M. Bergert, C. Diedrich, J. Kiefer, T. Bar, Automated PLC soft-
York, NY, USA, 2017, pp. 19–28. URL: http://doi.acm.org/10.1145/ ware generation based on standardized digital process information,
3086512.3086515. doi:10.1145/3086512.3086515. in: 2007 IEEE Conference on Emerging Technologies and Factory
Automation (EFTA 2007), IEEE, 2007, pp. 352–359.
[82] J. Burlein, M. Rassl, N. Schmidt, Introducing AutomationML
in a heterogeneous software tool landscape - a success story,
https://bit.ly/2LOfN4p, 2018.
Surveyed Methods
[83] P. Bihani, R. Drath, Concept for automationml-based interoperabil- [M1] R. Drath, A. Fay, T. Schmidberger, Computer-aided design and im-
ity between multiple independent engineering tools without semantic plementation of interlock control code, in: IEEE Conference on
harmonization: Experiences with automationml, in: 2017 22nd IEEE Computer Aided Control System Design, IEEE, 2006, pp. 2653-
International Conference on Emerging Technologies and Factory Au- 2658.
tomation (ETFA), IEEE, 2017, pp. 1–8.
[M2] M. Steinegger, A. Zoitl, Automated code generation for pro-
[84] S. Biffl, R. Mordinyi, H. Steininger, D. Winkler, Integrationsplattform grammable logic controllers based on knowledge acquisition from
für anlagenmodellorientiertes Engineering, in: Handbuch Industrie engineering artifacts: Concept and case study, in: Proc. of 2012
4.0 Bd. 2, Springer, 2017, pp. 189–212. IEEE 17th International Conference on Emerging Technologies &
Factory Automation (ETFA 2012), IEEE, 2012, pp. 1-8.
[85] M. Obermeier, S. Braun, B. Vogel-Heuser, A model-driven approach M. Steinegger, M. Melik-Merkumians, J. Zajc, G. Schitter, Au-
on object-oriented PLC programming for manufacturing systems with tomatic generation of diagnostic handling code for decentralized
regard to usability, IEEE Transactions on Industrial Informatics 11 plc-based control architectures, in: Proc. IEEE 21st International
(2015) 790–800. Conference on Emerging Technologies and Factory Automation
[86] W. Schäfer, R. Wagner, J. Gausemeier, R. Eckes, An engineer’s work- (ETFA), IEEE, 2016, pp. 1-8.
station to support integrated development of flexible production con- M. Steinegger, M. Melik-Merkumians, G. Schitter, Ontology-based
trol systems, in: Integration of Software Specification Techniques for framework for the generation of interlock code with redundancy
Applications in Engineering, Springer, 2004, pp. 48–68. elimination, in: Proc. 22nd IEEE International Conference on
Emerging Technologies and Factory Automation (ETFA), IEEE,
[87] A. Fay, B. Vogel-Heuser, T. Frank, K. Eckert, T. Hadlich, C. Diedrich, 2017, pp. 1-5.
Enhancing a model-based engineering approach for distributed manu-
[M3] S. Grüner, P. Weber, U. Epple, Rule-based engineering using declar-
facturing automation systems with characteristics and design patterns,
ative graph database queries, in: 2014 12th IEEE International Con-
Journal of Systems and Software 101 (2015) 221–235.
ference on Industrial Informatics (INDIN), IEEE, 2014, pp. 274-
[88] M. Wenger, A. Zoitl, C. Sunder, H. Steininger, Transformation of iec 279.
61131-3 to iec 61499 based on a model driven development approach, [M4] B. Vogel-Heuser, D. Witsch, U. Katzke, Automatic code generation
in: 2009 7th IEEE International Conference on Industrial Informatics, from a UML model to IEC 61131-3 and system configuration tools,
IEEE, 2009, pp. 715–720. in: 2005 International Conference on Control and Automation, vol-
ume 2, IEEE, 2005, pp. 1034-1039.
[89] W. W. Dai, V. Vyatkin, A case study on migration from iec 61131 plc
to iec 61499 function block control, in: 2009 7th IEEE International [M5] E. Estevez, M. Marcos, D. Orive, Automatic generation of plc au-
Conference on Industrial Informatics, IEEE, 2009, pp. 79–84. tomation projects from component-based models, The International
Journal of Advanced Manufacturing Technology 35 (2007) 527-
[90] C. Yang, V. Dubinin, V. Vyatkin, Ontology driven approach to gen- 540.
erate distributed automation control from substation automation de- [M6] D. Witsch, B. Vogel-Heuser, Close integration between UML and
sign, IEEE Transactions on Industrial Informatics 13 (2017) 668–679. IEC 61131-3: New possibilities through object-oriented extensions,
doi:10.1109/TII.2016.2634095. in: 2009 IEEE Conference on Emerging Technologies & Factory
Automation, IEEE, 2009, pp. 1-6.
[91] A. Voinov, C. Yang, V. Vyatkin, Automatic generation of function
block systems implementing hmi for energy distribution automation, D. Witsch, M. Ricken, B.Kormann, B.Vogel-Heuser, PLC-
in: 2017 IEEE 15th International Conference on Industrial Informat- Statecharts: An approach to integrate UML statecharts in open-loop
ics (INDIN), 2017, pp. 706–713. doi:10.1109/INDIN.2017.8104859. control engineering, in: 2010 8th IEEE International Conference on
Industrial Informatics, IEEE, 2010, pp. 915-920.
[92] C. Yang, V. Dubinin, V. Vyatkin, Automatic generation of control
D. Witsch, B. Vogel-Heuser, PLC-Statecharts: An approach to inte-
flow from requirements for distributed smart grid automation con-
grate UML-statecharts in open-loop control engineering - Aspects
trol, IEEE Transactions on Industrial Informatics 16 (2020) 403–413.
on behavioral semantics and model-checking, IFAC Proceedings
doi:10.1109/TII.2019.2930772.
Volumes 44 (2011) 7866-7872.
[93] J. Thieme, H.-M. Hanisch, Model-based generation of modular plc [M7] T. Lukman, G. Godena, J. Gray, M. Hericko, S. Strmcnik, Model-
code using iec61131 function blocks, in: Proceedings of the Inter- driven engineering of process control software - beyond device-
national Symposium on Industrial Electronics, volume 1, 2002, pp. centric abstractions, Control Engineering Practice 21 (2013) 1078-
199–204. 1096.

Koziolek et al.: Preprint submitted to Elsevier Page 25 of 26

 Classication Framework 61131 Logic Generation

[M8] F. Schumacher, S. Schröck, A. Fay, Tool support for an automatic

transformation of GRAFCET specifications into iec 61131-3 con-
trol code, in: 2013 IEEE 18th Conference on Emerging Technolo-
gies & Factory Automation (ETFA), IEEE, 2013, pp. 1-4.
F. Schumacher, S. Schröck, A. Fay, Transforming hierarchical con-
cepts of GRAFCET into a suitable petri net formalism, IFAC Pro-
ceedings Volumes 46 (2013) 295-300.
F. Schumacher, A. Fay, Formal representation of GRAFCET to au-
tomatically generate control code, Control Engineering Practice 33
(2014) 84-93.
R. Julius, M. Schürenberg, F. Schumacher, A. Fay, Transformation
of GRAFCET PLC code including hierarchical structures, Control
Engineering Practice 64 (2017) 173-194.
[M9] B. Vogel-Heuser, D. Schütz, T. Frank, C. Legat, Model-driven engi-
neering of manufacturing automation software projects - a SysML-
based approach, Mechatronics 24 (2014) 883-897.
[M10] M. L. Alvarez, I. Sarachaga, A. Burgos, E. Estevez, M. Marcos, A
methodological approach to model-driven design and development
of automation systems, IEEE Transactions on Automation Science
and Engineering 15 (2018) 67-79.
[M11] K. Thramboulidis, G. Frey, An MDD process for IEC 61131-based
industrial automation systems, in: ETFA2011, IEEE, 2011, pp. 1-8.
[M12] D. Hästbacka, T. Vepsäläinen, S. Kuikka, Model-driven develop-
ment of industrial process control applications, Journal of Systems
and Software 84 (2011) 1100-1113.
[M13] G. Koltun, M. Kolter, B. Vogel-Heuser, Automated generation of
modular PLC control software from P&ID diagrams in process in-
dustry, in: 2018 IEEE International Systems Engineering Sympo-
sium (ISSE), IEEE, 2018, pp. 1-8.

Koziolek et al.: Preprint submitted to Elsevier Page 26 of 26