PROGRAMMING EMBEDDED DEVICES IN IEC 61131-LANGUAGES ...

Download PDF
35 downloads 338626 Views 559KB Size Report
Comment
This paper describes a concept for adopting IEC 61131 programming suites and the PLCopen standard ... cal Commission, 2009) defines programming languages for PLCs. Figure 1 ..... [online] http://www.sps-magazin.de/mues/formmue.php?
10th Portuguese Conference on Automatic Control 16-18 July 2012

CONTROLO’2012 Funchal, Portugal

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, [email protected], [email protected], [email protected] ∗

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 serviceinterface blocks derived from IEC 61499 has been developed. An evaluation was performed R on LEGO Mindstorms for proving feasibility. Keywords: Programming approaches, Programmable logic controllers, Control enginering, PLCopen XML, Code converters, Control education, Programming environments

1. INTRODUCTION

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 automation control systems. The paper describes the concepts of IO mapping and XML processing. And it provides an evaluation of IEC 61131-3 tools focused on the aspect of PLCopen XML export. An evaluation has been R performed on LEGO Mindstorms as an easy to understand, inexpensive, indestructible teaching platform.

Programming PLC systems using standard industrial programming languages according to IEC 61131-3 has become widely accepted during the last decade. This approach should be extended to the application development 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 format 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 interface 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.

2. RELATED WORK The IEC 61131-3 standard (International Electrotechnical Commission, 2009) defines programming languages for PLCs. Figure 1 shows example code for these programming 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 exe51

LD Input1 AND Input2 ST Output

(a) instruction list (IL)

AND

Input1

Output

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.

start

Input2 step 1a

(b) function block diagram (FBD)

Output := Input1 AND Input2

(c) structured text (ST)

001

step 1b

step 2

Input1 Input2 Output

(d) ladder diagram (LD)

(e) sequential function chart (SFC)

Fig. 1. Examples for the five 61131-3 languages

(Carrillo et al., 2005) use instruction lists as immediate 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.

CONFIGURATION RESSOURCE TASK A

RESSOURCE TASK B

TASK C

cuted by tasks on resources in a configuration according to the PLC software model in figure 2.

As shown later, a common immediate format for code is required to address multiple target platforms. One possibility 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 different 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.

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 locations) 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.

A ST/IL compiler for the MatPLC (an open source PLC) is introduced in (de Sousa and Carvalho, 2003). Additionally, ST and IL related issues, that have been encountered while developing, were discussed. Relating to this, (Tisserant et al., 2007) presents an open source 611313 integrated development environment using PLCopen XML as basis. The IDE consists of a GUI for programming 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 PLCopen XML standard ((PLCopen Technical Committee 6, 2005; PLCopen TC6, 2009)) has been developed by the PLCopen organization (PLCopen – for efficiency in automation, 2011). Their Technical Committee 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.

The authors of (Kim et al., 1999) describe a complete compiler design for the five 61131-3-languages. All languages are broken down to IL as intermediate language. Additionally, software and hardware optimizations have been realized and finally benchmarked.

Program A Program B global, direct and instance specific variables

Program C

Fig. 2. 61131-3 software model (simplified from (International Electrotechnical Commission, 2009))

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 Electrotechnical 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.

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 controlled a virtual model of the shop floor (hardware in the loop simulation). The code shall be reviewed or refactored but not rewritten to be deployed into the PLCs.

Defining the concrete process mapping is a task of the development environment. The PLCopen XML document contains only the name and the type of each variable. According 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.

There are several programming tools or integrated development 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 consistent implementation. Hence real interoperability of PLC programming tools is not reached until now. 52

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.

3.2 Hardware of embedded devices/small systems R Small systems, for example a LEGO 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 system of a PLC has completely different tasks. It cyclically switches between execution of programs and the application of process values of local or remote IO devices. The communication between program and IO hardware is done via a process interface.

To create complex IO FBs, the IO parameterization values 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.

Another aspect is the execution strategy of software programs 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 execution. A PLC program is usually quite complex. Therefore, 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). I ... I I

Read inputs

FB_MoveToBump1 FB_MoveToBump m o to r_p o rt

FB_Motor

s ta rt

&

FB_TouchSensor sensor_port

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

mode power rotation_speed speed stop_angle tacho_count is_moving is_regulating mode_error cmd_error set_error

(a) FB MoveToBump

I

PRG1

System

FB1 O I FB2 O

