The International Electrotechnical Commission (IEC) Bridging the Gap Between PLC Programming Languages and Distributed Systems VALERIY VYATKIN

Transcription

1 BRAND X PICTURES Bridging the Gap Between PLC Programming Languages and Distributed Systems VALERIY VYATKIN The International Electrotechnical Commission (IEC) 6499 architecture [] incorporates several solutions of the known distributed automation challenges. It bridges the gap between the popular programmable logic controller (PLC) programming languages and distributed systems. The result of the design in IEC 6499 is an executable specification of a distributed automation systems. However, it was found that the standard s definitions related to the execution are incomplete and leave sufficient freedom for interpretation. In this article, we discuss the semantic problems of the standard and outline the ideas of some solutions currently being developed. The article is structured as follows. In the System-Level Design for Distributed Automation section, we give a general introduction to IEC 6499 in terms of its value for the automation systems developer. In the Elements of IEC 6499 Architecture section, the basic elements of the IEC 6499 architecture are presented using an illustrative example. The semantic problems of IEC 6499 are outlined in the Semantic Problems of IEC 6499 section. The Semantics of a Basic FB section focuses on the problems and solutions related to the basic Digital Object Identifier 0.09/MIE IEEE INDUSTRIAL ELECTRONICS MAGAZINE n DECEMBER /09/$26.00&2009IEEE

2 function block (FB) behavior. It is followed by the Semantics of FB Networks section that discusses semantic problems related to composite FB structures. In the Conclusions section, we list some open problems. System-Level Design for Distributed Automation The design of distributed automation systems is complicated by the fact that there is no single programming language in which the developer could describe the entire system, including the logic of each control node and their interactions. The control nodes are usually implemented using PLCs, possibly interconnected via various communication networks. Recently, many other information sources and consumers have appeared in industrial networks besides PLCs, for example, intelligent sensors and actuators, such as motor drives or human machine interface devices. The overall behavior of such distributed systems can be rather complicated and sometimes sensitive to subtle changes in the behavior of each participant. The changes can be caused not only by the internal logic but also by a variation in operating systems, network protocols, hardware performance, etc. Until recently, it was difficult for a designer to capture the decentralized logic of a distributed application within a single design framework, with sufficient details of each device and their communication that would allow easy mapping and remapping of the core-decentralized logic to different hardware architectures of networking control nodes. The IEC 6499 architecture [] was conceived in anticipation of the demand for distributed automation. It incorporates several solutions facing the distributed automation challenges. It can be said that IEC 6499 proposes a system-level design laguage for distributed measurement and control systems, thus bridging the gap between the popular PLC programming languages and distributed systems. According to the IEC 6499 model, a distributed system consists of computer devices equipped with interfaces to the environment, such as communication networks or physical machinery and processes. The universal design artifact of the IEC 6499 architecture is an FB. FBs not only can be used for describing decentralized control logic but also for describing properties of devices, such as their interfaces. To combine several FBs into an application, they are connected by event and data-connection arcs. Thus, the complete functionality of a distributed control system can be represented in terms of FBs and connections between them. Control engineers have always imagined better portability of programs between programmable controllers. The need to run a program on another type of hardware arises often and for many reasons. Toward this goal, programming languages of PLCs were standardized in 993 in the IEC 63-3 standard [5], and now, all major PLC vendors claim compliance of their products with this standard. However, unlike in personal computers, it is not easy to have a program run on a PLC of some other vendor. The problems can be due to different syntax but, in many cases, attribute to the different semantics of certain program structures. Another engineering problem refers to modular design. Automated machines are often built from relatively autonomous modules, each with its own control function. Intuitively, it is beneficial to organize the control code following the structure of the machine. For that, control functions of individual modules need to be encapsulated in program organization units (POUs), which can be assembled in bigger control programs of complete machines without changes to their internals.often,anewmachinereuses many mechanical components from the previous model as does the control program. Moreover, it can be beneficial to the design control of a machine in a more abstract way, without thinking at early design stages about the exact hardware architecture on which the code will run. Indeed, in many cases, the hardware can vary while the functionality and control code can remain (almost) the same. For example, the hardware can be a single PLC or a number of smaller PLCs connected via network. Thus, allocation of POUs to particular control devices shall be shifted to the later design stages. But, it was found that POUs of PLC programs do not always ensure correct encapsulation, since the code encapsulated in such POUs can behave differently depending on the context in which it is invoked, as illustrated in [6]. Different allocations can imply different context, thus changing the behavior of the overall system. Thus, portability happened to be tightly interrelated with encapsulation. The lack of portability can be due to the differences in syntax or semantics of certain programming language commands but, more generally, because of the different context in which POUs are invoked. This problem diminishes the benefits of modular design and is very common in the development of distributed control systems. The IEC 6499 architecture offers several semantic and syntactic provisions for portability. The encapsulation concept of IEC 6499 guarantees protection of the internal data of FBs. Blocks can only be invoked explicitly by passing events to them. Composite FBs can contain other FB instances, thus providing a flexible mechanism for modular design. On the syntactic level, there is a vendor-independent extensible markup language (XML) format for all design artifacts and device management commands, which enables easy exchange of source files between tools of different vendors, as well as interaction of tools with devices of different vendors. Elements of IEC 6499 Architecture The central structural unit of the IEC 6499 architecture is an FB. FBs have clearly defined interfaces of event and data inputs and outputs. Event inputs are used to activate the block. An FB may have internal variables that are fully protected, i.e., not directly accessible from the outside. As a result of internal computations, the block may change output data DECEMBER 2009 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 4

