INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO.

1, MARCH 2010

On the Use of Model-Based IEC 61499 Controller Design

Sebastian Preue, Dirk Missal, Christian Gerber, Martin Hirsch and Hans-Michael Hanisch
AbstractThe IEC 61499 standard provides advanced possibilities and ways to design control applications. Outstanding advantages are for example real object-orientation, event-driven execution behavior, vendor-independency and distributed controller design. Although 5 years have passed by since it has been nally standardized in the year 2005, it is yet not fully accepted among automation engineers. This contribution summarizes the development of formal modeling and verication of Function Blocks following the IEC 61499 and it provides a critical review on what has been done so far. Beyond this, it opens the view for further challenges in the development of formal techniques for IEC 61499. Index TermsIEC 61499, Model-Based Design, Net Condition/Event System, Simulation, Specication, Synthesis, Verication.

I. I NTRODUCTION The IEC 61499 standard [1] provides advanced possibilities and ways to design control applications. The work [2] was to the best knowledge of the authors the rst approach to deal with the IEC 61499 (that was just a draft at this time) in a formalized way and when it was presented in 1999 by one of the authors of this contribution, almost nobody in the audience had any idea what the work was all about. Fortunately, the situation has changed remarkably since that time. Unfortunately, many unsolved problems and questions remain. Therefore, the intention of this contribution is a revision of the work accomplished up to now and a projection of the upcoming issues in future. This contribution is mainly based on the experiences that have been made in the authors workgroup. It includes approaches of other groups, but only to the extent that conclusions can be drawn from that. It is therefore structured as follows. Section II gives a short introduction to the IEC 61499 standard. Afterwards, a plant example is described in Section III that shall serve as a means to explain some procedures of the approach. Section IV describes the general framework of a model-based controller design of IEC 61499 and the results that are available. Section V provides an overview of existing tools and benchmark applications. Finally, Section VI discusses some open issues and gives a conclusion. II. IEC 61499 The IEC 61499 is an industrial standard that denes an open architecture for the design of distributed control applications.
S. Preue, D. Missal, C. Gerber, M. Hirsch and H.-M. Hanisch are with the University of Halle-Wittenberg, Institute of Computer Science, Chair of Automation Technology, Kurt-Mothes-Strae 1, 06120 Halle (Saale), Germany email: {sebastian.preusse, dirk.missal, christian.gerber, martin.hirsch, hansmichael.hanisch}@informatik.uni-halle.de.

The standard provides a generic model for distributed systems, which contains processes and communication networks as a basis for the distribution of applications on devices and their resources. It got nally standardized in 2005 and before that, it has been available as a Public Available Specication since 2000. An IEC 61499 control system is based on Function Blocks (FBs) encapsulating functionalities and their signal interconnection. The functionality is called depending on events. The event-driven architecture represents a light-weight component solution that provides all essential features such as encapsulation of semantics from a particular execution platform, portability, reconguration and a holistic view on distributed applications. Function Blocks provide an interface with event and data inputs and outputs plus associations between events and data variables. Two different general FB types are dened according to their insides. Basic FBs are the basic building blocks. As shown in Figure 1, they consist of a body with data inputs and outputs and of a head with event inputs and outputs. Furthermore, they contain an Execution Control Chart (ECC) that controls the execution of algorithms depending on input events, input data and internal data and that produces output events. Composite FBs contain multiple FBs Basic FBs and/or Composite FBs. In contrast to Basic FBs, Composite FBs do not contain an ECC. The applications, represented by a FB network, can be distributed to any (set of) controller(s) within the system. Finally, Service Interface FBs (SIFB) explicitly dene mechanisms for the interaction of FB applications with hardware resources. That is for example reading the input variables from an input module, which is physically connected to the process that shall be controlled.

Fig. 1.

Basic Function Block.

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

Fig. 2.

IEC 61499 generic system model.

Fig. 3.

EnAS demonstrator.

