MANUFACTURING is one of the most important valueadding

Transcription

1 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART C: APPLICATIONS AND REVIEWS 1 Design and Execution Issues in IEC Distributed Automation and Control Systems Thomas Strasser, Member, IEEE, Alois Zoitl, Member, IEEE, James H. Christensen, and Christoph Sünder Abstract The standard IEC claims to be a standard for a distributed control environment consisting of a set of heterogeneous control devices from different vendors. Previous work on the implementation of IEC pointed out ambiguities in the standard, resulting in different execution behavior of IEC elements on different control devices. One of the key deficiencies is the lack of a definition for execution models of the device, the resource, and the function blocks. This paper discusses different design and execution issues related to the aforementioned problems for IEC distributed automation and control systems. Index Terms Distributed control system, Holonic Manufacturing System (HMS), IEC 61499, lower level control approach. I. INTRODUCTION MANUFACTURING is one of the most important valueadding pillars of developed and developing countries and regions. In Europe, manufacturing represents approximately 22% of gross domestic product (GDP), and it is estimated that about 75% of GDP and about 70% of employment are related to manufacturing [22]. But today s markets are becoming increasingly volatile, unpredictable, and subject to abrupt change. The accelerating speed of innovation with reduced model life cycles and increased product variety induces even more frequent changes. Therefore, manufacturing companies will face frequent and unpredictable market changes in this century. Economically viable production of small lot sizes is required to keep manufacturing as a significant contributor to the European economy. Manufacturing technologies and systems, and therefore, their information and communication technology (ICT) infrastructure must undergo radical improvements to keep pace with this trend: New, more flexible technologies and embedded components that support the possibility to flexibly compose systems from machines to entire plants are required [22]. New paradigms Manuscript received November 16, 2009; revised June 10, 2010; accepted August 5, This paper is submitted for the special issue on Industrial Applications of Holonic Systems (Eds. R. Brennan, W. A. Gruver, E. van Leeuwen, and K. Hall). This paper was recommended by Associate Editor R. W. Brennan. T. Strasser is with the AIT Austrian Institute of Technology, 1210 Vienna, Austria ( thomas.strasser@ait.ac.at). A. Zoitl is with the Vienna University of Technology, Automation and Control Institute, 1040 Vienna, Austria ( zoitl@acin.tuwien.ac.at). J. H. Christensen is with the Holobloc Inc., Cleveland Heights, OH USA ( james.h.christensen@gmail.com). C.Sünder is with the Thales Rail Signalling Solutions GesmbH, 1210 Vienna, Austria ( christoph.suender@thalesgroup.com). Color versions of one or more of the figures in this paper are available online at Digital Object Identifier /TSMCC like flexible production up to small lot sizes, mass customization, or zero downtime production will achieve these requirements, but demand completely new technologies for its realization [23]. Changeability, which describes the ability of companies being flexible concerning customer demands, impacts all levels of manufacturing. In particular, these are the agility at a strategic level, the transformability at a factory level, and the reconfigurability at the manufacturing system level [23]. The state of the art in manufacturing and its automation/ control systems is inadequate to meet these requirements. The development of an adequate automation system for heavily interacting distributed real-time systems can be seen as a major task. Current software architectures of industrial process measurement and control systems (IPMCS), such as IEC , do not conceptually support reconfiguration and distribution that are necessary for the aforementioned systems [5]. Distributed embedded real-time systems for industrial automation and control of plants that evolve toward zero timeless adaptable systems (i.e., dynamically reconfigurable systems) will play a key role to realize the roadmaps toward adaptive manufacturing [23], [24] of products, goods, and services in Most value will then be added in engineering and performing a system evolution (the change from one system state to another), rather than in engineering and performing normal operation [23], [24]. The challenge and aim of this paper is to discuss design and execution issues of the IEC elements function block (FB), resource, and device that has led to different interpretations and implementation in the past. The design of IEC was strongly coupled with the Holonic Manufacturing Systems (HMS) project. The main idea was to get an agile lower level control architecture as a basis for an HMS [11]. These different interpretations of the IEC Standard also lead to the fact that the aforementioned requirements and demands of future manufacturing and automation systems as well as requirements for lower level control in HMS are not fulfilled up to now. The paper is organized as follows. Section II gives a brief overview about the IEC Standard for distributed automation system. The execution of FBs in devices is discussed in Section III, and the execution of composite FBs (CFBs) and subapplications is analyzed in detail in Section IV. The paper ends with the conclusions in Section V. II. IEC STANDARD AS A REFERENCE MODEL FOR DISTRIBUTED AUTOMATION AND CONTROL The automation industry is characterized by a proliferation of proprietary software environments. Different platforms and tools are in use. In most cases, there is no interoperability /$ IEEE

