BULLETIN OF THE POLISH ACADEMY OF SCIENCES CONTROL AND INFORMATICS

TECHNICAL SCIENCES, Vol. 70(2), 2022, Article number: e140554

DOI: 10.24425/bpasts.2022.140554

Compiler and virtual machine of a multiplatform

control environment
Jan SADOLEWSKI and Bartosz TRYBUS ∗

Department of Computer and Control Engineering, Rzeszow University of Technology, ul. W. Pola 2, 35-959 Rzeszow, Poland

Abstract. Design and operation of a compiler and virtual machine, being the essential components of a multiplatform control programming
environment, are presented. The compiler translates source programs written in Structured Text language of the IEC 61131-3 standard into
executable code in a dedicated intermediate language. The virtual machine, i.e. a specially designed processor implemented in software, is a
runtime part of the environment executing the code in real time. Due to memory-to-memory operation principle the machine is able to process
various data types defined in the standard. The focus is given on overloading and extensibility of the functions, as well as on uniform invocations
of Program Organization Units. By selection of addressing mode, the environment can be deployed on multiple hardware platforms, beginning
from 8-bit microcontrollers up to 32/64-bit industrial PCs. Industrial applications are indicated.

Key words: control environment; IEC 61131-3 standard; intermediate language; compiler; runtime virtual machine.

1. INTRODUCTION duced in ISaGRAF [5] with an intermediate Target Independent

The IEC 61131-3 standard [1] on programming languages for Code. STRATON [6] also applies this approach although with-
control systems defines five languages, namely textual IL, ST, out disclosing details. Multiplatform applications, independent
graphical LD, FBD, and mixed SFC. Software environment im- from the target CPU, are benefits of the approach while less
plementing the standard in a particular controller consists of time efficiency due to operation of the VM itself is a disadvan-
two essential components, i.e. compiler and runtime. The com- tage.
piler translates a source program written in one of the IEC lan- For research reasons, the VM-based approach has been es-
guages (61131-3 dropped for brevity) into an executable code pecially interesting for academic community, initially with the
transferred to the runtime in the controller processor. The run- assembler-like IL as the intermediate language. In particular,
time executes the code in real time with a given cycle. compiler design involving translation of the four other IEC lan-
Three approaches to implementation of the standard are cur- guages to IL is described in [7]. Since IL instructions store re-
rently in use. The first one directly compiles the IEC programs sults in virtual registers, the authors stress importance of regis-
to processor code. Relatively uncomplicated runtime executes ter allocation by the compiler. A RISC processor executes the
the code quickly, so the approach is used mostly by established final code. A VM of [8] continuously decodes IL instructions
manufacturers. However, it is a single processor solution since and, if semantically correct, executes one after another. The ma-
change of CPU requires a new compiler. chine is written in C and runs on 8-bit CPU. An intermediate
The second approach involves compilation of IEC programs assembler-like language not tied up to IL is supported by a VM
to C/C++ and then another compiler translates it to the tar- of [9]. The VM has running stack and some x86-type registers.
get processor. Beremiz, a solution of academic origin, provides It is written in C and runs on embedded ARM as a SoftPLC.
capabilities to compile IEC projects to several hardware plat- Other solutions, close in fact to the second approach, apply
forms [2, 3]. GEB Automation [4] emphasizes educational ap- common intermediate languages such as Java or C#, followed
plications of its software by using open-source C/C++ compil- by ready-to-use Java Virtual Machine (JVM) or .NET Common
ers in the second step. Despite that the approach offers mul- Language Runtime (CLR). Multiple target platforms are thus
tiplatform applications, the industry often remains reluctant to enabled. In [10], ST and FBD programs are compiled to Java
the two-step toolchain and open-source compilers. bytecode transferred to embedded devices running the JVM.
The third approach is based on virtual machine (VM) con- Likewise in [11], one module of the environment compiles IEC
cept, i.e. an emulated abstract processor implemented in soft- projects into C# and another deploys them to CLR VMs in Win-
ware that executes certain intermediate code to which source dows or Linux. Java, C/C++ or Objective-C may be selected as
programs are compiled. The VM concept was originally intro- the intermediate language in a VM implementation for secure
Internet of Things [12].
∗ e-mail:
In addition to VMs implemented in software, a dedicated
[email protected]
runtime can also be designed in hardware, as demonstrated
Manuscript submitted 2021-07-30, revised 2022-01-08, initially in [13] for a Toshiba language processor. Nowadays hardware
accepted for publication 2022-01-25, published in April 2022. processors are typically designed in FPGA technology. For ex-

Bull. Pol. Acad. Sci. Tech. Sci., vol. 70, no. 2, p. e140554, 2022 1

