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

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.

Full text

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.
m o t o r_ p o r t
se n s o r _ p o r t
st a r t
bu m p_r e a c h e d
FB_MoveToBump
FB_MoveToBump1
sensor_port
FB_TouchSensor
is_pressed
100
&mode_forward
mode_backward
mode_stop_float
mode_stop_hard
cmd_reverse_direction
cmd_rotate_angle
cmd_rotate_angle_immediate
cmd_rotate_to
cmd_rotate_to_immediate
cmd_lock_positon
set_power
set_speed
set_brake_power
set_regulate_speed
smooth_acceleration
reset_tacho_count
motor_port
FB_Motor
mode
power
rotation_speed
speed
stop_angle
tacho_count
is_moving
is_regulating
mode_error
cmd_error
set_error
(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