2 2 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART C: APPLICATIONS AND REVIEWS between solutions from different vendors. The standard IEC [8] provides a small basis for common modeling of control programs, but platforms and tools are not able to interoperate. Several steps to improve this situation have been undertaken, mainly by the work from many small companies and user organizations, such as PLCopen [20]. As a result of these undertakings, IEC achieved the worldwide breakthrough. Unfortunately, most of the main demands/requirements for future automation systems, as stated by a study of the Iacocca Institute [21], are not supported by the industrial solutions available on the market yet. This is being painfully discovered by users again and again. There are many reasons for this lack of innovation, partially a matter of company policies of control vendors, partially of (so-called) compatibility, but also, as one has to admit, because of the lack of interest of application engineers and technology providers. An analysis of the Iacocca study identified the following high-level demands/requirements for future automation systems. 1) Portability: Software tools can accept and correctly interpret software components and system configurations produced by other software tools. 2) Configurability: Any device and its software components can be configured by software tools from multiple vendors. 3) Interoperability: Embedded devices can operate together to perform the functions needed for distributed applications. 4) Reconfiguration: The ability to adapt control hardware and software during operation. 5) Distribution: The ability to distribute software components onto different hardware devices, as requirements demanded from future IPMCS by the automation industry. In order to overcome the open issues in IEC as mentioned earlier and to fulfill the requirements of the Iacocca study, new ways for designing and implementing distributed control systems have to be taken. In early 1990, it was proposed that Technical Committee 65 of the International Electrotechnical Commission (IEC TC65) undertake the standardization of...certain aspects of the application of software modules called function blocks in distributed IPMCS [11]. At that time, the fieldbus standard (IEC 61158), utilized by IPMCS, was still in development, and the programming language standard for programmable controllers (IEC ), in which FBs are also an essential part, had just been completed. Therefore, TC65 assigned the task of developing a common model for the use of FBs to a new project, IEC This standard consists of the following parts, which are published in 2005 and scheduled for maintenance in ) IEC : Function blocks Part 1: Architecture [1]. 2) IEC : Function blocks Part 2: Software tool requirements [2]. 3) IEC : Function blocks Part 4: Rules for compliance profiles [4]. The Technical Report IEC [3] was published in 2004 and withdrawn as obsolete in To summarize, the new standard serves as a reference architecture that has been developed for distributed, modular, (re)configurable, and flexible control systems. It specifies an architectural model for distributed applications in automation in a very generic way and extends the FB model of its predecessor IEC with additional eventhandling mechanisms and concepts for distribution. FBs are an established concept for industrial applications to define robust and reusable software components. The network architecture is beyond the scope of this standard, but a compliance profile for feasibility demonstrations, which is provided by the HMS consortium, specifies its usage for Ethernet [11]. The following main features briefly characterize IEC [1], [2], [4], [12]: component-oriented building blocks called FBs, graphical intuitive way of modeling control algorithms through the connection of FBs, direct support for distribution, interaction between devices of different vendors, and basic support for reconfiguration, and it is based on existing domain standards. With the constructs and definitions of this standard, most of the aforementioned requirements can be fulfilled. Thus, IEC is suitable as reference architecture for building new agile lower and higher level control concepts for next-generation automation as well as for Holonic systems. Recent experience in the application of IEC has revealed that the ambiguities in this standard lead to different interpretations and also to different implementations, particularly in the area of runtime execution. In order to overcome the problems that occurred from different interpretations, a step toward a more rigid definition of the execution semantics for IEC through the derivation of execution models for devices, resources, and FBs is necessary. In Section III, the execution of these IEC elements is discussed in more detail. III. DISCUSSION OF FB EXECUTION ISSUES IN DEVICES AND RESOURCES IN IEC This section discusses issues on the execution of FBs and FB networks (FBNs) in IEC devices and resources. A. General Assumptions and Considerations 1) Investigations of the Execution of Devices and Resources: Up to now most work investigating the execution of IEC deal only with parts of the standard elements and not directly with real-time execution. Rumpl et al. [13] examined different event-propagation strategies and their impact on the execution behavior of IEC applications in detail. Ferrarini and Veber [14] compared different implementation strategies for IEC FBs regarding their execution behavior and comparing the execution overhead introduced by adding additional execution threads in a Java-based environment. An event-path concept with annotated real-time constraints has been introduced by Doukas and Thramboulidis [15]. This concept allows to derive a priority assignment scheme for FBs, which enables real-time execution of IEC applications, if each FB of such an event path gets its own execution context. The mapping from the event-based IEC execution to a cyclic, scan-based system as it is used in traditional programmable logic controller (PLC) systems has been shown in [16]. This mapping allows a deterministic preverifiable execution behavior and response times. But the main limiting point is the large

3 STRASSER et al.: DESIGN AND EXECUTION ISSUES IN IEC DISTRIBUTED AUTOMATION AND CONTROL SYSTEMS 3 overhead introduced by the scan cycle and as a result of this overhead the larger overall response time of the application. An analysis of the scan-based execution model that has been implemented within the commercial tool ISaGRAF has been done in [17]. They compared it to their event-based implementation and showed that in the scan-based execution model events may be lost. Zoitl et al. [18] did one of the first investigations on all execution elements within a control device. The main goal was to derive a new real-time execution approach. The investigation on usability and interoperability presented in [5] showed open points in the definitions of the standard for application modeling when executed on different devices. Semantic holes in the definition of the execution models of IEC have also been identified in [9]. Cengic and Akesson [25] provided a very good framework for the formal analysis of IEC applications, especially on execution semantics. 2) Overview on Execution Tasks of a Device and a Resource: A device is the IEC representation of any control equipment with the ability to encapsulate IEC resources and to execute IEC applications. It consists of a communication interface, a process interface, the device management, and can contain none, one, or more resources. The communication interface provides communication services for the device and the application parts residing in this device. The process interface provides the services for accessing the sensors/actuators needed to control the process. IEC does not require a one-toone association between a resource and its local computational unit (e.g., one central processing unit (CPU) per resource and one resource per CPU). Therefore, a device has to take care that each resource gets computing time corresponding to the needs of the resource or the constraints of the overall application. The device must also ensure that the execution of the resource does not interfere with other resources. Within a device, resources can be created, deleted, configured, etc. without interfering with other resources and their applications. If a device does not contain any resource explicitly, it has to behave like one overall resource and has to allow the execution of IEC applications built from connected FBs. In addition to the device functionality, such devices must perform the resource functionality as well. Therefore, the execution tasks of a device are supporting background functions, such as the communication interface, the process interface, the device management, and providing execution time for the resources located in the device. A resource is a functional unit that serves as containment for applications or application parts residing in the specific device and has independent control of its operation. A resource has to support the device in its task to encapsulate the contained applications properly. It provides an execution environment for applications. Applications are modeled as FBNs consisting of FBs interconnected via their interfaces. These connections can be event and/or data connections. The application execution environment has to provide means for moving data values along the data connections, for delivering event notification occurring on event outputs to the corresponding event inputs, and means that the FBs are able to process incoming events according to their internal structure. The standard depicts a special resource scheduling function shown in Fig. 1(a) for executing algorithms Fig. 1. Execution models for IEC FBs. (a) Execution steps of BFB [1]. (b) Derived general execution steps for all FB types. of FBs and the standard explains this in note 4 of Section as: Resources may need to schedule the execution of algorithms in a multitasking manner. The specification of attributes to facilitate such scheduling is described in Annex G. Butitis still an open point how to execute FBs as whole units, which is mainly important for non-basic FB (BFB) types. Within this paper, some approaches are discussed in order to provide some solutions of this very important question. Other tasks, the application execution environment has to fulfill, are not directly regulated in the standard. For instance, data have to be moved from the data outputs of FBs to the corresponding data inputs of the connected FBs. Depending on the implementation, this will need execution time that must not be neglected. The delivery of event occurrences along the event connections is the trigger for executing FBs. The kind of delivery method of the events has great influence on the behavior of the whole FBN and can lead to undesired side effects [13], [14]. 3) General FB Execution Model: As basis for the further investigation, we derive a general FB execution model based on the execution model for BFBs, as defined in IEC [1]. There a time sequence consisting of eight steps that defines the execution behavior of BFB. A short explanation is given here and more details can be found in Fig. 6 of the standard as well as the according Sect on pages 23ff. First, the input data need to be ready [t 1, see Fig. 1(a)]. Then, the input event triggers the evaluation of the execution control function [i.e., execution control chart (ECC)] (t 2 ). If an algorithm needs to be executed, the underlying scheduling function is informed (t 3 ), and when there is time, it is granted execution time (t 4 ). After the algorithm finished its execution (t 6 ), the ECC is notified (t 7 ) and appropriate output events may be sent (t 8 ). Although Fig. 1 targets the execution of BFB, it can be generalized for all FBs. The steps t 1, t 2, t 5, and t 8 are common for all types of FBs. Only the times in the middle (t 3, t 4, t 6, and t 7 ) are special for BFB. Therefore, by summarizing the times t 3, t 4, t 6, and t 7 to one new execution interval called internal FB execution, a general execution diagram for all FB types can be drawn, as shown in Fig. 1(b). Based on the definition of IEC , the redefined times t 1, t 2, t 3, and t 4 characterize the following actions. 1) t 1 : Relevant input variable values are made available (equal to the definition of t 1 in IEC 61499). 2) t 2 : The event at the event input occurs. The internal FB execution is started.

