Journal

Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°N°4 4 2019
2019

DEVELOPING A MULTIPLATFORM CONTROL ENVIRONMENT

Submitted: 15th July 2019; accepted: 20th December 2019

Dariusz Rzońca, Jan Sadolewski, Andrzej Stec, Zbigniew Świder, Bartosz Trybus, Leszek Trybus

DOI: 10.14313/JAMRIS/4‐2019/40 Compilers of control languages are basic compo‑

Abstract: nents of IEC 61131‑3 tools. A compiler translates
source program into machine code executed by run‑
IEC 61131‐3 control environment is called multiplatform
time software of the controller processor. Three ap‑
if source programs can be executed by various proces‐
proaches to compilation are encountered in practice.
sors, beginning from 8‐bit microcontrollers up to 32/64‐
In the �irst one, most common, IEC 61131‑3 programs
bit efficient CPUs. This implies that virtual machine (VM),
are directly translated into machine code. Execution
i.e. a software implemented processor, is used as runtime
is fast, so the approach is applied by leading manu‑
by the host CPU. The VM executes certain intermediate
facturers of control equipment, such as Siemens, ABB,
code into which IEC 61131‐3 programs are compiled. En‐
Schneider, Rockwell, Omron and others. Some tools
vironment of this type called CPDev has been gradually
from independent software providers, namely CODE‑
developed by the authors over the last decade, begin‐
SYS [1] (market leader) and LogicLab [2] also directly
ning with initial report in this journal in 2008 [47]. Howe‐
translate source programs into machine code. It is ho‑
ver, technical implementations of its functionalities have
wever a single platform solution since change of CPU
not been described so far. This involves such matters as
requires a new compiler.
intermediate language, parametrization of the compiler
and VM, multiproject runtime, translators of graphical Contrary to the direct translation the second ap‑
languages, device‐independent HMI, target platform and proach involves two steps. At �irst IEC 61131‑3 pro‑
communication interfacing, which are presented in com‐ grams are translated to C/C++ and then another tool
pact form in this paper. Some characteristic industrial im‐ generates the machine code. Academic open‑source
plementations are indicated. Beremiz [53] and independent GEB [16] apply this ap‑
proach which due to common C/C++ tools suits multi‑
Keywords: IEC 61131‐3 environment, virtual machine, ple platforms, not just one as before. The approach is
intermediate language, parametrized compiler, interfa‐ particularly suitable for education, however necessity
cing, HMI, industrial controllers of another C/C++ translation limits somewhat com‑
mercial applications.
1. Introduction In the third approach, source programs are compi‑
There is a common opinion among practising en‑ led into binary code of a dedicated intermediate lan‑
gineers and university staff that runtime engineering guage executed by specially designed virtual machine
environments based on IEC 61131‑3 standard [22] (VM), i.e. a software processor. The VM is in fact the
will remain state of industrial practice long into the runtime program of the target controller. The appro‑
next decade (e.g. [52], [56]). The standard de�ines �ive ach does not need translation to C/C++ and may be
programming languages, i.e. textual IL, ST, graphic LD, applied to multiple platforms. It was originally intro‑
FBD and mixed SFC, with time‑triggered scan cycle duced in ISaGRAF environment [21] with intermedi‑
execution. IL, LD and SFC are preferred in manufac‑ ate Target Independent Code. STRATON [9] (indepen‑
turing based on PLCs, whereas general automation dent) also applies this approach, however details re‑
favours ST, FBD and also SFC. Edition 3.0 (2013) of main con�idential. VMs are typical for academic solu‑
the standard has introduced object‑oriented program‑ tions reviewed in the next section. Nevertheless, time
ming by extending the original function block concept. ef�iciency of the approach is lower due to overhead im‑
Open architecture for distributed control and au‑ posed by the VM.
tomation focused on interoperability of the devices The other IEC 61499 standard is supported by se‑
con�igured by multiple tools, with function blocks as veral engineering tools of which nxtControl [38] used
reusable software components, is de�ined in another at academic institutions may be an example. Also ISa‑
IEC 61499 control standard [23]. Runtime software GRAF provides now IEC 61499 programming option.
is event‑driven. Code measures have shown [17] that The authors began developing an IEC 61131‑3 en‑
IEC 61499 is more appropriate for sequential controls, vironment over a decade ago encouraged by an equip‑
but IEC 61131‑3 suits better general applications. Ho‑ ment manufacturer and because of teaching needs. It
wever, due to insuf�icient support by commonly used was actually a next step from earlier works on multi‑
tools and runtimes IEC 61499 has not been gene‑ function controllers (e.g. [7]). Application of the �irst
rally accepted by industry so far [52], although some version of the environment called Control Program
successful applications particularly in energy sector Developer (CPDev) was reported in this journal [47]
have been reported (e.g. [10]). (also shown at Automation 2008 Fair). The �irst ver‑

73
73
 Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°
N°44 2019
2019