3 variables and emit output events, which if connected to event inputs of other blocks, will activate them. To illustrate the FB design and execution rules, we will use an example of a pneumatic cylinder presented in Figure (a). The cylinder shuttles back and forth, either from the left to the middle position or from the left to the end position, depending on the selected mode of operation. The mode is selected by pressing the MODE button that has two physical positions, one corresponding to the value zero and the other to the value one. When any object crosses the safety light curtain, the operation has to stop until the object leaves the safety zone. The light curtain signal is connected to a specific controller input that generates an interrupt at every change of the value. In terms of FBs, the interrupt is translated to an event at the input of an FB. The buttons and MODE are also generating interrupts, which are also represented as events. The IEC 6499 application for control of our system is presented in Figure (b). The central part of the application is an FB CONTROLLER, an instance of FB-type CYLINDER_CTL. This FB has six logic inputs, corresponding to both and MODE buttons, three discrete position values (HOME, MID, and END), and the logic status of the light curtain (ON). Also, there are four event inputs. is used for FB initialization. The BTN event input indicates a change in a button state (pressed/released), the SENS event input is raised when the cylinder arrives to one of the three discrete positions, and the LGHT event input indicates a change in the light curtain status. ThedataarrivetotheCONTROL- LER FB from three service interface FBs (SIFBs): BUTTONS, POSITIONS, and LIGHT. The first and the last ones implement the resource-initiated service model, i.e., upon any change of the source signal, e.g., light curtain status, the corresponding FB is activated without any input event and produces an output event CNF and an updated value of the data. The second SIFB POSITIONS (of FB-type ENCODER) is of a different nature, and it needs to be invoked by its event-input REQ to recompute its outputs based on the displacement of the cylinder. Note that the displacement value is assumed to be available for the block internally, rather than through an explicit input variable. To ensure regular update of the position values, the POSITION FB is activated periodically using an instance of E_CYCLE FB as a pulse generator. The CONTROLLER FB in our example is implemented as a basic FB (an instance of CYLINDER_CTL basic FB type). Behavior of basic FBs is determined by a state machine called execution control chart (ECC). ECC semantics is similar to that of a Mooretype finite automaton. States of ECC can have associated actions, each consisting of invocation of an algorithm and emission of an output event. Algorithms can be programmed in different programming languages even within a single basic FB. Thus, basic FBs can be regarded as a portable abstract model of a single controller. The control logic FB CONTROL- LER computes four output signals: two actuators, LEFT and RIGHT, and two indicators. LED is used for lighting the button in those times of operation when it needs to be sensitive to a hit, and OPMODE is used to display the current operation mode (i.e., Zones 0 or ). The interface, ECC, and some algorithms of the CONTROLLER FB are shown in Figure (c). Note that the algorithms in CYL- INDER_CTL are written in different programming languages: some in ladder logic diagrams and others in structured text. Each algorithm invocation results in a single scan through the ladder diagram or code. FB instances can be connected with one another by event and data-connection arcs, forming FB networks. The connections define control and data flow between FB instances, thus determining the network s execution semantics. FB networks are seen as an universal model of control systems, both distributed and centralized. In distributed systems, FB instances included in a network can be regarded as independent processes. Communication between them is abstractly modeled by event and data passing, whichisassumedtobeinstantaneous. However, in a real-distributed system, communication is not instantaneous and sometimes even not reliable. The IEC 6499 standard includes a mechanism to add more detail to the abstract FB network model of a system. An application s FBs can be allocated to distributed devices, and communication FBs are inserted whenever event or data connections cross borders of devices. The result of this mapping operation is called system configuration. This is illustrated in Figure 2. For reuse, FB networks can also be encapsulated in components such as composite FBs and subapplications. Semantic Problems of IEC 6499 To completely and precisely determine the behavior of a distributed application, it is important to know the rules of FB execution, i.e., semantics. The IEC 6499 standard defines the semantics for basic and composite FBs and their networks. These definitions have attracted attention of many researchers and have been the focus of several research projects worldwide, which led to the formation of the international organization O 3 neida [4], whose focus is now in extending the development and promotion of distributed intelligent automation, in general, and IEC 6499, in particular. Even the first studies, conducted during the standard s development and trial period of industrial and academic approbation (about ), have indicated some semantic weaknesses. Thus, some ambiguities related to the lifetime of event variables in ECC evaluation were reported in [2], and the possibilities of different FB scheduling in composite structures were studied in [3]. The final text of the standard has taken onboard some but not all of the findings and not always in a satisfactory way in our view. For example, an early draft of the standard was 42 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n DECEMBER 2009