4 4 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART C: APPLICATIONS AND REVIEWS Fig. 2. Generalized FB model for resource-initiated FBs. 3) t 3 : The internal FB execution completes the establishment of values for the output variables associated with the event output by the WITH qualifier. 4) t 4 : The execution control function signals an event at the event output (equal to the definition of t 8 in IEC 61499). What has to be noted that FBs may send several output events as result to one input event trigger. This leads to a sequence of t 4 s, each defining the time of an output event sent. Therefore, t 4 cannot be taken as the overall time an FB needs for its execution because after the output event has been sent additional internal execution may occur. For this model, this is of less concern as this generalized FB execution model treats every FB as a component that needs a certain amount of time for execution after an input event has been delivered. But the standard does not only define BFB types. Further FBs are CFBs and service interface FBs (SIFB). Especially in the case of SIFBs, the execution model presented in Fig. 1 needs to be adapted, as the so-called responder primitive of SIFBs is mentioned by IEC Moreover, this execution model is also not sufficient for CFBs. This issue is discussed in more detail in Section IV. Up to now, there exist no mechanisms to introduce any events into applications, which is a critical issue. The responder SIFBs are so-called resource initiated and they are special SIFBs that are triggered by an external event source (ES). Therefore, such specific SIFBs generate events for applications. This means that an underlying service (e.g., timing interrupt or network invocation) activates the execution of FBs. This can be possible not only for the previously mentioned SIFBs, but also in the case of CFBs, if they include responder SIFBs. An adapted FB model with respect to this fact is shown in Fig. 2. B. Assigning an Execution Context to IEC Elements IEC allows the control engineer to model concurrent distributed control applications based on FBs. An execution model needs to define how the concurrent elements of a control application are to be executed in parallel. In state-of-the-art control software, concurrent elements get their own execution context 1 (ECTX) that will be scheduled by the execution environment. In order to provide such definitions for IEC also, this section investigates those execution elements of IEC that may have their own ECTXs. 1 Execution contexts may be tasks, processes, or threads. As long as not noted especially these are treated equally in this paper. 1) One Execution Context Per FB: FBs are independent reusable software components that shield their internals through a defined interface. They can be requested for execution through triggering one of their event inputs. Therefore, the FB is a typical candidate for getting its own ECTX. Within this ECTX, the FB waits for triggers on one of its event inputs. As a reaction to the trigger, the ECTX of the FB is woken up and can execute its internal structure independently of other FBs in the same or in other resources. In order to achieve real-time execution, the FBs may be given real-time constraints, such as activation time or deadlines [15]. Based on these constraints, an underlying operating system (OS) scheduler can determine the most important FB and schedule its ECTX for execution. If a more important FB requests execution, the currently executing FB is preempted in favor of the more important one. Event connections will be realized as inter-ectx communication services that need to be provided by the underlying OS that also provides a multitasking mechanism. This approach of ECTX assignment results in a large number of tasks (depending on the application s size). A higher number of ECTXs results in several drawbacks. First of all, each ECTX needs memory for saving its state, stack, etc. Increasing the quantity of ECTX enlarges the memory usage as well, which is a severe limitation for using such a system on a small embedded control platform with a small memory footprint. A second limitation is that typical OSs for small control devices normally have a limited number of ECTXs available. Using many ECTXs will increase the amount of ECTX switches. Therefore, the overhead that is needed for switching between the ECTX cannot be neglected. It will consume processing time and make the overall system less efficient. The underlying OS will handle the scheduling and the task switches, which is complicated to implement. The point that makes it even more complicated is the strong coupling between the tasks through the event and/or data connections. Ferrarini and Veber [14] compared several different implementations for execution environments, where each FB has assigned its own task. The measures showed that the overhead for synchronizing the different tasks resulted in a poorer execution performance of the application. It mainly results in a higher worst-case execution time, which is the determining factor for meeting real-time constraints. 2) One Execution Context Per Resource: In Clause of IEC , a resource is defined as: For the purpose of this specification, a resource is considered to be a functional unit, contained in a device which has independent control of its operation. It may be created, configured, parameterized, started up, deleted, etc., without affecting other resources within a device. [1, p. 20]. Because of this independence in control, the resource is a target for ECTX assignment. This allows the parallel execution of applications in different resources without major interference. Within the task of one resource facilities for delivering events and for executing, FBs must be provided for a correct execution of FBNs. This is, especially, of interest when not all FBs within the resource can be treated equally, for example, when different parts of the application need to satisfy different real-time constraints. If concurrent application parts reside in one resource, means have to be provided that

