1-4244-1506-3/08/$25.00 ©2008 IEEE

Transformation of existing IEC 61131-3 automation projects into control logic according to IEC 61499

Christoph Sünder, Monika Wenger, Christian Hanni,

Ivo Gosetti Vienna University of Technology (ACIN)

Gusshausstr. 27-29/376 A-1040 Vienna

{suender, wenger, zoitl} @acin.tuwien.ac.at

Heinrich Steininger

logi.cals Austria kirchner SOFT GmbH

Mailüfterlweg 1 A-3124 Oberwölbling

heinrich.steininger @logicals.com

Josef Fritsche

Bachmann electronic GmbH

Kreuzäckerweg 33 A-6800 Feldkirch-Tosters j.fritsche@bachmann.info

Abstract

The new IEC 61499 standard provides new concepts and paradigms of system engineering to the automation and control system domain. But the customer can not start from scratch and develop their systems new as they have invested a lot of money into libraries and control logic. Therefore this paper aims at a transformation of existing IEC 61131-3 automation projects into the models of the new IEC 61499 standard. Next to the transformation of the control logic itself it is of eminent importance to consider also the overall architecture defined in IEC 61131-3, as especially the different kinds of variables influence the functionality of an automation project to a big extent.

1. Introduction

The standard IEC 61131-3 [1] is widely supported for a wide range of automation and control applications. Nearly every Programmable Logic Controller (PLC) manufacturer provides support for the programming languages defined by the standard. The main reason for the development of IEC 61131 was the existence of a huge variety of languages for PLC programming and therefore a unsatisfactory situation for the users. The current situation is much better for the user, since most PLC vendors are compliant to the definitions of the IEC 61131-3 standard and similar means for programming are available on the different PLC platforms. Nevertheless, the PLC vendors try to separate against each other by introduction of additional concepts and programming means. Therefore portability of automation projects is hardly possible in industrial practice.

During the last 15 years (in detail since work for the first version of IEC 61131-3 was finished), the

International Electrotechnical Commission (IEC) has developed a new standard dedicated to the field of automation and control systems, the IEC 61499 standard [2]. The reasons for the new standard are manifold, for instance support for distribution as well as dynamic reconfiguration. Further the principles portability, configurability, and interoperability have been kept in mind during its definition. At the moment support for IEC 61499 based systems is very low in industrial practice, but a huge amount of research work is available that utilizes the basic concepts of IEC 61499 standard. An overview is given for instance by Zoitl et al. [3] or Thramboulidis [4].

From the industrial practice point of view the applicability of IEC 61499 does not only depend on the open points that need to be solved in current and future solutions. The ARTIST roadmap [5] describes also for the special domain of industrial automation that IEC 61499 seams to provide a basis for currently open issues. It is also a fact that especially in mechatronics industry ([5] Section 28.2) the amount of software functionality within machines will increase tremendously. In order to apply new paradigms such as IEC 61499 it is important to provide protection of investments for the companies. A huge amount of manpower and money has been spent in industry in order to establish applications and libraries for IEC 61131-3. Therefore it is necessary to provide also means for the transformation of existing IEC 61131-3 automation projects into new control paradigms, in detail the concepts of IEC 61499 standard.

The topic of transformation between different control paradigms has been discussed especially for the two standards IEC 61131-3 and IEC 61499 in some publications. Hussain and Frey [6] describe the migration of PLC control applications based on the use of Signal Interpreted Petri Nets (SIPN). They base their consideration on a design flow which starts with the

369