© 2022 The Author(s). This is an open access article under the CC BY license (http://creativecommons.org/licenses/by/4.0/)
 J.Sadolewski and B.Trybus

ample, a PLC design as a System-on-a-Chip with IL as the na- mode for multiplatform implementations, and some universal C
tive language is described in [14]. code.
One may also add that a general purpose LLVM (initially The paper is organized as follows. The next section presents
Low-Level Virtual Machine) infrastructure provides a toolchain a concept of the intermediate language called Virtual Machine
framework to develop efficient compilers [15]. The LLVM is Assembler (VMASM). Section 3 describes the scanner and
an intermediate stage between the source code and the native parser with semantic validation, followed by an explanation
code of a target processor. To apply LLVM the source code, of nested POU invocations. Code generation involving digi-
originally in C or C++, must be converted into an intermediate tal identifiers of the VMASM instructions is presented in Sec-
representation (IR), which is a kind of a high-level assembler. tion 4. The identifiers express overloading and extensibility.
Then the LLVM compiles and optimizes such front-end to gen- VM architecture, operation algorithm, and exemplary C code
erate intermediate code in IR. Finally, the IR code is converted including automatic implementation of 16- or 32-bit addressing
into native code by a code generator (back-end) dedicated to a are described in Section 5. Two industrial implementations are
particular processor. Adaptation of the Beremiz front-end [2, 3] reviewed in Section 6. The last section summarizes the paper.
to create LLVM compilers of IEC languages has been described
in [16] recently.
Working with a few colleagues, the authors of this paper 2. CONCEPT OF THE INTERMEDIATE LANGUAGE
began developing a control programming environment named The choice of how the virtual machine is going to operate deter-
CPDev (Control Program Developer) over 10 years ago, as- mines the VMASM language. A memory-to-memory operation
suming initially that it would not be restricted to any particu- principle is chosen due to numerous data types. This principle
lar processor or hardware solution. This excluded the first of and the extensibility of some IEC functions determine the syn-
the three approaches indicated above. The second approach, al- tax of the VMASM instructions. Assuming control orientation
though appropriate for teaching and research, suffers in the case of the VM, one part of the instructions consists of direct coun-
of industrial applications. Therefore, the third approach involv- terparts of the IEC standard functions, whereas the other part
ing a custom-designed VM remained an appropriate choice. involves assembler-like jumps, memory copying, subprogram
In the proposed solution the intermediate code generated by calls, etc., called system procedures.
the compiler is portable, so there is no need to generate the na-
tive code or LLVM back-end separately for each type of the 2.1. Expression tree
target processor or architecture. This is advantageous in dis- Various sizes and types of IEC data imply that it would be dif-
tributed systems involving controllers with various processors ficult to design a conventional accumulator- or register-based
where portable intermediate code can be generated and de- architecture of the VM. The difficulty may be overcome by
ployed by the same tool. Since the layout of the code and data in choosing an architecture based on memory-to-memory opera-
memory is identical for all targets, debugging is unified as code tion principle, which means that the result of instruction exe-
interpretation is the same in the simulator, debugger and the tar- cution is directly uploaded into the memory. Such a solution
get controller. The disadvantages compared to native compilers avoids the register scarcity problem already encountered in [7].
or LLVM-based solutions are the significantly longer execution As an introductory example, consider control of a MOTOR
time of the programs interpreted by the virtual machine and turned on after pressing START, and turned off after pressing
necessity of development of custom compilation, optimization STOP or when an ALARM appears. The corresponding ST assign-
and debugging tools. ment may have the form
To enable complex programming, the textual ST was selected MOTOR := (START OR MOTOR) AND NOT (STOP OR ALARM);
as the first language supported by the CPDev environment.
A tree representing the expression on the right side is shown in
Graphical diagrams in LD, FBD, and SFC are translated to their
Fig 1.
textual representation in ST and then compiled. IL programs are
executed after converting to the portable code. The original and
AND
last versions of CPDev are described in [17] and [18], respec-
tively. Petri-net models of the VM and a list of prototype func-
OR NOT
tions to handle general target hardware can be found in [19].
The VM source code for some popular platforms is available in
the public repository at [20]. START MOTOR OR
The available literature on environments and tools for IEC
programming and runtime, including [17–19], reports on gen- STOP ALARM
eral characteristics, functionalities, and implementations rather
Fig. 1. Expression tree for the MOTOR example
than how the environments have been created. Therefore, the
novelty of this paper rests in the presentation of solutions ap-
plied in CPDev compiler and virtual machine to such issues Let the identifiers of ST variables and IEC functions AND, OR,
as overloading and extensibility of IEC functions, components NOT, etc. remain unchanged in the VMASM language. Notice
of semantic validation of the parsed code, nested invocations that processing the tree will require some additional compiler-
of POUs (Program Organization Units), selection of addressing generated variables. They can be distinguished from the ST

2 Bull. Pol. Acad. Sci. Tech. Sci., vol. 70, no. 2, p. e140554, 2022
 Compiler and virtual machine

ones by including a symbol not admitted in ST, for instance [17, 19]. The total of 45 procedures can be divided into the fol-
question mark ? placed at the beginning. So ?R1 may mean a lowing groups:
result of the first OR in Fig. 1. If needed, another ? may appear • jumps (8), • arrays and pointers (17),
somewhere inside such identifier. • subprograms (6), • assertions (3),
Due to the memory-to-memory operation, the result ?R1 • initializations (5), • other (5).
must appear on the operand list of the first OR, either at the end • copying (4),
or at the beginning. However, since OR is an extensible function, The subprogram group includes CALB (CALL-program-
placing the result at the end would make its memory location Block) and RETURN instructions that handle invocations of
dependent on the number of operands, whereas the beginning POUs. Assertions are used for debugging.
provides a convenient constant location. Hence the instruction Note that the intermediate language of [9] consists of 54 in-
implementing the first OR may look as follows structions with 0, 1 or 2 operands, including boolean, mathe-
matical, bit and other operations. These are executed here by
OR ?R1, START, MOTOR the IEC function counterparts.
Recall that for example the x86 assembler also places instruc-
tion results at the beginning of operand list [21]. 3. COMPILER
Scanner and parser involving semantic validation transform an
2.2. VMASM syntax ST project into VMASM mnemonic code. User-defined func-
Besides the compiler-generated variables, labels for jump in- tions, function blocks, and programs are invoked in a uniform
structions are also needed. Therefore the syntax of the VMASM way.
instructions has the form
[:label] instruction [operand0] [, operand1] 3.1. Scanner and parser
[, operand2] ... The compiler converts an XML source file with an ST project
into an executable VMASM file in the hexadecimal format. Di-
The label is optional, number of operands depends on in- agram of the compiler operation is shown in Fig. 3.
struction, although it is limited to 16 for practical reasons. In
the case of a function like OR the operand0 means a result, ST source SCANNER
ST source Token list
while in the direct jump JMP it will be a label. The label itself, XML file Token list
XML file
as a compiler-generated identifier, has the question mark ? right PARSER
after the colon. Thus, :?L1 may be an example of the label. Semantic validation
Coming back to the MOTOR example, VMASM mnemonic Mnemonic Executable
Mnemonic CODE Executable
code implementing the expression tree of Fig. 1 may look as in VMASM code GENERATOR hex file
VMASM code hex file
Fig. 2. JZ is the common Jump-if-Zero, whereas MCD (Memory-
Copy-Data) copies the given number of data bytes (operand1)
Fig. 3. Components of the ST-to-VMASM compiler
and the content (operand2) to the result (operand0). Notice
that if the result ?R1 of the first OR is 0 then the following JZ
jumps to :?L1 to set MOTOR to 0, thus abandoning five sub- The scanner analyzes character stream from the source file
sequent instructions. This is an example of the so-called lazy and decomposes it into lexical tokens classified into categories
evaluation of an expression when a partial outcome indicates such as identifiers, keywords, operators, constants, etc. The to-
the final result [22]. The compiler presented here translates ST kens with categories are collected on a list passed to the parser.
expressions for lazy evaluation. After checking whether the tokens contain valid characters
only, the parser proceeds with a top-down syntax-directed trans-
OR ?R1, START, MOTOR lation [23] by grouping the tokens into constructs according to
JZ ?R1, :?L1 ST language grammar. If the constructs are correct the parser
OR ?R2, STOP, ALARM builds an internal abstract syntax tree.
NOT ?R3, ?R2 In the next phase the tree is semantically validated with re-
JZ ?R3, :?L1 spect to variables, expressions, invocations, and nesting [3, 24]
MCD MOTOR, 1, 1 by performing the following checks:
JMP :?L2 • variables: declaration before usage, visibility in the POU
:?L1 MCD MOTOR, 1, 0 context, consistency of data type and initial value,
:?L2 ... • expressions: compatibility of operators and operand data
types,
Fig. 2. Translation of the MOTOR example • invocations: declaration of POU in the project or library,
number of operands and their types consistent with POU
interfaces, user-defined function cannot invoke function
2.3. System procedures blocks,
As indicated before, the VMASM instructions consist of IEC • nesting: nested IFs and invocations must follow the recur-
function counterparts and assembler-like system procedures sive order.

Bull. Pol. Acad. Sci. Tech. Sci., vol. 70, no. 2, p. e140554, 2022 3
 J.Sadolewski and B.Trybus

Having the validated tree the parser replaces the ST con- ters with code and data address pointers, called code and data
structs with sets of mnemonic VMASM instructions like the registers for brevity. The type :rdlabel (relative-data-label) of
ones in Fig. 2. To do so it employs the built-in elementary data InstPtr above means an address in the data memory relative
types and the list of instructions. Some translations require in- to the content of the data register, whereas :gcdlabel (global-
troduction of additional variables and labels. An expression in- code-label) of FunBlockAddr is a direct address (global) in the
volving operators is first transformed into a subtree and then code memory. Stack emulation mechanism triggered by CALB
an appropriate routine converts it into VMASM code. Multi- pushes the registers on corresponding stacks. RETURN pulls the
element types such as arrays and structures, and POUs acquired stacks.
from libraries are also parsed. Finally the code is consolidated In the case of a user-defined function, the data memory ad-
with other mnemonic codes and written in a special text format. dress of the operating area for local variables must be the same
for all invocations of the function. The address is jointly indi-
3.2. Classes of the internal data cated by the relative InstPtr and the data register.
Basic elements of the compiler are designed as classes Each program executed by the VM must be able to access
in the C# language. The scanner generates objects of the global variables. Let 0 (zero) be the beginning address of the
BasicToken class. The ST tokens acquired by the parser area for the global variables and let the data register content
become objects of relevant classes such as STVariable, while invoking a program be also 0. Hence the invocation of a
STFunctions, STLibrary, etc. The classes inherit from an ab- program accessing the global variables may have the form
stract STIdentifier class.
CALB 0, ProgramAddr
The mnemonic instructions passed from the parser to
the code generator are represented by instances of the Since the invoked program ends up with RETURN, the next
VMInstruction class. The VMOperand list is a field in this program will be also called with the zero data register.
class. For the program invocation as above, code of a task that
During compilation, object identifiers are collected on appro- cyclically executes some programs PRG1, PRG2, ... may have
priate lists. So there is a list of global identifiers, lists of local the form shown in Fig. 4.
identifiers for POUs, etc. By applying predictors to find identi-
fiers on the lists the cumbersome hash tables are avoided. :?TSK1 CALB 0, :?PRG1?CODE
CALB 0, :?PRG2?CODE
3.3. POU invocations and tasks ...
Invocations of all POU types, i.e. user-defined functions, TRML :?TSK1
function blocks, and programs are executed by the same
CALB. . . RETURN pairs. A single call has the form Fig. 4. Code of the task loop
CALB InstPtr, FunBlockAddr
where InstPtr denotes an instance and FunBlockAddr an ad- The TRML instruction defined in Table 1 terminates the task.
dress of the POU code, here indicating a function block. Defi- Its AddressStart indicates the starting point used by the run-
nitions of CALB, RETURN, and two other instructions are in Ta- time when the task is resumed, i.e. the label :?TSK1 is Fig. 4.
ble 1. A task can be executed in one of three modes:
• cyclic – as a loop with constant cycle time,
Table 1
Definitions of three VMASM procedures and OR function
• continuous – loop with next execution resumed immedi-
ately,
<sysproc name="CALB" vmcode="1C16"> • triggered – execution when a condition is met.
<op no="0" name="inst" type=":rdlabel"/> A control project may involve a loop task and several single
<op no="1" name="clbl" type=":gclabel"/> execution tasks triggered by some events.
</sysproc> Before resuming a task the TRML instruction activates exe-
cution of the VM internal code dependent on implementation.
<sysproc name="RETURN" vmcode="1C13"> Typically it involves I/O handling, communications, and test-
</sysproc>
ing [19]. When the internal code is completed, AddressStart
<sysproc name="TRML" vmcode="1C1D">
is fetched to the code register and VM begins execution of the
<op no="0" name="AddressStart" type=":gclabel"/> task.
</sysproc>
3.4. Example with function blocks
<function name="OR" vmcode="09*0" return="BOOL"> The MOTOR control of Section 2 will now be implemented by
<op no="*" name="arg*" type="BOOL"/> means of two nested function blocks according to the diagram
</function> of Fig. 5a. The PRG program invokes an instance SS1 of a user-
defined function block SS which nests the OR function and an
Although the VM architecture will be explained only later instance RS1 of the standard RS flip-flop. Implementation in the
in Section 5, it is now indicated that the VM contains regis- CPDev environment as a project PRO in which the PRG program

4 Bull. Pol. Acad. Sci. Tech. Sci., vol. 70, no. 2, p. e140554, 2022
 Compiler and virtual machine

PRG program
a) b)
SS → SS1