5 STRASSER et al.: DESIGN AND EXECUTION ISSUES IN IEC DISTRIBUTED AUTOMATION AND CONTROL SYSTEMS 5 allow parallel execution of these application parts. In this case, the resource would serve only as a shell, shielding the application within the resource against the executions of the other resources. To the internal elements of the resource, the shell provides a kind of sub-ectx, handling the different execution elements within the resource. In this case, the resource has to implement scheduling mechanisms. In current OSs used for personal computers, this concept is equal to the heavy-weight process that may contain one or more light-weight threads. This concept incorporates with additional execution overhead: First, because now two scheduling mechanisms are cascaded, and second, because more memory is needed to store all the state information of the task and subtask on task switches. Therefore, most OSs for small embedded controllers do not support such twofold scheduling. Consequently, the support for sub-ectx has to be implemented in the execution environment for such systems. This is not an easy job to solve, and in most cases, it strongly depends on the particular processor being used. A conceptually different approach, which sits in the middle of the previous scenarios, has been implemented and presented in [10]: There every FB s network container, i.e., resources and CFBs, gets its own ECTX. This solution has been chosen for executing a CFB as an entity exactly like a BFB, i.e., the internal activity of the CFB is executed in a single run (see also Section IV-B1). 3) One Execution Context Per Device: Although the standard states that the resource has its own scheduling function, it could be interesting to attempt to transfer the functionality of FBN scheduling from the resource level to the device level. This has the advantage of reducing the complexity and overhead necessary for scheduling, leaving more processing power for executing applications. This is of great importance for limited-cost devices, as only one ECTX is needed for such an approach. This would be suitable even for very small control devices with no OS. This idea has the drawback that regarding reconfiguration and resource encapsulation the device cannot directly distinguish between the elements of different resources. 4) Assigning an Execution Context to Application Areas: The Event Chain Concept: A direct mapping between IEC execution elements and ECTXs provides a solution for executing IEC 61499, as discussed in the previous sections. But none of the approaches could fulfill the requirements for a flexible real-time capable execution environment on small embedded control platforms. Therefore, we will take into consideration the different parts of an IEC application. A new element has to be introduced, serving as the element that gets its own real-time task. As basis for this new element, the active elements within an IEC application are chosen in [15] and [18]. 1) Event sources: From a general point of view, an IEC FB is commonly a passive element. It only needs execution time when it is triggered by an arriving input event. Although the assignment of an ECTX to each FB is a convenient way for implementing IEC execution support, the drawbacks are overwhelming. Also, it is an excessive approach since a general FB is passive and waits for event input triggers (as shown in Fig. 1). Therefore, most of the time its ECTX is suspended waiting for an event to arrive. In an IEC application, the only active elements are responder FBs. These FBs are triggered not only by event inputs, but also by the underlying OS (e.g., interrupts). Therefore, these FBs are also often called ES-FBs. By analyzing the execution flow of FBs and event notifications, it can be observed that all execution paths within an application originate from ES-FBs (see Fig. 2). Therefore, ES-FBs will be a main element of this new execution model for IEC In the following, we investigate the execution started from an ES-FB and its impact on an execution environment in more detail. 2) Event sinks: Up to now only the origins of events have been investigated. But for a full execution behavior, the analysis of applications and sinks of event flows have to be considered also. As an event-sink (ESK), we define the point in an FBN where the execution of an FB will not lead to any further FB execution. There are three possibilities for such points. The simplest one is that the ESK is represented by an FB with no event output. This is not a very common FB because most FBs provide at least status outputs on the success of their execution. A more common point is that the output events are not connected to other FBs, and therefore obviously no further execution will be initiated, although an output event is sent. In this case, it has been the decision of the control engineer to end the FB execution. The not so obvious to identify ESK is the possibility that the internals of an FB decide to send no output event. As a consequence, there will be no further execution, although there are FBs connected to the ESK-FB event output. 3) Definition of an event chain: With the ES and the ESK in hand, we define an event chain (EC) as the chain of FB executions started through an event occurrence at one ES-FB and ending in an ESK. This EC concept will serve as elementary execution element in the new execution model for IEC Each EC will get its own ECTX and if it is necessary for its execution behavior also real-time constraints. This concept allows that less ECTX will be used than when assigning each FB an own task, but keeps all independent elements within an FBN autonomous. C. FBN Execution Model With the earlier identified EC, a mapping to ECTX could be found. This allows the concurrent execution of IEC application parts. What is still undefined is how FBNs within an EC are executed. The necessary execution within an EC is the delivery of event, and it has to allow the FBs within the EC to process their received input events according to their internal structure. From a general point of view, this can be seen as scheduling of FBs, whereas the input events are the activation notifications. In comparison to normal scheduling, there are some restrictions that simplify this task. The first point is that all FBs within an EC are equally important. Therefore, there is no need for interrupting an FB by another one. Resulting from the single trigger through the ES only one FB will be active within an EC. Only if the EC contains branches, several FBs will be active. But as the whole EC has the same set of real-time