establishment of SIPNs in order to describe the control behavior. There exist approaches in order to generate IEC 61131-3 programs based on a SIPN-based description, and therefore a migration to IEC 61499 is possible by generation of IEC 61499 applications from the SIPN-based description. Sünder et al. [7] describe the use of a special library, the PLCopen motion control library, within an IEC 61499 based control system. The library consists of IEC 61131-3 function blocks that are defined by their interface and behavior. In order to use similar function blocks (FBs) according to IEC 61499 the authors describe a transformation of the interface. For instance, the trigger of the execution of a motion command by a rising edge of a Boolean input can be transformed as input event. Already Annex D of IEC 61499 [2] provides an informal suggestion for the transformation of simple FBs from IEC 6113-3 to IEC 61499. In this case the FBs are enhanced by a simple event interface in order to trigger their execution. Gerber et al. [8] discuss the transformation of FBs in a more general manner based on examples from different typical application fields for IEC 61131-3. As a result a set of six transformation rules is given which aims at definition of IEC 61499 FB interfaces and also separation of algorithms within basic FBs. Riedl et al. [9] take into account the transformation of Sequential Function Chart (SFC) into an IEC 61499 FB network. They map the control flow within SFC into an event flow. A different approach focused on the automatic generation of IEC 61131-3 based control applications is presented by Estévez et al. [10]. Herein a general description of a control system as well as its hardware configuration is put in the center as basis for a transformation into different, current available IEC 61131-3 platforms. Due to the differentiation of IEC 61131-3 platforms it is necessary to adapt the hardware independent description of control applications and the hardware configuration to the special framework requirements of PLC vendors.

The aim of this paper is to provide a very general description of the transformation of IEC 61131-3 automation projects into the models and paradigms of IEC 61499 based on the definitions of the standards. This includes not only FBs and FB networks but the overall software model of IEC 61131-3. Based on the concepts that are supported and used within a concrete IEC 61131-3 automation project, only a subset of the provided transformation rules may be used for the migration from IEC 61131-3 to IEC 61499. Due to the high diversity of IEC 61131-3 implementations it is not possible to provide only one single transformation but again a high diversity of possible migration strategies can be chosen.

The remainder of the paper is organized as follows: In order to provide the basis for the transformation between the two standards, IEC 61131-3 will be described in Section 2 and IEC 61499 will be mentioned accordingly

in Section 3. The transformation from the IEC 61131-3 software model point of view into the IEC 61499 system model is given in Section 4. The detailed description of transformation rules based on the different elements of IEC 61131-3 is given in Section 5. The paper concludes with a short summary and an outlook to further work based on the presented transformation rules.

2. IEC 61131-3

The international standard IEC 61131 provides a set of eight parts concerning PLCs and their associated peripherals. The most important part is part 3 [1], which defines programming languages, data types, and software architecture for PLCs.

2.1. Software model The main elements of the software architecture

defined in IEC 61131-3 are given in Fig. 1. The top element is called ‘configuration’ and represents a programmable controller (this term is used by the standard for a PLC). A configuration consists of one or more ‘resource’ elements, which represent a signal processing function. A resource consists of ‘task’ and ‘program’ elements. A task is an execution control element that provides periodically or event-triggered execution of associated program organization units (POUs). This association is depicted by the execution control paths in Fig. 1. In general POUs may be programs, FBs, or functions. Programs can only be instantiated within resources, while FBs can be instantiated within programs and FBs. The difference between functions and FBs is that functions shall contain no internal state information.

Figure 1. IEC 61131-3 software model

Data types: (IEC 61131-3, 2003) defines a set of elementary data types, such as integers, strings, or real numbers, a hierarchy of generic data types in order to enable overload mechanisms, and so-called derived data types. The last one describes user-defined data types that are derived from the existing data types, for instance an enumeration or a structure.

370

Variables: Variables are data objects associated with the inputs, outputs, or memory of the PLC. A variable can be declared to be one of the elementary or derived data types. There exist several variants of variables, which have important influence on the PLC programming methodology. A detailed list is given in ([1], Table 16):

• Directly represented variables provide access to data elements with physical or logical locations in the PLC’s input, output, or memory structure.

• VAR and VAR_TEMP identify internal variables (the second one means temporary storage).

• VAR_INPUT, VAR_OUTPUT, and VAR_IN_OUT define the interface of a POU, whereas the last one can be seen as a reference instead of a storage element.

• VAR_GLOBAL defines variables that can be used within the whole scope of a configuration or resource. By use of the VAR_EXTERNAL construct a POU can yield access to a globally defined variable.

• VAR_ACCESS defines variables that can be used for remote access via the communication services specified in part 5 of IEC 61131.

• VAR_CONFIG is used to provide a means to assign a location or an initial value to symbolically represented variables. For this special case the use of an asterisk notation is possible, which enables the utilization of a ‘*’ in a type definition. The full specification of the asterisk notation has to be expressed in the configuration which uses an instance of this type. Structuring of programs and FBs: A POU is