RS → RS1
START IN1 S Q1 OUT MOTOR
STOP IN2 R1
OR
ALARM IN3

Fig. 5. a) Diagram of the example; b) implementation in the CPDev environment

is executed by the task TSK is shown in Fig. 5b. Global variables A vmcode is a two-byte entity composed of the group ig
START, STOP, etc. are imported by the (*$AUTO*) directive. and type it components shown in Fig. 6. In the case of a func-
The IEC_61131 library includes the RS flip-flop. tion, ig denotes the name of an overloaded group, such as OR,
Mnemonic instructions of the TSK loop and the ones im- NOT, ADD, etc., whereas it specifies the number num of input
plementing nesting by means of CALBs are shown in Table 2 operands and return type. By changing it the specific func-
(project name PRO begins the labels). The dropped code is char- tions of the overloaded group are selected. An asterisk * as
acterized in comments with final RETURNs. num indicates extensible number of inputs, as in the case of
vmcode=09*0 for OR (09) that returns BOOL (0) (Table 1). As
Table 2 another example, NOT (05) for one (1) WORD operand (4) has
Function block nesting in the mnemonic code vmcode=0514. System procedures such as JMP, CALB, RETURN,
etc. belong to one group ig=1C and are also selected by it.
Entity Mnemonics for nested POUs
:?PRO.TSK?TSKLOOP vmcode
TSK CALB #0000, :?PRO.PRG?CODE
ig it
TRML :?PRO.TSK?TSKLOOP
group num type
:?IEC_61131.RS?CODE
... /* RS code, RETURN */ Fig. 6. Digital identifier of a function
RS1 :?PRO.SS?CODE
... /* S:=IN1, R1:=OR(IN2, IN3) */ 4.2. Memory allocation
CALB RS1, :?IEC_61131.RS?CODE Besides the instructions, the LCF file also specifies particular
SS1
... /* OUT:=Q1, RETURN */ implementation by size of the address equal to two or four
:?PRO.PRG?CODE bytes (16- or 32-bit addressing). Since the vmcode consists of
... /* IN1:=START, ... */ two bytes, so the code memory section occupied by a single
CALB SS1, :?PRO.SS?CODE instruction with n operands is either 2+n*2 or 2+n*4 bytes, re-
PRG ... /* MOTOR:=OUT, RETURN */ spectively.
To make allocation of operating areas in the data memory to
POUs easier to verify during debugging it is assumed that each
area must be a multiple of a standard segment. The size of the
4. EXECUTABLE CODE segment equals the size of the longest elementary data which
After scanning and parsing the code generator converts the con- may be a single operand. So it is 8 bytes, as for LREAL or
solidated mnemonic code into the executable hexadecimal file DATE_AND_TIME. The operating areas are determined at the
(Fig. 3). Digital identifiers of the VMASM functions take into final stage of parsing.
account overloading and extensibility. When a POU is invoked during execution the stack mech-
anism automatically increases the data register by the size of
4.1. Code generator relevant operating area. Nested invocations enlarge this register
The generator replaces instruction mnemonics by correspond- accordingly.
ing digital identifiers and addresses of operands or constants.
To do so, the generator employs a Library Configuration File 4.3. Remarks on hexadecimal code
(LCF) with instruction definitions as the ones in Table 1, where Because the POUs of the exemplary project use only a few
the vmcodes denote digital identifiers. BOOL variables, the operating areas of standard eight bytes