6 6 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART C: APPLICATIONS AND REVIEWS Fig. 3. Scheduling of FBs within (shaded area) an EC done by the EDC. constraints assigned, it does not matter if one branch is finished earlier than a second branch. These features lead to a nonpreemptive scheduling of FBs as nonpreemptive scheduling implies less overhead and is easier to implement. 1) Function Block Runtime Environment Execution Model: The first time an execution model for IEC FBN has been implemented was by James H. Christensen within the FB runtime environment (FBRT). This is part of the FB Development Kit (FBDK), both freely available from [11]. A detailed description of this execution model is given in [5], where it is called a NonPreemptive Multi-Threaded Resource (NPMTR). There ES (e.g., timers) are mapped to own Java threads. Within this thread, the active element is handled (e.g., wait for timeout) and according to the function of the FB output data are set and corresponding output events are triggered. The event-notification mechanism is implemented as a simple function call. This means that the originating FB calls the notification function of the event connection, which calls its destination FBs by itself. Because of this function call approach, the execution of the originating FB is blocked until the function call returns. This may take quite a lot of time if a longer chain of FBs is triggered. Additionally, it is possible that in case of closed-event loops, an FB is not in the correct internal state (e.g., wrong ECC state) [13], [14]. 2) Event Dispatcher Concept: The event dispatcher concept (EDC) is a scheduling mechanism, which has already shown that it is capable of executing IEC FBNs in [13], [15], and [19]. It provides a deterministic execution and in addition a decoupling of FBs in order that FBs behave as independent components, as intended in the standard. In the EDC, a so-called event dispatcher (ED) will store the current active event inputs in an first input first output (FIFO) queue the so-called event queue (EQ) as shown in Fig. 3. When the ES triggers the EC, the connected event inputs are notified. This notification leads to an addition of the event input in the EQ and the corresponding task will be activated. The ED will notify the FB that owns the first event input in the EQ and allows the FB processing the event input according to its internal structure. While the FB is executing, the FB may add several new entries at the end of the EQ. When the FB finished its execution, the ED takes the next entry of the EQ and notifies it. If the EQ is empty, the EC has finished its execution and will suspend itself until the next trigger of the ES-FB occurs. IV. DISCUSSION OF CFB AND SUBAPPLICAITON EXECUTION ISSUES IN IEC This section discusses issues on the execution of FBs, especially the CFB and the subapplication, since the BFB execution has already been discussed in detail in Section III. A. General Assumptions and Considerations It is clear to the authors that the execution model of CFBs and subapplications is very closely related with the execution models for event propagation within FBNs, as these two standard elements just provide some kind of container for FBNs. Nevertheless, separated considerations of these topics seem to be valuable, since there have to be taken into account even more critical aspects than just event propagation. To generalize our investigations, we will act on the following general four assumptions. 1) Execution of BFBs: We will follow the definition of [6] concerning a single run of a BFB. A single run means that the FB execution activated by an event ends if no more ECC transition can be evaluated to TRUE (see also Section III-A3). Consequences of this assumption are as follows. a) There is only one event active during the single run (no concurrent events) [7]. After the first transition clears, the event occurrence clears too. An event input can be used at most once, but it may possibly clear unused [9]. b) During a single run of a BFB, several states may be executed. After changing the state of the ECC the first time, the event input is cleared. Only transitions that purely consist of guard condition are then able to clear [5]. 2) External event-handling mechanism: An external mechanism is necessary to handle events that are emitted by the FB [9]. This mechanism should act as an ED, as already discussed in Section III, which stores all events in a queue. A dispatching mechanism (e.g., first-in first-out) notifies and schedules the connected FBs [7], [10]. Events cannot be lost when propagating within the FBN and especially within BFBs [5], [6]. There are only two possibilities that event propagation stops within the application: either (1) the event is not handled within the active ECC state (defined ignoring of events [5]); or (2) the output event of the FB is not connected to any other event input (trivial). A detailed definition of ESK is given in Section III-B4. 3) Execution of SIFBs: There exist two types of SIFBs: the requester and the responder type [1]. The requester type is an application-initiated SIFB. It remains passive until an input event arrives. Therefore, its execution is similar to the BFB type [7]. The responder type is a resource- or hardware-initiated SIFB. If the underlying service (e.g., timer) triggers its execution, it can issue an output event [7] and therefore behaves as an ES. 4) Execution of CFBs: Events can be lost within a CFB only if there are no connections from the FB interface to the component FBs. B. CFB Execution Model The first step when thinking of an execution model for an element of the standard IEC [1] is of course a careful consultation of the standard itself. Therefore, we give a very short excerpt of the main facts regarding the element CFB. 1) Execution control in composite function blocks is achieved via event flow within the function block body. [1, subclause 4.5.3, Note 2]. The rules for the declaration

7 STRASSER et al.: DESIGN AND EXECUTION ISSUES IN IEC DISTRIBUTED AUTOMATION AND CONTROL SYSTEMS 7 of a CFB are the same as for FBN in applications (see e.g., [1, subclause 5.3.1]). FB instances within the FB body are called component FBs. 2) Use of the WITH qualifier in the declaration of event inputs of composite function block types is required. Use of the WITH qualifier may result in the sampling of the associated data inputs as in the case of basic or service interface function blocks. [1, subclause e])]. 3) If an element declared... (data inputs and outputs)... is associated with an input or output event, respectively, by a WITH construct, this will result in the creation of an associated input or output variable, respectively, as in the case of basic function block types. [1, subclause 5.3.1, Note 2]. 4) The behavior of instances of CFBs is described in [1, subclause 5.3.2]. Events that occur at the composite/component FB interface cause the generation of an event at the associated (connected) composite/component FB interface. Based on these considerations, we can think of two very different execution models possible for CFBs. The first one is related to the execution model of BFBs, which we have characterized by a single run. The second one is more or less motivated by the wish to have a means for the hierarchical engineering of FBNs. Therefore, the borders of the CFB should be transparent for execution. There may be other intermediate models also possible. Based on our experiences, these two are most relevant at the current stage of IEC ) CFBs as an Entity: The basic idea of this paradigm is that there exists a single run for CFBs in the same way as described for BFBs. If the execution of the CFB is triggered by an input event, all actions that have to be performed according to the FBN in the FB body are executed in a critical region. What does this mean in case of a simple example? Fig. 6 depicts such a simple example of a CFB consisting of four component of FBs. If the execution is triggered by the event CompositeFB.EI1,this means that at first the data value of CompositeFB.DI is latched, second FB1 is executed, then FB2, FB3, and FB4 (assumption: data values do not influence the execution order). If we assume that the occurrence of FB4.EI1 results in the occurrence of the output event FB4.EO, then the last step of execution would be the registration of the output event CompositeFB.EO1 to the ED (including data latching of CompositeFB.DO). In the case of the occurrence of CompositeFB.EI2, the execution behavior will be analogous. The important fact is that the runtime environment does not execute any other occurring input event of CompositeFB. This could be possible due to an SIFB that is triggered by its service during the execution of CompositeFB. Therefore, this solution can be easily understood by the engineer, because at engineering time he can clearly describe the behavior of the FBN within the CFB. There will be only one input event at one time. This event will propagate through the internals of the CFB until everything is calculated. This understanding of the execution of a CFB is rather close to the understanding within IEC [8]. Of course, there is no event interface available in the IEC , but due to the underlying cyclic execution the engineer is aware that the CFB will be calculated at once. To summarize the execution of CFBs as an entity, we point out some characteristics of this approach, which are as follows. 1) Reactivity of the FBN: During the execution of the CFB, the runtime environment is blocked. The only exception is the execution of responder-type SIFBs. As there is no limitation for the size of the component FBN within the CFB, the runtime environment may be blocked for a long time. In [5], Sünder et al. claimed that it is good programming style to have short algorithms due to yield in a high reactivity of the application. This paradigm enables to block all other applications within a device/resource for a long time. In case of an EC concept with real-time constraints, the reactivity of more important parts of the application is still given. 2) Responder-type SIFBs within the CFB: The procedure of execution described earlier implies that the CFB is activated by the application. But it is also possible/useful that instances of SIFBs can be component FBs of a CFB. If this SIFB is of type responder, also the overall CFB will become of the same type. It can be triggered by any input event of the CFB interface, and additionally it is possible to activate the execution of a resource-triggered output event of a component SIFB. From the point of engineering, the execution behavior can be described exactly at engineering time in this case also. Since each activation of the CFB is handled as an entity, the different sources of FB invocation have to be handled sequentially by the ED (also if the component SIFB event output issues an event during execution of its parent CFB). 3) Data consistency: Another important aspect for the execution of a CFB is the consistency of its data. In this case, the input data is of special interest. Due to the paradigm of execution as an entity, during the overall execution of one invocation of the CFB data inputs of the CFB are stable. If the invocation of the CFB is based on an output event of a component SIFB, the actual values of the data inputs belong to the latest invocation by a CFB interface event input (of course according to the WITH qualifier). 2) CFB as a Transparent Container for Events: Within this paradigm, an event output of a component FB within a CFB is handled in the same way as any other event output within the application. This means that if an output event of a component FB emits an event, this event is put into the ED (common for the whole runtime environment). This behavior has been stated explicitly by Dubinin and Vyatkin: For the purpose of defining clear execution semantics the hierarchical FB structures can be reduced to the flat ones consisting only of basic FBs [9, Sec. 2.5]. They claim that the introduction of data variables for each data connection is sufficient to describe the same behavior in case of a flat FB structure. The data buffers are necessary to achieve the same behavior as in the hierarchical structure; furthermore, the standard claims the WITH construct. So what does this paradigm mean again for the simple example shown in Fig. 4? If the execution of the FB is triggered by the input event CompositeFB.EI1, then FB1 will be executed after latching of the associated input data. FB1 finishes its execution by emitting the output event FB1.EO, which is registered