considered as a single action which is executed under control of the invoking entity. Additional structuring of programs and FBs is possible by means of the SFC constructs. Herein actions are associated with states, and the active state evolves according to interrelation of states via transitions and evaluation of the transition conditions. SFC represents a kind of state machine, whereas it is possible that more than one state can be active at the same time. The execution of actions is additionally parameterized by action qualifiers, so that for instance an action may only be executed once when the corresponding state becomes active. As a result programs and FBs can be structured in a sequential manner.

Programming languages: IEC 61131-3 [1] defines four programming languages, namely Instruction List (IL). Structured Text (ST), Ladder Diagram (LD), and Function Block Diagram (FBD). LDs come from relay ladder logic diagrams and provide a similar visual interface. IL is very similar to the assembler language and provides a very simple instruction set. In contrast ST is similar to a higher level programming language such as Pascal or ADA, but with limited functionality. The FBD programming language stems from Boolean logic

diagrams, but additionally supports non-Boolean data types. A general difference to programming languages from computer science that needs to be kept in mind for all IEC 61131-3 programming languages is their execution behavior. The execution element is a task which can be triggered cyclical (which is typically the case) or by occurrence of an event, and POUs are executed in the context of these tasks.

3. IEC 61499

The IEC 61499 standard consists of four parts. Part one [2] includes all definitions and models in order to describe the architecture of the standard. The above discussed issues portability, configurability and interoperability are mainly solved by the definition of compliance profiles, which are a means to specify implementation dependent details of a given product.

3.1. Basic architecture The architecture of the IEC 61499 standard is

described as a list of models. Fig. 2 includes several of these models which can be considered as basic architecture of the IEC 61499 standard. A system consists of devices, which are interrelated by some communication network, and applications. A device includes resources and interfaces to the process and/or the communication network. The resource1 is the element which executes FBs independently. It makes use of the interfaces from the device. An application consists of a FB network, which is composed of FB instances, parameters and connections between the FBs. The execution of applications is determined by the event and data flow within the FB network. An application can be distributed to different resources, which may be located on different devices. In Fig. 2 ‘Application A’ is distributed to different devices, ‘Application C’ is distributed to different resources within the same device. ‘Application B’ is distributed to ‘Device 2’ and ‘Resource X’ in ‘Device 3’. As the execution flow of an application is given by events, a distributed application will behave in the same manner as if it is located within one resource, if there are no significant delays or loss of data in the communication network.

The most important element of the IEC 61499 standard is the function block. In contrast to an FB defined by IEC 61131-3 [1] the FB interface is not only defined by variables but also by events. The internals of a FB can be categorized in three main types, which are called Basic FB (BFB), Composite FB (CFB), and Service Interface FB (SIFB):

Basic function block: The behavior of a BFB is defined as event driven state machine, the so-called Execution Control Chart (ECC). There can only be one

1 The definition of a resource in IEC 61499 is not equivalent to the one

of IEC 61131-3.

371

transition that fires (there exists an order for evaluation) and the active state of the ECC changes (there is only one active ECC state at one time possible). When a new state is entered, the corresponding actions are executed. An action consists of an algorithm, or an output event, or both. An algorithm within a BFB can be written in any programming language, but the IEC 61499 standard especially mentions the languages defined in [1]. An algorithm can use only input data, output data, and internal data of the FB type, therefore a BFB defines a very strong encapsulation of algorithms.

Figure 2. IEC 61499 models: system, device, resource

Composite function block: The behavior of a CFB is defined by a FB network. The FBs within a CFB are called component FBs, and there is no restriction to a special FB type. For instance, hierarchical structures can be designed by reuse of existing CFBs. The execution of a CFB is defined according to the event and data connections of the component FB network. A CFB cannot have internal data.

Service interface function block: The SIFB is a concept for the encapsulation of the interaction with external elements, which are not in the scope of the definitions of the IEC 61499 standard. Within a SIFB any kind of functionality may be hidden. But the interface is equal to a BFB or CFB. In order to provide more information about the hidden functionality, a sequence diagram is defined by the standard. An SIFB may be either application triggered, or resource triggered, or both.

4. General transformation concepts