4 MODE Zone CPU Start mode 0.. opmod Left Right LED encod Air Air Zone 0 light IN-INTIN-Log MODE OUT-Log 0.. E (a) BUTTONS O WARM REQ CNF O BTN REQ CNF WRITE_2 LGHT DO 2 O SENS READ_2 E_RE ACTUATORS CONTROLLER COLD DI DO2 7 DI2 CYLINDER_CTL POSITIONS PERIODIC O REQ CHG E_CYCLE ENCODER 4 LEFT MODE RIGHT HOME LED MODE_DISP OPMOD MID 3 DT LP END MP ON O REQ CNF WRITE_2 DI 6 RP 8 DI2 LIGHT O CNF READ_ DO 5 (b) Interface ECC Algorithms BLK:=; LGHT and Z0 and Not ON BLOCK WAIT O LEFT:=0; RIGHT:=0; RESET O BTN BTN LGHT and Z0 and Not ON CHG:= not(mode = OPMD) CHKMODE STOP LEFT:=0; RIGHT:=0; S_3 HOME S_0 S_0 S_ END S_ END S_0x S_x LGHT LGHT and ON SENS CTL UNBLK BLK:=0; S_2x SENS LGHT Not CHG CYLINDER_CTL LEFT MODE RIGHT HOME MID LGHT and ON S_2 S_3x CHG CHG LED CHG0 CHG0 SELECT ;CHG0 S_0:=S0_0; S_:=S0_; S_4:=S0_2; Not CHG ZONE0 CTL0 ZONE SETSTATE0 ON S_3 MID S_4 HOME SETOUTS0 S_4x MODE = MODE = 0 OPMOD END MID MODE= and Not BLK MODE = 0 CHG0 S_3 SETSTATE CTL S_0:=S_0x; S_:=S_x; S_2:=S_2x; S_3:=S_3x; S_4:=S_4x; SETSTATE BTN and CHG BTN and CHG SETOUTS SETOUTS MDCOPY OPMD:=MODE; CHG:=0; LED:=S_0!S_; RIGHT:=S_; Z0:=S_4; LEFT:=S_3; (c) FIGURE (a) Pneumatic cylinder with two modes of operation and a safety light curtain. (b) FB application of the cylinder control: the controller FB connected with service interface FBs reading sensor values from inputs and writing actuators values to the outputs. (c) FB implementing the cylinder controller: interface, ECC, and some algorithms are shown. DECEMBER 2009 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 43