The encapsulation of controller functions into objects is a very intuitive approach because plants are constructed in a modular and hierarchical way as well. Therefore, the control application for each plant part is represented by its own FB and, as in real world, the FBs are hierarchically composed to build the whole controller structure. Figure 2 displays the generic system model of IEC 61499. The controlled process is connected to devices that execute the control software. Each device has several resources, such as inputs and outputs or memory, and the different applications can access these resources. As the structure is distributed, applications run allocated on one or more devices. The standard features vendor-independency, amongst others, by an XML-based interchange format for FBs and control applications. There is no restriction concerning the applied controller and communication networks, while specic SIFBs are provided. This marks very clearly the benet of IEC 61499 because in contrast to IEC 61131, the controller structure is really object oriented and distributed and allows reconguration at runtime [3] and optimal utilization of resources [4]. III. P LANT E XAMPLE The contribution gives an overview about model-based controller design. Section IV discusses this topic in detail. Not being too much concentrated on theory, an exemplied plant shall be considered to clarify the application of different methods. The demonstrator in Figure 3 is part of the EnAS project1 , which deals with energy self-sufcient actuators and sensors. The testbed consists of two identical plant modules, which are rotated by 180 to each other. Figure 4 shows a CAD drawing of the plant from the birds eye view. The conveyors 1, 2, 3 ) of both modules form a circuit and transport ( pallets cyclically to each processing station in the clockwise direction. Each conveyor is moved by a separate drive, and all six conveyors transport pallets with tins and workpieces inside from one processing station to another. 1 has no mounted processing station and marks Conveyor 4 either removes a lid the wait position. The Jack Station 5 from a tin or deposits a lid on the tin. The Slide Station stores up to two workpieces that are taken from or put inside
1 EnAS

6 either locks the lid the opened tins. The Gripper Station of a tin or lifts up a tin to deposit it on another pallet.

IV. M ODEL -BASED C ONTROLLER D ESIGN The rising size and complexity of controlled systems as well as growing safety and quality requirements cause high demands on controller design. Within the framework of computer aided engineering (CAE), the model-based controller design provides instruments to meet the modern demands. Figure 5 shows the general framework for model-based controller design as it is commonly used in control engineering. One sees that generally there are two ways to get a correct controller. The most elegant one is synthesis. For this, a model of the uncontrolled plant behavior and a formal specication of the desired plant behavior are necessary. By applying a synthesis algorithm that is proven to be correct, a model of the controller is generated that fullls the specications in closed loop. Since the model of the controller is not the implementation of the controller, the control code has to be generated from the controller model. This should be done automatically. Synthesis is described more in detail in Section IV-G. The other way is controller verication. For this, a controller

website. URL, http://www.energieautark.com/, March 2010.

Fig. 4.

CAD drawing of the EnAS testbed.

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

Fig. 5.

Formal methods on controller design.

model, a model of the uncontrolled plant behavior and a formal specication of the desired plant behavior under control is necessary. The formal model of the controller has to be interconnected with the plant model to a model of the closed loop. The formal specication is applied to this closed-loop model by means of model-checking to be veried. This may end up in iterations if the controller is not correctly designed. In both cases, models of the uncontrolled plant behavior and formal specications have to be provided. The models as well as the specications have to be designed by engineers who are experts in designing and operating manufacturing systems but by no means experts in formal methods. Applying such methods even to traditionally PLC-based control systems is by no means easy. Nonetheless, it is the keystone in future engineering methodologies for distributed control systems. Therefore, this section describes what has been done in this eld for distributed control systems following the IEC 61499 so far. A. Plant Modeling If control is seen decoupled from the object that has to be controlled, it is no longer control. It is then merely information processing, in which way ever. It is therefore a domain for Computer Scientists that is called embedded systems or reactive systems. Control, however, means always a closedloop interaction of the controller with the object that is controlled (we call it plant). From this point of view, the plant is the dominating part, and the controller itself is in any case a means to realize a behavior of the plant that is desired. That, in turn, means that the design of a controller without a minimum knowledge of the plant is a very doubtful activity. That does not mean that it is not a severe scientic problem, but related to control, its results can

be only as good as the knowledge of the plant behavior. This contribution focuses on approaches that use a formal plant model that is not only used for simulation but for formal verication (see Figure 5). Modeling techniques for discrete event systems are described in literature for state-machinebased models, for algebraic models and for Petri net models and derivatives. Obviously, designing a plant model is time consuming and therefore a cost factor that must not be underestimated. Designing a model from scratch is therefore not appropriate. A methodology of engineering models in a systematic way rather than designing them is required. Such methodologies are described in [5; 6] for example. Detailed models of the plant behavior are composed of simple component behavior models following the structure of the physical plant. The basic component models of for example actuators, cylinders and sensors are arranged and connected as in the real plant (basic structure as in the plant part in Figure 9). A modular and compositional approach is helpful although it is not the ultimate solution of all problems. The formalism of Net Condition/Event Systems (NCES) has been developed in the authors group. It is often seen as only an extension of ordinary Petri nets by some kind of new arcs that connect transitions. From a formal point of view and after complete composition, this may be true. The major point of interest, however, is not yet another enrichment of Petri net formalisms but a yet formal methodology that is tailored to the needs of engineers and allows real modularity, object orientation (to some extent), behavior encapsulation, block diagram orientation, a concept of signals as usual in control engineering and last but not least a way to engineer models rather than to design them from scratch. While the modeling of plant equipment behavior can be eased through repeatedly using building blocks (e.g., for binary sensors, magnetic valves, cylinders etc.), the model of workpiece properties is mostly process specic. Obviously, such properties must be included in the model since the goal of the whole manufacturing/production process is to perform stepwise changes of these properties, and a major part of the specications are expressed in terms of properties of manufactured goods. Modeling of workpiece properties in manufacturing is relatively simple, at least if compared to chemical engineering. In most manufacturing processes, workpieces are naturally discrete and do not have their own dynamic behavior. If we look to batch processes in chemical engineering that have the strongest similarities with manufacturing, things are much more complicated. The manufactured goods are not naturally discrete, the batch size can continuously be changed, batches can be mixed (blending operations), can be separated (ltration, distillation etc.) and so on. Furthermore, the processed substances have their own dynamic behavior driven by the laws of chemical kinetics, thermodynamics etc. It seems to be surprising, but it is a fact, that such processes are quite well (to a certain extent) understood and controlled. The basis is the concept of Unit Operations that is about 100 years old. Nonetheless, it is the conceptual basis for the method of Recipe Control [7; 8] that is commonly accepted and applied in batch process control.

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

Fig. 7.

Model transformation tool.

Fig. 6.

Simulation model.

checking (see Sec. IV-F) and is performed in combination with a formal specication (see Sec. IV-D). B. Controller Modeling

The methodology as well as implementations [9] show some strong similarities with object-oriented approaches in manufacturing. It is obvious that object orientation is a very helpful issue in plant modeling. It is clear that a plant is a composition of similar or even identical physical components that can be identied and modeled separately. It leads in a very natural way to the concept of Automation Objects [10; 11; 12]. However, the need of manual modeling of workpiece properties remains. The authors workgroup currently works on the OMSIS project2 that deals, among other things, with simulation of plant behavior. The idea of this work is to translate existing plant simulation models to formal models to enable formal analysis. For this, the plant is modeled with a 3D simulation engineering tool. The simulation model of the EnAS testbed is shown in Figure 6 from the birds eye view. According to 1, 2, 3 ), the Jack Station 4 , the Figure 4, the conveyors ( 5 and the Gripper Station 6 are displayed. Slide Station The simulation is converted semi-automatically to a formal NCES model. This is done with the software tool shown in Figure 7 by mapping the modules of the simulation to the corresponding formal modules taken from a library and by recognizing signal connections. The resulting formal plant model is applied further for formal analysis. Although creating a simulation model means additional work and expense, the procedure has some essential benets. On the one hand, it can be proven whether the construction is physically possible and on the other hand, control software can be tested before starting-up the real plant. The project goes one step ahead because the generated formal models can be applied to verify the control software. For this, not only scenarios are simulated, but a whole reachability analysis of all possible states is performed, so that rare but often critical incorrect behavior can be exposed. This procedure is called model2 OMSIS project. URL, http://aut.informatik.uni-halle.de/forschung/omsis/, March 2010.

In early works [13; 14], the authors were focused on modeling the execution control and simple Boolean operations of FBs. Also other researchers found this issue interesting, like for example shown in the work [15] about automatic controller modeling and verication of the closed-loop system with the limitation to use only assignment statements inside the algorithms. But the algorithms inside the FBs, however, change and transmit not only Boolean data but integer-valued data as well. Therefore, transformation rules from the designed FB to formal models representing the execution control as well as the algorithms and internal variables are required. Because of the wide range of functions being available in IEC 61499 algorithm languages, this can only be done for a step by step extended but restricted subset. A rst step is done for variable value operations for the Boolean and integer data type by dening such transformation rules introduced in [16], where models for Boolean and integer-valued data processing algorithms can automatically be retrieved from Function Blocks. Currently, work is done on proving the rules correctness and their implementation. In contrast to [17], the authors use a binary coding of the integer-valued data, which allows to transfer the modeled data values from one module to another one within one step. Furthermore, it allows to derive the used models of integer operations from already proven and optimized methods of computer science to reduce the state explosion problem of the verication and model-checking process. Beside the issue of algorithm modeling, the issue of execution modeling includes some critical problems. The execution of FBs and in this case the scheduling of FBs inside a FB network of a resource differs between different runtime implementations [18]. That is mainly because the IEC 61499 does not exactly dene the execution semantics of FBs within a network. Different implementations handle the situations with more than one FB - ready for or in execution - differently. One approach puts all published events of a FB onto a stack.

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

The last added event is handled rst and the events of the triggered FBs are processed and put onto the stack before the next event of the originally event-publishing FB is handled. Another approach implements event-handling as FiFo. The events of the originally event-publishing FB are handled rst and afterwards the events of the triggered FBs are processed. Again, another one uses an event-scan-based one or a pure cyclic execution instead of an event-driven one. Thus, an engineer developing IEC 61499 applications has to be very careful relating to portability between several runtime environments. In [19] two examples as well as two different formal controller modeling approaches for different runtime environments are presented. Thereby it is observed that one execution model fullls the provided specication and the other one does not. Obviously, a general verication method needs analysis of many different execution models of different runtime environments, what is not manageable for an engineer in everydays practice. But due to the semantic of NCES, a wide range of the mentioned possible implementation alternatives is covered, without using different modeling approaches as done in [19]. Furtheron, at each transformation from a semi- or non-formal description - as IEC 61499 - to a formal one, all transformation rules depend on a formal interpretation of the non-formal source. Therefore, the articles [14; 20; 16] dene successional transformation rules for each part of an IEC 61499 distributed system. As described in Section II, the basic element is the Basic FB consisting of event in- and outputs associated with data in- and outputs, the ECC and algorithms. Figure 8 shows the structure of a NCE Module retrieved from an automatic translation of a Basic FB. Thereby, each structural element is represented by a separate subnet. On the next compositional level, these retrieved NCE Modules are connected to models of Composite FBs or applications. Depending on the application mapping, several FBs are connected to abstract models of SIFBs to connect the control application to the plant and to model the communication channel. Last but not least, each resource model includes an abstract model of the FB E Restart to start the execution model. In the ongoing research work, these abstract models shall be extended for several runtime and hardware congurations. But these examinations about event propagation delays, start-up and communication delay as well as algorithm execution times

Fig. 9.

Closed-loop model scheme.

are beyond the scope of this work. C. Composition Plant and controller models have to be interconnected to a closed-loop model to get a system behavior model. In reality, plant and controller(s) are interconnected via sensor/actuator signals that carry Boolean or integer-valued data. Models should explicitly represent this. If an interested engineer has to examine the interaction among controllers and plant, she or he should see it immediately in the model. Plant and controllers do not exchange any tokens (as it is assumed in the Petri net community), and they do not share common variables or events (as the automata community assumes). They are interconnected via signals that must physically be represented, transmitted etc. In general, these signals do not transfer the complete state information of the plant to the controller but rather information that is important for the operation, as for example end positions or pressed buttons. NCES provide very easy means to compose plant and controller models by interconnecting them via signals. Figure 9 shows the general scheme of signal interactions that is assumed. It is common to any control engineer, and it is the standard paradigm of automatic control that has been shown to be appropriate since decades. Hence, it is well established and applied by the authors without the need to change it. D. Specication A specication in general is a description of a product, a system or a service. Its aim is to dene characteristics and attributes and to explain functionalities. A specication of a technical system should be well-dened and formal. This mathematical basis allows analyzing the system with wellestablished methods and provides an unambiguous description of the system. However, a specication is non-executable because it describes what the system does, but not necessarily how. The automatic transformation of a specication together with a plant model to an implementation is called synthesis. This procedure is described in Section IV-G. Designing a technical plant starts with the description of the desired plant behavior. Based on this specication, the plant is constructed, and the control software is implemented. Usually,

Fig. 8.

Translated Basic Function Block.

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

the design process is team work between engineers with different technical background. So, it is natural that the specication has to be well-dened on the one hand, but also understandable without restrictions on the other hand. This is essential for the exchange of ideas, the documentation, the implementation of control software, the subsequent modernization and migration and last, not least for the analysis of plant and control models. Especially the last point, namely the verication of models, is very important according to safety because in contrast to simulation, verication considers every possible scenario and delivers an assertion of correctness. Previously it was described, how the closed-loop model of plant and controller can be developed. The point of interest is now how to obtain a formal and well-dened specication, which is free from misunderstandings. This requirement is vitally important, if the closed-loop model shall be veried in connection with the specication by the use of a modelchecking tool. A lot of workgroups deal with the specication of behavior of IEC 61499 control systems. For example, the execution behavior of FBs is modeled with timed automata in [21] or with activity diagrams of the Unied Modeling Language (UML) in [22]. However, the authors workgroup is certainly focused on specication of plant behavior. This description is summarized under the synonym of process requirements, which are divided into two categories. On the one hand, safety or nonfunctional requirements examine plant behavior, which is absolutely necessary for a failure-free operation. The constructs contain a small number of variables and are precisely formulated. On the other hand, production or functional requirements check liveliness, the absence of deadlocks and complex production sequences. They examine whether the actual production process corresponds to the required one. In [23] it is described how a specication of plant behavior could be formulated with the Timed Computation Tree Logic (TCTL). This temporal logic allows combining the qualitative temporal assertions together with real-time constraints, what is important for a specication of dynamic behavior. To support

Fig. 11.

Compiler for SOTL.

Fig. 10.

STD Creator.

the user in creating such a description of plant behavior, a graphical specication method was proposed in [24] and [25]. Here, Timing Diagrams (TD) are used to specify production sequences. A Timing Diagram Editor (TDE) was implemented in [26] to translate the diagrams to TCTL formulas. Another graphical method for the specication of production sequences is proposed in [27]. The authors use Symbolic Timing Diagrams (STD) to describe plant behavior in an intuitive way. For the translation of the diagrams to temporal logic formulas, the Symbolic Timing Diagram Creator, shown in Figure 10, has been implemented. It derives Computation Tree Logic (CTL) or extended CTL (eCTL) [28] formulas automatically, so that the engineer has not to be familiar with the complex theory. Regarding the gripper of the EnAS testbeds Gripper Station, the production sequence, which is displayed in the screenshot, can be specied. In the initial state, the sensor gripper up is activated. In the next state, the actuator gripper lower is activated, and the gripper moves down. Consequently, the sensor gripper up is deactivated. Following the sequence of states, the gripper nally reaches the end state, which is equal to the initial state. The STD is translated to the eCTL formula shown at the bottom of the screenshot and can further be applied to the closed-loop model. The UML offers a further graphical specication method. In [29] activity diagrams are used to specify production sequences. The Systems Modeling Language (SysML) is an extension based on UML and provides description methods that are important for modeling of a system. There are essential diagram types available for the specication of plant behavior, namely activity diagrams, sequence diagrams, state machine diagrams and use case diagrams. For static descriptions, SysML offers diagram types like block diagrams, internal block diagrams and package diagrams. An outstanding difference between UML and SysML is the fact that SysML offers requirement diagrams. In these diagrams, textually formulated requirements for a system are graphically represented, and their relationships among each other are shown. The clue is to assign each requirement to one or more according diagram component. By simulating the system, one automatically gets a simulation of the requirements. In [30] the application of the different diagram types and facts on simulation, which are provided by SysML, are described. A text-block-based approach is presented in [31]. The authors

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

use a Safety-Oriented Technical Language (SOTL) to describe safety requirements. The approach is capable of specifying production requirements as well, but due to the problem that text-block-based approaches produce rather long and confusing expressions the more complex the requirements get, the application is limited to short and precisely formulated ones. The language consists of 21 pattern phrases, which are based on a formal grammar. A compiler tool, namely the Compiler for SOTL, shown in Figure 11, has been implemented to translate the SOTL expressions to CTL formulas, so that the approach can further be used for formal analysis. In the screenshot, one can see a SOTL safety requirement for the EnAS testbed. In order to prevent damage, it expresses that the slide of the Slide Station will never move if the vacuum sucker of the Jack Station is lowered. The expression is translated to the CTL formula shown in the gure and can be further applied to the closed-loop model. Normally, the specication comes from an engineer who is an expert in manufacturing but not in the eld of formal modeling or model-checking. The concern of all approaches is to support a user in creating a well-dened description of plant behavior. This specication can be used to provide a welldened documentation but it is reasonable as well to be used for the verication of the closed-loop model. This possibility shall be discussed in Section IV-F. E. Hardware in the Loop Simulation IEC 61499 FBs can be tested within most engineering environments presented in Section V-A. This is done by compiling and executing the FBs. At run-time, the user can force the input values of a FB and can observe whether the output values correspond to the expectation. This test helps simulating Basic and Composite FBs, but it is inappropriate to test the whole application. Furthermore, the control program is executed on a PC and not on the controller, so that it is not tested in a closed loop. In contrast, a Hardware in the Loop (HiL) test is applied, using the hardware controller, which inputs and outputs are con-

Fig. 12.

Hardware in the Loop simulation.

nected to a simulation of the process that shall be controlled. The aim is to test the control software in connection with a model before starting-up the real plant. The test is usually performed considering certain scenarios. For this, the control inputs are set to specic values - manually or by the simulation - and after executing the control program, the output values are evaluated according to consistency. Although this procedure can expose many errors, which occur during usual operation, it does possibly not cover faults, which are rare but the more critical ones because they are not considered. This marks the disadvantage of a classic simulation because passing successfully all tests does not necessarily mean correctness. For this, it is advantageous to combine the HiL test with formal methods. In Section IV-A, a procedure is described how to convert a 3D simulation to a formal model. This formal model can be connected to the hardware controller to perform the simulation, what is depicted in Figure 12. There is no restriction concerning the applied control hardware because a controller just serves as a device to ensure that the implemented behavior will be executed. That means in particular, only sensor and actuator signals, which are transferred from and to the formal model, are of interest, and it makes no difference, what kind of controller is applied. In Figure 12, the values of the control outputs are transferred 1 . This marks the initial state for computing to the model 2 . The computation is executed until the reachability graph the value of at least one control input changes in a state. The 3 and the resulting state is mapped back to the formal model 4 . The control input values are transferred to the controller software reacts according to the new information and generates new output information. Then, the procedure starts again. The calculation of the state space will be nished if the whole graph is computed or if a certain nal state is reached. This of course belongs to the plant model and the regarding process, i.e. if it is cyclic or linear. Admitting that the results are trivial if everything works ne, it shall be emphasized that the approach detects errors, which are not obvious by just observing the controlled plant, i.e. unexpected behavior that happens rarely but that is the more critical because it has not been considered while programming. Those possible error trajectories within the reachability graph 5 . With this can be visualized in a Gantt Chart, for example 6. information, the control software can be corrected Figure 13 illustrates a reachability graph that has been generated during a HiL test. One can see that the trajectories through the state space are not linear. Several branches can exist, which have to be analyzed. For this, each trajectory of every branch has to be passed through to check the correct behavior of the control software. There are two possibilities to handle this task. On the one hand, the reachability graph is calculated based on the initial state and at the branching point, the state of the plant model as well as the state of the controller are recorded. After computation of a trajectory is nished, the recorded states of a branch are transferred back to the plant model and the controller to compute the other possible trajectory. On the other hand, the plant model and the controller have to be reset to their initial

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

automatic testing of a control implementation rather than doing it by a human being (who would simulate every scenario of plant behavior manually). Obviously, the state of the closed-loop system is given by the state of the plant and the state of the controller. Since we only know the inputs and outputs of the controller, the method for testing is strongly limited. Having a plant model goes beyond most approaches for controller testing since this allows studying any plant behavior that will occur during executing a control program on the plant. At the moment, testing is done using a formal model of plant behavior that comes from the simulation model (see Sec. IV-A). In future, the state of the controller (internal variables, counters etc.) will be included in the simulation. This requires access to the internal variable of the controller. It can be performed using, just for example, the tool AutoSPy. Using that approach, it is even more realistic to perform validation of controller behavior than doing it by modeling and formal verication. F. Model-Checking Model-checking is the automatic and machine-based verication of a given system model on a formal specication. In model-based controller design it is used to verify closedloop system behavior automatically, and it provides either the Fig. 13. Hardware in the Loop results. assertion that a specication is fullled or it delivers a counter example. For this purpose, a model of the closed loop of states after having nished computation of one possible path. plant and controller(s) is analyzed in connection with a formal Afterwards, the software passes through the already calculated specication of the desired and forbidden plant behavior. The trajectory to the branching point and takes the alternative path. procedure provides a machine-based assertion of correctness Although the rst possibility is the better way to be sure that because every reachable state is computed, and it veries the the image of the controller state - including variables, ags, specication to hold for each sequence. In contrast to this, timers, counters etc. - is exactly the same at the branching simulation only tests a cutout of possible scenarios. Rare point, it is rather complicated to be implemented. Reading but often critical cases are not considered, so that incorrect and writing internal variables of a controller at run time is not behavior could suddenly happen. For this reason, verication trivial and only possible with additional software tools. For is usually the only possibility to exclude these worst case example the tool AutoSPy implemented by GWT-TUD 3 can scenarios. monitor the internal information of PLCs. Anyway, manipu- For formal modeling, the authors prefer the usage of NCES. lating a running PLC program is much more complicated and That kind of model allows verifying functional and temporal properties. A further advantage is that it corresponds to the usually not intended by the hardware manufacturer. For this, the second possibility is more practicable because modular thinking of engineers. The naturally distributed state resetting a controller to its initial state is a standard function. formalism guarantees a higher efciency of model-checking. The approach uses the plant model that is connected to models That means combinations of concurrent processes that are of the control inputs and outputs. The controller itself is difcult to predict in advance, can be computed. seen as a black box that processes data inputs and provides The formal specication must be ready for computing. Thereinformation to data outputs. The reachability graph, which is fore we choose CTL and eCTL to verify the systems behavior. calculated based on this model, reects the state space of the Automatic translation of verbally or graphically formulated controlled plant model. However, it does not represent the state process requirements is possible (see Sec. IV-D). space of the closed loop of plant and controller model and However, it is a challenge even for modern computers to handle the calculation of all possible states, because the comconsequently the procedure does not provide verication. The formal specication (see Sec. IV-D) can be applied to plexity rises exponentially (in the case of concurrent behavior) the reachability graph by performing model-checking, what is the more complex models become. Since the problem of state space explosion is well-known, there are several contributions, discussed in Section IV-F. HiL test is based on the idea that it is much better to perform which consider the topic. For example, the approach in [29] proposes to do hierarchical level-by-level verication to verify 3 AutoSPy. URL, http://iis807.inf.tu-dresden.de/webpages autospy/index.php, the system efciently. The method basically is to rst verify March 2010. the tasks of a module (separate and application-independent).

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

Afterwards, the pre-veried task controllers can be arranged in various combinations. Then, one can verify the coordination of the system, without considering the detailed behavior models of the task controllers of the modules. With the models and the specication one can perform modelchecking using appropriate tools, e.g. the Signal-Net System Analyzer (SESA) [28]. There, faulty behavior can be localized and the origin of a malfunction can be tracked. Other appropriate software implementations for modelchecking are for example NuSMV4 that is based on Binary Decision Diagrams, UPPAAL5 that is based on timed automata or SPIN6 that is used to verify protocols. Anyway, all tools are not directly related to IEC 61499. They need formal models as input, so that informal FBs cannot be applied without translation. Even though different workgroups use different tools and formalisms, the idea behind model-checking is common, i.e. the automated analysis of the entire state space and the assertion of fulllment of a specication. The main issue in controller verication is to handle the complexity. The complexity of model and specication requires modular and hierarchical models and modeling methods. The computational complexity of the analysis has to be reduced to be able to handle real scale problems. A rst step to tackle that issue is the hierarchical verication. G. Synthesis Formal synthesis is based on the idea of automatic controller generation. It is a procedure proven to be correct to generate a controller model based on a formal plant model and a formal specication of intended or/and forbidden system behavior. Code for controller software can be generated based on the resulting controller model. Synthesis approaches are described for different plant models and different control problems. Finite state machine models are mainly used in supervisory control synthesis [32; 33]. Petri nets [34] and variations as condition nets [35] and NCES [36] are in use for supervisory control problems and low level plant controller synthesis. The synthesis approaches are almost independent of the subsequent control code generation. Naturally, distributed controller synthesis should be related to IEC 61499 implementations. A formal distributed controller model is source of the controller code generation. There is some work on code generation for IEC 61131 languages from formal controller models. The authors are not aware of any results for generation of IEC 61499 function blocks from formal models so far. In [37] an approach for synthesis of distributed safety controllers is presented, which results in Basic FBs according to IEC 61499. The used synthesis formalism from NCES plant behavior models and state predicate specications of forbidden states to formal controller models is described in [38]. The work on code generation is still ongoing. Function Blocks for control components can be generated based on IEC 61499 system descriptions within such a framework.
model-ckecker. URL, http://nusmv.irst.itc.it/, March 2010. model-ckecker. URL, http://www.uppaal.com/, March 2010. 6 SPIN model-ckecker. URL, http://spinroot.com/spin/ whatispin.html, March 2010.
5 UPPAAL 4 NuSMV

Controller synthesis allows the generation of correct FBs or even complete control applications. The issue to consider different execution models remains in that context again. The generated implementation has to ensure correct execution as well. The main issue inhibiting general application is the computational complexity of the synthesis approaches. Modular approaches as [36] can reduce that problem. V. A PPLICATION This section gives an overview on application of the IEC 61499 standard. Major aspects are the existing tools enabling the design of IEC 61499 conform control applications. Some benchmarks implemented using the tools are discussed afterwards. They show the slowly growing acceptance of the IEC 61499 framework as an alternative to the already popular controller programming methods. A. Tools For implementing IEC 61499 compliant applications, during the last decade a couple of tools have publically been made available. Thanks to those tools, the emerging standard became famous in the area of research and, signicantly to be mentioned, their students, just because the trial implementations made the entrance of the standard into the teaching area possible. In the following, the authors would like to present a short survey of the most common tools that have been developed in the last years, without claiming completeness of the list. First of all, one needs to mention the Java-based Function Block Development Kit (FBDK) implementation by J. H. Christensen7 . That tool is widely used in research trial implementations, and also mainly used in the authors workgroup. The FBs are executed on the controller, using the Java-based Function Block Runtime (FBRT). A lot of SIFB implementations have been developed, so the tool can be used in combination with lots of different Java-based control devices. A short introduction can be found in [39; 40]. The CORFU Engineering Support System by the workgroup of K. Thramboulidis8 supports an UML-based design approach of IEC 61499 compliant system design. The implementation of CORFU FBDK is developed with Borlands Delphi IDE. Beyond implementing IEC 61499 programming software, the workgroup also considers the applied eld bus systems [41] and discusses questions about capability of industrial standardized communication systems. Also to mention is the O3 NEIDA workbench, which includes the concept of Automation Objects. The workbench is an open source project of the OOONeida Community of Common Interest9 . Its purpose is to develop plug-in modules for the Eclipse and NetBeans Integrated Development Environments to support experimental development and global standardization of formats for the interchange of Automation Objects for industrial-process automation and control systems.
FBDK. URL, http://www.holobloc.com, March 2010. ESS 1.0. URL, http://seg.ee.upatras.gr/corfu/dev/ download.htm, March 2010. 9 O3 NEIDA. URL, http://www.oooneida.org, March 2010.
8 Corfu 7 Holobloc

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

10

The 4DIAC Integrated Engineering Environment10 is an engineering environment based on the Eclipse open tool framework, developed at the Vienna University of Technology. To execute the compiled FBs on embedded controllers, the C++based Forte Runtime Environment is used. The nxtStudio is the commercial software solution of nxtControl11 . It uses the 4DIAG core and provides extensions for visualization, simulation, communication, project management etc. The software combines the advantages of IEC 61499 programming and different customer demands. It is therefore a tool, which is usable for professional applications in industry and builds a bridge from pure academic research to practical application. Another remarkable industrial tool implementation is ISaGRAF12 . This software was the rst commercial tool available for IEC 61499 programming. It combines both IEC 61131 and IEC 61499 compliant implementation methods and is adjusted to costumers, who are used to employ IEC 61131 standard languages but who want to benet from IEC 61499 features such as real object orientation. In the following section existing benchmarks of IEC 61499 compliant testbed implementations are briey specied. B. Existing Benchmarks Application of the IEC 61499 standard is not only conned to the industrial manufacturing sector. Although developed for that eld, one also comes across example implementations from automobile comfort electronics sector [42] and aviation electronics sector [43]. But basically, the standard has been developed for industrial manufacturing systems, and basically the most benchmarks have been developed on that background, although they have not yet reached it completely. Many workgroups have been dealing with IEC 61499 compliant testbeds. Due to those activities, naturally a certain amount of benchmarks has been developed and commissioned. Thereby, one can differentiate between pure academic testbeds on the one hand and rare industrial-like prototypes on the other hand. The authors group started implementing prototype benchmarks for IEC 61499 compliant controllers in 2003 [39]. Through the years, the methodologies advanced in many directions. Starting with systematic building of models of the plant for a sound visualization, also the controller design methodologies were further developed. Based on simple centralized controllers, systematic methodologies for implementing distributed controllers were developed. Controller design methods have been published by the group in [39; 44; 40; 29] (chronological). Above all, the issue of reusing controllers in exible automation unavoidably led to the design of hierarchical control patterns. Current state of the art benchmarks of the group are the EnAS Project Demonstrator13 shown in Figure 3 and the VAIAS
URL, http://www.fordiac.org, March 2010. 11 nxtControl. URL, http://www.nxtcontrol.com/, March 2010. 12 ICS Triplex ISAGRAPH. URL, http://www.isagraf.com, March 2010. 13 EnAS Project Demonstrator. URL, http://aut.informatik.unihalle.de/forschung/enas demo, March 2010.
10 4DIAC.

Fig. 14.

VAIAS testbed.

Project testbed14 shown in Figure 14. The group of G. Frey also developed so called functional mechatronic controllers [45]. The design approach is similar to the workgroups. Further, academic testbeds from the University of Auckland and Vienna University of Technology should be specied. In a few years, the group of V. Vyatkin created an IEC 61499 compliant testbed laboratory15 . Reconguration on the y, reusability of distributed control components and verication of the control software are major points of interest in the research of this group. Furthermore, a prototype-industrial luggage conveyor system case study taken from an airportvendor is to be mentioned [46]. The group of the Vienna University of Technology possesses a big lab, dealing with distributed control methods, among others the IEC 61499 standard16 . Furthermore, the group makes a point demonstrating future scenarios for application of IEC 61499 [47]. A rather industrial-like application of the standard can be found in [48]. In contrast to IEC 61131 frameworks, the authors this contribution recognized an effective high-level view of the application. The development process showed up to be more rapidly due to reusing and adapting existing Function Blocks. At present state, examples for industrial applications are rare. The most signicant reason is that engineering software is mainly used and developed in academic environment. That means tools do not meet the requirements of companies, who are pressed for time and cannot afford to test new approaches. Furthermore, as the IEC 61499 is yet not fully accepted among automation engineers, expert staff is missing to bring the ideas from academia to industry. A further very important point is the certication of software. Even if the tools work as good as or even better than IEC 61131-conform software, missing
14 IEC 61499 Festo testbed. URL, http://aut.informatik.unihalle.de/forschung/testbed, March 2010. 15 MITRA. URL, http://www.ece.auckland.ac.nz/vyatkin/ mitra lab.html, March 2010. 16 Odo Struger Laboratory, Vienna Technical University. URL, http://www.acin.tuwien.ac.at/forschung/Projekte/255/, March 2010.

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

11

certicates prevent the application because companies require ofcial references to legitimate their solutions towards the costumer. Last but not least, there are still open questions concerning the execution behavior of IEC 61499 FB networks, which have to be discussed and nally answered. The software tool provided by nxtControl (see Sec. V-A) is one of the commercially available solutions that are tailored to specic customer demands. Several projects, in particular dealing with building automation, have been realized with this tool. These are for example the building automation of a training center, of a university and of a shopping mall. A rather industrial-like solution is the automation of a complete high-pressure testing facility. These pilot projects are beginnings for a further spread of IEC 61499 applications. The rst steps are done to apply the standard also in industrial environment but it is far behind the success of IEC 61131. Concluding this section, IEC 61499 has reached the threshold to be applied in industrial applications. However, if a realistic view on all the benchmarks is taken, an application to real manufacturing systems will not be visible. This point of view leads to the critical remarks and the conclusion. VI. C ONCLUSION Despite the need for better runtime platforms and development tools, there are also other issues that may play an important role in future. The use of IEC 61499, UML and other emerging technologies does not automatically generate good and exible automation solutions. These technologies must be accompanied by engineering methodologies that would eventually enable more reliable, exible and recongurable systems. Anyway, the initiative to develop such methodologies must come from manufacturing industries themselves. Universities, research centers etc. may help, but they do not have the power to impose the pressure to control systems vendors to develop new generations of control systems that would be able to satisfy the above mentioned requirements. As long as big manufacturing companies do not feel the urgent need to take advantage of the emerging technologies, research in academia will get stuck in playing around with benchmark examples and possibly some kind of exotic applications. Recipe Control in Batch process engineering is an excellent example for control systems engineering. Batch process systems in multipurpose plants have always been extremely exible and recongurable. Recipe control is an engineering concept that actually came from a consortium of big (German) companies that released just a recommendation [7] that eventually ended up in an International Standard [8]. Based on the economic power of their customers, almost all big providers of Process Control Systems realized means to fulll this recommendation within a couple of years. Therefore, Recipe Control has become the unied approach for control design in Batch process engineering. Up to now, something comparable cannot be seen in manufacturing. Some of the concepts developed in academia as for example agent-based technologies, Automation Objects and other

approaches seem to be appropriate for developing control software but from the point of view of shop-oor requirements, they are a bit over-sophisticated. The reason is a mutual misunderstanding of experts in embedded systems (focused on software) and manufacturing engineers (focused not only on their manufacturing hardware but on the goal to provide products). Another huge issue is the problem of migration. It is completely unrealistic to assume that a company will make a strict and complete transition from its traditional PLC-based automation concepts to new technologies. Therefore, heterogeneous systems - both in hardware and software - will appear and will exist a rather long time. This generates completely new questions of engineering, modeling, verication and operation of such systems. Also the transition from traditional (sub-) systems to IEC 61499-based ones without changing the behavior of the control loops is an issue of highest signicance. The ongoing spread of the Fieldbus technology provides a point of contact allowing step by step migration of new control technologies. The development of methods to use existing potential and of migration strategies premise a cooperation of researchers and manufacturers of the eld of manufacturing control and communication technology. Unfortunately, it is also observable that missing communication between researchers of different background (manufacturing control, computer science) leads to misunderstanding or misinterpretation. How to cross this gap is an open question left to the decision of the reader. Instead of promising too much, the community should ask itself how far it has gone, what has been accomplished and what needs to be done in nearer or further future. ACKNOWLEDGMENT This work was partially funded by the Federal Ministry of Economics and Technology (BMWi) under reference 16 IN 0651 and 01 MG 566 on account of a decision of the German Bundestag and by the German Research Foundation (DFG) under reference Ha 1886/16-1 and Ha 1886/16-2. The authors are responsible for the contents of this contribution. R EFERENCES
[1] IEC 61499 - 1, Function Blocks - Part 1 Architecture, IEEE Std., 2005. [2] V. Vyatkin and H.-M. Hanisch, A Modeling Approach for Verication of IEC1499 Function Blocks Using Net Condition / Event Systems, in Conference on Emerging Technologies and Factory Automation (ETFA), Catalonia, Spain, October 1999, pp. 261269. [3] C. S under, A. Zoitl, B. Favre-Bulle, T. Strasser, H. Steininger, and T. S., Towards Reconguration Applications as basis for Control System Evolution in Zero-downtime Automation Systems, in Intelligent Production Machines and Systems (IPROMS), 2006, pp. 523528. [4] M. Khalgui, M. Hirsch, D. Missal, and H.-M. Hanisch, Reconguration of Embedded Systems, in International Conference on Informatics in Control, Automation and Robotics (ICINCO), 2008, pp. 157162.

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

12

[5] V. Vyatkin and H.-M. Hanisch, Reuse of Components in Formal Modelling and Verication of Distributed Control Systems, in Conference on Emerging Technologies and Factory Automation (ETFA), Catania, Italy, September 2005, pp. 129 134. [6] D. Missal and H.-M. Hanisch, Modular Plant Modelling for Distributed Control, in International Conference on Systems, Man and Cybernetics (SMC), Montr eal, Canada, October 2007, pp. 34753480. [7] Namur, NE33 - Requirements to be met by systems for recipebased operations, WG 2.3: Functions of Operation Management and Production Control Level Std., 1993. [8] ANSI/ISA-88 Batch Control Part 1: Models and Terminology, ISA-S88.01, ISA Std., February 1995. [9] M. H. William and T. Fisher, Batch Control Systems: Design, Application, and Implementation, 2nd ed. ISA, 2006. [10] Automation Objects for industrial-process measurement and control systems, IEC, SB3/ Technical Commitee 65, Working draft Std., 2002. [11] V. Vyatkin, H.-M. Hanisch, S. Karras, T. Pfeiffer, and V. Dubinin, Rapid engineering and re-conguration of automation objects using formal verication, International Journal of Manufacturing Research (IJMR), vol. 1, no. 4, pp. 382404, 2006. [12] R. Brennan, An Initial Automation Object Repository for OOONEIDA, Lecture Notes in Computer Science (LNCS), vol. 3593, pp. 154164, 2005. [13] V. Vyatkin and H.-M. Hanisch, Verication of distributed control systems in intelligent manufacturing, in Journal of Intelligent Manufacturing (JIM), 2003, pp. 123136. [14] I. Ivanova-Vasileva, C. Gerber, and H.-M. Hanisch, Transformation of IEC 61499 control systems to formal models, in International Conference AUTOMATICS AND INFORMATICS (CAI), Soa, October 2007, pp. V5V10. [15] G. Cengi c and K. Akesson, A Control Software Development Method Using IEC 61499 Function Blocks, Simulation and Formal Verication, in 17th IFAC World Congress, Seoul, South Korea, July 2008, pp. 2227. [16] C. Gerber, I. Ivanova-Vasileva, and H.-M. Hanisch, A Data processing Model of IEC 61499 Function Blocks with IntegerValued Data Types, in Workshop on Intelligent Manufacturing Systems (IMS), Szczecin, Poland, 2008, pp. 239244. [17] C. Pang and V. Vyatkin, Towards Formal Verication of IEC61499: modelling of Data and Algorithms in NCES, in International Conference on Industrial Informatics (INDIN), Vienna, Austria, 2007, pp. 879884. [18] C. S under, A. Zoitl, J. H. Christensen, V. Vyatkin, R. W. Brennan, A. Valentini, L. Ferrarini, T. Strasser, J. L. MartinezLastra, and F. Auinger, Usability and Interoperability of IEC 61499 based distributed automation systems, in International Conference on Industrial Informatics (INDIN), Singapore, August 2006, pp. 3137. [19] G. Cengi c, O. Ljungkrantz, and K. Akesson, Formal Modeling of Function Block Applications Running in IEC 61499 Execution Runtime, in Conference on Emerging Technologies and Factory Automation (ETFA), Prague, Czech Republic, 2006, pp. 12691276. [20] I. Ivanova-Vasileva, C. Gerber, and H.-M. Hanisch, Basics of Modelling IEC 61499 Function Blocks with Integer-Valued

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

[30]

[31]

[32]

[33]

[34]

[35]

Data Types, in Workshop on Intelligent Manufacturing Systems (IMS), Szczecin, Poland, 2008, pp. 233238. M. Khalgui, X. Rebeuf, and F. Simonot-Lion, A behavior model for IEC 61499 function blocks, in Third Workshop on Modelling of Objects, Components and Agents (MOCA), Aarhus, Denmark, October 2004, pp. 7188. S. Panjaitan and G. Frey, Functional Design for IEC 61499 Distributed Control Systems using UML Activity Diagrams, in International Conference on Instrumentation, Communications and Information Technology (ICICI), Bandung, Indonesia, August 2005, pp. 6470. V. Vyatkin, H.-M. Hanisch, P. Starke, and S. Roch, Formalisms For Verication Of Discrete Control Applications On Example Of IEC 61499 Function Blocks, in Fachtagung Verteilte Automatisierung, Magdeburg, Germany, 2000, pp. 7279. H.-M. Hanisch and V. Vyatkin, Application of Visual Specications for Verication of Distributed Controllers, in International Conference on Systems, Man and Cybernetics (SMC), Tucson, Ariz, USA, October 2001, pp. 646651. V. Vyatkin, H.-M. Hanisch, and G. Bouzon, Open ObjectOriented Modelling and Validation Framework for Modular Industrial Automation System, in Symposium on Information Control Problems in Manufacturing (INCOM), Salvador da Bahia, Brazil, April 2004. G. Bouzon, V. Vyatkin, and H.-M. Hanisch, Timing Diagram Specications in Modular Modeling of Industrial Automation Systems, in 16th IFAC World Congress, Prague, Czech Republic, July 2005, pp. 208221. S. Preue and H.-M. Hanisch, Specication and Verication of Technical Plant Behavior with Symbolic Timing Diagrams, in International Design and Test Workshop (IDT), Monastir, Tunisia, December 2008, pp. 313318. P. Starke and S. Roch, Analysing Signal-Net Systems, Informatikberichte, Humboldt-Universit at zu Berlin, vol. 162, September 2002. D. Missal, M. Hirsch, and H.-M. Hanisch, Hierarchical Distributed Controllers - Design and Verication, in Conference on Emerging Technologies and Factory Automation (ETFA), Patras, Greece, 2007, pp. 657664. M. Hirsch and H.-M. Hanisch, Systemspezikation mit SysML f ur eine Fertigungstechnische Laboranlage, in Entwurf komplexer Automatisierungssysteme (EKA), Magdeburg, Germany, April 2008, pp. 2334. S. Preue and H. H.-M., Specication of Technical Plant Behavior with a Safety-Oriented Technical Language, in International Conference on Industrial Informatics (INDIN), Cardiff, United Kingdom, 2009, pp. 632637. R. Su and W. M. Wonham, Supervisor Reduction for DiscreteEvent Systems, Discrete Event Dynamic Systems, vol. 14, no. 1, pp. 3153, 2004. H. Flordal, R. Malik, M. Fabian, and K. Akesson, Compositional Synthesis of Maximally Permissive Supervisors Using Supervision Equivalence, Discrete Event Dynamic Systems, vol. 17, no. 4, pp. 475504, 2007. M. V. Iordache and P. J. Antsaklis, Supervisory Control of Concurrent Systems: A Petri Net Structural Approach (Systems & Control: Foundations & Applications). Birkhauser, 2006. L. E. Holloway, X. Guan, R. Sundaravadivelu, and J. A. Jr, Automated synthesis and composition of taskblocks for control

INTERNATIONAL JOURNAL OF DISCRETE EVENT CONTROL SYSTEMS (IJDECS), VOL. 1, NO. 1, MARCH 2010

13

[36]

[37]

[38]

[39]

[40]

[41]

[42]

[43]

[44]

[45]

[46]

[47]

[48]

of manufacturing systems, Transactions on Systems, Man and Cybernetics (SMC), vol. 30(5), pp. 669712, 2000. D. Missal and H.-M. Hanisch, Synthesis of Distributed Forcing/Locking Safety Controllers, in Conference of the IEEE Industrial Electronics Society (IECON), Orlando Fl., USA, 2008, pp. 383390. , Synthesis of Distributed Safety Controllers with Incomplete State Observation, in Annual Conference of the IEEE Industrial Electronics Society (IECON), Porto, Portugal, 2009, pp. 44194426. , Synthesis of Distributed Controllers by Means of a Monolithic Approach, in Conference on Emerging Technologies and Factory Automation (ETFA), Prague, Czech Republic, September 2006, pp. 356363. X. Cai, V. Vyatkin, and H.-M. Hanisch, Design and Implementation of a Prototype Control System According to IEC 61499, in Conference on Emerging Technologies and Factory Automation (ETFA), Lisbon, Portugal, 2003, pp. 269276. M. Hirsch, C. Gerber, V. Vyatkin, and H.-M. Hanisch, Design and Implementation of Heterogeneous Distributed Controllers according to the IEC 61499 Standard - A Case Study, in International Conference on Industrial Informatics (INDIN), Vienna, Austria, 2007. K. C. Thramboulidis and C. S. Tranoris, Developing a CASE Tool for Distributed Control Applications, International Journal of Advanced Manufacturing Technology (IJAMT), vol. 24, no. 1-2, pp. 112, 2004. M. Hirsch, V. Vyatkin, and H.-M. Hanisch, IEC 61499 Function Blocks for Distributed Networked Embedded Applications, in International Conference on Industrial Informatics (INDIN), Singapore, August 2006, pp. 670675. C. C. Insaurralde, M. A. Seminario, J. F. Jimenez, and J. M. Giron-Sierra, IEC 61499 Model for Avionic Distributed Fuel Systems with Networked Embedded Holonic Controllers, in Conference on Emerging Technologies and Factory Automation (ETFA), Prague, Czech Republic, September 2006, pp. 388396. V. Vyatkin, M. Hirsch, and H.-M. Hanisch, Systematic Design and Implementation of Distributed Controllers in Industrial Automation, in Conference on Emerging Technologies and Factory Automation (ETFA), Prague, Czech Republic, September 2006, pp. 633640. S. Panjaitan, Development Process for Distributed Automation Systems based on Elementary Mechatronic Functions, Ph.D. dissertation, Technical University of Kaiserslautern, Germany, November 2007. V. Vyatkin, Z. Salcic, P. S. Roop, and J. Fitzgerald, Now thats smart! IEEE Industrial Electronics Magazine (IEM), vol. 1, no. 4, pp. 1729, 2007. T. Baier, J. Fritsche, G. Keintzel, D. Loy, R. Schranz, H. Steininger, T. Strasser, and C. S under, Future scenarios for application of downtimeless reconguration in industrial practice, in International Conference on Industrial Informatics (INDIN), Vienna, Austria, June 2007, pp. 11291134. M. Colla, A. Brusaferri, and E. Carpanzano, Applying the IEC61499 Model to the Shoe Manufacturing Sector, in Conference on Emerging Technologies and Factory Automation (ETFA), Prague, Czech Republic, 2006, pp. 13011308.

Sebastian Preue is a graduate engineer. He has been a member of the scientic staff of the Chair of Automation Technology since 2008. His main research topics are specication of plant behavior and verication of control software.

Dirk Missal is a graduate engineer. He has been a member of the scientic staff of the Chair of Automation Technology since 2005. His main research topics are formal synthesis of (distributed) controllers, modeling and verication using Net Condition/Event Systems (NCES) and design of distributed controllers in IEC 61499.

Christian Gerber is a graduate engineer. He has been a member of the scientic staff of the Chair of Automation Technology since 2006. His main research topics are design and implementation of heterogeneous and distributed control systems.

Martin Hirsch is a graduate engineer. He has been a member of the scientic staff of the Chair of Automation Technology since 2006. His main research topics are systematic modeling and design of distributed controllers in IEC 61499, formal verication of embedded controllers using NCES and system modeling with UML/SysML.

Hans-Michael Hanisch is Full Professor and Head of the Chair of Automation Technology at the Martin Luther University Halle-Wittenberg in Germany. His main research topics are (amongst others) methods for modeling, synthesis and verication of discrete and hybrid systems and distributed systems.