The first step for a transformation of IEC 61131-3 automation projects is to consider the software model which provides the fundamental framework for the control logic. Although we will only focus on the definitions in the standard their may exist different possibilities for the transformation of these models as the equivalence between model elements can be interpreted in different ways. This variety may emerge as in industrial practice the different PLC vendors on the one hand provide only a subset of these elements (e.g., a configuration with one resource and one task may be

summarized as only one element) or on the other hand add specific elements or special behavior of elements (e.g., special enhancements to the programming language or SFC). As a consequence the transformation rules and equivalences presented below need to be arranged according to the given system architecture they should be applied to.

NOTE: In order to avoid mismatch of element names between the standards we will add the name of the standard to distinguish the resource element. Also for FBs similar names are used which will be distinguished if necessary also by the name of the standard.

4.1. Equivalence of executing element When we consider the different elements of

IEC 61131-3 and IEC 61499 there exists one element within each of the standards that is responsible for the execution of control logic. In the IEC 61131-3 software model the task is responsible for the execution of programs and offers appropriate parameters in order to describe the way of execution. In IEC 61499 standard a resource is a container which is responsible for the execution of FB networks, whereas the FB network itself includes the parameters which determine the concrete execution behavior. Therefore, it is obvious to base the transformation of IEC 61131-3 element on this equivalence. Accordingly, the elements within the software model are mapped to IEC 61499 in the following way (see also Fig. 3, which shows the equivalent IEC 61499 representation of Fig. 1):

• A configuration represents a part within a system. As a system may include different devices and also communication networks, the configuration is limited to a portion within a system.

• Each IEC 61131-3 resource represents a signal processing entity and therefore can be mapped to a device. In Fig. 3 there exist two devices which are related to the same PLC, as IEC 61131-3 focuses on single PLCs.

• According to the equivalence of the execution elements a task is mapped to an IEC 61499 resource.

• A program is represented by an application. As IEC 61499 represents the execution behavior by the event connections, this aspect which comes from the parameters from the task has to be modeled within this application. The IEC 61499 resource guarantees that the execution of FB networks within is independent from other resources. Further there exist different special cases for the

transformation. Fig. 3 provides also a schematic of an application which is distributed to two IEC 61499 resources, as the FBs within the corresponding program (see Fig. 1) are related to different tasks. An IEC 61131-3 implementation has to provide an internal solution for the synchronization of the execution of programs that are related to different tasks. Due to the transformation to IEC 61499 the synchronization methodology has to be

372

modeled within the application. Further there may exist programs that are not associated with tasks. These will be executed “with the lowest priority”. According to our transformations a “background” resource in IEC 61499 should be established in this case.

Figure 3. Transformation according to the executing elements

4.2. Equivalence of the name of element resource As we have mentioned already there exists the

element resource in IEC 61131-3 as well as in IEC 61499. This may yield to problems simply by confusing the elements of the two standards. Therefore another approach for the transformation of the element defined in the IEC 61131-3 software model can be based on the equivalence of the resource elements. The corresponding mappings based on this basic equivalence are as follows (Fig. 4 provides a schematic of this transformation according to Fig. 1).

• The highest element within IEC 61499, the system, does not have an appropriate equivalence within IEC 61131-3 for this transformation. As in some IEC 61131-3 engineering tools also different configurations (and therefore different PLCs) can be handled by a project (the name may differ between the tools), this new element can be mapped to a system.

• The configuration can be depicted as device within IEC 61499. This transformation encourages the view of a device as a PLC, which is not based within the definitions of IEC 61499.

• The resource in IEC 61131-3 is equivalent to a resource in IEC 61499.

• The combination of tasks and programs is mapped to applications. As already depicted the previous transformation in Section 4.1 the execution behavior of the task has to be modeled within the FB network of the IEC 61499 application. But in this special case different tasks are included within one IEC 61499 resource, what may generate conflicts as the different execution paths may influence each other within the resource. The IEC 61499 standard

defines independent execution only between resources, which may result in conflicts within the execution behavior. In order to provide a solution for this problem additional concepts such as real-time execution within IEC 61499 have to be incorporated (see for instance Smodic et al. [11]). Fig. 4 does not mention the situation of a program

that is related to different tasks. The solution will be the same as depicted in Section 4.1 with the only difference that the corresponding application needs not to be distributed between IEC 61499 resources. Due to the distribution model of IEC 61499 this aspect is not relevant during application modelling.

Figure 4. Transformation based on the similar naming of element resource

5. Transformation rules

