(Contributed by their authors)
Announcement on the Compliance Profile working group creation
Content
1 .Joint publication by OOONEIDA authors
2. Publications by Vyatkin, Hanisch and Dubinin
3. Publications by Wagner and Hagge
4. Publications by M. Colla, et al.
5. Publications by Strasser, Zoitl, Sünder, et al.
Some full papers are available for download here (check the hyperlinks), some are provided at the work group SFTP site.
Christoph Sünder, Alois Zoitl, James H. Christensen, Valery Vyatkin, Robert Brennan, Antonio Valentini, Luca Ferrarini, Thomas Strasser, Jose L. Martinez-Lastra, and Franz Auinger, "Usability and Interoperability of IEC 61499 based distributed automation systems," in 4th IEEE International Conference on Industrial Informatics (pdf).
V.Vyatkin,
V.Dubinin, Execution Model of IEC61499
Function Blocks based on Sequential Hypothesis, working draft (pdf)
V. Dubinin, V.
Vyatkin, "Towards a Formal Semantic Model of IEC 61499 Function
Blocks," in 4th IEEE International Conference on Industrial
Informatics
(INDIN),
V. Vyatkin, "Execution Semantic of Function Blocks based on the Model of Net Condition/Event Systems," in 4th IEEE International Conference on Industrial Informatics (INDIN), Singapore, August 2006 (pdf).
V. Dubinin, V. Vyatkin, and H.-M. Hanisch, "Modelling and Verification of IEC 61499 Applications using Prolog", 11th IEEE Conference on Emerging Technologies and Factory Automation, Prague, September, 2006 (pdf)
V. Dubinin, V. Vyatkin “Formalized definition and modelling of IEC 61499 function block systems”, Letters of Tertiary Education Institutions, Volga region, ISSN 1728 - 628X, Russia, 2005, N 5, pp.76-89 [in Russian] (cover page, first page scan, text in pdf)
This journal paper introduces a way of formal syntax for function blocks and several tricks for function block network flattening such as data valves. Unfortunately, it was in Russian, so the authors have translated main ideas into English and published them in subsequent INDIN/ETFA papers in 2006.
V. Vyatkin,
H.-M. Hanisch,
Practice
of Modeling and Verification of Distributed Controllers
using Signal Net Systems (pdf),
Workshop
on Concurrency, Specification and Programming, Proceedings, Berlin,
October
2000
V.
Vyatkin, H.-M. Hanisch,
Modeling
of IEC 61499 function blocks - a clue to their
verification (pdf), XI Workshop on
Supervising
and Diagnostics of Machining Systems, Proceedings,
V. Vyatkin,
H.-M. Hanisch,
A
modeling approach for verification of IEC1499 function
blocks using Net Condition/Event Systems (pdf),
IEEE conference on Emerging
Technologies in
Factory Automation (ETFA'99), Proceedings, pp. 261--270,
This work deals with the idea of having well-defined interfaces not only on a design level but also on an implementation level even if the code is generated automatically. Code patterns are proposed that reflect the meaning of CNet interface elements. The same is possible for IEC function blocks. This has several advantageous outcomes, e.g.: if different tool vendors use the same code patterns, generated target code can unrestrictedly combined no matter which tool has been used, at the moment often tools from the same vendor are not compatible to each other, sometimes even a version update causes problems. Second, with well-defined interface models designed in different source languages can be combined at implementation levels (adapter pattern)
Transactions on Industrial Informatics, 2005
Introduces CNet and gives a comparison with function blocks. The main difference on the component level is the way connections aremodeled: In CNet data and event flow is expressed together by the flow of colored tokens. Functions blocks have separate data and event connections. This can be problematic in the way that events cause function blocks to sample the wrong data value. Event the draft of the standard 61499 contained such a problem. I had mail conversation with Jim Christensen about this. The problem is shown in the paper and corrected. With a combined data/event flow this could not have been happened.
This paper gives first ideas for code generation for event-discrete behavioral models. CNet is based on Petri nets, which are very strong in modeling concurrent and event discrete (only partially synchronized) processes. Concurrent implementations don't exploit this but perform sequentializations which destroy the concurrency, but allow easier but deterministic target implementation. This was fine in the past. But CNet as well as function blocks are event-discrete models. The proposed and sketched handler-based execution model conserves the event-discrete nature of the design language
This work is about validation. The idea is not only to have design rules how to combine components but to have formal verifiable rules that say that components connection can "make sense". Since Petri nets are formal, it is possible to derive certain properties from the designed models. E.g. if a certain combination of components can create an unbounded number of tokens ("input events") at a component, that model is potentially unsafe and may probably contain design flaws. Such analysis is possible since CNet supports to model the behavior of the plant using the same language elements. This enable the designer to have a closed-loop model of the system. Analysis of single components are required only once and can be stored together with its description in a component library. For function blocks, the IEC standard does not provide anything to support validation in a comparable way. A compliance profile would be a step in the right direction.
This publication focuses on function blocks and an event-discrete execution model. The so-called "handler-based execution model" that has been defined for CNet is abstracted and generalized based on the concepts: resource, event, handler. A resource (don't confuse with the IEC term resource) is a state storage that is able to produce events. Events indicate state changes and other happenings important to the system. Handlers are assigned to events. A handler is a sequence of operations which are executed upon occurrence of "their" events. A special graphical notation (XNet) is introduced to describe how a behavioral model following this concept must be executed/implemented. It is further shown how the elements of basic FB can be mapped to XNet. Composite FB must also be handled with care, since their interfaces are not transparent. They do affect the final behavior and cannot just be omitted. For this reason composite function blocks are first transformed and so-called latch FBs are inserted catching up the behavior of the CFBs interface. With XNet it is possible to visualize (and formalize?) for example how the execution model of FBs has changed from the PAS (in 2000) to the final standard in 2005. Maybe XNet can be used or at least help to describe the "right" execution model of FB in the compliance profile.
A. Zoitl, R. Smodic, C.Sünder, G. Grabmair, "Enhanced Real-Time Execution of Modular Control Software based on IEC 61499", IEEE International Conference on Robotics and Automation (ICRA06), Orlando, Florida, USA, 2006
This work gives a very detailed description of the execution of IEC 61499 models within a control device in Chapter II (it does not mention distributed execution of IEC 61499 applications). It represents our understanding of the models within the standard, e.g. a device has to take care that each resource gets computation time corresponding to the needs of the resource or the contained application. We also state that the kind of delivery of events has great influence to the behaviour of the whole FB network (more details about our event-dispatcher approach can be found in the BASYS'02 or INDIN05 paper). Regarding the FBs and their execution we state the following: - basic FB: remains passive until an input event arrives, the resource is responsible for scheduling the algorithms - composite FB: Internally the CFB behaves like a resource, which handles the internal data and event connections (IEC 61499-1 does not consider nested resources, but they could be a helpful extension to it). - SIFB Requester: execution similar to a basic FB - SIFB Responder: These FBs are the origin of all events! The underlying service can trigger its execution and the sending of output events. As the underlying service can trigger the responder SIFB at any time and indefinitely often these FBs can disturb the execution of all FBNs in the device! (each trigger request needs processing time for execution) Device Management has also to be mentioned for execution within a device. When executing IEC 61499 applications within a device or a resource these management services have great influence on the execution behaviour of the application. They allow the changeability of the application while the application itself or other applications are executing. There should be no impact on the running applications. The rest of the paper concerns to the approach of providing real-time constrained execution for IEC 61499 applications. This seams to be an further topic that may be discussed in this workgroup, but this may be a second step. The first one is to define a sufficient semantic for execution of "normal" IEC 61499 applications. The concepts for real-time execution can be seen as "orthogonal" to the normal execution and may be discussed separately.
Alois Zoitl, Gunnar Grabmair, Franz Auinger, Christoph Sünder: "Executing real-time constrained Control Applications modelled in IEC 61499 with respect to Dynamic Reconfiguration" 3rd International IEEE Conference on Industrial Informatics (INDIN05), Perth, Australia, 2005
This paper consists of 3 main parts. Part 1 (Chapter II) regards to the execution behaviour of IEC 61499 applications in a similar manner as already described in the ICRA06 paper. As ICRA06 is more detailed, the material of this part of the paper is obsolete. Part 2 (Chapter III) describes different ideas for the scheduling IEC 61499 models and is very interesting for the workgroup. The base for scheduling several independent applications parts is pre-emption. This pre-emption mechanisms can be utilized to schedule function block networks. When considering pre-emption for the execution of IEC 61499 applications the two basic elements to discuss are the FB and the resource: FB: If the FB are pre-emptive, this allows quasi-parallel execution of FBs within one resource. But it also produces a big memory overhead and all connections have to be synchronised in a way that the corresponding execution parts do not interfere. resource: If resources can be pre-empted, this will introduce a much smaller memory overhead because there are fewer resources than FBs in a device. The problem of synchronisation is also not directly given. Only the communication via SIFBs is possible. One of the main determinant elements for execution in a FBN are the event connections. They serve as kind of dynamic scheduling program and are responsible for the execution order of the FBs in a FBN. The paper discussed three possibilities of event propagation policies briefly (direct function call, signals, event dispatcher). One idea is to provide different event propagation in one device/resource by use of different event types. Another point of consideration is the separation between ECC execution and algorithm execution introduced by the standard: - The ECC together with the event connections can be interpreted as dynamic scheduling algorithm, only algorithms have to be scheduled. - The FB is considered as entity. The scheduling algorithm triggers the execution of the whole FB. Regarding the scheduling duty of resources and devices also two different strategies can be investigated: - Transfer the FBN-scheduling from the resource level to the device level. - Keep the 2 step approach described by the standard. Part 3 (Chapter IV) of this work describes an first approach of real-time execution of IEC 61499 applications by use of an event dispatcher within the resource and a priority based scheduling policy within the device.
Werner Rumpl, Franz Auinger, Christoph Dutzler, Alois Zoitl, "Platforms for scalable flexible automation considering the concepts of IEC 61499", BASYS02, Cancun, Mexico, 2002
The intention of this work is to enable IEC 61499 execution on embedded execution platforms (slow processor, little memory and small or no operating system) in order to realize small and smart field devices (Chapter 3). Chapter 3.1 introduces an execution model for a single tasking operation system with multi-threading. There should be one thread for management services as well as one thread assigned to each Responder SIFB. Chapter 3.2 introduces an execution model with an event / data scheduler. This means a global event queue (event dispatcher) is used for event propagation. The order of events in the queue is equivalent to their order of occurrence (and this will be their execution order - strict sequential execution according to this order). This concept has the drawback that events and corresponding data might be inconsistent. Two approaches are described in the paper to face this drawback - Storing not only events in a queue but also the corresponding data - Definite Ignoring of Events according to IEC 61499-1: events may be lost while waiting for ECC to finish execution. Please mention that we interpret the occurrence of an event already as starting point of the execution of the FB to apply this rule within the event dispatcher.
Christph Sünder, Alois Zoitl, Bernard Favre-Bulle, Thomas Strasser, Heinrich Steininger, Siegmar Thomas, "Towards Reconfiguration Applications as basis for Control System Evolution in Zero-downtime Automation Systems", 2nd I*PROMS Virtual Conference on Intelligent Production Machines and Systems (IPROMS06), 2006
This paper presents the approach of controlled changes within an application without stopping the execution of the application. This is done by use of an IEC 61499 function block network, that includes special function blocks that are able to access the management interface. This situation is depicted in Figure 2. As defined by the existing compliance profile there is a MGR-resource that provides access to the management service of the device for some external component (e.g. the engineering environment). The task of controlled changes is done by a reconfiguration application. This means, there are even more FBs within the device that can access the management service of the device. The reconfiguration application models exactly the way the changes have to be performed. The general situation is, that now many different FBs have access to the management service. That is not prohibited by the standard. But it is very essential for the execution. - the management service is executed within the device, therefore the device has to schedule this in parallel with the resources (already described in ICRA06). - The occurrence of management commands is not only driven by a tool but also by an application. Therefore the scheduling of event propagation within a resource and the scheduling of resources and management services within the device are tightly coupled in the case of such reconfiguration applications. In this paper we propose a engineering methodology for the modelling of such a reconfiguration application as well as a set of "optimized" management FBs for the use in reconfiguration applications. Our work has shown that the current set of management commands defined in the standard is not sufficient to provide downtimeless reconfiguration of control applications - this may be an additional topic within this workgroup.
Alois Zoitl, Christoph Sünder, Ivanka Terzic, "Dynamic Reconfiguration of Distributed Control Applications with Reconfiguration Services based on IEC 61499", IEEE 2006 Workshop on Distributed Intelligent Systems (DIS06), Prag, Czech Republic, 2006
This paper presents in a more general manner the topic of reconfiguration services that are necessary to provide dynamic reconfiguration (downtimeless changes within running applications). The paper does not focus on IEC 61499 directly. The needed services are described in general and five categories of services are identified: structural services, execution control services, state information services, query services and FB library services. The paper includes the situation defined in IEC 61499 in comparison to the general view. As already described in the IPROMS06 paper, there are services missing in the standard IEC 61499 that may to topic of this workgroup.
Gunnar Grabmair, Roman Froschauer, Thomas Strasser, Alois Zoitl, "Modelling Execution Order and Real-time Constraints in IEC 61499 Control Applications", IEEE 2006 Workshop on Distributed Intelligent Systems (DIS06), Prag, Czech Republic, 2006
This paper includes a detailed description of our approach to the modelling of real-time constraints in IEC 61499 applications. Therefore it is not so relevant for the basic work of the workgroup, but as described for the ICRA06 paper, this may be a possible next step in the workgroup.
© 2006-2007This document authored, composed and maintained by: Valeriy V. Vyatkin All rights reserved