sion compiled ST programs into intermediate Virtual and plant model written in ST. HT‑PLC [26] runs LD
Machine Assembler (VMASM) executed by runtime programs on Arduino with Ethernet. Among relevant
VM on AVR and MCS51 8‑bit microcontrollers. It alre‑ solutions in other areas one may mention security‑
ady involved certain provisions to facilitate porting to oriented IoT environment [32] involving SIL interme‑
different hardware and interfacing communications. diate language, C/C++/Java‑to‑SIL compiler and VM.
Over the following years CPDev has been exten‑ Scan cycle, important particularly in manufactu‑
ded on 32/64‑bit processors, augmented with transla‑ ring, can be decreased by direct execution at a dedi‑
tors of graphical languages, HMI design tool and multi‑ cated processor, as shown in [39] for a Toshiba CPU.
project runtime (initially applied in FPGA [18]). PhD Nowadays hardware processors are designed in FPGA
research has been supported by Model Driven Deve‑ technology, as demonstrated by early double proces‑
lopment and unit‑testing extensions [29], [27]. So far sor for a PLC [6] and in [42], [35] for current multi‑
several Small and Medium Scale (SMES) manufactu‑ core solutions. Comparison of execution times for a
rers use the environment. few PLCs and FPGA has been presented in [18]. A num‑
The early paper [47] and the others have focu‑ ber of FPGA designs can be found in the proceedings
sed on CPDev functionalities rather than on explaining of PDES conferences (Programmable Devices and Em‑
how they have been created. Therefore the purpose of bedded Systems).
this paper is to present technical aspects of: Details of IEC 61131‑3 compilers are typically not
‑ portability of the compiler and VM to different CPUs disclosed. As an exception the early paper [31] descri‑
‑ implementation of interfaces for various target plat‑ bes structure of the compiler, code optimization and
forms support of logic operations by a programmable de‑
vice. Nevertheless, one may generally expect that most
‑ translators of graphical languages of the compilers apply Static Single Assignment (SSA)
‑ structure of device‑independent HMI tool syntax and corresponding translation described for
‑ data for binding variables to communication inter‑ instance in [8]. Occasionally semantic‑driven transla‑
faces. tion can also be encountered [13]. SSA syntax has been
This paper is thus organized as follows. Next recently applied for inference of types in dynamic lan‑
section reviews related work concerning IEC 61131‑ guages [45], such as Python. Parametrization of GCC
3 environments. Section 3 summarizes basic features compiler due to limited resources has been presented
of CPDev. Section 4 overviews VMASM language, pa‑ in [44].
rametrized compiler and presents example running Activity on Vertex (AOV) graph transformation al‑
throughout the paper. Architecture of the VM, im‑ gorithms are typically used to translate LD diagrams
plementation of target platform interfaces and multi‑ into IL or ST [12], [20]. Direct translation of AOV into
project runtime are described in Section 5. Section 6 ST is applied in CPDev. More advanced Enhanced Data
presents translators of graphical languages and struc‑ Flow Graphs from [36] can implement IL, LD and SFC
ture of the HMI tool. List of data required to bind varia‑ programs.
bles to communication interfaces and some characte‑ Parametrized formal semantics for execution of
ristic industrial implementations are shown in Section SFC diagrams has been proposed in [4] to avoid am‑
7. biguities of IEC 61131‑3 standard. Unsafe components
of SFCs created using CODESYS semantics (also app‑
lied in CPDev) can be detected by static analysis [49].
2. Related Work
Principles of HMI design for control applicati‑
An interest in virtual machines, i.e. abstract pro‑ ons have been described in [14]. German standard
cessors for speci�ic languages implemented by soft‑ VDI/VDO 3699 [51] also covers this area. Future ad‑
ware on particular hardware platforms has been in‑ vanced solutions may involve 3D graphics and virtual
creasing since Java Virtual Machine (JVM) appeared reality [50]. Some features of industrial operator pa‑
over 20 years ago [55], followed later by Common Lan‑ nels and in‑vehicle infotainment systems [34] are cle‑
guage Runtime (CLR) for .NET framework [46]. In par‑ arly the same.
ticular, most of ARM‑based mobile phones implement Implementation guidelines and technical details
JVM processors in Jazelle technology. concerning industrial communications can be found
VM‑based control solutions with the standard IL as for instance in [59]. Comparison of industrial and pu‑
the intermediate language appeared in literature in si‑ blic networks taking into account control, standardi‑
milar time as the early paper [47] (besides commer‑ zation and dependability is discussed in [15].
cial ISaGRAF). VM of [58] was written in C and app‑
lied in 8‑bit C8051 CPU. Whimori CDU [48] educati‑
onal tool translated LD into IL. UniSim [11], although 3. CPDev Overview
restricted to a few data types, provided graphical pro‑ The CPDev tool, initially providing just ST pro‑
gramming. IL was also used in [57] for VM implemen‑ gramming, supports now all IEC 61131‑3 languages,
tation of ARM‑based softcontroller. HMI design, documentation generator and research‑
More recently, IEC 61131‑3 applications have been oriented extensions. Multi‑project runtime for com‑
executed by CLR, i.e. a .NET VM [5]. Development plex software is also available. Steps of control pro‑
of various educational tools continues. For example, gram processing are shown in Fig. 1. ST and IL pro‑
WEB PLC Simulator [41] executes control algorithm grams are compiled into mnemonics of the intermedi‑

74
74 Articles
Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°N°4 4 2019
2019

ate VMASM. LD, FBD and SFC diagrams are translated up to 16 operands where the �irst one denotes the re‑
to ST and then compiled. Assembler converts the mne‑ sult. Procedures shown in Table 1 (examples) are ty‑
monics into executable binary code uploaded into VM. pical for machine languages, so they control program
The VM is written in C, so may be implemented in va‑ �low, call subprograms, copy memory, etc.
rious CPUs.
Tab. 1. Procedures of the VMASM language
SFC FBD LD
Mnemonic Meaning
JMP Unconditional jump
JZ Conditional jump
Translators JR Unconditional relative jump
CALB Subroutine call
RETURN Return from subroutine
IL ST MCD Initialize data
MEMCP Copy memory block
FPAT Fill memory block
Compiler
Syntax of VMASM instructions is the following:
[:label] instruction [operand1]
VMASM [,operand2][,operand3]...
mnemonics
Label is optional, instruction speci�ies number of
operands, i.e. variables, labels or constants. Since in
case of functions operand1 denotes a variable (result),
Assembler
so the syntax expresses memory‑to‑memory type of
operation. Question mark ? at the beginning indicates
Binary
label or in ?LR? pre�ix a temporary variable created by
code the compiler. Dot operator (.) selects components of
arrays or structures.
Runtime
Note that in IL language, often used as intermedi‑
VM ate (Sec. 2), result of a command is kept in Current Re‑
sult (CR) register equivalent to accumulator. Later the
Fig. 1. Processing of control programs CR is copied into a variable. By placing the result in the
operand1, VMASM combines these two steps into one.
Basic functionalities of CPDev are practically the The notion of accumulator does not exist in VMASM.
same as in other control environments. Automatic 4.2. Parametrized Compiler
connections provided by LD and FBD editors may be
an exception (A* algorithm [19]). HMI tool applies To ensure portability of implementations one has
components from device‑independent libraries. Data to take primarily into account sizes of addresses requi‑
for interfacing communications and I/Os are genera‑ red by CPUs, so typically 16 or 32 bits. Also some data
ted by the compiler as an XML �ile. types may be not needed. To provide such features
Model Driven Development extension translates the CPDev compiler is parametrized by means of an
SysML diagrams [40] into templates of programs or XML Library Con�iguration File (LCF) involving de�i‑
communication tasks [29]. Another extension sup‑ nitions of hardware resources, data types, instructions
ports unit testing of POUs (Program Organization and conversions. Given the parametrized LCFs dedica‑
Units) [27]. All CPDev modules have XML interfaces ted compilers and VMs for particular platforms can be
to enable agile and round‑trip software development created from one general compiler and generic VM.
[28].
<HARDWARE>
Extended runtime environment besides the VM for
<AddressSize>2</AddressSize>
control functions involves HMI runtime for the inter‑
<MaxCodeAddress>0xFFFF</MaxCodeAddress>
face. The VM and HMI runtime are executed in parallel
<MaxDataAddress>0xFFFF</MaxDataAddress>
exchanging data by means of global variables.
</HARDWARE>
<TYPES>
4. Intermediate VMASM and Compilation <type name="UINT" implement="alias">
4.1. Overview of VMASM <alias name="WORD"/>
As an IEC 61131‑3‑oriented language, Virtual Ma‑ </type>
chine Assembler accepts all elementary data types <deny-type name="LREAL" />
except WSTRING. Number of types required by parti‑ </TYPES>
cular application may be restricted by parametrizing
the compiler. VMASM instructions consist of functions Fig. 2. Specification of hardware and data types
and procedures. Functions are the same as in the stan‑
dard, so ADD, OR, EQ, CONCAT, EXPT, etc. They admit Sample speci�ication of <Hardware> resources in