The transformation of an IEC 61131-3 automation project into an IEC 61499 system will be considered from the viewpoint of a virtual conversion program which has all information about the IEC 61131-3 automation project. Further we assume that the used IEC 61499 runtime environment provides some additional functionality, e.g. a service that provides global variables. The purpose and usage of these services will be explained accordingly in the following sections, which will start from the top level of an IEC 61131-3 automation project (configuration) until the lowest level of a FB and function and describe our approach for an transformation based on the two general concepts presented above.

5.1. Configuration The configuration includes the information

concerning the IEC 61131-3 resources which will be used for the general transformation as discussed above. But there is also much more information concerning especially variables and configuration settings which need to be handled for a transformation of the overall IEC 61131-3 automation project.

373

VAR_GLOBAL: IEC 61499 does not provide global variables by itself. The concept of global variables may be represented by an appropriate IEC 61499 application standard or enhanced runtime capabilities. For this work we will presume an IEC 61499 runtime environment which provides a SIFB that stores variables. This “global variables” are accessible by an interface that consists of at least three different SIFB types for creation, writing, and reading. In order to transform the information of the configuration concerning global variables a simple FB network consisting of Create-SIFBs has to be modeled that initiates the necessary variables in a sequential manner. According to the general concepts mentioned in Section 4 this application may be located in a separate device (Section 4.1) or a separate IEC 61499 resource (Section 4.2).

VAR_ACCESS: This element provides an interface for the cooperation of different IEC 61131-3 configurations. For the transformation the IEC 61499 runtime environment needs to provide additional services in order to provide interoperability to IEC 61131-3 systems (the other way round has been proposed an annex to IEC 61131-3 [12]). The SIFBs in order to establish the defined associations can be used to model a FB network as already mentioned for global variables. Herein especially the execution time of this application has to be considered carefully. For global variables the application has to be executed before all other elements. For VAR_ACCESS the application has to be executed after everything has been finished.

VAR_CONFIG: The specific initialization of variables has to be considered in two different manners. For the use of the asterisk notation we propose to integrate the information within the configuration to configure the IEC 61499 system already during the translation process. The second type of changing values of variables can again be represented by a special service within the IEC 61499 runtime environment or the use of IEC 61499 management commands. In both cases again an appropriate FB network can be established which should be executed after the initialization of the creation of the translated IEC 61499 system.

5.2. IEC 61131-3 Resource The IEC 61131-3 resource and its elements task and

program have been mapped to an application within the general concepts in Section 4. The only difference between the two concepts is the number of IEC 61131-3 resources within one IEC 61499 resource. The general architecture of such an application is depicted in Fig. 5. The task is represented by an ‘E_CYCLE’ FB for the cyclic execution and a ‘SIFB’ (which reacts on the rising edge of a Boolean variable) for triggered execution. The general idea is to represent a program as an FB (‘program_FB’) and provide the necessary access to the different variables as ‘READ’ or ‘WRITE’ SIFBs. These may read any variable within the IEC 61499 system

(similar to a management command, which could be realized also as direct connection) or also a global variable (see below Section 5.3).

Figure 5. IEC 61499 representation of an IEC 61131-3 resource

Additionally there may exist also global variables within IEC 61131-3 resources. A similar FB network as already described for configurations can be used to create the necessary memory elements within an underlying runtime service.

5.3. Program For the transformation of a program again the two

different tasks have to be considered: the declaration part and the control logic.

Declaration: The different main variables types, that define the interface of a program, can be treated for the transformation to IEC 61499 as follows (see also ‘program_FB’ in Fig. 5):

• VAR_INPUT can be mapped directly to an input variable of ‘program_FB’ (e.g., ‘VAR_IN1’).

• VAR_OUTPUT can be mapped directly to an output variable of ‘program_FB’ (e.g., ‘VAR_OUT1’)

• VAR is an internal variable which is available if ‘program_FB’ is a BFB type (see discussion below).

• VAR_INOUT is a special type of variable as it represents the concept of pointers as for instance used in C/C++. IEC 61499 does not provide such a mechanism, but it may be modeled by separated inputs and outputs of ‘program_FB’ (e.g., ‘VAI_IN1’ and ‘VAO_OUT1’ which represent together a VAR_IN_OUT variable). The problem is that as soon as such a variable is written it needs to be updated in all other elements that use this variable (and not at the end of the execution of the program), which requires special mechanisms for the transformation (see below).