(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.

example call tree:

Execute program

O ... O O

b u m p _ re a c h e d

se n so r_p o rt

Write outputs

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 function 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 interface can be addressed. Still, the axis specification has to be mapped to the process interface, which is not part of the program.

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 concept it is necessary to provide a library, which contains these hardware specific function blocks. The PLC programming 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.

When addressing embedded devices, it is possible to go further using those methods. The complete IO parameterization may be passed as constant function block parameter. The function block determines any IO addresses from this parameter and is completely independent of additional 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

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 controls the hardware (in the target platform’s programming language).

IEC_projekt.xml

61131-3 programming tool

Furthermore, IEC 61131-3 describes standardized function blocks and functions. Standard FBs adopt the strategy 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 functions (stored in a single container class).

x-mas 2009 BETA

XML export whole project single FB TC6 XML

X 2.01

Figure 5 gives an overview of the tool chain, that processes 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.

X PC

infoteam Software

3.4 (SP1)

4.8 (206) 5.0 (235)

6.2.1

X X 2.01 1)

X X 1.0

X 1.0

2)

Linker (linker.sh)

4.3 Overview of the compiler tool chain

WO R

enP CS Op

RO G MU

LT IP

s Sy De Co

rem iz Be

version

KWSoftware

*.java

LIB_*.java {IEC-Standard-FB}.java StdFunctions.java

generate PLCopen XML files, PC WORX is quite useful. This tool can export a complete PLCopen XML file version 1.0 without reservation. The platform-specific interface blocks can be imported via ST-code or PLCopen XML and be used in a program.

Table 1. 61131-3 tools supporting PLCopen XML

3SSoftware

{FBn}.java

Fig. 5. Overview of the tool chain

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.

Beremiz

library

IEC compiler

{PRGn}.java UserFunctions.java

Java compiler

4.2 Exporting PLCopen XML

company

LIB_*.st

POUs.st ieclib.txt

SoftPLC.java

target system

iecCompiler.sh linker.sh

XML parser

Phoenix Contact 5.20 (SP4.45) 6.0 (SP3)

The five 61131-3 languages are stored in different formats 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 textbased and transformed graphical POUs. However, it becomes necessary to restore the complete POU including 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 611313 standard functions and the 61131-3-standard/platformspecific function blocks.

X X 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 environments. ST is available in some tools only. Another aspect relates to PLCopen XML v2.0: A new XML-tag “addData” 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 54

4.4 Processing PLCopen XML

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.

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.

R 5. EVALUATION ON LEGO MINDSTORMS NXT R LEGO Mindstorms NXT is a product of the toy manuR facturer LEGO . The aim of this series is the opportunity to build programmable robots. Core of the system is a programmable Lego brick, which can be connected to various motors and sensors.

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 interface and code body) and the configurations. The textbased languages are stored as one text string (sometimes HTML is used to mark line breaks) and the graphicbased languages as a traversable syntax tree. For further processing, graphical languages are converted to textbased 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.

In (Lew et al., 2010) and (Oates and Zoitl, 2010) there also have been approaches to use Mindstorms for educational 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 programming can be taught in a practical environment.

The last part of a PLCopen XML file are the configurations, 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.

According to 3.3, motors and sensors of the NXT are represented 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 without any user interaction with the PLCopen XML file as input.

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 developed. 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 region. 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 description 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

Listing 1: Function block “NXT TouchSensor” (ST version) FUNCTION_BLOCK NXT_TouchSensor VAR_INPUT sensor_port : INT; END_VAR VAR_OUTPUT is_pressed : BOOL; END_VAR (* ... *) END_FUNCTION_BLOCK

55

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). Programmable Controllers - Part 3: Programming languages. Java Mobile APIs Page (2012). [online] http://www.

Listing 2: Function block “NXT TouchSensor” (Java version) 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(); } }

oracle.com/technetwork/java/javame/ javamobile/documentation/index.html.

6. CONCLUSION

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 Proceedings 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. Sherriff (2010). Using LEGO MINDSTORMS NXT and LEJOS in an Advanced Software Engineering Course. In: Proceedings of the 2010 IEEE Conference on Software Engineering Education and Training. 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 611313 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. Trybus and L. Trybus (2008). IEC structured text programming 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 programming in the IEC 61131-3 ST language. Comput. Sci. Inf. Syst. 4(2), 133–148. SPS-Magazin (2009). Produkt-Katalog Programmiersoftware f¨ur SPSen (SPS-Special / 2009). [online]

The solution described in the paper is suitable for extending 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 oriented approach. Modular IO reconfiguration as preferred in pure PLC environments becomes more difficult. However, using a function block oriented approach, programming 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 development 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 development and deployment of reusable software components for industrial embedded devices and thus for easier integration of them into industrial control applications. 7. REFERENCES AutomationML

e.V.

(2011).

http://www.automationml.org/.

[online]

Carrillo, Snaider, Agenor Polo and Mario Esmeral (2005). Design and Implementation of an Embedded Microprocessor Compatible with IL Language in Accordance to the Norm IEC 61131-3. International 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-

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