Bull. Pol. Acad. Sci. Tech. Sci., vol. 70, no. 2, p. e140554, 2022 5
 J.Sadolewski and B.Trybus

suffice for each of them. So when the PRG program invokes the and pointers supports invocations of POUs. The target platform
block SS1, the data register is increased to 8, and when SS1 sub- interface involves low-level functions dependent on hardware
sequently invokes the RS1 flip-flop it is farther increased to 16. platform and operating system [19].
Hence the global variables START to MOTOR of the project are The code register, in other words instruction pointer, contains
assigned the addresses 0 to 3, the interface variables INT to OUT addresses of instructions and operands. The data register (data
of SS1 the addresses 8 to 11, and S,R1,Q1 of RS1 the addresses pointer) keeps the base address of the POU operating area for
16, 17, 18. relative addressing. The task cycle length register indicates the
Hexadecimal representations of two initial instructions from time till the end of the cycle. The flags register contains status
Table 2, for instance placed by the compiler at the addresses flags for operating modes, errors, and unusual events.
:001E and :0024 (hex), respectively, are as follows The components can be implemented in 16- or 32-bit ver-
CALB :001E 1C16 0000 9200
sions, depending on the maximum size of code and data memo-
TRML :0024 1C1D 1E00 ries (64 kB vs. 4 GB). So a VM for a given hardware is specified
by the size of address in the LCF configuration file and the tar-
The lines begin with the vmcodes from Table 1. The subse- get platform interface.
quent addresses are in the little endian form, so 1E00 in TRML
means :001E in the preceding CALB. Likewise 9200 in CALB 5.2. Instruction processing
means the address :0092 allocated to :?PRO.PRG?CODE (Ta- Each line of the executable code acquired by the instruction
ble 2). processing module begins with vmcode composed of the group
and type identifiers ig and it (bytes). An algorithm for pro-
cessing a single line is shown in Fig. 8. Assuming that the code
5. VIRTUAL MACHINE register initially points out to the vmcode, the algorithm be-
Architecture of the virtual machine reflects the memory-to- gins with fetching ig and it followed by incrementations of the
memory operation. By means of the group and type identifiers code register. After that the register points to the first operand
selected from the vmcode, a proper instruction is acquired and of the instruction.
processed. According to the length of addresses the VM can be
deployed in 8, 16 or 32/64-bit platforms.