8 8 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART C: APPLICATIONS AND REVIEWS Fig. 4. Example of a CFB. to the ED. During the execution of FB1, an SIFB instance of type responder may be triggered. Therefore, this event will be executed before FB2 will be executed. Of course, there may be also several other events that are stored within the ED at the time the invocation of the CompositeFB takes place. According to the dispatching algorithm, this will result in quasi-parallel execution of the CFB and the overall application. In our example, this means that the sequence of execution is then FB2, FB3, and FB4, but there may be several other FBs from the application executed in between of these steps. At this point, there may be no difference between the execution of CFBs as an entity and this paradigm of a transparent container for events. But there may happen also invocations of CompositeFB during its execution. Let us assume that CompositeFB has been invoked by the input event CompositeFB.EI1, and at this moment FB2 is executed. Now think of two different situations, which may happen, for instance, due to an SIFB of type responder. 1) The event input CompositeFB.EI2 is issued to the ED. After finishing the execution of FB2, the event FB2.EO is issued to the ED. The next event that will be executed is CompositeFB.EI2, which leads to the invocation of FB4.EI2. After execution of FB4, FB3 will be executed and then FB4 again. If we consider the situation from the perspective of CompositeFB, this means that the event propagation from CompositeFB.EI2 to CompositeFB.EO has been faster than the event propagation from CompositeFB.EI1 to CompositeFB.EO. The main question is if an engineer is able to think of all such situations (in case of more complex and deep structured FBs, this becomes even more relevant) to decide whether his FB behaves in the way he suggests to do? A standalone simulation of the CFB will not help to decide this in an easy manner. 2) The event input CompositeFB.EI1 is issued to the ED. After the event FB2.EO has been issued to the ED, FB1 will be executed by invocation with the event FB1.EI. This means that the data value of CompositeFB.DI is latched again. The execution order without any further disturbances will be FB3, FB2, FB4, FB3, and FB4. The first time FB4 is executed in this sequence relates to the first invocation of CompositeFB. But the data that will be latched for its execution belongs to different invocations of CompositeFB. (FB4.DI1 to the first, FB4.DI2 to the second). This means that the first execution of FB4 within this sequence is based on inconsistent data. To summarize and to compare the execution of CFBs as a transparent container for events, we use the same categories, as already applied in Section IV-B1. Fig. 5. CFB for the case study. 1) Reactivity of the FBN: The CFB is not executed at once, but each component FB of the CFB is executed at once (BFBs or SIFBs of the responder type). If the component FB is a CFB by itself, again each component FB of this component FB will be executed at once. Between each of these component FBs, any other FBs that have been invoked within the runtime environment will be executed. Therefore, the overall execution time for a CFB will be greater than or equal to the sum of the execution times of all component FBs. But the overall application will be much more reactive, since the maximum length of blocking of the runtime environment is the execution time of a single component FB. 2) Responder-type SIFBs within the CFB: An SIFB instance of responder type is handled similarly to all other component FBs of the CFB; furthermore, it is handled similarly to all other FB instances within the runtime environment. As all event outputs are passed through the ED, there is no difference for the execution model whether the CFB is invoked by the application (requester type) or it acts as a responder type due to its component FB. Please note that a CFB may be executed application- and resource-triggered at the same time! 3) Data consistency: The topic of data consistency has been already addressed by the example described earlier. Due to the transparency for events, it is possible that the data inputs of straightforward event propagation within the CFB can be changed by the (re)invocation of the CFB. This situation is very complicated for the engineer to investigate at design time. Therefore, this behavior of data inconsistency is one main disadvantage of the paradigm of transparent container for events. 3) Case Study for CFBs: In order to describe the differences and implications of the two execution models for CFBs presented in this section, we provide a case study for a very simple CFB. The main idea for this case study is that a CFB consisting only of BFBs can be represented as one BFB. The example is depicted in Fig. 5 and it consists only of two component of FBs. FB1 is of type FBalg, the ECC of FBalg is depicted in Fig. 6(a). This is a very simple FB capable of executing one algorithm for initialization and one algorithm for common operation. The second component of FB, FB2, is the event FB E_REND, asit is defined in [1, Annex A]. Fig. 6(b) depicts the ECC for the E_REND FB.