5 prescribing in an FB implementation to store a copy of event-input variable value (so-called latch). Because it was shown in [2] that the latches still can lead to a loss of input events, they were completely removed from the text. This amendment is not very essential in our view for preventing incorrect behavior. However, a more essential recommendation concerning conditions of transitions going out of an ECC state to have a logically complementary set of conditions (e.g., their OR always to be TRUE) was not added. In subsequent works, e.g., [8] [0] and [22], the ambiguities of the IEC 6499 semantics were classified and analyzed in detail, showing a possible impact of different interpretations on the correctness of control applications. Implementation of IEC 6499compliant devices and systems is achieved by compilers translating the source code of FBs and applications built thereof into executable code, and/or by run-time environments interpreting the source code or the compiled executable code. When developing such compilers, many implementers can take different decisions on ambiguous issues, and, as a result, the same control application will run differently in the control devices of various vendors. Diverse interpretations of the standard s text can add to the confusion even more. Without revealing sensitive commercial details, we would like to cite two examples. One of the implementers incorrectly understood the term transition clearance in the Application standard s text, interpreting it as clearance of event variables. As a result, the implementers decided to clear event variables at the end of an FB invocation so that an event variable could be used several times. Such interpretation differs much from the standard s prescription to use the event once. Another company has developed a built-in interpreter tool of FBs along with a compiler for some embedded targets. Because of the lack of attention to the semantic issues, the same FB runs differently in the interpreter and after compilation and deployment. Investigation of the semantic issues of FBs happened to be a very exciting research activity, with research methods ranging from computer science to somewhat like legal studies. Indeed, analyzing the Device FB2 Device Border Crossing Points: Here communication FBs for interdevice communication are to be inserted. FB2 FB FB Device 2 FB3 FB3 Device Device 2 FB2 Subscribe FB Publish Subscribe FB3 Publish Network FIGURE 2 Distribution of the application across two devices: the connections between blocks that are mapped to the same device are preserved. The connections crossing the device boundaries are appended by communication FBs [6]. 44 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n DECEMBER 2009

6 standard and deriving from its text, formal models of FB execution is not a very formal process requiring interpretation of a semiformal document. Sometimes, the text is insufficient to make an unambiguous conclusion, so other relevant sources have to be taken into account. Two major groups of issues in FB semantics have been spotted and investigated by researchers. The first is the behavior of basic FBs, and the second refers to the semantics of FB networks, which form applications and a body of composite FBs and subapplications. An application built of FBs already represents a model of a distributed control system. However, the system configuration is a step closer to the reality, since it includes details of devices and communication between them. Obviously, the semantics of distributed systems is even more complex to describe, as it is very much dependent on the properties of communication networks. The distributed semantic models for IEC 6499 are yet to be proposed. In 2006, O 3 neida [4] formed a taskforce aiming at the development of a document, removing ambiguities of the standard. Such a document is called a compliance profile on execution semantics. In this article, we present some of the findings produced in the course of compliance profile development. Respecting the provisions of the standard is very important when a commercial implementation is developed. In our view, removal of ambiguities from the standard does not mean it is not good. When developers attempt to create devices and tools that are compliant with IEC 6499, they shall follow the letter of the standard (whenever possible) or its spirit (when the letter is insufficient). We have to admit that academic developers who strictly follow the standard in this way have not often been spotted. But, this can be explained by the research nature of their work and the need to broaden their horizons and to see new challenges in distributed automation. The industrial implementers have to be more careful in the standard s interpretation to achieve true portability of their products. Semantics of a Basic FB A basic FB is activated by an event input. Thus, in our example, CON- TROLLER is a basic FB, and it can be activated by event arrival to any of its four event inputs. A reaction to an event is determined by the evaluation of ECC and invocation of algorithms. Event outputs can also be emitted in states after the associated algorithms are executed. A single invocation of FB and subsequent executions of ECC and algorithms are referred to as a single FB run. A number of standard s prescriptions imply that the run is atomic, i.e., it cannot be interrupted by some other FB. Also, it has to be reasonably short, to avoid starving other FBs waiting for execution. It turns out that ECC states can be of two types: those where the ECC can stop and wait for incoming input events (let us call them sensitive) and transitional, which are just passed during a run. In Figure (c), sensitive states are outlined by a gray shading. The order of ECC transitions evaluation follows their order in the textual XML-based representation of the FB. However, in the graphical representation, no hints were provided to determine the order. This can result in two ECCs looking identical but producing completely different reactions. The syntax of ECC transitions is defined ambiguously. In one place, the standard refers to event-input variables, thus implying that several such variables can be used in the same expression. However, the normative Annex explicitly defines the syntax of ECC transition condition as ½event inputšj ½Boolean expression over datašj ð½event inputš& ½Boolean expression over datašþ: () The impact of the syntax is quite substantial. If more than one event variable was allowed in the transition conditions, it would imply the possibility of several events arriving simultaneously at the FB inputs. This would defy the atomic nature of the single FB run. It would also allow checking the simultaneous arrival of events that is impossible with only one event-input reference. As we will see later, several implementations of IEC 6499 imply the possibility of simultaneous input events, although it may contradict the standard s spirit. The standard does not provide sufficient details on how to treat event-input variables. Lack of attention to these fine details is explained by the concept of event-driven invocation of FBs, suggesting that there is no need to consider event-input variables as real variables, since they are used only once. However, it turns out that there are many subtle issues around that. For example, the lifetime of their values is not well defined. It seems that the most appropriate solution is to allow such variables to keep their values in the interval between FB invocation until the earliest of two events: either an ECC transition whose condition includes reference to the variable evaluates to TRUE or evaluation of the FB ends and the FB becomes idle, so that no event variable would remain TRUE for the next run. These provisions would imply that in every run exactly one event-input variable is TRUE. Furthermore, the ECC transition syntax allows the omission of event input, i.e., conditions that are only Boolean expression over data. Imagine an ECC state with all outgoing transitions of this type. For example, the SELECT state in ECC in Figure (c) is such a state. If the logical sum (i.e., OR) of all transition conditions going from such a state is not TRUE, then the FB could stop in the state (unlike our case where (MODE¼0) OR (MODE¼) ¼ TRUE). Some implementations, e.g., the FB Development Kit (FBDK) [7], used to treat such states in a quite nonintuitive way, failing to evaluate the noneventful ECC transitions. The FBDK developers DECEMBER 2009 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 45