5.1. Architecture
The VM software-implemented architecture shown in Fig. 7 in-
volves Harvard separate code and data memories, instruction
processing module, code and data stacks, registers and pointers,
and a target platform interface. The instruction processing mod-
ule fetches the instructions from the code memory, executes
them acquiring the operands from data or code memories and,
in case of the functions, stores the results in the data memory.
Assembler-like system procedures change internal state of the
VM components. Stack mechanism composed of the two stacks

Fig. 8. Algorithm for processing single line of code

The following part matches the group identifier ig to partic-

ular group of functions or to procedures. In the case of a func-
tion the algorithm matches it to relevant type and executes the
code. The procedures and type conversions are selected by it.
Implementation of the algorithm in C is fairly straightforward
Fig. 7. Architecture of the virtual machine by means of the switch() statements.

6 Bull. Pol. Acad. Sci. Tech. Sci., vol. 70, no. 2, p. e140554, 2022
 Compiler and virtual machine

5.3. Addresses and instructions in C recognizes particular type by masking it&0x0F (see Fig. 6) and
Let unsigned short ADDRESS or unsigned long switches to execution by ADD_TYPE. Here the shift it>>4 ac-
ADDRESS define 16- or 32-bit implementation of the VM quires the number num of inputs and implements the adding in
according to the LCF file. Suppose the code register points a loop (not shown). Note that the ADD_TYPE definition retains
out to an operand of instruction, initially to the first one. case and break for the switch from IG_ADD_01. 0x000F in
GetCodeAddress function shown in Fig. 9 transforms the case indicates that up to 16 IEC data types can be processed
standard byte pointer *CodeMemory[CodeReg] into *ADDRESS by ADD.
pointer and copies the content into a 16- or 32-bit variable addr All system procedures from the group ig=1C are handled
being returned. The code register is incremented accordingly by the function IG_SYSPROC_1C outlined in Fig. 11, with self-
to point out to the next operand. explanatory CALB shown only.