• VAR_EXTERNAL can be transformed by use of a SIFB capable to read/write the mentioned global variable.

• SIFBs can be used in order to integrate directly represented variables.

374

• The attributes CONSTANT and RETAIN may be applied with additional services of the runtime environment and the hardware system. Control logic: To realize the proper control logic in

IEC 61499 two solution methods according to the used programming language can be provided. The first one utilizes a BFB type for ‘program_FB’ and incorporates the control logic as algorithms. The second one maps the control logic to an IEC 61499 FB network. Table 1 gives an overview which method suites for the respective IEC 61131-3 programming languages.

solution method

programming language a) BFB b) CFB SFC — X LD X — FBD X X ST X — IL X —-

Table 1. Programming language in IEC 61131-3 for solutions a) and b)

To clarify why one method suites better to the specific programming languages than the other one the two mentioned solution methods have to be described more detailed. ‘program_FB’ as BFB: The control logic within the algorithm is executed in an ECC of the ‘program_FB’. Fig. 6 depicts an ECC that includes also initialization and deinitialization of the FB. If ‘READY’ is active the ‘program_FB’ is ready for execution of the algorithm (depending on the trigger from ‘TASK’). As soon as a ‘REQ’ event is issued, the corresponding algorithm is executed. Fig. 6 depicts the special situation of the use of one VAR_IN_OUT variable that is written within the algorithm. The whole algorithm is split up into two parts, exactly after assigning a value to the VAR_IN_OUT variable (if this happens more often within the algorithms this procedure has to be repeated appropriately). After the first part of the algorithm the output event ‘AO’ is sent which can be used to update the variable by use of a SIFB. Then the ‘AI’ event input has to be triggered in order to proceed with the execution of the second part of the algorithm.

ECC representing an SFC? The central elements of an ECC are EC State, EC Transition and EC Action which are similar to the parts of a SFC program like Steps, Transition and Actions. However the essential difference between the ECC and the SFC program is that in an ECC only one State can be active at one time. But in a SFC several steps can be active as well as actions can be active over several steps too. This leads to the problem that a more complex structure as well as the increasing functionality of a SFC has to be mapped into a simpler structured ECC. Because of this circumstance

we will not consider a transformation of a SFC into an ECC.

Figure 6. ECC for ‘program_FB’

‘program_FB’ as CFB: The second method maps the control logic within a program into a FB network. In case of a FBD this is a relatively natural step. Based on the data connections in the FBD an execution order of IEC 61131-3 FBs can be established. This can be used for the transformation into an event flow of a corresponding IEC 61499 FB network. The modeling of SFC as FB network is much more complicated. As it has been described by Riedl et al. [9] it is possible to display a simple SFC through two IEC 61499 FBs, FB_Split and FB_Step. When considering also more complex SFCs utilizing for instance different qualifiers for actions, the situation is also much more complicated. In order to provide a rough description of a transformation method, we introduce three key elements: ‘FB_step’ in order to represent an SFC step, ‘FB_cond’ for a SFC condition, and ‘FB_action’ for a SFC action (see Fig. 7).

Figure 7. SFC elements Step, Transistion and Action as IEC 61499 FB_step, FB_cond and FB_action

Each step, action, and condition within the SFC is represented by an instance of ‘FB_step’, ‘FB_action’, and ‘FB_cond’. The general idea of this kind of transformation is that each of these elements is triggered within one execution cycle. At first all ‘FB_cond’ instances are triggered, but only those will be evaluated which have an active predecessor step. Based on the result of the evaluation (‘TRUE’, ‘FALSE’, and

375

‘NEXT’) for instance in case of positive evaluation the previous step will be informed that he is not active any more and additionally the successor is triggered, too. The ‘FB_step’ and ‘FB_action’ instances are closely related, but due to the different qualifiers additional elements such as a delay for activation by use of an E_DELAY FB may be added.

A detailed description of the necessary transformation rules for the representation of all possible kinds of SFC combinations and actions qualifiers is not possible due to the lack of space. Based on the different solution methods for the representation of a program we conclude that any programming language into a corresponding IEC 61499 FB network is in principle possible.

5.4. IEC 61131-3 FB and function For the consideration of IEC 61131-3 FBs and