7 were referring to the concept of event-driven invocation, arguing that transitions from sensitive states must explicitly include event names they are listening to. The standard also does not define when the output events are exactly emitted by a basic FB. This can happen after an action is completed, or after all actions of a state are completed, or at the end of a single run altogether for all states that have been passed through. Letusconsiderindetailsomeof these issues using our example for illustration(seefigure3fortheenlarged ECC fragment). In the WAIT state, the controller is waiting for an input stimulus, which can be any change in the position information (event SENS), pressing of a button (event BTN), or the change in the light curtain status (event LGHT). Upon any of these events, the transition conditions are evaluated, and two of the semantic issues may show their impact. First, the order of transition evaluation may play its role in case if LGHT and SENS occur simultaneously (if the semantic assumptions allow for multiple input events). SENS may coincide with the LGHT event because of the timer-driven nature of SENS, and it is emitted by the tick-generator FB PERI- ODIC. Since the transition priorities are not visible from the graphical representation of ECC, the transition from WAIT to SELECT can be of a high priority than from WAIT to STOP, so the light curtain event will be missed and an accident can happen. Second is the input-event clearance rule. Suppose LGHT event has BLOCK BLK:=; LGHT and Z0 and Not ON BTN WAIT SENS LGHT and Not Z0 and Not ON LGHT and ON FIGURE 3 Enlarged fragment of the ECC of CYLINDER_CTL. occurred, there are three transitions from the WAIT state having LGHT in their conditions. Suppose the transition WAIT -> BLOCK has the highest priority, it will be evaluated first. If an implementation has chosen to use the event only once (regardless of the evaluation result), it will evaluate (to FALSE) the transition WAIT-> BLOCK, and will clear the event variable LGHT, so all other transitions will also evaluate to FALSE and, as a result, the light curtain event will be missed. So, the life of an input event has to be longer. But how much longer? Suppose the ECC transition from WAIT to STOP occurs, the LGHT event should be cleared; otherwise, the next transition from STOP to UNBLK would immediately happen, which would be incorrect. The compliance profile [4] proposes to clear event-input variable after the first transition that includes it and evaluates to TRUE but in the end of the run at the latest. This solution seems to be the only reasonable one. Semantics of FB Networks The semantics of FB networks is determined by the sequence of FB invocation. The abstract event-flow model of IEC 6499 seems to be insufficient to define the execution sequence unambiguously. Several provisions of the standard related to basic FB semantics imply the fact that, in a single FB network (say, in a part of an application allocated to a particular device), only one FB can be active at every moment of time. This conclusion led to two STOP LGHT UNBLK LEFT:=0; RIGHT:=0; BLK:=0; implementation ideas: sequential and cyclic execution models. The sequential model has been justified by sequential hypothesis in [8], formulated as a result of studying and interpreting text of the standard. In the sequential model, attempts are made to ensure that the sequence of emitted events is preserved in the order of invocation of destination FBs. Several implementation ideas of such event serialization have been proposed: ) store events emitted by all blocks in a global queue [9], 2) keep references to the FBs in a queue, recipients of events (in the order of event emissions) [0], or 3) store events in the queues associated with each event input of each FB in the network [], [2]. Once a FB has finished its run, the next FB to be executed will be determined by selecting the FB reference from the top of the queue. The most notable implementation of the sequential model is FORTE run time [24] that is used in two tools: 4DIAC-IDE and nxtcontrol Studio [25]. The cyclic model is justified by the legacy of PLC-based automation systems, in which FBs are invoked periodically in a cyclic manner. When this idea is transplanted to the IEC 6499 (first discussed in [3] and [4] and implemented in ISaGRAF [5]), it can still preserve the unit nature of FB invocation. An unpleasant consequence, however, is the possibility of having several energized input events at an FB invocation. As we have seen in the previous section, in a basic FB, there is no way to distinguish this situation from a sequential arrival of events. The simplest form of cyclic execution may require invocation of each FB in the FB network, as it is done in ISaGRAF [5] [7]. A possible optimization can invoke only those FBs that received events in the previous scan cycle, as proposed in [8]. Another, recently appeared model of the FB network semantics is a parallel model [9]. Its main idea is to allow parallel execution of several FBs. Although the standard favors one FB execution at a time, this requirement stems from the need to execute codes of FBs on single-processor devices. 46 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n DECEMBER 2009