ADDRESS GetCodeAddress(void) void IG_SYSPROC_1C(BYTE it)

{ {
ADDRESS addr = switch(it)
(*(ADDRESS*)(CodeMemory[CodeReg])); {
CodeReg += sizeof(ADDRESS); ...
return addr; case 0x16: /* CALB call a function block */
} {
ADDRESS instaddr =
dataReg + GetCodeAddress();
Fig. 9. Getting the operand address ADDRESS clbl = GetCodeAddress();
push_CodeStack(codeReg);
push_DataStack(dataReg);
If the operand means a label or an immediate value then its dataReg = instaddr;
address in the code memory is acquired by codeReg = clbl;
}
ADDRESS operand = GetCodeAddress(); break;
...
However, if the operand is a variable or a POU instance then }
the sum return;

ADDRESS operand = DataReg + GetCodeAddress(); Fig. 11. System procedure group with CALB
involving the data register gives a global address in the data
memory.
An overloaded function may be implemented by calling a 6. IMPLEMENTATIONS
single C function for all relevant data types to avoid repetitions The original CPDev environment was implemented for the first
of rather similar code. In turn that single function may call a time by Lumel [25] in a small distributed control system de-
code macrodefinition parametrized with respect to type to exe- scribed in [17, 19]. The system involved 8-bit AVR processor
cute calculations. and several remote I/O modules with serial Modbus communi-
An example of IG_ADD_01 function that implements the cation. The system is still installed by ISS [26], Philippines.
overloaded extensible ADD is shown in Fig. 10. The function Ship navigation and automation systems from Praxis [27],
the Netherlands, are the most significant implementations of
void IG_ADD_01(BYTE it) the environment, providing for over decade continuing moti-
{
switch (it & 0x0F) vation for further development. Propulsion control (Fig. 12a,
{ version for yachts and small ships), power management, head-
ADD_TYPE(SINT); ing control (autopilot), and a few other systems are connected
ADD_TYPE(INT);
to the ship main computer by redundant Ethernet. Each sys-
ADD_TYPE(DINT);
ADD_TYPE(LINT); tem consists of a control processor, I/O units, and a TFT touch
... /* other types */ panel, each of them equipped with 32-bit ARMs. CAN is ap-
} plied for communication with I/O units and Ethernet (redun-
return;
}
dant) for TFT panels. TFT displays are integrated with con-
trol software by means of global variables. NMEA serial/Ether-
#define ADD_TYPE(TYPE) \ net protocol is used by marine electronic devices. Programs are
case IT_ADD_##TYPE & 0x000F: \ written in ST language.
{ \
BYTE num = it >> 4; \
Remote telecontrol units (Fig. 12b) from iGrid [28], Spain,
... are applied for substation automation, medium voltage con-
} \ trol, and grid reconfiguration by means of triggered-mode tasks.
break; A unit involves an ARM processor, I/O board, and a few com-
munication interfaces including IEC 60870 and 61850 dedi-
Fig. 10. Outline of the ADD implementation cated for power systems. LD and FBD languages are preferred.

Bull. Pol. Acad. Sci. Tech. Sci., vol. 70, no. 2, p. e140554, 2022 7
 J.Sadolewski and B.Trybus

a) b)

