Conference PaperPDF Available

Programming embedded devices in IEC 61131-languages with industrial PLC tools using PLCopen XML

Authors:

Abstract

Application development for industrial embedded devices is often a device-specific task. In contrast, PLC programming is performed using standard industrial programming suites using IEC 61131. Using these suites for programming embedded devices would help to reuse existing applications and engineering concepts and opens an easy way for prototyping and learning. This paper describes a concept for adopting IEC 61131 programming suites and the PLCopen standard export format as input for the device-specific tool chain. In order to address interoperability, a variable-independent IO data mapping using service-interface blocks derived from IEC 61499 has been developed. An evaluation was performed on LEGO R Mindstorms for proving feasibility.
PROGRAMMING EMBEDDED DEVICES IN
IEC 61131-LANGUAGES WITH INDUSTRIAL PLC
TOOLS USING PLCOPEN XML
Markus Simros Stefan Theurich Martin Wollschlaeger
Technische Universit¨
at Dresden,
Institute for Applied Computer Science, Industrial Communications,
markus.simros@mailbox.tu-dresden.de,
stefan.theurich@tu-dresden.de,
martin.wollschlaeger@tu-dresden.de
Abstract: Application development for industrial embedded devices is often a device-specific
task. In contrast, PLC programming is performed using standard industrial programming
suites using IEC 61131. Using these suites for programming embedded devices would help to
reuse existing applications and engineering concepts and opens an easy way for prototyping
and learning. This paper describes a concept for adopting IEC 61131 programming suites
and the PLCopen standard export format as input for the device-specific tool chain. In
order to address interoperability, a variable-independent IO data mapping using service-
interface blocks derived from IEC 61499 has been developed. An evaluation was performed
on LEGO R
Mindstorms for proving feasibility.
Keywords: Programming approaches, Programmable logic controllers, Control enginering,
PLCopen XML, Code converters, Control education, Programming environments
1. INTRODUCTION
Programming PLC systems using standard industrial pro-
gramming languages according to IEC 61131-3 has be-
come widely accepted during the last decade. This ap-
proach should be extended to the application develop-
ment for embedded systems. Thus, this paper focuses
on an approach for using industrial tools directly for
programming embedded devices. The idea is to use only
one library, which contains all device specific function
blocks. This should be sufficient to write programs in
any IEC 61131 tool and is the only part, which has to
be exchanged when replacing the target device.
With PLCopen XML there is a standard exchange for-
mat developed for interoperability and exchangeability
of IEC 61131 projects. As a tool-spanning data format
it opens the feasibility for using it as an universal in-
terface to existing tool chains. It can be used beside the
aforementioned library as the only input for a specific
compiler which generates the code for a selected target
device. Special attention has been paid to the mapping of
process data. Since the use of variables according to IEC
61131 is not possible, interface function blocks have been
developed instead. This abstraction layer for hardware
specific aspects enhances the object oriented approach of
the IEC 61131. Thus code reuse will be more familiar.
Based on the mentioned aspects, software development
becomes independent of process mapping and device
specific configuration files. Programmers can focus on
the algorithm and control development. Device specific
knowledge is outsourced into the block library and can
be substituted, every time a new target device should be
programmed. Additionally, the use of embedded devices
opens new ways of prototyping, testing and teaching au-
tomation control systems. The paper describes the con-
cepts of IO mapping and XML processing. And it pro-
vides an evaluation of IEC 61131-3 tools focused on the
aspect of PLCopen XML export. An evaluation has been
performed on LEGO R
Mindstorms as an easy to under-
stand, inexpensive, indestructible teaching platform.
2. RELATED WORK
The IEC 61131-3 standard (International Electrotechni-
cal Commission, 2009) defines programming languages
for PLCs. Figure 1 shows example code for these pro-
gramming languages. They define the content of program
organization units (POU) – functions, function blocks
and programs. These POUs can be reused in other POUs,
to define more complex behaviour. The root node of such
hierarchic code structures are programs. They are exe-
10th Portuguese Conference on Automatic Control
16-18 July 2012
CONTROLO’2012
Funchal, Portugal
51
LD Input1
AND Input2
ST Output
(a) instruction
list (IL)
AND
Output
Input1
Input2
(b) function block dia-
gram (FBD)
Output :=
Input1 AND Input2
(c) structured text (ST)
001 Input1 Input2 Output
(d) ladder diagram
(LD)
start
step
1a
step
1b
step
2
(e) sequential
function
chart (SFC)
Fig. 1. Examples for the five 61131-3 languages
CONFIGURATION
RESSOURCE R ESSOURCE
TASK A
Program A
TASK B
TASK C
Program B
Program C
global, direct and
instance specific
variables
Fig. 2. 61131-3 software model (simplified from
(International Electrotechnical Commission, 2009))
cuted by tasks on resources in a configuration according
to the PLC software model in figure 2.
The connection to the POU and the controlled process
is done via variables. The address space for variables is
divided in process inputs, process outputs and memory.
The size of this address space (number of valid loca-
tions) is PLC-dependent. The semantic of the variables
is defined by the configuration of the system. This is
where input and output locations are assigned to local
or remote process IO. In most cases, a direct variable
representation has a symbolic name to make program
code more readable.
The PLCopen XML standard ((PLCopen Technical Com-
mittee 6, 2005; PLCopen TC6, 2009)) has been devel-
oped by the PLCopen organization (PLCopen – for ef-
ficiency in automation, 2011). Their Technical Commit-
tee 6 (XML) published two major versions: 1.01 in 2005
and 2.01 in 2009. This format was intended to exchange
PLC programs between different tools and projects. PLC
programming tools are obliged to export the code in
XML form. Every version of PLCopen XML defines a
XML schema to validate the output for conformance.
Any conform XML file shall be soundly interpreted by
the import function of any supporting tool.
PLCopen XML is used for program code exchange in
the AutomationML (AutomationML e.V., 2011) project.
Here, it is intended to reuse PLC programs which con-
trolled a virtual model of the shop floor (hardware in the
loop simulation). The code shall be reviewed or refac-
tored but not rewritten to be deployed into the PLCs.
There are several programming tools or integrated de-
velopment environments (IDE) which support the IEC
61131-3 standard (SPS-Magazin, 2009). But only a few
ones support the PLCopen XML standard. These tools
can export the XML format, though there is no consis-
tent implementation. Hence real interoperability of PLC
programming tools is not reached until now.
The authors of (Rzo´
nca et al., 2007; Rzonca et al., 2008)
have programmed a small distributed control system with
IEC 61131 ST. The program code is written using a tool
that has been developed within their project. There is
also a tool that helps configuring the IO mapping for an
application. In this cases the POUs are compiled directly
into a platform specific format. Thus, the application in
detail and the IO Mapping have to be reconfigured for
different IO configurations, if applied to single devices.
(Carrillo et al., 2005) use instruction lists as immedi-
ate format for micro controller programs executed on a
FPGA. As with the focus on hardware design, the IO
addresses have to be adjusted when addressing different
IO modules or IO configurations.
As shown later, a common immediate format for code is
required to address multiple target platforms. One possi-
bility is Java bytecode. Due to the rapid development of
virtual machines (VM) with little memory consumption
and efficient execution mechanisms, the usage of JVMs
on embedded devices is feasible. This is shown in differ-
ent projects e.g. (Java Mobile APIs Page, 2012; Gatzka et
al., 2003; LeJOS Team, 2008). Even real time constraints
can be met with some VMs.
A ST/IL compiler for the MatPLC (an open source PLC)
is introduced in (de Sousa and Carvalho, 2003). Addi-
tionally, ST and IL related issues, that have been encoun-
tered while developing, were discussed. Relating to this,
(Tisserant et al., 2007) presents an open source 61131-
3 integrated development environment using PLCopen
XML as basis. The IDE consists of a GUI for program-
ming and an extended version of MatIEC (de Sousa and
Carvalho, 2003) for compiling a 61131-3-project into a
C++ program, usable on various platforms.
The authors of (Kim et al., 1999) describe a complete
compiler design for the five 61131-3-languages. All lan-
guages are broken down to IL as intermediate language.
Additionally, software and hardware optimizations have
been realized and finally benchmarked.
3. IO MAPPING WITHIN FUNCTION BLOCKS
3.1 IO Mapping in 61131-3 and PLCopen XML
In PLCopen XML, there is no standard way to store
properties of process IO mapping. The only conclusion
to hardware mapping are the direct (or located) variables
defined in the IEC 61131-3 (International Electrotechni-
cal Commission, 2009, p. 36). These variables specify a
hardware location in their identifier name. But using such
variables postpones the problem of correct assignment
into the deployment phase.
Defining the concrete process mapping is a task of the de-
velopment environment. The PLCopen XML document
contains only the name and the type of each variable. Ac-
cording to this, function blocks that refer to hardware are
depending on the IO mapping. Thus, this way of process
mapping forbids complex standard function blocks that
access process inputs and outputs. Hence, there are few
possibilities to reuse code.
52
3.2 Hardware of embedded devices/small systems
Small systems, for example a LEGO R
Mindstorms NXT,
often provide only a small, manageable number of IO
devices. It is possible to know which actors or sensors
have to be considered and if they are in use. Often, a
tiny operating system is running on such small devices.
It manages program execution and encapsulates (direct)
hardware calls into system functions. The operating sys-
tem of a PLC has completely different tasks. It cyclically
switches between execution of programs and the appli-
cation of process values of local or remote IO devices.
The communication between program and IO hardware
is done via a process interface.
Another aspect is the execution strategy of software pro-
grams on a PLC and on a small device. A PLC uses
cyclic execution for running programs. The typical PLC
execution loop is shown in figure 3. In opposite, single
program execution is the typical execution strategy on a
small device. A program runs once and has to be called
again only if terminated (accidentally). Because of this
difference, it is necessary to use a runtime environment
on a non PLC device to provide cyclic program execu-
tion. A PLC program is usually quite complex. There-
fore, the IEC 61131-3 defines program organization units
(POU). A POU can use another one as an instance in its
code block to use its functionality. In this way the POUs
of a program form a call tree (see fig. 3).
Read
inputs
Execute
program
Write
outputs
I
...
I
I
O
...
O
O
example call tree:
Fig. 3. Way of working of a PLC
3.3 Mapping inside Function Blocks
The IEC 61499 standard (International Electrotechnical
Commission, 2003) introduces service interface func-
tion blocks, that are system-specific black-box function
blocks which may access the process interface in an
abstract manner. The PLCopen standard motion control
library (TC 2) defines movement-function blocks with
drive axis specifications as input parameters. So, different
drive instances and a special range of the process inter-
face can be addressed. Still, the axis specification has to
be mapped to the process interface, which is not part of
the program.
When addressing embedded devices, it is possible to go
further using those methods. The complete IO parame-
terization may be passed as constant function block pa-
rameter. The function block determines any IO addresses
from this parameter and is completely independent of ad-
ditional configuration data. All configuration is set in the
program by the PLC programming suite. Targets, which
are not supported by the tool, can be programmed easily
via PLCopen XML export. Configuration and program
are in one source file then. Normally, while developing a
61131-3 project the hardware configuration and hardware
binding has to be created separately. As shown, this step
can be avoided. This IO parameterization data is platform
dependent in opposite to the system IO function block
(IO FB) it is passed to. Of cause, an IO FB may only be
used, if the represented IO device may be plugged and
accessed on the current target platform.
To create complex IO FBs, the IO parameterization val-
ues of all inner IO FBs can be carried out as shown in
figure 4a. Using this method, reusable and application
independent IO FBs may be defined for libraries.
(a) FB MoveToBump
System
PRG1
FB1
FB2
I
O
O
I
(b) SoftPLC
Fig. 4. IO Mapping inside function blocks, IO access out
of function blocks
The system IO FBs have to be implemented for each
platform, their represented IO hardware can be plugged
to. Typically, a hardware instruction on an embedded
device affects the relating hardware without delay. This
hardware access is encapsulated for each sensor or actor
in a separate IO FB. Thus for example, a motor is
realized by an IO FB and a switch by another IO FB.
Every function block gets its own small program specific
process image, which allows external access to FB input
and output parameters as defined in IEC 61131-3 (figure
4). The execution of a FB can be divided into three
phases: reading inputs, executing program code and as
third setting outputs. The resulting execution loop of
the software PLC is shown in figure 4b. On the target
hardware, the program code of such a special function
block contains the direct hardware calls for interacting
with the physical hardware. In this way each execution of
a function block affects the relating sensor or actor and
updates a FB specific process interface. It can be read by
external parameter accesses as defined in the IEC 61131
standard.
4. TOOL CHAIN
4.1 Library for device specific function blocks
The previous chapter has described the way of mapping
hardware to function block instances. To realize this con-
cept it is necessary to provide a library, which contains
these hardware specific function blocks. The PLC pro-
gramming tool only requires the interfaces of the function
blocks. Later, the implementation is needed in the last
phase of the tool chain, when the application is deployed
to the target.
There are two files for one FB: On the one hand the POU
in the language structured text defining only the interface
53
of the FB and on the other hand, the implementation
additionally including the code that configures and con-
trols the hardware (in the target platform’s programming
language).
Furthermore, IEC 61131-3 describes standardized func-
tion blocks and functions. Standard FBs adopt the strat-
egy of the platform specific FBs. Here, the interface
and the semantics are defined by the standard. Only the
platform-specific implementation has been added. POUs
of the FUNCTION type are a simple collection of func-
tions (stored in a single container class).
4.2 Exporting PLCopen XML
Currently, the number of development environments that
can export PLCopen XML is still low. A Database at
the pages of the German magazine “SPS Magazin” lists
62 PLC programming environments that are currently on
the market (SPS-Magazin, 2009). A search for tools that
support PLCopen XML provided only a small number
of development environments. These are the open source
tool PLCOpen Editor (Tisserant et al., 2007) and the
commercial software packages CoDeSys, OpenPCS, PC
WORX and MULTIPROG (see table 1). However, it must
be noted, that CoDeSys and Multiprog are often used as
a base for company specific programming-environment
development. These tools (except PC WORX, that bases
on MULTIPROG) have not been considered in the list,
because their features usually are quite similar.
Table 1. 61131-3 tools supporting PLCopen XML
Beremiz
CoDeSys
MULTIPROG
OpenPCS
PC WORX
company Beremiz 3S-
Software KW-
Software infoteam
Software Phoenix
Contact
version x-mas
2009
BETA
3.4
(SP1) 4.8 (206)
5.0 (235) 6.2.1 5.20
(SP4.45)
6.0 (SP3)
XML export
whole project X X X X X
single FB -XX-X
TC6 XML 2.01 2.01 1) 1.0 1.0 2) 1.0
1) Exports only: POUs in ST 2) Exports only: ST, IL, SFC, declarations
of global/direct global variables
All tools can import and export a version of PLCopen
XML. Some support an extended version of PLCopen
XML to store more data into the project file. But in
general, these five tools export the basic project data,
like data types, POU and configurations. However, the
supported 61131-3 languages are the major difference
between the export filters of the programming environ-
ments. ST is available in some tools only. Another aspect
relates to PLCopen XML v2.0: A new XML-tag “ad-
dData” has been introduced and makes ambiguous use
fairly possible. CoDeSys stores some important project
data (for which standard tags are provided) into this tag.
The resulting PLCopen XML file is still valid, but not
company independent anymore. Beside this, “pragmas”
and the “documentation”-tag allows misuse too, like e.g.
OpenPCS uses it for exporting variable declarations. To
XML parser
IEC compiler
POUs.st
ieclib.txt
SoftPLC.java
Linker (linker.sh)
{FBn}.java
IEC_projekt.xml
library
61131-3
programming tool
LIB_*.st
LIB_*.java
{IEC-Standard-FB}.java
StdFunctions.java
Java compiler *.java
{PRGn}.java
UserFunctions.java
iecCompiler.sh
linker.sh
target system
Fig. 5. Overview of the tool chain
generate PLCopen XML files, PC WORX is quite use-
ful. This tool can export a complete PLCopen XML file
version 1.0 without reservation. The platform-specific in-
terface blocks can be imported via ST-code or PLCopen
XML and be used in a program.
4.3 Overview of the compiler tool chain
Figure 5 gives an overview of the tool chain, that pro-
cesses a PLCopen XML project. At first a XML parser
reads the PLCopen XML file. If it is valid, the parser
generates the software PLC, prepares the POUs for an
IEC-Compiler and generates some scripts for starting the
next steps of the tool chain. The IEC-compiler translates
the given POUs into Java, that has been chosen as target
language (because of the platform independency of Java
and the availability of efficient Java-VMs for embedded
systems and the Mindstorms NXT). Every POU becomes
an own Java class, except functions, that were collected
in one single class file. Next, a linker replaces the device
specific interface FBs with functional ones. Finally, a
Java compiler generates the code for the target platform.
The five 61131-3 languages are stored in different for-
mats in the XML file. POUs written in one of the two
text-based languages ST and IL, contain in addition to the
well parsed interface only a string with the program code.
In contrast to this, the representation of a POU in one
of the graphical languages FBD and LD is a traversable
syntax tree. Likewise SFC, what is represented as a tag
tree too. So there is a fundamental design decision: On
the one hand the whole PLCopen XML structure can
be handled in a monolithic tool, whose output is the
final, runable program. Only in this case it is possible
to use the data structure of the data types and graphical
languages existing in the PLCopen XML file. On the
other hand, either ST or IL is used as an intermediate
language in which the graphical POUs are converted.
Then an existing ST/IL-compiler can process the text-
based and transformed graphical POUs. However, it be-
comes necessary to restore the complete POU includ-
ing all variable declarations and let it compile by the
compiler. Thus, a generator is necessary to generate the
runtime environment for executing PLC programs and a
kind of linker has to integrate the library with the 61131-
3 standard functions and the 61131-3-standard/platform-
specific function blocks.
54
4.4 Processing PLCopen XML
The XML parser validates the XML document and stops
in case of errors. Furthermore, the included project data
should be prepared for processing in the next steps of
the tool chain. It is necessary to validate each XML file
against an PLCopen XML scheme (currently versions
1.0, 2.0 and 2.01 are supported). However, that is no
final guarantee for a correct data representation in the
XML structure. Such cases were mentioned before in
subsection 4.2.
The XML file consists of four main parts, which typically
have to be processed separately – the file and project
data, user defined data types, the POUs (consisting of in-
terface and code body) and the configurations. The text-
based languages are stored as one text string (sometimes
HTML is used to mark line breaks) and the graphic-
based languages as a traversable syntax tree. For further
processing, graphical languages are converted to text-
based languages within the XML-parser. An algorithm to
do so has been developed in (Tisserant et al., 2007) and
is adopted here exemplary for converting FBD into ST.
Its main idea is, that it traverses the XML-tree of a FBD
from the sinks to the sources, generating a ST-statement
for each function block and port.
The last part of a PLCopen XML file are the configura-
tions, that represent the software model of the 61131-3
above the POUs (compare fig. 2). This data is used to
generate a software PLC, that executes the whole PLC
project.
4.5 Translating text-based languages
The basis of IEC-compiler is the MatIEC from the
Beremiz-Suite, for which a new backend has been devel-
oped. The compiler is written in C++ with the help of flex
and bison. For this work a copy of the C backend (this
backend produces target code in C) has been used. The
target language is Java because of the possibility to use
parallels between classes and POUs and the mentioned
aspects in 4.3. Most language elements can be adapted
and thus modifications remain within a manageable re-
gion. Each POU of the type PROGRAM or FUNCTION
BLOCK becomes a new Java class. The POUs of the type
FUNCTION are collected as static functions in one single
class. That is useful, but entails a restriction: Only one
return parameter can be realized yet.
4.6 Runtime environment
The runtime environment is a piece of software PLC
realizing the cyclic program execution paradigm. It is the
base for executing PLC projects on a “non-PLC-system”.
So far, the focus was taken to the interval control.
These informations are extracted from the task descrip-
tion and are used while generating the software PLC.
The IEC compiler only generates empty Java classes
for the platform-specific blocks because at development
time only the interface blocks are used. However, these
resulting empty files are replaced with the ones from
the platform specific FB library (as described in 4.1)
and standard/platform-specific functions become added.
After this step, all generated source files are passed to the
Java compiler.
5. EVALUATION ON LEGO R
MINDSTORMS NXT
LEGO R
Mindstorms NXT is a product of the toy manu-
facturer LEGO R
. The aim of this series is the opportu-
nity to build programmable robots. Core of the system is
a programmable Lego brick, which can be connected to
various motors and sensors.
In (Lew et al., 2010) and (Oates and Zoitl, 2010) there
also have been approaches to use Mindstorms for educa-
tional purpose. As stated in a probands survey in (Lew et
al., 2010), the easy to understand “toy” makes the start
easier and is motivating for practical work. (Oates and
Zoitl, 2010) also mentions Mindstorms as inexpensive
and robust platform. So, working practically on a test
set up is safe, clean and needs few supervision because
it’s difficult to harm the hardware. Also dirty code can
be tested without any danger to man and hardware. By
using industrial programming tools, IEC 61131-3 pro-
gramming can be taught in a practical environment.
According to 3.3, motors and sensors of the NXT are rep-
resented by function blocks. Exemplary, the code of the
function block NXT TouchSensor is shown in listings 1
and 2. The first listing shows the interface block, that can
be imported in a 61131-3 programming tool. The second
code listing shows the final Java code for the function
block. The described tool chain has been prototypically
implemented and a run will be described in the following.
At first, a new project has to be created in PC WORX. The
necessary NXT function blocks must be imported and
a configuration named “Mindstorms” with the resource
“NXT” has to be created. After constructing the planned
program, the whole project can be exported as PLCopen
XML. This file is parsed by the first part of the tool
chain: the XML parser. It generates the software PLC,
stores all POUs (currently only ST and FBD) in a text file
and produces the two scripts (IEC compiler and Linker).
Next, the IEC compiler compiles the POUs in the text file
to the target language Java. The second to last operation
is the linker, which substitutes the “empty” Java function
blocks with the final one of the library. Finally, the whole
project has to be compiled with the NXJ Java compiler
and transferred onto the NXT. This procedure runs with-
out any user interaction with the PLCopen XML file as
input.
Listing 1: Function block “NXT TouchSensor” (ST ver-
sion)
FUNCTION_BLOCK NXT_TouchSensor
VAR_INPUT sensor_port : INT;END_VAR
VAR_OUTPUT is_pressed : BOOL;END_VAR
(*... *)
END_FUNCTION_BLOCK
55
Listing 2: Function block “NXT TouchSensor” (Java ver-
sion)
import lejos.nxt.SensorPort;
import lejos.nxt.TouchSensor;
public class NXT_TouchSensor {
public int sensor_port; // IN
public boolean is_pressed; // OUT
private TouchSensor mySensor; // internal
// init. of ’mySensor’ left out
public void execute() {
is_pressed = mySensor.isPressed();
}
}
6. CONCLUSION
The solution described in the paper is suitable for extend-
ing the standard industrial PLC programming languages
and concepts to application development for embedded
devices in automation. PLCopen XML can be used as an
accepted exchange format and as the only input source
for the device-specific tool chain. The evaluation has
shown that the effort for extending the existing tool chain
is relatively small. Compared to PLC programming, the
IO addressing has to be adapted to a more platform ori-
ented approach. Modular IO reconfiguration as preferred
in pure PLC environments becomes more difficult. How-
ever, using a function block oriented approach, program-
ming embedded and small devices in IEC 61131 can be
simplified. This is due to the fact that once the platform
specific FB library was added into the tool, there are no
more uncertainties between program and target hardware
configuration.
Future work will be performed evaluating other methods
for ensuring consistency of the process data image, for
example using caching. Further effort will be spend for
automatically checking IO function blocks for correct
implementation and for an extension of IO function block
mapping techniques to modular IO devices. The develop-
ment of function block libraries for embedded devices is
intended. Finally, collaborative applications on multiple
devices need to be investigated.
The approach described in this paper is a step towards de-
velopment and deployment of reusable software compo-
nents for industrial embedded devices and thus for easier
integration of them into industrial control applications.
7. REFERENCES
AutomationML e.V. (2011). [online]
http://www.automationml.org/.
Carrillo, Snaider, Agenor Polo and Mario Esmeral
(2005). Design and Implementation of an Embed-
ded Microprocessor Compatible with IL Language
in Accordance to the Norm IEC 61131-3. Inter-
national Conference on Reconfigurable Computing
and FPGAs (ReConFig’05) p. 23.
de Sousa, M´
ario and Adriano Carvalho (2003). An
IEC 61131-3 compiler for the MatPLC. In: Emerg-
ing Technologies and Factory Automation, 2003.
Proceedings. ETFA ’03. IEEE Conference. Vol. 1.
pp. 485–490 vol.1.
Gatzka, Stephan, Thomas Geitner and
Christian Hochberger (2003). The Kertasarie VM.
In: Tagungsband Net.ObjectDays 2003. c/O tranSIT
GmbH. pp. 285–299.
International Electrotechnical Commission
(2003). Function Blocks for industrial measurement
and control systems - Part 1 - Architecture.
International Electrotechnical Commission (2009). Pro-
grammable Controllers - Part 3: Programming lan-
guages.
Java Mobile APIs Page (2012). [online] http://www.
oracle.com/technetwork/java/javame/
javamobile/documentation/index.html.
Kim, Hyung Seok, Jae Young Lee and Wook Hyun Kwon
(1999). A compiler design for IEC 1131-3 standard
languages of programmable logic controllers. In:
SICE Annual, 1999. 38th Annual Conference Pro-
ceedings of the. pp. 1155–1160.
LeJOS Team (2008). NXJ technology. [online] http://
lejos.sourceforge.net/nxj.php.
Lew, Michael W., Thomas B. Horton and Mark S. Sher-
riff (2010). Using LEGO MINDSTORMS NXT
and LEJOS in an Advanced Software Engineering
Course. In: Proceedings of the 2010 IEEE Confer-
ence on Software Engineering Education and Train-
ing.
Oates, Carolyn and Alois Zoitl (2010). Utilizing Lego
Mindstorms as a Teaching Platform for Industrial
Automation. In: Proceedings of the 1st international
conference on Robotics in Education, RiE2010. FEI
STU, Slovakia. pp. 31–36.
PLCopen TC6 (2009). XML Formats for IEC 61131-
3 Version 2.01. [online] http://www.plcopen.
org/pages/tc6_xml/.
PLCopen Technical Committee 6 (2005). Xml formats
for iec 61131-3 version 1.01.
PLCopen – for efficiency in automation (2011). [online]
http://www.plcopen.org/.
Rzonca, D., J. Sadolewski, A. Stec, Z. Swider, B. Try-
bus and L. Trybus (2008). IEC structured text pro-
gramming of a small Distributed Control System.
In: Computer Science and Information Technology,
2008. IMCSIT 2008. International Multiconference
on. pp. 757–760.
Rzo´
nca, Dariusz, Jan Sadolewski and Bartosz Trybus
(2007). Prototype environment for controller pro-
gramming in the IEC 61131-3 ST language. Com-
put. Sci. Inf. Syst. 4(2), 133–148.
SPS-Magazin (2009). Produkt-Katalog Programmier-
software f¨
ur SPSen (SPS-Special / 2009). [online]
http://www.sps-magazin.de/mues/formmue.php?
mue=24\&s=0\&l=100.
Tisserant, E., L. Bessard and M. de Sousa (2007). An
Open Source IEC 61131-3 Integrated Development
Environment. In: Industrial Informatics, 2007 5th
IEEE International Conference on. Vol. 1. pp. 183–
187.
56
... Current literature presents several solutions in the direction just pointed out. For example, in [5], the use of the Java Virtual Machine (JVM) to deploy IEC 61131-3 applications to embedded devices has been proposed. In [6] different levels of an automation process are proposed and a cloud-based solution is presented. ...
... On this basis, the authors believe that one of right possible directions to reach the aim of the paper is that to adopt languages supporting VMs for the deployment of IEC 61131-3 application on common computing platforms. This idea was already pointed out in [5], which proposed the deployment of IEC 61131-3 applications using Java bytecode as a common intermediate format, although the deployment was limited to the embedded devices. ...
... One concept for creating such an isolated environment is a virtual machine [3]. In general terms, a virtual machine (referred to as VM) is understood here as a type of processor with its own instruction set and data types, implemented through software on specific hardware platforms. ...
... In this regard, we have followed the PLCopen group committee guidelines, which have established an open interface that supports a broad set of software tools (O5). We have focused on TC6 for XML workgroup, as it enables the transmission of screen-based data to other platforms [78]. This way, the PLC code is converted to PLCopen XML to perform a vendor-independent PLC testing approach in the next step. ...
Article
Full-text available
Current approaches to manufacturing must evolve to respond to increasing demands for short product life cycles and customised products. Adaptive manufacturing systems integrate advanced technologies, automation, and data-driven methodologies to develop adaptable, efficient, and responsive production processes. Central to this concept is the emphasis on human involvement and fostering synergy between human operators and the manufacturing system. Significant changes to the system's controller are required to achieve adaptivity, with programmable logic controllers (PLCs) being a common controller type. After the necessary changes to the configuration of the manufacturing system, the PLC should be reconfigured to orchestrate the new required behaviour. Automated reconfiguration is vital to rapidly responding to change, but some changes cannot be entirely achieved without human input in collaboration with automated methods. Conventional practices in PLC programming include manual, repetitive coding practices subject to errors. As a result, to ensure operational safety, the changes must be tested before being deployed to operations, ensuring it is error-free. This paper presents a methodology to automatically reconfigure the simulation environment and controller in response to a new product request. We automate the PLC code generation and testing practices to support and free up the operators when performing repetitive manufacturing reconfiguration tasks. The methodology is based on human learning, software automation, customised program development, knowledge graphs, and Graph Neural Networks (GNNs). The presented solution is a generic, vendor-agnostic, and interoperable solution that facilitates information exchange among multiple heterogeneous environments. Lastly, we have validated the methodology as a proof of concept at an adaptive assembly cell at the University of Nottingham in the United Kingdom.
... Założeniem projektowym środowiska programistyczno-uruchomieniowym CPDev [15] są wcześniej wymienione przenaszalność i uniwersalność oprogramowania tworzonego w językach normy PN-EN 61131-3 [8,13], osiągane przede wszystkim za pomocą kodu pośredniego. Głównym filarem pakietu jest maszyna wirtualna CPDev, którą można dostosować do określonej platformy sprzętowej [2]. ...
Article
The article presents performance tests of code executed by STM32 microcontrollers using a virtual machine (so-called intermediate code) dedicated to control systems. The ARM architecture used in these chips has limitations related to access to non-aligned addresses. Three ways to overcome these limitations have been proposed, and each has been subjected to a suite of tests to determine their performance. Tests were conducted for two operating modes, i.e. with 16- and 32-bit addressing for different generations of chips. The test results allow to choose the right solution for a specific platform.
... Multiple target platforms are thus enabled. In [10], ST and FBD programs are compiled to Java bytecode transferred to embedded devices running the JVM. Likewise in [11], one module of the environment compiles IEC projects into C# and another deploys them to CLR VMs in Windows or Linux. ...
Article
Full-text available
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, so it executes 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 the 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.
... The assignment is independent from programming, allowing to use the same program for various hardware solutions. Even greater portability can be achieved by using common formats (such as XML) for storing the configuration, as shown in [9]. The other approach involves direct referencing of I/Os in the program, which does not require the additional step, but makes the program hardware-dependent, i.e. it will run on a particular hardware. ...
Article
The paper presents interfaces for handling inputs and outputs from IEC 61131-3 control software available in the CPDev engineering environment. The programmer can use code-embedded clauses which directly connect addresses of variables to particular I/Os. Another approach is to perform additional configuration step to map the variables to hardware channels, what is especially convenient when external modules are used. I/O function blocks are yet another possibility to connect variables to inputs and outputs. The blocks may be either generic or specialized for particular purposes such as fieldbus communications or to perform additional signal processing.
Conference Paper
Full-text available
This study explains the design and implementation of a Virtual Reality (VR) framework for 'fun-based' interactive programming instruction in engineering education courses. Students continue to face several difficulties when learning programming [1] and the lack of efficient tools to overcome such difficulties can affect the students' motivation [2]. Over time, this creates a drastic and negative impact in their attitude towards 'learning programming,' which is undesirable for student success in engineering education. To rectify this, a suitable approach that can motivate students needs to be developed to change students' mindset towards learning programming. Student motivation is considered imperative as it is directly influences a student's perseverance and dedication towards accomplishing an objective [3]. Rather than viewing programming courses as a means to complete coursework requirements, students should be made to realize the 'power of programming.' Learning and gaining experience in computer programming necessarily involves the development of computational/critical thinking and problem solving skills. All these skills sharpen the minds of the students while simultaneously opening up multiple job prospects for them upon graduation. To this end, to facilitate interactive and fun-filled learning, this research employs a learner-centric, user-friendly Virtual Environment (VE) to teach programming concepts. In doing so, this research aims to make a paradigm shift in the 'approach to teaching and learning programming.'
Article
Full-text available
Industrial control systems are taught best using real systems. Such systems can be expensive, dangerous, and may break easily. In the other side simulations often do not react like the real system. IEC 61499 automation standard supports the current control system trend toward networks of event-driven distributed devices. Support for event driven control applications is new in IEC 61499 as are the tools supporting it. Three tutorials are presented to teach developing IEC 61499 event driven appli-cations along with control theory basics using open source tools with the Lego™ Mindstorms hardware. This inexpensive train-ing system can be used for teaching industrial control methods for students, as well as industrial professionals.
Conference Paper
Full-text available
This paper describes the benefits of using LeJOS and the Lego Mindstorms NXT set for teaching advanced software development. While Lego Mindstorms has been used in introduction to computer science courses, it is not reported to be widely used in a simulated production environment requiring such things as threading, network communications, and the implementation of command protocols. Additionally, because the Mindstorms NXT system supports Bluetooth communications with multiple devices, it is possible to use this system as the basis for a complex, communicating system requiring multiple software artifacts on different machines.
Article
Full-text available
A prototype compiler of the ST language (Structured Text), its operation and internal structure is presented. The compiler is a principal part of CPDev engineering environment for programming industrial controllers according to IEC 61131-3 standard. The CPDev is under development at Rzeszow University of Technology. The compiler generates an universal executable code as final result. The code can be interpreted on different platforms by target-specific virtual machines. Sample platforms include AVR, ARM, MCS-51, PC.
Conference Paper
Full-text available
The IEC 61131-3 standard defines a common framework for programming PLCs (programmable logic controllers), which includes the complete definition of four programming languages and a state machine definition language. Industrial PLC vendors are slowly offering support for this standard, however small inconsistencies remain between their implementations, transferring programs between vendors is almost impossible due to different file formats, and licenses are generally too expensive to allow students do install these commercial solutions on their own computers. To this end, the authors have developed an integrated development environment (IDE) for the IEC 61131-3 framework, which is being offered to the general public under the GNU public license (GPL). The IDE consists of a graphical user interface (GUI) and a backend compiler. Using the GUI the user may develop programs in any of the four programming languages, as well as the state machine definition language. The backend compiler is used to convert these programs into equivalent C++ programs which may later be compiled and executed on various platforms.
Conference Paper
A prototype environment called CPDev for programming small distributed control-and-measurement systems in Structured Text (ST) language of IEC 61131-3 standard is presented. The environment consists of a compiler, simulator and configurer of hardware resources, including communications. Programming a mini-DCS ( Distributed Control System ) from LUMEL Zielona Gora is the first application of CPDev.
Conference Paper
The use of HDLs (Hardware description languages) allows the design of a considerable variety of embedded systems. As a good example of this we present the flow used in the design and construction of an application specific non-pipelined microprocessor, that will serve as core of a PLC (programmable logic controller) compatible with the programming language IL (instruction list) according to the norm IEC 61131-3. Tests to the design, used platform, resources consumed and relevant conclusions are included about the hardware and software aspects of the implementation.
Conference Paper
We have implemented an IEC 61131-3 IL (Instruction List) and ST (Structured Text) compiler that will be part of an open source PLC. In doing so, several issues were found regarding the specification of the IL and ST languages, produced by the IEC (International Electrotechnical Commission ) standards body. The uncovered issues are discussed in this paper, and some changes to the standard are proposed. The architecture used in the compiler implementation is also outlined in the paper.
Conference Paper
This paper proposes a compiler design for IEC 1131-3 standard languages of PLCs (programmable logic controllers). It describes the structure of the front end of the compiler and the optimization phase of the intermediate representation of the back end. The paper also proposes optimization methods using several characteristics of the PLC. A software-based optimization uses the flow of the program and a hardware-based optimization is implemented by a programmable logic device to accelerate the logical operations that are most part of the PLC instructions. A benchmark test shows the proposed compiler speeds up the execution of the PLC
The Kertasarie VM In: Tagungsband Net.ObjectDays 2003. c/O tranSIT GmbH Function Blocks for industrial measurement and control systems -Part 1 -Architecture
  • Stephan Gatzka
  • Thomas Geitner
  • Christian Hochberger
Gatzka, Stephan, Thomas Geitner and Christian Hochberger (2003). The Kertasarie VM. In: Tagungsband Net.ObjectDays 2003. c/O tranSIT GmbH. pp. 285–299. International Electrotechnical Commission (2003). Function Blocks for industrial measurement and control systems -Part 1 -Architecture.