8 This now seems to be a bit outdated. One can use multicore processor architectures or even custom hardware implementation of a given FB network. So, FBs can be executed in parallel, provided that the blocks do not interrupt each other and do not modify internal data of each other. The parallel model has one very important feature: it preserves the semantics of FB applications when they are mapped to different networking architectures of hardware. In the parallel semantics, it is proposed to treat event forking (similar to E_SPLIT FB) as a parallel launch of event-recipient FBs. The next question that may arise is at which pace the concurrent FBs are run. The synchronous model [20] proposes to align the speed of running with global instantaneous event called tick. In particular, in [20], it was chosen to align the tick with one ECC transition in a basic FB, but other ideas are also possible, for example, assume that a single run of any FB exactly takes one tick. Asynchronous parallel model [9] does not make any assumptions on the speed of FB execution. The synchronous parallel model was used in the development of a FB to a C compiler reported in [20]. It must be noted that the compliance profile s provision for the lifetime of event inputs can work in any of the three proposed models. In the case of parallel and cyclic models, when several event inputs can be TRUE at an FB invocation, it is up to the ECC developer to decide how to react to such a situation. All of the event inputs will be cleared at the end of a single run anyway. Thus, the current version of compliance profile does not change the (im)possibility of checking the simultaneity of two input events. The FBDK/FB run-time (FBRT) implementation of IEC 6499 is using an execution model different from the ones mentioned earlier. With respect to a FB network, it implements the depth-first search approach, interpreting an event passing as a direct method call at the destination FB. This execution model was analyzed in [22], where it was named as nonpreemptive multithreading resource (NPMTR). This model, in our view, is not fully compliant to the provisions of the standard but was very useful for quick and simple prototype implementation of IEC In Figure 4, the behavior of our sample application from Figure (b) is presented in the four mentioned execution models. The initialization chain is chosen for the illustration, which starts with the FB. Arrows indicate events passing from block to block. For example, let us consider the sequential execution model. After the resource start-up, the FB emits the COLD output event. It is connected to three FBs. First, it is received by the BUTTONS FB (at the event input). The block will execute and emit the O event that is connected to the CONTROLLER FB. However, before the CONTROLLER FB is activated, the earlier emitted event.coldwillbedelivered to POSITIONS. and LIGHT.. This is seen in the diagram: first, is active, then BUTTONS, POSI- TIONS, and LIGHT FBs (which will emit O connected to MODE_DISP. BUTTONS POSITIONSONS LIGHT PERIODIC CONTROLLER ACTUATORSTORS MODE_DISP BUTTONS POSITIONS LIGHT PERIODIC CONTROLLER ACTUATORS MODE_DISP (a) (c) ), and only after that, the CON- TROLLER FB will be invoked. It will be followed by MODE_DISP, ACTUATOR, and PERIODIC FBs, concluding the initialization process. Alternatively, in the case of cyclic semantics, all of the FBs are assigned with a priority, a number written on each block in Figure (b), defining their place in the invocation sequence. In each scan, the blocks are invoked in the increasing order of their priorities but are invoked only once if they have input events. In the first scan, this results in the sequence of seven FBs having skipped the PERIODIC FB with Priority 3, because when its turn comes, it has no input events. In the second scan, the PERIODIC FB is invoked, then it passes an event to the POSITIONS FB and so on. Strictly speaking, FB invocations following the PERIODIC FB already belong to the working sequence rather than to the initialization. In the parallel execution model, the event.cold invokes three FBs concurrently: BUTTONS, POSITIONS, and LIGHT. Two of them emit output events, invoking concurrent execution of CONTROLLER and MODE_DISP. t Scan (b) (d) Next Scan Legend: Initialization Sequence Working Sequence FIGURE 4 Sequence of FB invocation during initialization in four execution models. Arrows show events passing between FBs. (a) Sequential, (b) cyclic, (c) NPMTR (FBRT), and (d) parallel. t DECEMBER 2009 n IEEE INDUSTRIAL ELECTRONICS MAGAZINE 47