Fig. 12. a) Propulsion Control System [27]: control processor with I/O (left) and communication terminals (bottom), lever
with TFT 2.5" operator panel; b) Remote Telecontrol Unit [28]

Some information on runtime for complex software involv- ges,” European Committee for Electrotechnical Standardization,
ing several cooperating VMs running with different cycles and Tech. Rep, 2013.
on domestic implementations can be found in [18]. The run- [2] Beremiz integrated development environment. [Online]. Avail-
time is called WinController and runs on 32/64-bit industrial able: www.beremiz.org (Accessed 2021-11-24).
PC with Windows Embedded OS. [3] E. Tisserant, L. Bessard, and M. de Sousa, “An Open Source
IEC 61131-3 Integrated Development Environment,” in IEEE
Int. Conf. on Ind. Inform., 2007, pp. 183–187, doi: 10.1109/ IN-
DIN.2007.4384753.
7. CONCLUSION [4] GEB Automation, GEB Automation IDE Guide. [Online]. Avail-
The paper has presented solutions applied in the compiler and able: www.gebautomation.org (Accessed 2021-11-24).
virtual machine of the CPDev control environment to a few is- [5] Rockwell Automation, ISaGRAF Workbench. [Online]. Avail-
sues related to the IEC standard, namely overloading and ex- able: www.isagraf.com (Accessed 2021-11-24).
tensibility, semantic verification, nested invocations, selection [6] COPA-DATA France, STRATON. [Online]. Available: www.
of addressing mode, and outline of some code. Standard IEC straton-plc.com (Accessed 2021-11-24).
functions are built into the VMASM language. [7] H.S. Kim, J.Y. Lee, and W.H. Kwon, “A compiler design for
IEC 1131-3 standard languages of programmable logic con-
The platform-independent code generated by the compiler
trollers,” in SICE’99 Ann. Conf., 1999, pp. 1155–1160, doi:
facilitates deployment on a variety of hardware, from 8-bit mi- 10.1109/SICE.1999.788715.
crocontrollers to 32/64-bit industrial PCs. [8] C. Zhou and H. Chen, “Development of a PLC Virtual Ma-
chine Orienting IEC 61131-3 Standard,” in Int. Conf. Meas.
Tech. and Mechatr. Autom., vol. 3, 2009, pp. 374–379, doi:
ACKNOWLEDGEMENTS 10.1109/ICMTMA.2009.422.
Contribution of D. Rzońca, A. Stec, Z. Świder and L. Trybus to [9] M. Zhang, Y. Lu, and T. Xia, “The Design and Implementa-
development of the CPDev environment is acknowledged. tion of Virtual Machine System in Embedded SoftPLC System,”
This project is financed by the Minister of Education and Sci- in Int. Conf. Computer Sci. and Appl., 2013, pp. 775–778, doi:
10.1109/CSA.2013.185.
ence of the Republic of Poland within the “Regional Initiative
[10] M. Simros, M. Wollschlaeger, and S. Theurich, “Programming
of Excellence” program for years 2019–2022. Project number embedded devices in IEC 61131-languages with industrial PLC
027/RID/2018/19, amount granted 11 999 900 PLN. tools using PLCopen XML,” in CONTROLO’2012 Portug. Conf.
Autom. Control, 2012, pp. 51–56.
[11] S. Cavalieri, G. Puglisi, M.S. Scroppo, and L. Galvagno, “Mov-
REFERENCES ing IEC 61131-3 applications to a computing framework based
[1] International Electrotechnical Commission, “EN 611313:2013 on CLR Virtual Machine,” in IEEE 21st Int. Conf. Emerg. Techn.
– Programmable controllers – Part 3: Programming langua- Fact. Autom., 2016, pp. 1–8, doi: 10.1109/ETFA.2016.7733632.