75
Articles 75
 Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°
N°44 2019
2019

the LCF �ile is shown in Fig. 2 (upper part) with initializes TON1.PT (4 bytes, TIME) with #B80B0000,
AddressSize and MaxAddresses of code and data me‑ i.e. 2000 ms (little endian form). Final CALB calls code
mories available for VM. 2 as AddressSize means 2 of TON1 block from IEC_61131 library. Value testing
bytes needed for 16‑bit addressing of up to 64 kB me‑ and jumps could be avoided by writing the Boolean ex‑
mory (0xFFFF). 4 represents 32‑bit addressing of 4 pression in function form as AND(IN,TON2.Q)).
GB. Note that the AddressSize de�ines addressing for Translation of TON2 call is similar. OUT statement
VM only, so 16‑bit VM may be executed by a 32 or 64‑ is translated in the same way as the expression for
bit CPU. TON1.IN. Optimization of the mnemonic translation to
<TYPES> part of the LCF �ile (Fig. 2) de�ines data minimize the number of temporary variables precedes
types available in particular implementation. By using generation of binary code.
deny-type one can remove not needed types, for in‑
stance LREAL. The deny-type option enables con�i‑ 5. Binary Code and Virtual Machine
guration of the environment for so‑called made‑to‑ 5.1. Assembling the Mnemonics
measure PLCs, suitable particularly for IoT and Indu‑
To generate the binary code, VMASM instructions
stry 4.0 applications.
are de�ined in the LCF �ile by means of digital identi‑
Given the LCF �ile, scanner and parser of the com‑
�iers vmcode composed of group ig and type it sub‑
piler translate the source program into a �ile with
identi�iers as shown in Fig. 4a. In case of functions
VMASM mnemonics. By using another set of keywords
ig indicates name, so ADD, MUL, AND, EQ, etc., whereas
the ST scanner also processes IL, where ad hoc tempo‑
it refers to data type, BOOL, INT, TIME and so on.
rary variables replace CR register. The parser applies
In this way type‑speci�ic functions such as ADD:INT,
top‑down syntax‑directed translation [8]. Basic com‑
AND:BOOL and others may be expressed in digital form.
ponents of the compiler are de�ined as classes in C�
Fig. 4b (upper part) shows de�inition of AND:BOOL
language. Internal data are kept in lists.
where ig=08 denotes AND and it=*0 indicates BOOL
4.3. Compilation Example (0) and varying number of inputs (*).
All VMASM procedures belong to one group ig=1C
ST program for switching OUT on‑and‑off in 3+2 se‑
with it choosing speci�ic procedure. �e�inition of MCD
conds cycle while IN is a active, and VMASM transla‑
that initializes data memory beginning from DST (des‑
tion of the �irst TON1 call are shown in Fig. 3. A warning
tination) relative label (:rdlab) with imm1 bytes (im‑
light may be triggered in this way.
mediate value) from the source imm2 of varying type
(*) is also in Fig. 4b (lower part).