9 Then, PERIODIC and ACTUATORS FBs are concurrently executed, and this concludes the initialization sequence and starts the working sequence of invocations driven by the periodic events emitted by the FB PERIODIC. Obviously, differences in the sequence of FB invocation can lead to different computation results, i.e., the same application may produce different results if executed on devices implementing different execution models. Conclusions The IEC 6499 standard proposed a new way of control systems design based on FBs connected by event and data flow. This new design language has already found many supporters, as it reflects best software engineering practices and brings them to the automation world in an elegant visual form. However, some ambiguities in the execution semantics descriptions gave rise to several semantic interpretations. As a result, three distinct execution models have been formulated: sequential, parallel, and cyclic. It seems impossible at this stage to come up with a single execution model of FB networks, so defining a limited number of models can be seen as a progress toward improving portability of FB applications. The compliance profile [4] follows this approach. It is also quite obvious that differences in execution models show themselves in quite extraordinary conditions, i.e., in the presence of several simultaneously (or nearly simultaneously) generated events. Defining the conditions of execution semantics tolerance (i.e., achieving identical behavior of FB applications in different semantics) seems to be an exciting research topic for the near future. Another clear challenge is to propose a consistent semantic model for algorithms written in PLC languages within basic FBs. This issue has been slightly touched in [23] and [7] but definitely requires further attention. The IEC 6499 has reached certain maturity, and certification on compliance becomes an important task. The compliance profile defining a limited set of execution models can serve as a guideline for the certification. Biography Valeriy Vyatkin (v.vyatkin@auckland. ac.nz) is a senior lecturer and director of software engineering program at the University of Auckland, New Zealand. He is the head of the Laboratory of infomechatronics and Industrial Automation Research Lab (MITRA), with a research focus on the next generation of intelligent automation systems based on self-configuration, plug and play, adaptability, and resilience to faults. His research expertise is software engineering for industrial automation systems, including architectures such as IEC 6499, new methods of automatic validation of industrial automation systems, and theoretical algorithms improving their performance. He has published more than 50 papers in international journals and refereed conferences, and three books including IEC 6499 Function Blocks for Embedded and Distributed Control Systems Design. Heisa member of the IEC Workgroup 5, responsible for IEC 6499 maintenance and cochair of the O 3 neida workgroup developing IEC 6499 compliance profile on execution semantics. He is a Senior Member of the IEEE. References [] Function Blocks for Industrial-Process Measurement and Control Systems Part : Architecture, IEC 6499, [2] V. Vyatkin, H.-M. Hanisch, P. Starke, and S. Roch, Formalisms for verification of discrete control applications on example of IEC499 function blocks, in Proc. Int. Conf. Verteilte Automatisierung (Distributed Automation), Magdeburg, Germany, Mar. 2000, pp [3] L. Ferrarini and C. Veber, Implementation approaches for the execution model of IEC 6499 applications, in Proc. 2nd IEEE Conf. Industrial Informatics, Berlin, June 2004, pp [4] O 3 neida. (2009, Mar.). IEC 6499 compliance profile Execution models of IEC 6499 function block applications, draft in progress [Online]. Available: oooneida.org/standards_development_ Compliance_Profile.html [5] Programmable Controllers Part : General Information, 2.0 Edition, IEC 63-3 International Standard, [6] V. Vyatkin, IEC 6499 Function Blocks For Embedded and Distributed Control Systems Design. ISA/O 3 neida, Triangle Park, NC, [7] Holobloc, Inc. (2009, Sept.). FBDK Function Block Development Kit [Online]. Available: [8] V. Vyatkin and V. Dubinin, Sequential axiomatic model for execution of basic function blocks in IEC6499, in Proc. 5th IEEE Conf. Industrial Informatics (INDIN 07), Vienna, 2007, pp [9] V. Vyatkin, V. Dubinin, L. Ferrarini, and C. Veber, Alternatives for execution semantics of IEC6499, in Proc. 5th IEEE Conf. Industrial Informatics, Vienna, 2007, pp [0] G. Čengić, O. Ljungkrantz, and K. Åkesson, Formal modeling of function block applications running in IEC 6499 execution runtime, in Proc. th IEEE Int. Conf. ETFA 2006, Prague, pp [] K. Thramboulidis and C. Tranoris, IEC6499 execution model semantics, in Proc. Int. Conf. Industrial Electronics, Technology & Automation (CISSE-IETA 06), Dec. 4 4, 2006, pp , Tech. 86. [2] C. Sünder, A. Zoitl, J. H. Christensen, M. Colla, and T. Strasser, Execution models for the IEC 6499 elements: Composite function block and subapplication, in Proc. IEEE Int. Conf. Industrial Informatics (INDIN 07), Vienna, 2007, pp [3] J. L. M. Lastra, L. Godinho, A. Lobov, and R. Tuokko, An IEC 6499 application generator for scan-based industrial controllers, in Proc. 3rd IEEE Conf. Industrial Informatics, Perth, Australia, Aug. 2005, pp [4] L. Ferrarini, M. Romanò, and C. Veber, Automatic generation of AWL code from IEC 6499 applications, in Proc. 4th IEEE Conf. Industrial Informatics (INDIN 06), Singapore, Aug. 2006, pp [5] ICS Triplex. ISaGRAF Workbench for IEC 6499/ 63, v.5. [Online]. Available: [6] J. Chouinard and R. Brennan, Software for next generation automation and control, in Proc. 4th IEEE Int. Conf. Industrial Informatics, Singapore, 2006, pp [7] V. Vyatkin and J. Chouinard, On comparisons the ISaGRAF implementation of IEC 6499 with FBDK and other implementations, in Proc. 6th IEEE Int. Conf. Industrial Informatics (INDIN 08), Daejeon, Korea, July 2008, pp [8] P. Tata and V. Vyatkin, Proposing a novel IEC6499 runtime framework implementing the cyclic execution semantics, in Proc. 7th IEEE Conf. Industrial Informatics (INDIN 09), Cardiff, July 2009, pp [9] V. Vyatkin, Modelling and execution of reactive function block systems with condition/event nets, in Proc. 4th IEEE Conf. Industrial Informatics (INDIN 06), Singapore, 2006, pp [20] L. H. Yoong, P. S. Roop, V. Vyatkin, and Z. Salcic. (2009, Sept. 2). A synchronous approach for IEC 6499 function block implementation, IEEE Trans. Comput. [Online]. Available: society.org/0.09/tc [2] A. Zoitl, Real-Time Execution for IEC 6499, ISA-O3neida, Triangle Park, NC, [22] C. Sünder, A. Zoitl, J. H. Christensen, V. Vyatkin, R. Brennan, A. Valentini, L. Ferrarini, T. Strasser, J. L. Martinez-Lastra, and F. Auinger, Usability and interoperability of IEC 6499 based distributed automation systems, in Proc. 4th IEEE Conf. Industrial Informatics (INDIN 06), Singapore, 2006, pp [23] M. Riedl, C. Diedrich, and F. Naumann, SFC in IEC 6499, in Proc. 3th IEEE Conf. Emerging Technologies and Factory Automation, Prague, Sept , 2006, pp [24] (2009, June). 4DIAC-RTE (FORTE): IEC 6499 compliant runtime environment [Online]. Available: org/8.0.html [25] nxtcontrol GmbH. (2009, June). nxtcontrol Next generation software for next generation customers [Online]. Available: 48 IEEE INDUSTRIAL ELECTRONICS MAGAZINE n DECEMBER 2009