8 Bull. Pol. Acad. Sci. Tech. Sci., vol. 70, no. 2, p. e140554, 2022
 Compiler and virtual machine

[12] Y. Lee, J. Jeong, and Y. Son, “Design and implementation of [19] B. Trybus, “Development and Implementation of IEC 61131-3
the secure compiler and virtual machine for developing secure Virtual Machine,” Theoret. Appl. Informatics, vol. 23, no. 1, pp.
IoT services,” Future Generation Computer Systems, vol. 76, pp. 21–35, 2011.
350–357, 2017, doi: 10.1016/j.future.2016.03.014. [20] CPDev VM public sources. [Online]. Available: https://github.
[13] M. Okabe, “Development of processor directly executing IEC com/CPDev-ControlProgramDeveloper (Accessed 2021-11-24).
61131-3 language,” in SICE’08 Ann. Conf., 2008, pp. 2215– [21] K.R. Irvine, Assembly language for X86 processors (Eigth edi-
2218, doi: 10.1109/SICE.2008.4655032. tion). Hoboken: Pearson, 2018.
[14] P. Mazur, R. Czerwinski, and M. Chmiel, “PLC implementa- [22] F.A. Turbak and D.K. Gifford, Design Concepts in Programming
tion in the form of a System-on-a-Chip,” Bull. Pol. Acad. Sci. Languages. The MIT Press, 2008.
Tech. Sci., vol. 68, no. 6, pp. 1263–1273, 2020, doi: 10.24425/b- [23] K.D. Cooper and L. Torczon, Engineering a Compiler (Second
pasts.2020.135386. Edition). Boston: Morgan Kaufmann, 2012.
[15] LLVM Compiler Infrastructure. [Online]. Available: www.llvm. [24] E. Ferreira, R. Paulo, D. Cruz, and P. Henriques, “Integration of
org (Accessed 2021-11-24). the ST Language in a Model-Based Engineering Environment
[16] T. Catalão and M. de Sousa, “IEC 61131-3 Front-End for the for Control Systems – An Approach for Compiler Implemen-
LLVM Compiler Family,” in 25th Int. Conf. Emerg. Techn. tation,” Comp. Sci. and Inform. Sys., vol. 5, no. 2, pp. 87–101,
Fact. Autom., vol. 1, 2020, pp. 1191–1194, doi: 10.1109/ 2008, doi: 10.2298/CSIS0802087F.
ETFA46521.2020.9211921. [25] Lumel S.A. [Online]. Available: www.lumel.com.pl (Accessed
[17] D. Rzońca, J. Sadolewski, A. Stec, Z. Świder, B. Trybus, and 2021-11-24).
L. Trybus, “Mini-DCS system programming in IEC 61131-3 [26] Instrument Science Systems. [Online]. Available: www.issi.com.
Structured Text,” JAMRIS, vol. 2, no. 3, pp. 48–54, 2008. ph (Accessed 2021-11-24).
[18] D. Rzońca, J. Sadolewski, A. Stec, Z. Świder, B. Trybus, [27] Praxis Automation Technology. [Online]. Available: www.pra
and L. Trybus, “Developing a multiplatform control environ- xis-automation.nl (Accessed 2021-11-24).
ment,” JAMRIS, vol. 13, no. 4, p. 73–84, 2019, doi: 10.14313/ [28] iGrid T&D. [Online]. Available: www.igrid-td.com (Accessed
JAMRIS/4-2019/40. 2021-11-24).

Bull. Pol. Acad. Sci. Tech. Sci., vol. 70, no. 2, p. e140554, 2022 9