9 STRASSER et al.: DESIGN AND EXECUTION ISSUES IN IEC DISTRIBUTED AUTOMATION AND CONTROL SYSTEMS 9 Fig. 6. ECCs of (a) component FBs FBalg and (b) E_REND. Fig. 8. ECC of an analog BFB for the execution of the CFB as a transparent container for events. Fig. 7. ECC of an analog BFB for the execution of the CFB as an entity. If someone would model a new BFB capable of the functionality of this CFB, the procedure may be as follows. Take the ECC of the E_REND FB type and add 1) the INIT sequence to the state START; 2) add the algorithm REQ to the state EI1; and 3) add an intermediate state within the transition from state EI2 to state EO that executes the algorithm REQ. But how does the adequate ECC of a BFB look like, if its execution is based on the different execution models? 1) CFBs as an entity: If we assume that the CFB is executed as an entity, the adequate ECC of an analogous BFB can be described in a very simple manner. As the invocation of an input event is processed at once, the event propagation FB1.CNF to FB2.EI1 can be described by use of an always TRUE transition. The resulting ECC is depicted in Fig. 7. Again the ECC of the E_REND FB builds the basis. Instead of a transition with event EI1, a module consisting of transition REQ, state with execution of algorithm REQ, transition with guard condition TRUE can be inserted. The main difference to the user-driven approach presented earlier is that the INIT sequence occurs three times, once at each ECC state that is stable (FB execution can stop there). 2) CFBs as a transparent container for events: In case of the second paradigm, the resulting ECC is a little bit trickier. To be able to model an interruption of the ECC execution after the execution of a component FB (e.g. FB1), we suggest the following procedure. Each internal event output that is connected within other component FBs requires an additional event input and event output. The output event is connected with the input event. For instance, FB1.CNF is modeled by use of the event output HO and the event input HI. Therefore, the intermediate states of the ECC in Fig. 5 (REQ1 and REQ2) become now stable ECC states. During the execution of FB1, the input event REQ may occur. This means that FB1 is executed again and the ED includes the event HI twice. Another curious behavior of the FB is if the input event REQ occurs during the execution of FB1 (and a previous execution of event EI2 just before that). This means that the active ECC state within Fig. 8 is REQ2. In this case, the ED holds the event HI twice. To represent the correct behavior within the ECC, the transition from state START to state EI1with the condition HI is necessary. But there is also a different behavior of the FB possible: if state REQ2 is active and CompositeFB receives an R event before HO has been emitted. START will become active, and HI will lead to EI1 as active state. No event EO will be emitted and the resulting active ECC state is different from an execution model according to Fig. 7. C. Subapplication Execution Model At a first glance, the element subapplication of the standard IEC [1] is very similar to the CFBs. We start our considerations again with the most important excerpts about subapplications from the standard, which are as follows. 1) Subapplications are instances of subapplication types, which like applications consist of function block networks. Application names, subapplication and function block instance names may therefore be used to create a hierarchy of identifiers that can uniquely identify every function block instance in a system. [1, subclause 4.4]. 2)...an application or subapplication can be distributed by allocating its function block instances to different resources in one or more devices. [1, subclause 4.6] 3) Instances of subapplication types, as defined in 5.4, shall not be used in the specification of a CFB type. [1, subclause 5.3.1f)]. 4) The WITH qualifier is not used in the declaration of event inputs and event outputs of subapplication types. [1, subclause 5.4.1a)]