ig it
�rou� �de�t���er t��e �de�t���er
(a)
TON1(IN:=IN AND NOT TON2.Q, PT:=T#3s);
TON2(IN:=IN AND TON1.Q, PT:=T#2s); <function name="AND" vmcode="08*0" return="BOOL">
OUT := IN AND NOT TON1.Q; <args>
JZ IN, :?WARN?AN10 <arg no="*" name="arg*" type="BOOL"/>
NOT ?LR?AN11, TON2.Q </args>
JZ ?LR?AN11, :?WARN?AN10 <comment>Binary AND of BOOL operands</comment>
MCD TON1.IN, #01, #01 </function>
JMP :?WARN?EA14 <sysproc name="MCD" vmcode="1C15">
:?WARN?AN10 <args>
MCD TON1.IN, #01, #00 <arg no="0" name="DST" type=":rdlabel"/>
:?WARN?EA14 <arg no="1" name="imm1" type=":imm.BYTE"/>
MCD TON1.PT, #04, #B80B0000 <arg no="2" name="imm2" type=":imm.*"/>
CALB TON1, :?IEC_61131.TON?CODE </args>
<comment>Initializes data at arg0 address with area
Fig. 3. ST code and part of VMASM translation size arg1 and source pattern arg2.</comment>
</sysproc>
The compiler translates Boolean expressions in‑ (b)
volving in�ix operations like IN AND TON2.Q by me‑
ans of value testing and jumps. Hence the VMASM Fig. 4. a) Structure of vmcode, b) specification of
translation begins with jump JZ to :?WARN?AN10 la‑ function and procedure
bel if IN is zero. If not, NOT of TON2.Q is evaluated
in ?LR?AN11 temporary variable, followed by anot‑ Having the �ile with VMASM mnemonics all pro‑
her JZ to the same label if the variable is zero. If gram modules are consolidated and assembled into bi‑
not, MCD instruction sets 1 byte (�irst #01) at TON1.IN nary code by replacing:
to 1 (second #01), followed by unconditional JMP to ‑ instruction mnemonics by digital identi�iers vmcode
:?WARN?EA14. At the :?WARN?AN10 label another MCD (ig and it)
sets TON1.IN to 0 (#00). The third MCD at :?WARN?EA14 ‑ names of variables by addresses in data memory

76
76 Articles
Journal
Journalof
ofAutomation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent Systems
Intelligent Systems VOLUME
VOLUME 13,13, N°N°44 2019
2019

‑ labels by addresses in code memory. ‑ VMP_PreCycle – updates program variables from

Binary code assembled from the �irst four VMASM external inputs before calculations, stores initial
instructions in Fig. 3 looks as follows: state of system clock
‑ VMP_PostCycle – updates external outputs with re‑
1C02 0000 B900 sults of calculations; if time is left triggers tests or
0510 0200 2100 other activities
1C02 0200 B900
‑ VMP_CurrentTime – returns current value of system
1C15 0800 0101
clock to determine TIME variables.
In case of cycle time overrun, the VMP_PostCycle sets
The vmcodes of JZ, NOT and MCD instructions are 1C02,
a �lag in the VM status. The VM checks the �lag and ta‑
0510, 1C15, respectively. IN is allocated to address 0
kes appropriate steps (failure LED, safe outputs, etc.).
in data memory, TON2.Q to 21 (hexadecimal), tem‑
porary ?LR?AN11 to 2, and TON1.IN to 8. The label By assumption, the code that �ills the prototypes
:?WARN?AN15 indicates B9 in the code memory. is written in C/C++ by implementation engineer and
consolidated with the generic VM. Some other har‑
5.2. Virtual Machine dware functions may be added.
As indicated in the introduction the use of VM leng‑
General architecture of CPDev virtual machine in‑
thens the execution cycle as compared to direct trans‑
volving code and data memories, instruction proces‑
lation to machine code or to C/C++. To evaluate the
sing module, and target platform interface is shown in
overhead, execution times of standard function blocks
Fig. 5. The module fetches instructions from code me‑
such as �lip‑�lops, edge detectors, counters and timers
mory, executes them acquiring operands from data or
have been measured, at �irst implemented in ST and
code memories (variables or constants) and in case of
then in C by means of so‑called native blocks (Sec. 7.1).
functions stores the results in data memory. Procedu‑
By average, the VM solution has turned out about four
res change internal state of VM. Target platform inter‑
times slower than translation to C/C++ [16], [53]. So
face in the generic VM consists of speci�ications of low‑
the use of native blocks reduces the overhead consi‑
level functions �illed in by appropriate code while por‑
derably.
ting. VM components are implemented as 16 or 32‑bit
according to AddressSize. 5.3. Runtime for Complex Software
The generic VM described above executes single
Code Instruction processing Data project involving one task. However, deployment of
stack module stack
a few VMs in a multi‑core FPGA has been tested al‑
Memory-to-memory
ready [18], leading the way to development of multi‑
project runtime needed for a supervisory computer or
Code Data
memory memory software processing station. To make implementation
Target platform interface relatively simple it has been assumed that operating
Prototypes of low-level system of the computer will take care of scheduling or
functions multitasking of the VMs.
This concept has been recently transferred into
Fig. 5. General architecture of the virtual machine runtime for industrial PC with Windows Embedded
operating system. The runtime is called WinController
and can execute complex software composed of pro‑
Generic part of VM is written in standard C, so suits
jects run by corresponding VMs with different or the
any general purpose CPU. Note that the VMs mentio‑
same cycles. The VMs exchange data through global
ned in Section 2 are mostly written in C. The VM ope‑
variables. Field devices, namely PLCs, PACs, I/O cards
rates as an interpreter executing successive lines of
etc. are interfaced by means of special I/O and Data
code. Overloaded functions such as AND, MUL, GT, etc.
adapters. The WinController is implemented as a ser‑
accept all meaningful data types. Variable number of
vice in the Windows service system functionality. It
operands is handled by a for loop. A procedure indi‑
runs nonstop in the background and starts automati‑
cated by ig=1C is selected by switch(it) command.
cally when the computer is switched on.
Speci�ications of low‑level functions included into
The service is con�igured by WinController Ma‑
the generic VM are expressed by function prototypes
nager with relevant part of main window shown in
(empty), independent of CPU and hardware solution.
Fig. 6. Besides Service status, I/O and Data adapters,
Initial set of prototypes has been presented in [54] ba‑
the window includes two VMs running AUTOPILOT
sed on experience with multifunction instruments [7]
and HMI projects. Data exchange is con�igured by I/O
and industrial controllers. Some of the prototypes are
mappings.
listed below:
‑ VMP_LoadConfiguration – loads task parameters
(cycle, number of POUs, etc.), binary code and allo‑ 6. Graphical Translators and HMI Tool
cates memory for data 6.1. LD and FBD Translators to ST
‑ VMP_PreRunConfiguration – initializes hardware Although LD and FBD diagrams look different, CP‑
and stores the initial state (time, parameters) Dev editors are similar partly due to the same A*

77
Articles 77
 Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°
N°44 2019
2019

Fig. 8. LD diagram and ST translation

Fig. 6. Configuration window of WinController Manager
6.2. SFC Translation
path�inding algorithm used for automatic connections SFC diagram for the running example is shown
[19]. Translation replaces the connections by auxili‑ in Fig. 9. Actions set or reset the OUT output. The
ary local variables to display ’live” diagrams in the diagrams composed of steps, transitions, jumps, se‑
online mode. Actually the vertices of corresponding quence selections and simultaneous sequences are
AOV graph represent diagram elements whereas vir‑ kept in memory as trees. The �irst three elements cre‑
tual nodes denote connections. Each line of ST pro‑ ate the last two. Actions bound to steps are de�ined by
gram re�lects the node. quali�iers such as N Normal/Non‑stored, S Set, R Reset,
Three‑rung LD version of the running example fol‑ L time Limited, D Delayed and other [22].
lowed by ST translation of the �irst rung is shown
in Fig. 7. The auxiliary variables beginning with
out_contact_ are declared automatically in VAR ...
END_VAR section. Besides the connections the varia‑
bles represent branch points and outputs of function
blocks or functions.

Fig. 9. SFC diagram for the running example

Translation of SFC to ST is supported by

two system function blocks, SFC_STEP and
SFC_ACTION_CONTROL, connected as in Fig. 10.
The �irst one determines step activity according to the
Fig. 7. FBD diagram and ST translation next_step_flag. The outputs X, T indicate activity
and time elapsed since activation (see Fig. 9). By
means of the A output the second block triggers action
FBD diagram and corresponding translation are
(code) bound to the step according to given quali�ier.
shown in Fig. 8. �ere the pre�ix out_ indicates auxili‑
This is provided by connecting the output X of the
ary variables. Except for such variables the translation
�irst block to the input of the second block indicated
does not differ from the ST original in Fig. 3.
by the quali�ier (N, S, R, L, D, ...).
To make the automatically created connections
ST translation of SFC diagram begins with
looking more or less like drawn ”by hand” the original
declarations of the instances of SFC_STEP and
A* algorithm has been extended to penalize path cros‑
SFC_ACTION_CONTROL, and next_step_flags.
sings and direction changes [13]. Note also that after
PROGRAM section consists of three parts:
each correction of the diagram the algorithm calcula‑
‑ activation of step blocks by next_step_flags
tes all paths anew, so they may be a little different than
before. ‑ execution of actions bound to active steps

78
78 Articles
Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°N°4 4 2019
2019

next_step_flag

IN
SFC STEP
X T

N S R L D ...
SFC ACTION CONTROL
A

IF A THEN action_code
END_IF

Fig. 10. Execution of step‐action pair

Fig. 11. TFT display for power management at a ship [43]

‑ setting next_step_flags by evaluation of transi‑
tion conditions.
below:
The �irst two parts correspond to Fig. 10 while the
‑ DrawRectangle: position, size, border color and
last one creates the tree structure according to SFC
width
diagram. Simultaneous sequence may set/reset a few
next_step_flags by a single preceding transition. ‑ FillRectangle: position, size, �ill color.
As explained in [4], SFC diagrams may exhibit By assigning a variable to FillRectangle’s size
unreachable and unsafe behaviour. Unreachability is the two primitives may create a bargraph. DrawArc,
partially restricted by the editor but the designer’s FillPie, FillTriangle, ProcessValue are examples
task is to avoid unsafe diagrams. of other primitives.

6.3. Human Machine Interface

Small control systems based on PLCs and PACs of‑ Device
ten include graphical operator panels. The panels may independent
be integrated with controllers, as in case of Horner,
Unitronix, Beckhoff and others.
HMI software for such panels consists of two parts
related to visualization and behaviour. Visualization
Device
involves a set of displays built from graphic objects se‑
dependent
lected from libraries. Behaviour is determined by HMI
programs that select displays and specify appearance
of the objects. To do so, relevant variables are exchan‑ Fig. 12. Structure of the HMI tool
ged between the controller and panel. The variables
are bound to attributes of the objects during con�i‑
Implementation of CPVis for particular display de‑
guration. If control and HMI programs belong to the
vice requires �illing the drawing primitives with ap‑
same project they access common global variables to
propriate code using the mechanisms and library spe‑
exchange data.
ci�ic for the device, for instance �amTex, �LCD or �DI�.
Features outlined above are provided in the envi‑
Custom graphic objects are created by writing the
ronment by CPVis tool involving a dedicated graphic
code in C with calls of drawing primitives. Such ob‑
editor for de�ining displays, adding objects, moving
jects can be displayed by another device provided that
them, etc. Attributes of the objects are determined by
the drawing primitives are prepared for it. Notice that
global variables or constants. XML data of the project
the concept of drawing primitives is similar to the pro‑
converted into binary code are used in the runtime en‑
totype functions speci�ied for the target platform in‑
vironment where VM and CPVis runtime jointly pro‑
terface (Sec. 5.2).
vide control and HMI functions. Example of display for
power management at a ship is shown in Fig. 11.
7. Communication and Implementations
By splitting the HMI software into device‑
dependent and device‑independent parts proposed 7.1. Structure of Communication Data
in [30], visualizations created by CPVis can be dis‑ By the original assumptions, the implementa‑
played by different devices, i.e. TFT or LCD panels, tion engineers themselves develop con�iguration tools
monitors or tablets. The device‑dependent parts are while porting the environment to particular platforms
speci�ied by common prototypes of low‑level drawing (along with target platform interfaces). To support
functions called drawing primitives. Codes of graphic this the compiler‑generated XML �ile (DCP extension),
objects call the prototypes by name only, so they besides binary code and VMASM mnemonics (for de‑
are device‑independent, as depicted in Fig. 12. Two bugging), also contains relevant data on global varia‑
drawing primitives concerning a rectangle are shown bles. The data are kept in VAR entities, such as those

79
Articles 79
 Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°
N°44 2019
2019

in Fig. 13 for IN and OUT variables from the running 7.2. Characteristic Implementations
example. The successive entries denote: As may be concluded from above, the implementa‑
‑ LName – local name inside current variable scope tion engineer can port CPDev environment to particu‑
‑ PName – physical name including project name scope lar platform after development of:
‑ target platform interface
‑ Addr – hexadecimal address (16‑bit version in ‑ communication and I/O con�iguration tool
Fig. 13)
‑ deployment module to upload the binary code and
‑ AddrType – address type; :gdlabel means global con�iguration data into the controller.
data label Upgrading existing devices such as dedicated con‑
‑ Size – variable size in bytes trollers, distributed I/O units or data loggers with
IEC 61131‑3 capabilities has been the main purpose
‑ Type – variable type of the implementations so far. Therefore the engineers
could use major portions of low‑level software while
‑ PType – physical type; $Default scope involves sy‑
porting. Deployment has involved Ymodem for serial,
stem elements
ftp or tftp for Ethernet and GSM/GPRS for wireless.
‑ VarFlags – �lags related to variable. Power management, propulsion control, heading
Variables imported from libraries have control and other subsystems belonging to Mega‑
LIBRARY.VARIABLE as physical name to avoid con‑ Guard ship automation and navigation system from
�licts. �esides elementary types, AddrTypes include Praxis [43] are most signi�icant implementations of
data label relative to current POU (:rdlabel), global CPDev. Each subsystem involves a control processor,
or relative labels to code (:gclabel, :rclabel), I/O unit (units) and TFT touch‑panel (as in Fig. 11), all
array and structures indicated by ?ARRAY?NUM and of them equipped with ARM CPUs. CAN is applied for
?STRUCT?NUM (unique NUM). Flags involve: 1 – retain, communication with I/O and Ethernet (redundant)
4 – constant, 8 – variable with address de�ined by for TFT. The processor for controlling a setup com‑
AT, 0x4000 – global, 0x800000 – data channel. Other posed of diesel engine, electric generator and circuit
�lags may be de�ined. breaker is shown in Fig. 14. Praxis software is writ‑
ten in ST. TFT displays consist of components from
<VAR LName="IN" PName="RevSwitchST.IN" Addr="0000" user‑de�ined libraries. NMEA serial/Ethernet protocol
AdrType="gdlabel" Size="1" Type="BOOL" is used by marine electronic devices.
PType="$DEFAULT.BOOL" VarFlags="00004000" />
<VAR LName="OUT" PName="RevSwitchST.OUT" Addr="0001"
AdrType="gdlabel" Size="1" Type="BOOL"
PType="$DEFAULT.BOOL" VarFlags="00004000" />

Fig. 13. <VAR> entities in the DCP file

Depending on software solution, local or physical

names and addresses may be used by con�iguration
tools to bind variables to interfaces. The original pa‑
per [7] presented CPCon tool to interface remote I/Os
by means of physical data. Local data suf�iced to con‑
�igure SCADA InTouch for supervisory PC.
An OPC server can also be designed given XML DCP
�ile. In fact, simple server adapted from publicly avai‑
lable LightOPC [33] is built‑in into the CPDev softcon‑
troller.
�esides the DCP‑based con�iguration tool a few va‑
riables can be interfaced to dedicated external ports
by using native block concept (as in Java Native Inter‑
face or .NET Platform Invoke). It was originally descri‑
bed in [54] and applied for GPS module with NMEA se‑
rial communication. Native blocks are function blocks
written in C/C++ but, unlike typical function blocks,
they are deployed on the target platform as compo‑ Fig. 14. Power management processor [43]
nents of the VM, similarly as the target platform inter‑
face. To some extent they resemble hardware blocks Substation automation and medium voltage Grid
from multifunction instruments. Software algorithms control is provided by Remote Telecontrol Units
implemented as C/C++ native blocks are executed (RTUs) from iGrid T&D [24] shown in Fig. 15. RTUs
much faster than blocks written in IEC 61131‑3 lan‑ consist of ARM processor, I/O board and communi‑
guages (Sec. 5.2). cation interfaces for a number protocols including

80
80 Articles
Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°N°4 4 2019
2019

IEC 60870 and 61850 dedicated for power systems.

Documentation generation with complicated FBD and
LD diagrams is important. AUTHORS
Dariusz Rzońca∗ – Department of Computer and Con‑
trol Engineering, Rzeszow University of Technology,
ul. W. Pola 2, 35‑959 Rzeszow, Poland, e‑mail: dr‑
[email protected].
Jan Sadolewski – Department of Computer and
Control Engineering, Rzeszow University of Techno‑
logy, ul. W. Pola 2, 35‑959 Rzeszow, Poland, e‑mail:
[email protected].
Andrzej Stec – Department of Computer and Con‑
trol Engineering, Rzeszow University of Technology,
ul. W. Pola 2, 35‑959 Rzeszow, Poland, e‑mail: as‑
[email protected].
Zbigniew Świder – Department of Computer and
Control Engineering, Rzeszow University of Techno‑
logy, ul. W. Pola 2, 35‑959 Rzeszow, Poland, e‑mail:
[email protected].
Bartosz Trybus – Department of Computer and Con‑
trol Engineering, Rzeszow University of Technology,
ul. W. Pola 2, 35‑959 Rzeszow, Poland, e‑mail: btry‑
Fig. 15. Remote Telecontrol Unit [24] [email protected].
Leszek Trybus – Department of Computer and Con‑
Mini‑DCS system from LUMEL described in [7] trol Engineering, Rzeszow University of Technology,
was the �irst domestic implementation of CPDev �also ul. W. Pola 2, 35‑959 Rzeszow, Poland, e‑mail: ltry‑
found in Philippines [25]). StTr‑PLC controller from [email protected].
NiT [37] for control of communal facilities distributed ∗
Corresponding author
over large area, such as water supplies, heating stati‑
ons or sewage pumps, is another one. StTr‑PLCs are
monitored by GSM/GPRS integrated communication ACKNOWLEDGEMENTS
platform also used for mobile applications. Recently
developed PLC1 controller from BartCom [3] with lo‑ Help from Marcin Jamro a few years ago is ackno‑
cal or distributed I/Os �Modbus, Pro�ibus) is dedicated wledged.
for intelligent homes and general automation. This project is �inanced by the Minister of Science
and Higher Education of the Republic of Poland within
the ”Regional Initiative of Excellence” program for ye‑
8. Conclusions
ars 2019 – 2022. Project number 027/RID/2018/19,
Technical aspects of current features of CPDev total amount granted 11 999 900 PLN.
multi‑platform engineering environment have been
presented. The runtime is based on virtual machine REFERENCES
executing intermediate VMASM code into which ST
and IL programs are compiled. Programs written in [1] 3S‑Smart Software Solutions GmbH. “CODESYS”.
graphical languages are translated into ST. Parame‑ www.codesys.com. Accessed on: 2020‑02‑28.
trization of the compiler and VM for commonly used [2] Axel S.r.l. “Logiclab”. www.axelsoftware.it/
16‑ and 32‑bit addressing and for eventual restriction en/. Accessed on: 2020‑02‑28.
of data types is provided by the Library Con�igura‑ [3] Bart‑Com. www.bart-com.pl. Accessed on:
tion File. Implementations on diverse hardware plat‑ 2020‑02‑28.
forms are supported by prototypes of low‑level functi‑
ons introduced into the generic VM. HMI projects split [4] N. Bauer, R. Huuck, B. Lukoschus, and S. Engell.
into device‑independent and device‑dependent parts “A Unifying Semantics for Sequential Function
may be displayed by different devices. General pur‑ Charts”. In: H. Ehrig, W. Damm, J. Desel, M. Große‑
pose �ML �ile with compiler‑generated data on glo‑ Rhode, W. Reif, E. Schnieder, and E. Westkä mper,
bal variables support con�iguration of communicati‑ eds., �ntegration of Soft�are Speci�ication �echni‑
ons and I/Os. Native blocks may considerably decre‑ ques for Applications in Engineering: Priority Pro‑
ase the VM overhead. Implementations have shown gram SoftSpez of the German Research Founda‑
that equipment manufacturers themselves are able to tion (DFG), Final Report, Lecture Notes in Com‑
port the environment to relevant devices. puter Science, 400–418. Springer, Berlin, Heidel‑
Object‑oriented programming and moving the berg, 2004, 10.1007/978‑3‑540‑27863‑4_22.
multi‑project runtime into multi‑core processors, [5] S. Cavalieri, G. Puglisi, M. S. Scroppo, and
with each core executing a single project, are currently L. Galvagno, “Moving IEC 61131‑3 applicati‑
under investigation. ons to a computing framework based on CLR

81
Articles 81
 Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°
N°44 2019
2019

Virtual Machine”. In: 2016 IEEE 21st In‑ gies and Factory Automation (ETFA), vol. 1, 2018,
ternational Conference on Emerging Technolo‑ 1047–1050, 10.1109/ETFA.2018.8502464.
gies and Factory Automation (ETFA), 2016, 1–8, [18] Z. Hajduk, B. Trybus, and J. Sadolewski, “Archi‑
10.1109/ETFA.2016.7733632. tecture of FPGA Embedded Multiprocessor Pro‑
[6] M. Chmiel and E. Hrynkiewicz, “Concurrent ope‑ grammable Controller”, IEEE Transactions on In‑
ration of processors in the bit‑byte CPU of a PLC”, dustrial Electronics, vol. 62, no. 5, 2015, 2952–
Control and Cybernetics, vol. 39, no. 2, 2010, 559– 2961, 10.1109/TIE.2014.2362888.
579.
[19] P. E. Hart, N. J. Nilsson, and B. Raphael, “A For‑
[7] J. Cisek, W. Mikluszka, Z. Swider, and L. Try‑ mal Basis for the Heuristic Determination of Mi‑
bus, “A Low‑Cost DCS with Multifunction Instru‑ nimum Cost Paths”, IEEE Transactions on Systems
ments and CAN Bus1”, IFAC Proceedings Volumes, Science and Cybernetics, vol. 4, no. 2, 1968, 100–
vol. 34, no. 29, 2001, 64–69, 10.1016/S1474‑ 107, 10.1109/TSSC.1968.300136.
6670(17)32794‑5.
[20] L. Huang, W. Liu, and Z. Liu, “Algorithm of trans‑
[8] K. D. Cooper and L. Torczon, Engineering a formation from PLC ladder diagram to structu‑
Compiler, Morgan Kaufmann: Boston, 2012, red text”. In: 2009 9th International Conference
10.1016/C2009‑0‑27982‑7. on Electronic Measurement Instruments, 2009, 4–
[9] COPA‑DATA France. “STRATON–PLC”. www. 778–4–782, 10.1109/ICEMI.2009.5274701.
straton-plc.com. Accessed on: 2020‑02‑28. [21] ICS Triplex. “ISaGRAF”. www.isagraf.com.
[10] W. Dai, V. Vyatkin, J. H. Christensen, and V. N. Accessed on: 2020‑02‑28.
Dubinin, “Bridging Service‑Oriented Architec‑ [22] IEC. “IEC 61131‑3 – Programmable controllers –
ture and IEC 61499 for Flexibility and In‑ Part 3: Programming languages”, 2013.
teroperability”, IEEE Transactions on Industrial
[23] IEC. “IEC 61499 – Function Blocks”, 2012.
Informatics, vol. 11, no. 3, 2015, 771–781,
10.1109/TII.2015.2423495. [24] iGrid T&D. www.igrid-td.com. Accessed on:
2020‑02‑28.
[11] G. De Tommasi and A. Pironti, “An educational
open‑source tool for the design of IEC 61131‑3 [25] Instrument Science Systems, Inc. www.issi.
compliant automation software”. In: Automation com.ph/. Accessed on: 2020‑02‑28.
and Motion 2008 International Symposium on Po‑ [26] H. I. Inzunza Villagó mez, B. Pé rez Arce, S. I.
wer Electronics, Electrical Drives, 2008, 486–491, Herná ndez Ruiz, and J. A. Ló pez Corella, “De‑
10.1109/SPEEDHAM.2008.4581144. sign and implementation of a development en‑
[12] G. Fen and W. Ning, “A Transformation Algorithm vironment on ladder diagram (HT‑PLC) for Ar‑
of Ladder Diagram into Instruction List Based duino with Ethernet connection”. In: 2018 IEEE
on AOV Digraph and Binary Tree”. In: TENCON International Conference on Automation/XXIII
2006 ‑ 2006 IEEE Region 10 Conference, 2006, 1– Congress of the Chilean Association of Automa‑
4, 10.1109/TENCON.2006.343937. tic Control (ICA‑ACCA), 2018, 1–6, 10.1109/ICA‑
ACCA.2018.8609850.
[13] E. Ferreira, R. Paulo, C. D. Da, and P. Henriques,
“Integration of the ST language in a model‑based [27] M. Jamro, “POU‑Oriented Unit Testing of IEC
engineering environment for control systems: 61131‑3 Control Software”, IEEE Transactions on
An approach for compiler implementation”, Com‑ Industrial Informatics, vol. 11, no. 5, 2015, 1119–
puter Science and Information Systems, vol. 5, no. 1129, 10.1109/TII.2015.2469257.
2, 2008, 87–101, 10.2298/CSIS0802087F. [28] M. Jamro and D. Rzonca, “Agile and hierarchical
[14] J.‑Y. Fiset, Human‑machine interface design for round‑trip engineering of IEC 61131‑3 control
process control, Instrumentation, Systems, and software”, Computers in Industry, vol. 96, 2018,
Automation Society: Research Triangle Park, NC, 1–9, 10.1016/j.compind.2018.01.004.
2009. [29] M. Jamro, D. Rzonca, and W. Rząsa, “Testing com‑
[15] P. Gaj, J. Jasperneite, and M. Felser, “Compu‑ munication tasks in distributed control systems
ter Communication Within Industrial Distribu‑ with SysML and Timed Colored Petri Nets mo‑
ted Environment—a Survey”, IEEE Transactions del”, Computers in Industry, vol. 71, 2015, 77–87,
on Industrial Informatics, vol. 9, no. 1, 2013, 182– 10.1016/j.compind.2015.03.007.
189, 10.1109/TII.2012.2209668. [30] M. Jamro and B. Trybus, “IEC 61131‑3 program‑
[16] GEB Automation. “GEB IDE”. www. mable human machine interfaces for control de‑
gebautomation.com. Accessed on: 2020‑02‑28. vices”. In: 2013 6th International Conference on
[17] P. Gsellmann, M. Melik‑Merkumians, and G. Schit‑ Human System Interactions (HSI), 2013, 48–55,
ter, “Comparison of Code Measures of IEC 10.1109/HSI.2013.6577801.
61131–3 and 61499 Standards for Typical Au‑ [31] H. S. Kim, J. Y. Lee, and W. H. Kwon, “A com‑
tomation Applications”. In: 2018 IEEE 23rd In‑ piler design for IEC 1131‑3 standard langua‑
ternational Conference on Emerging Technolo‑ ges of programmable logic controllers”. In:

82
82 Articles
Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°N°4 4 2019
2019

SICE ’99. Proceedings of the 38th SICE An‑ [46] J. Richter, CLR via C#, Microsoft Press: Redmond,
nual Conference. International Session Papers Washington, 2012.
(IEEE Cat. No.99TH8456), 1999, 1155–1160, [47] D. Rzoń ca, J. Sadolewski, A. Stec, Z. S� wider, B. Try‑
10.1109/SICE.1999.788715. bus, and L. Trybus, “Mini‑DCS system program‑
[32] Y. Lee, J. Jeong, and Y. Son, “Design and imple‑ ming in IEC 61131‑3 structured text”, Journal of
mentation of the secure compiler and virtual ma‑ Automation Mobile Robotics and Intelligent Sys‑
chine for developing secure IoT services”, Fu‑ tems, vol. 2, no. 3, 2008, 48–54.
ture Generation Computer Systems, vol. 76, 2017, [48] S. Shin, M. Kwon, and S. Rho, “Whimori CDK:
350–357, 10.1016/j.future.2016.03.014. A Control Program Development Kit”. In:
[33] Light OPC Server. www.ipi.ac.ru. Accessed on: Engineering and Information 2009 Internatio‑
2020‑02‑28. nal Conference on Computing, 2009, 115–118,
10.1109/ICC.2009.33.
[34] D. Massonie, C. Hacker, and T. Sowa, “Modeling
Graphical and Speech User Interfaces with Wid‑ [49] H. Simon and S. Kowalewski, “Static analy‑
gets and Spidgets”. In: Speech Communication; sis of Sequential Function Charts using ab‑
11. ITG Symposium, 2014, 1–4. stract interpretation”. In: 2016 IEEE 21st In‑
ternational Conference on Emerging Technolo‑
[35] A. Milik, “Multiple‑Core PLC CPU Implementa‑ gies and Factory Automation (ETFA), 2016, 1–4,
tion and Programming”, Journal of Circuits, Sy‑ 10.1109/ETFA.2016.7733648.
stems and Computers, vol. 27, no. 10, 2018,
[50] T. Skripcak, P. Tanuska, U. Konrad, and
1850162, 10.1142/S0218126618501621.
N. Schmeisser, “Toward Nonconventional
[36] A. Milik and E. Hrynkiewicz, “Distributed PLC Ba‑ Human–Machine Interfaces for Supervisory
sed on Multicore CPUs ‑ Architecture and Pro‑ Plant Process Monitoring”, IEEE Transactions on
gramming”, IFAC‑PapersOnLine, vol. 49, no. 25, Human‑Machine Systems, vol. 43, no. 5, 2013,
2016, 1–7, 10.1016/j.ifacol.2016.12.001. 437–450, 10.1109/THMS.2013.2279006.
[37] Nauka i Technika. www.nit.pl. Accessed on: [51] VDI/VDE 3699 Process control using display
2020‑02‑28. screens, 2015.
[38] nxtControl GmbH. www.nxtcontrol.com/. [52] K. Thramboulidis, “A cyber–physical system‑
Accessed on: 2020‑02‑28. based approach for industrial automation sys‑
tems”, Computers in Industry, vol. 72, 2015, 92–
[39] M. Okabe, “Development of processor directly
102, 10.1016/j.compind.2015.04.006.
executing IEC 61131‑3 language”. In: 2008
SICE Annual Conference, 2008, 2215–2218, [53] E. Tisserant, L. Bessard, and M. de Sousa, “An
10.1109/SICE.2008.4655032. Open Source IEC 61131‑3 Integrated Develop‑
ment Environment”. In: 2007 5th IEEE Internati‑
[40] OMG. “OMG Systems Modeling Language, V1.3”, onal Conference on Industrial Informatics, vol. 1,
2012. 2007, 183–187, 10.1109/INDIN.2007.4384753.
[41] L. B. Palma, V. Brito, J. Rosas, and P. Gil, “WEB PLC [54] B. Trybus, “Development and Implementation
simulator for ST programming”. In: 2017 4th Ex‑ of IEC 61131‑3 Virtual Machine”, Theoretical
periment@International Conference (exp.at’17), and Applied Informatics, vol. 23, no. 1, 2011,
2017, 303–308, 10.1109/EXPAT.2017.7984410. 10.2478/v10179‑011‑0002‑z.
[42] C. G. Penteado, E. D. Moreno, and F. D. Pereira, [55] B. Venners, Inside the Java Virtual Machine,
“A microcontroller multicore in FPGAs: detailed McGraw‑Hill: New York, 1997.
architecture and case studies of embedded cri‑ [56] B. Vogel‑Heuser, D. Schü tz, T. Frank, and C. Legat,
tical applications”, International Journal of Grid “Model‑driven engineering of Manufacturing Au‑
and Utility Computing, vol. 8, no. 3, 2017, 169, tomation Software Projects – A SysML‑based ap‑
10.1504/IJGUC.2017.087815. proach”, Mechatronics, vol. 24, no. 7, 2014, 883–
[43] Praxis Automation Technology B.V. www. 897, 10.1016/j.mechatronics.2014.05.003.
praxis-automation.nl. Accessed on: 2020‑ [57] M. Zhang, Y. Lu, and T. Xia, “The Design and Im‑
02‑28. plementation of Virtual Machine System in Em‑
[44] L. Pé rez Cá ceres, F. Pagnozzi, A. Franzin, and bedded SoftPLC System”. In: 2013 International
T. Stü tzle, “Automatic Con�iguration of GCC Conference on Computer Sciences and Applicati‑
Using Irace”. In: E. Lutton, P. Legrand, P. Par‑ ons, 2013, 775–778, 10.1109/CSA.2013.185.
rend, N. Monmarché , and M. Schoenauer, eds., [58] C. Zhou and H. Chen, “Development of a PLC Vir‑
Arti�icial Evolution, Cham, 2018, 202–216, tual Machine Orienting IEC 61131‑3 Standard”.
10.1007/978‑3‑319‑78133‑4_15. In: 2009 International Conference on Measuring
[45] J. Quiroga and F. Ortin, “SSA Transformations to Technology and Mechatronics Automation, vol. 3,
Facilitate Type Inference in Dynamically Typed 2009, 374–379, 10.1109/ICMTMA.2009.422.
Code”, The Computer Journal, vol. 60, no. 9, 2017, [59] R. Zurawski, ed., Industrial Communication
1300–1315, 10.1093/comjnl/bxw108. Technology Handbook, Industrial information

83
Articles 83
 Journal
Journal of
of Automation,
Automation,Mobile
MobileRobotics
Roboticsand
andIntelligent
IntelligentSystems
Systems VOLUME
VOLUME 13,13, N°
N°44 2019
2019

technology series, CRC Press, Taylor & Francis

Group: Boca Raton London New York, 2015.

84
84 Articles