function again the two different parts declaration and control logic have to be considered. A first hint for the transformation is already included in Annex D of [2] the same data interface is used for transformation with a simple REQ/CNF event interface. As there exist also other variable types for IEC 61131-3 FBs and functions (e.g., VAR_IN_OUT) a similar procedure as already depicted for programs (see Section 5.3) is necessary for the transformation of the interface. Additional rules as for instance provided by Gerber et al. [8] can be applied.

6. Conclusion and outlook

The paper presents a detailed analysis of the differences of the two standards IEC 61131-3 and IEC 61499 based on the transformation of all elements defined in IEC 61131-3. A full transformation without additional means is not possible as for instance global variables or RETAIN is not possible. But by use of underlying runtime environment services we have shown different ways to transformation IEC 61131-3 automation projects.

As a next step we will investigate on the automatic transformation of given IEC 61131-3 projects, which needs to be investigated based on the special behavior of the IEC 61131-3 system environment.

Further research may be necessary for additional transformations within the resulting IEC 61499 models may incorporate simplifications, e.g. aggregation of programs coupled via VAR_ACCESS in distributed applications without extra SIFBs.

Acknowledgement

The work leading to this invention has received funding from the European Community's Seventh Framework Program (FP7/2007-2013) under grant

agreement nb° 211448. Further information is available at: www.medeia.eu

References

[1] IEC 61131-3, “Programmable Controllers—Part 3: Programming languages”, International Standard, Second Edition, 2003

[2] IEC 61499-1, “Function blocks—Part 1: Architecture”, International Standard, First Edition, 2005

[3] A. Zoitl, T. Strasser, K. Hall, R. Staron, C. Sünder, B. Favre-Bulle, „The Past, Present, and Future of IEC 61499“, In: Proc. of Int. Conf. On Industrial Applications of Holonic and Multi-Agent Systems (HoloMAS’07), LNCS 4659, Springer Berlin, Regensburg (Germany), September 2007, pp. 1-14

[4] K. Thramboulidis, “IEC 61499 in Factory Automation”, In: Proc. of Int. Conf. on Industrial Electronics, Technology & Automation (IETA’05), Springer Netherlands, December 2005

[5] B. Bouyssounouse, J. Sifakis (Eds.), Embedded Systems Design: The ARTIST Roadmap for Research and Development, Springer Berlin, LNCS 3436, ISBN 978-3-540-25107-1

[6] T. Hussain, G. Frey, “Migration of a PLC Controller to an IEC 61499 Compliant Distributed Control System: Hands-on Experiences”, In: Proc. of IEEE Int. Conf. on Robotics and Automation (ICRA’05), Barcelona (Spain), April 2005, pp. 3984-3989

[7] C. Sünder, A. Zoitl, F. Mehofer, B. Favre-Bulle, „Advanced use of PLCopen motion control library for autonomous servo drives in IEC 61499 based automation and control systems“, e & i Elektrotechnik und Inform-ationstechnik, Springer Wien, Vol. 123, Nb. 5, May 2006, pp. 191-196

[8] C. Gerber, H.-M. Hanisch, S. Ebbinghaus, „From IEC 61131 to IEC 61499 for Distributed Systems: A Case Study”, EURASIP Journal on Embedded Systems, Hindawi Publishing Corp., Volume 2008, 8 pages

[9] M. Riedl, C. Diedrich, F. Naumann, „SFC inside IEC 61499“, In: Proc. of IEEE Conf. on Emerging Technologies and Factory Automation (ETFA’06), Prague (Czech Republic), Sept. 2006, pp. 662-666

[10] E. Estévez, M. Marcos, D. Orive, “Automatic generation of PLC automation projects from component-based models”, The Int. Journal of Advanced Manufacturing Technology, Springer London, Vol. 35, Nb. 5-6, pp. 527-540, Dezember 2007

[11] R. Smodic, A. Zoitl, G. Grabmair, T. Strasser, “A Real-Time Execution Model for IEC 61499 based Control Applications”, In: Proc. of IFAC Symp. on Information Control Problems in Manufacturing (INCOM’06), Saint Etienne (France), May 2006, pp.541-546

[12] IEC 61131-3, Draft-Annex H: Interoperability with IEC 61499 devices, [Online], http://www.holobloc.com/ stds/iec/sc65bwg7tf3/html/news.htm

376