10 10 IEEE TRANSACTIONS ON SYSTEMS, MAN, AND CYBERNETICS PART C: APPLICATIONS AND REVIEWS In the case of subapplications, the tutorial information [3] offers an interesting aspect of interpretation. It states that modeling of applications by use of subapplications may include the following step within the engineering tool: Remove the encapsulation around subapplications, exposing their component FBs (...) as distributable elements of the application [3, Sec. 2.5]. Based on these statements, two different scenarios for the execution or usage of subapplications can be found. The first one grounds on the statement that a subapplication is an element that can be instantiated. The second one will not be investigated further since the report [3] has been withdrawn. If we think of a subapplication as a type that can be instantiated, the definitions of the standard in Part 1 [1] can be fulfilled to a large extent. The difference with a CFB type is that there exist no data latching if an event is issued to an input of the subapplication interface. With regard to our investigations in this section, it is clear that the second paradigm has to be adopted for subapplications. The main problem of this paradigm, data inconsistency, can be neglected in the case of subapplications, as it is clear to the user that the consideration of a subapplication is only useful in the context of its applications. Furthermore, communication has to be added for distributed subapplications. Depending on the primitives of the communication network, execution may become more complex. This kind of interpretation is especially valuable for configuration of a runtime environment. As a subapplication type is available within the runtime, it can be instantiated, started, stopped, etc., by single management commands instead of sequences of commands for all component FBs. But the standard lacks clarity in consequence of the statement that subapplications may be distributed. This is in opposition to the statement that subapplication names can be used in a hierarchy to uniquely identify all FB instances. For this purpose, think of the possibility to restore the current system state by use of the query command during runtime. The standard therefore needs to describe in more detail, how to define the type and instance name of a distributed subapplication. V. CONCLUSION This paper presented and discussed different execution models for the execution of FBs in IEC devices and resources as well as the execution of CFBs and subapplications. Especially in the case of CFBs, the behavior of an instance can differ in a very broad spectrum due to the execution model of the runtime environment with respect to the execution of BFBs as well as event-propagation mechanisms. Even if these ambiguities are resolved, there exist different possibilities for the execution behavior of CFBs and subapplications. Therefore, even stricter and more precise provisions are required in order to achieve the main goals of the IEC standard that are portability, (re) configurability, interoperability, and distribution. Our investigations are contributions in order to find a compliance profile for an interpretation of the standard that achieves these goals. REFERENCES [1] IEC, IEC : Function Blocks Part 1 Architecture, International Standard, First Edition, International Electrotechnical Commission, Geneva, , [2] IEC, IEC : Function Blocks Part 2 Software Tools Requirements, International Standard, First Edition, International Electrotechnical Commission, Geneva, , [3] IEC, IEC/TR : Function Blocks Part 3 Tutorial Information, International Standard, First Edition, International Electrotechnical Commission, Geneva, , [4] IEC, IEC : Function Blocks Part 4 Rules for Compliance Profiles, International Standard, First Edition, International Electrotechnical Commission, Geneva, , [5] C. Sünder, A. Zoitl, J. H. Christensen, V. Vyatkin, R. W. Brennan, A. Valentini, L. Ferrarini, T. Strasser, J. L. Martinez-Lastra, and F. Auinger, Interoperability and useablity of IEC 61499, in Proc. IEEE Int. Conf. Ind. Inf. (INDIN), 2006, pp [6] V. Vyatkin, Execution semantic of function blocks based on the model of net condition/event systems, in Proc. IEEE Int. Conf. Ind. Inf. (INDIN), 2006, pp [7] A. Zoitl, G. Grabmair, F. Auinger, and C. Sünder, Executing real-time constrained control applications modelled in IEC with respect to dynamic reconfiguration, in Proc. IEEE Int. Conf. Ind. Inf. (INDIN), 2005, pp [8] IEC, IEC : Programmable Controllers Part 3: Programming Languages, International Standard, Second Edition, International Electrotechnical Commission, Geneva, , [9] V. Dubinin and V. Vyatkin, Towards a formal sematic model of IEC function blocks, in Proc. IEEE Int. Conf. Ind. Inf. (INDIN), 2006, pp [10] M. Colla, E. Carpanzano, and A. Brusaferri, Applying the IEC model to the shoe manufacturing sector, in Proc. IEEE Int. Conf. Emerg. Technol. Factory Autom. (ETFA), 2006, pp [11] J. H. Christensen. (2009, Nov.). HOLOBLOC. com Function blockbased, holonic systems technology [Online]. Available: com [12] R. W. Lewis, Modeling Control Systems Using IEC London, U.K.: IEE Publishing, 2001, ISBN: [13] W. Rumpl, C. Dutzler, A. Zoitl, and F. Auinger, Platforms for scaleable flexible automation considering concepts of IEC 61499, presented at the 5th IEEE/IFIP Int. Conf. Inf. Technol. Balanced Autom. Syst. Manuf. Serv., Cancun, Mexico, [14] L. Ferrarini and C. Veber, Implementation approaches for the execution model of IEC applications, INDIN04, in Proc. IEEE Int. Conf. Ind. Inf., Berlin, Germany, 2004, pp [15] G. S. Doukas and K. Thramboulidis, A real-time linux execution environment for function block based distributed control applications, in Proc. 3rd IEEE Int. Conf. Ind. Inf., Perth, Australia, 2005, pp [16] J. L. Martinez Lastra, L. Godinho, A. Lobov, and R. Tuokko, An IEC application generator for scan-based industrial controllers, in Proc. 3rd IEEE Int. Conf. Ind. Inf., Perth, Australia, 2005, pp [17] G. Cengic, O. Ljungkrantz, and K. Akesson, Formal modeling of function block applications running in IEC execution runtime, in Proc. IEEE Int. Conf. Emerg. Technol. Factory Autom. (ETFA), 2006, pp [18] A. Zoitl, R. Smodic, C. Sünder, and G. Grabmair, Enhanced real Time execution of modular control soft-ware based on IEC 61499, in Proc. IEEE Int. Conf. Robot. Autom., Orlando, FL, 2006, pp [19] N. Hagge and B. Wagner, Applying the handler-based execution model to IEC basic and composite function blocks, in Proc. IEEE Int. Conf. Ind. Inf., Singapore, 2006, pp [20] PLCopen. (2009, Nov.). PLCopen For efficiency in automation [Online]. Available: [21] R. N. Nagel, R. Dove, K. Preiss, and Iacocca Institute, 21st century manufacturing enterprise strategy: An industry-led view, Iacocca Institute, Bethlehem, PA, Tech. Rep. D148708, [22] European Commission, MANUFUTURE A Vision for 2020, Report of the High-Level Group, 2004, ISBN: [23] Y. Koren, U. Heisel, F. Jovane, T. Moriwaki, G. Pritshow, G. Ulsoy, and H. van Brussel, Reconfigurable manufacturing systems, Ann. Int. Inst. Prod. Eng. Res. (CIRP), vol. 48/2, pp , [24] E. Abele, A. Wörn, C. Stroh, and J. Elzenheimer, Multi machining technology integration in RMS, presented at the CIRP Sponsored 3rd Conf. Reconfigurable Manuf., University of Michigan, Ann Arbor, MI, May [25] G. Cengic and K. Akesson, On formal analysis of IEC applications. Part B: Execution semantics, IEEE Trans. Ind. Inf., vol.6,no.2,pp , May 2010.

11 STRASSER et al.: DESIGN AND EXECUTION ISSUES IN IEC DISTRIBUTED AUTOMATION AND CONTROL SYSTEMS 11 Thomas Strasser (M 09) received the Ph.D. degree in mechanical engineering, with focus on control theory, from Vienna University of Technology, Vienna, Austria. He was a Research Assistant at the Institute for Machine and Process Automation, Vienna University of Technology. He was a Senior Consultant for advanced automation systems at PROFACTOR GmbH, Austria. He is currently a Research Coordinator for electrical energy systems at the AIT Austrian Institute of Technology, Vienna. He is involved in international research projects, mainly as a Coordinator and a Senior Researcher. Dr. Strasser is a member of the IEC Subcommittee (SC) 65B/Working Group (WG) 15 Team for the IEC Standard. He is the Co-Founder of the IEC Open-Source Initiative Framework for Distributed Industrial Automation and Control. James H. Christensen received the Ph.D. degree in chemical engineering in computer science from the University of Wisconsin at Madison, Madison. He is currently at Holobloc Inc., Cleveland Heights, OH. He is an internationally recognized expert in the standardization and application of advanced software technologies to the automation and control of manufacturing processes. Dr. Christensen was the recipient of the Rockwell International Engineer of the Year and Lynde Bradley Innovation Awards in 1991for his achievements in pioneering applications of object-oriented programming in Smalltalk and the IEC 1906 Award and membership in the Process Automation Hall of Fame in 2007 for recognition of his accomplishments in international standardization of programming languages and architectures for industrial automation. Alois Zoitl (M 09) received the Ph.D. degree in electrical engineering, with the focus on automation and control technology, from Vienna University of Technology, Vienna, Austria, in Since 2002, he has been at the Automation and Control Institute, Vienna University of Technology, where he is currently the head of the Agile Control Group. He has participated in several research projects with direct relation to industry. His research interests include low-level control of manufacturing system with the focus on distributed reconfigurable real-time control systems based on IEC Dr. Zoitl is a member of the IEC Subcommittee (SC) 65B/ Working group (WG) 15 Team for the IEC Standard. He is the Co-Founder of the IEC Open-Source Initiative Framework for Distributed Industrial Automation and Control. Christoph Sünder received the M.Sc. and Dr.Sci. degrees in electrical engineering from Vienna University of Technology, Vienna, Austria, in 2004 and 2008, respectively. He is currently a Safety Manager for main line interlockings at Thales Rail Signalling Solutions GesmbH, Vienna. He was a Research Assistant at Automation and Control Institute, Vienna University of Technology, and was involved in the discussion for execution semantics of IEC61499 within the O3neida organization and worked in cooperation with industry on the topics of this paper.