IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA’06) Sept 2006, Prague. “©2006 IEEE. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE.”
Design Alternatives in the IEC 61499 Function Block Model Kleanthis Thramboulidis Electrical & Computer Engineering University of Patras, Greece
[email protected]
Abstract—The International Electro-technical Commission through the 61499 standard establishes the basic infrastructure towards an open market in the control and automation domain. This standard can be considered as the first step towards the development of the next generation agile manufacturing systems where distribution, interoperability and re-configuration are between the most important requirements. However, even though many researchers are working during last years towards this direction, the understanding of the use of the IEC 61499 between practitioners is weak. The standard has many open issues regarding the design views that are required for an effective design process for distributed control systems. In this paper, the inefficiencies of IEC 61499, at least as far as the design phase is considered, are highlighted and the way that these inefficiencies can be addressed is discussed. A laboratory system, the FESTO Modular Production System, is used as a running example to demonstrate possible design alternatives.
I.
INTRODUCTION
The IEC 61499 standard [1] enhances the Function Block (FB) model, which was introduced by IEC 1131, to exploit in the development process of open, interoperable, distributed control applications (DCAs), many of the well defined and already widely acknowledged benefits introduced by object technology. However, even though the interest from academia for this standard is growing last years with many researchers working to exploit IEC 61499 in factory automation [2], it was found that the standard has many weak points regarding the design phase artefacts that provides for the modelling of real world systems. More expressive design diagrams and support for expressing the design in different abstraction levels are required for the IEC FB model to be effectively used in the development process of factory automation systems. Other researchers have already reported inefficiencies of the IEC FB model. Stromman et al. in their research to increase the understanding of the use of the IEC 61499 by industrial practitioners claim that “is no obvious way to define good guidelines” [3]. Lewis [4] argues that even though the IEC 61499 represents an important step towards a unified design architecture it provides just one of the five design views required for distributed control systems. He also claims that the other views will emerge as designers start to face the challenge of building large distributed systems. Christensen [5] argues that the use of design patterns can simplify the job of becoming
familiar with the application of the IEC61499 concepts. The use of framework technology is proposed in [6] to address problems in this direction. This paper presents and discusses inefficiencies of the IEC FB model; it proposes and discusses design alternatives and the way these techniques can be exploited in the development process of DCAs, for the standard to be seriously considered by industry. The most important limitation of the FB model is the fact that the FB construct and the diagrams proposed by the standard i.e. the FB Network Diagram (FND) and the Execution Control Chart (ECC), prove insufficient to capture the different aspects of DCAs. ECC is used to express the sequencing of algorithm invocations of the FB type, while FND is defined as an aggregation of interconnected FB instances. The semantics of FND, as defined by the standard, prove insufficient to capture the structure and behaviour of control applications. Even more there is no: a) methodology that will guide the control engineer to define the FND that models the control application at design time, and b) guidance on how to identify the FB types that are required to compose a control application. The use of already defined FB types is a significant starting point; however, a lot of other FB types should be defined to represent specific functionality of the control application as well as to capture the application logic, with the control engineer having no guidance to this direction. The remainder of this paper is organized as follows. In the next section, a brief description of the FESTO Modular Production System (MPS) that is used as a running example in this paper is given. In section 3, design alternatives are presented and examined regarding their effectiveness in the development process. In section 4, the FB Interaction Diagram (FID) as a mean to get more expressive design specifications is presented. In section 5, the levelled FND as an effective mechanism for modelling DCAs is considered. Finally the paper is concluded in the last section. II.
BACKGROUND WORK
A. The FESTO MPS case study The example system used as a case study in the context of this work is the FESTO MPS shown in Fig. 1. The class diagram of Fig. 2 represents the structural information of this system. Each one of the three units that constitute the system i.e., distribution unit, test unit and processing unit, is further defined as an aggregation of other mechanical units.
IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA’06) Sept 2006, Prague. B. The IEC61499 Function Block model The FB, which is the main building block of the IEC 61499 FB model, consists of a head and a body. The head is connected to the event flows and the body to the data flows, as shown in Fig. 3, where the graphical representation of the detectorUnit FB type is given. An FB can be simple enough such as the one that controls a feeder, or complex such as the one that controls the testing unit of FESTO MPS.
Fig. 1. FESTO Modular Production System (schematic diagram)
Fig. 3. Graphical representation of DetectorUnit FB type
Fig. 2. FESTO MPS composition hierarchy
The distribution unit, which is composed of a pneumatic feeder and a converter, forwards cylindrical work pieces from the Stack to the Testing unit. The testing unit is composed of the detector, the elevator and the shift out cylinder. The detection unit performs checks on work pieces for height, material type and colour. Work pieces that successfully pass this check are forwarded to the rotating disk of the processing unit, where the drilling of the work piece is performed as the primary processing of this MPS. The result of the drilling operation is next checked by the checking machine and the work piece is forwarded for further processing to another mechanical unit. A detailed description of FESTO MPS can be found in [7][8]. FESTO MPS is a well documented system used by many universities for research and education purposes [7][8][9]. It is also used by other research groups to demonstrate the applicability of the IEC61499 model. In [10] the Model/View/Controller pattern is utilized to demonstrate the applicability of the IEC FB model in a real application and it is argued that “much more effort both from industry and from academia has to be spent in developing systems, methodologies, and tools for putting such new developments into practice.” In [11] authors present their experiences from a migration of a PLC controlled centralized laboratory application into an IEC 61499 compliant distributed control application. Function Block diagrams and ECCs are utilized as design diagrams. The 61499 compliant specifications are produced manually from a Signal Interpreted Petri Nets formal specification.
The functionality of the FB is provided by algorithms, which process inputs and internal data and generate output data. The sequencing of algorithm invocations is defined in the FB type specification using a variant of state charts called ECC. An ECC consists of EC states, EC transitions and EC actions. The application model is defined as a FND that is a “network whose nodes are function blocks or sub-applications and their parameters and whose branches are data and event connections” [1]. III.
DESIGN ALTERNATIVES
In the context of this work, we exploit the extensions to the FB notation that have been proposed in the context of the CORFU framework. We mainly utilize the concepts of Industrial Process Terminator (IPT) and Industrial Process Parameter (IPP) [13], and a different representation and implementation of event FBs [17]. The IPT construct is used to represent in the design level every entity of the controlled process that is either controlled or monitored by the control application. The IPT is the unit of distribution of the controlled process’s entities to processing devices. Fig. 4 shows the system-layer diagram that was created using CORFU FBDK [12]. Nine IPTs were defined; one for each discrete mechanical unit, plus one for the control panel. Alternately, if all sub-units of a mechanical unit are assigned to the same processing device, as is the case for the three IPTs of the testing unit shown in Fig. 4, one IPT can be defined. In this case this IPT will represent in the design level the whole testing station. Parameters (variables) of the controlled process that are accessed (read/set) either through sensors or actuators are represented at the design level as IPPs that are assigned to the corresponding IPTs.
IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA’06) Sept 2006, Prague. The use of the IPP construct greatly simplifies the FND since there is no need to use in the design phase the Service Interface FB (SIFB) type, defined by the standard. It also provides along with the IPT construct an effective notation to graphically interface the control application with the controlled process.
Fig. 4. The system-layer diagram for the FESTO MPS.
In the context of this work three approaches are considered for the identification of FB types and the subsequent generation of FNDs. The first one utilizes a use case driven technique in the context of the proposed in [13] hybrid approach. The second utilizes the top-down approach that was used for many years by the Structured Analysis/Structured Design (SA/SD) methodology. This approach was criticized for its ineffectiveness in general purpose software applications, but the most of its disadvantages are not valid in the control and automation domain, if as basis for the partitioning of the control application to lower level constructs, the hierarchical organization of the mechanical system is considered. The third one is the well known bottom-up approach. For each one of the above approaches, design alternatives will be considered and the effectiveness of the IEC FB model to present these alternatives will be discussed. A. Applying a use case driven approach The use case driven approach is quite similar with the middle-out approach proposed by Modern Structured Analysis. Use cases are identified and described in the form proposed in [13]. Object Interaction Diagrams (OIDs) are utilized for the realization of use cases. These OIDs are next automatically transformed to FNDs using the CORFU built-in transformation facility manager. These FNDs are automatically merged by CORFU FBDK to provide the complete FND [14] for the control application. The so produced flat FND is very complicated making difficult, if not impossible, for the control engineer to understand and check its behaviour. It is also clear that this approach is impossible to provide manageable FNDs for complex systems, if specific mechanisms to handle the complexity are not introduced. An approach that can be used to handle the complexity is to represent the FND of the control application as a set of hierarchical FB networks, where each level corresponds to a specific abstraction level. This can be achieved in two ways.
The first one is to use as basis, the flat FND produced by the hybrid approach, and apply on it specific FB composition techniques, which have to be defined, to create FNDs that represent higher layers of abstraction. The second one utilizes the top-down approach that is described in the following subsection. Ferrarini and Veber in [15] propose also a multi-level presentation of the FB design diagrams. This approach results in a quite different, restricted to the device level, multi-level presentation of the FB design diagrams using the concepts of device function and proxy FB. B. Applying a top-down approach Adopting the top-down approach in the modelling of the system, the whole control application of Festo MPS is represented in the upper layer of abstraction, as a FB type. An instance of this FB type will be used for the design of the control application of a bigger mechanical system that should use Festo MPS as one of its constituents. More FB instances will appear in the lower layer of abstraction. Even though the way to define these FB instances is not yet well known, current software engineering practices can be utilized to get an efficient design. In the context of this work, we define one FB type for each one of the three mechanical units that constitute the system. The following FB types were defined: distributionUnitFB, testUnitFB and processingUnitFB. Each one of them encapsulates all the control logic required for the operation of the corresponding mechanical unit. This means that the only IPPs used at this level of abstraction will be: Init, Stop, and Start, which are input events for the control application, and Stoplight, which is output event. To simplify the FND, the notation proposed in [17] for rendezvous events was also adopted. All the above resulted in the quite simple top-level FND shown in Fig. 5. For this FND a simple initialization process is assumed according to which each device issues the output event inito after its initialization. Inito of the processingUnit FB instance is used along with the start event of the control panel to create using a rendezvous FB instance the start input event that triggers the distributionUnit FB to start operation. The distributionUnitFB captures all the control logic for the distribution unit so when the work piece is ready to be moved to the testing station the pieceReady2Move output event is issued. This event is driven to the e_rend4 rendezvous FB instance, which has also as input the ready4Piece event output of the testingUnit FB, which means that the testing unit is ready to accept the next work piece. The output event of the e_rend4 FB instance is connected to the movePiece input event of the distributionUnitFB instance to trigger the action of moving the work piece to the testing unit. Alternatively, this logic can be considered internal for the distribution unit. In this case the functionality of the e_rend4 FB instance will be included in the distributionUnitFB and so the ready4Piece event output of the testUnitfb3 will be connected to the movePiece event input of the distributionunitfb1. In a quite
IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA’06) Sept 2006, Prague. similar way the synchronization of testUnitFB with the processingUnitFB is obtained. The behaviour expressed by the e_rend6 FB instance can be considered internal to the testingUnitFB, so the ready4Piece event output of the processingunitfb5 will be connected to the move2RotDisc event input of the testunitfb3. In any case, it is clear that at this level of abstraction only the coordination logic is captured leaving implementation details of constituent FB instances to the lower level of abstraction. The result is a FND that contains only the information that is required to represent the control application in this level of abstraction. B.1. Distributed vs. centralized control approach It is clear that the distributed control approach was utilized to construct the top level FND of Fig. 5. Alternatively, the centralized control approach can be adopted according to which the whole co-ordination logic of the three FB instances will be captured in a new FB instance, namely festoMpsFB. Using this FB, a more complex collaboration can be obtained between coordinated FB instances. For example, the INIT event from the control panel will be connected to this FB which will capture the control logic for the initialization of the whole system. Each of the controlled FB instances will accept its INIT event input from the festoMpsFB instance and after performing the corresponding initialization algorithm will issue back to the festoMpsFB the inito event. The big advantage of this approach is that the initialization process of the whole system can be changed without any modification to the FND since the whole co-ordination logic is captured into the festoMpsFB that has to be modified accordingly. It must also be noticed that the distribution of the application control logic into constituent components has a negative impact on the reusability of these components. C. Applying a bottom-up approach - The level of granularity in FB type definition According to the bottom-up approach each discrete
Fig. 5. Top level FB network for the FESTO MPS
mechanical unit of FESTO MPS is considered separately and one FB network (possibly containing one FB instance) is produced for each one of them. At this stage the level of granularity of FB definition should be defined. For example it has to be decided if a FB type to capture the control logic of the whole distribution unit will be defined or an FB for each one of its constituent sub-units will be defined and a FB network diagram will be constructed to capture the control logic of the composite unit. To increase reusability in control application design and also improve the modularity of the system, the control logic of each discrete mechanical unit is encapsulated in a FB type. This is the preferred approach for simple mechanical units such as the feeder or converter of the example system. However, for complex mechanical units which can not be considered as an aggregation of discrete mechanical sub-units a FND is required to capture the control logic of the unit. This is the only choice in the case that more than one activities are concurrently performed by the unit. This is due to the fact that the basic FB type has according to the IEC FB model one thread of execution that is expressed by its ECC. The FB types used in this case to construct this FND have no one to one correspondence with mechanical units making the design process more dependent on the designer’s skills. To apply the bottom-up approach to the distribution unit we assume that each sub-unit has each own FB instance that encapsulates its control logic. The diagram shown in Fig. 6 presents the FND of the distribution-unit’s control application. Feeder FB type encapsulates the control logic for the Feeder unit, while the Converter FB type encapsulates the control logic of the converter unit. Fig. 6 applies the distributed control approach, in which the control logic for the coordination of Feeder and Converter is distributed in the FND. Alternatively, the centralized control approach is shown in Fig. 7. In this FND the distrUnitCentrContrl FB type captures the coordination logic of Feeder and Converter FBs. The movePiece event input of distrUnitCentrContrl1 FB instance is connected to the read4Piece event output of the testing unit.
IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA’06) Sept 2006, Prague.
Fig. 6. FND for the distribution unit (distributed control approach)
unit, it is very difficult for the control engineer to reliably work with this kind of design specifications. To overcome this limitation the use of the FB Interaction Diagram (FID) that provides a more human readable way of representing the collaboration between FB instances, is proposed. It is shown that using FIDs along with ECCs produced adopting minor modifications to the IEC model a more clear and expressive design model for the control application is obtained. Fig. 10 presents the FID for the normal operation mode of the Testing unit. Each FB instance is represented as a vertical line, while the events that are send from FB instance to FB instance are represented by horizontal lines where the arrow shows the consumer FB instance. Time is increasing from up to down. A special notation is utilized to indicate specific points in time where exceptions from the normal operation may occur.
Fig. 7. FND for the distribution unit (centralized control approach)
IV.
FUNCTION BLOCK INTERACTION DIAGRAM
Applying the bottom-up approach for the Testing Unit and adopting the centralized control technique, the FND shown in Fig. 8 was constructed. TesterFB captures the control logic for the co-ordination of detectorUnitFB, elevatorUnitFB and socFB instances. Fig. 9 presents the ECC of the testerFB type that would be created by most of the developers following the IEC 61499 concept.
Fig. 8. Top level FB network diagram for the Testing unit
Even though the provided in Fig. 8 FND along with the specifications of the corresponding FB types (ECCs and algorithms) contains all the information required to produce the executable model of the control application for the Testing
Fig. 9. ECC of the testerFB type (commonly used)
So, after the check performed in the down position of the elevator the event dCheckFailed that notifies the existence of a fail in the down position check, is considered as an exception (exc1) and the subsequent collaboration to handle this case is depicted in a separate FID or in the same FID after the normal case, as is the case for Fig. 10. In the same way the fail to the up position check is considered as exc2 and is depicted in the bottom of the FID of Fig. 10. It should be noted that rectangles in vertical lines can be used to define the time periods that the corresponding FB instances are running. In the same FID the synchronization of the tester controllerFB with the corresponding controllers of distribution and processing stations is shown. A notation with special semantics is utilized for this synchronization. The ‘WAIT for’ keyword is used to define the event that the specific FB instance is waiting for. ‘WAIT for’ means that as soon as, the FB instance comes to this point the corresponding event store is checked for the existence of an event. If an event exists it is immediately consumed and the processing continues accordingly. If the event does not exist, the FB instance waits for this event. When the event arrives the FB instance is
IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA’06) Sept 2006, Prague. notified to consume the event. Alternatively, UML’s activity diagrams can be used to represent this synchronization. Fig. 11 presents part of the FB activity diagram (FAD) that presents the synchronization of FB instances involved in Fig. 10. It should be noted that when the emphasis is on activities, FADs can be used instead of FIDs to represent the same collaboration.
Another benefit of using FIDs is that this diagram allows for the definition of real-time constraints in the design level. Endto-end constraints as well as message latency and processing time constraints can be captured on this diagram and be properly explored by subsequent model analysis tools to produce the proper implementation and deployment model that will meet these constraints.
Fig. 12. ECC to reduce the semantic gap between the mechanical system and the application model Fig. 10. Function Block Interaction Diagram (FID) for the Testing unit
V. INTEGRATING THE DIFFERENT LEVELS OF ABSTRACTION
Fig. 11. FB activity diagram (FAD) to show synchronization.
However, even using FIDs it is very difficult to clearly understand the behaviour of the design model if the guidelines of the IEC model for the ECC construction are used. This is due to the fact that the ECC does not clearly represent the states of the mechanical unit that the FB instance represents in the design diagram. So, the ECC of Fig. 9 for the TesterFB does not clearly shows the states of the Testing unit and this creates a significant semantic gap between the mechanical system and the model of the controlling application. To reduce this semantic gap and for the FID to become more usable for describing the collaboration of complex FB type instances, a different approach compared to the one proposed by the IEC model to construct the ECC, is adopted. Fig. 12 presents the same ECC following the proposed approach. This ECC is more expressive and if combined with the FID it can provide a more expressive design alternative compared with the one of using FNDs and the traditional ECC.
In order to integrate FNDs of different levels of abstraction we have to look for appropriate techniques and mechanisms that the IEC61499 FB model provides to this direction. An interesting question is to what extend the IEC61499 FB model provides the mechanisms that are required to allow the design to be expressed in different levels of abstraction without cluttering the upper level design diagrams. It is also interesting to examine the possible design alternatives for the implementation of the FB types of the upper level FNDs. In the rest of this section an attempt is made to address these issues. A. Using-interface vs. Implementation-interface To integrate FNDs of the different levels of abstraction without cluttering the different levels with information provided by the other layer (higher or lower) the concept of using-interface and implementation-interface for the FB is defined. Using-interface for a FB is this part of the event and data interface that is used in the upper level diagram that the FB appears. For example the using-interface for the elevatorUnitFB type is shown in Fig. 8 where the corresponding FB instance is used to create the top level FND for the Testing unit. The implementation-interface will be used in the lower level of abstraction where the FB type will be implemented to provide the functionality assumed in the upper layer. Input and output events and data that will connect the FB
IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA’06) Sept 2006, Prague. instance with the controlled mechanical process will constitute the implementation-interface for this FB type. Fig. 13 presents both using and implementation-interfaces for the elevatorUnit FB type. This distinction can be obtained by defining each event and data as public for the using-interface and private for the implementation-interface.
Fig. 13. Using and implementation-interfaces of the elevatorUnit FB type
B. Creating a levelled FB network diagram The question now is how a lower level FND can be connected to its upper level FND. Or, to give an example, how the FND of Fig. 8 can be integrated with the top level FND of Fig. 5 to create a levelled FND for the Festo MPS. In other words we have to examine the relation of testnunit Fb instance that is used in the top level FND to capture the testing unit control logic, with the FB instances of the lower FND that was created to capture the collaboration of the constituent sub-units of the Testing unit as for example the FND of Fig. 8 where the centralized control approach was adopted. The same question is valid for the corresponding FND that will be created adopting the distributed control approach. We consider as example the testUnit FB instance of Fig.5 and discriminate the following design alternatives: 1. the upper layer FB instance is considered as a composite FB. In this case testUnitFB that is composed of all the FB instances that constitute the FB network diagram of Fig. 8, 2. the upper layer FB instance is a basic FB type, that encapsulates the control logic required to coordinate the FB instances of the rest constituent FB instances of the lower level FB network. For the case of testUnitFB, it will encapsulate the control logic required to coordinate the FB instances that control the three sub-units of the unit, i.e. the testUnitFb of Fig. 5 is the same with the testerFB of Fig. 8. For both cases the adoption of using and implementationinterface allows for the FB instance to hide in each diagram this part of the interface that is not required. The case for the upper layer FB instance to be considered as a basic FB type that encapsulates the whole control logic of the unit that was supposed to represent in this high level of abstraction FND should also be mentioned when applying the top-down approach. This alternative is not always possible. If the corresponding mechanical unit is composed of modules that work concurrently as for example the processing unit, the basic FB type cannot be used to implement the instance since according to the IEC FB model the basic FB type has one thread of execution that is expressed by its ECC. This is not valid for the composite FB type (first alternative), which does
not have its own ECC to encapsulate the coordination of constituent components. A different approach, not compliant with the IEC16499 model, which allows the basic FB to encapsulate concurrent processes, is examined in [16]. C. Levelled FB network diagram semantics To better understand the semantics of the FB model and our attempt to construct a levelled FND we proceed to a comparison of the FND with the Data Flow Diagram (DFD). DFDs are a well known and extensively used modelling notation in the development of real time systems. The upper half of Fig. 14 shows a part of the leveled DFD diagram that presents the processes P1 and P2 that have been decomposed into the lower level data transformations and the corresponding control processes. A control process in DFD captures the coordination logic that defines the order of execution of data transformations. The corresponding FB network is given in the bottom half of Fig. 14. FB1 can be considered to represent in the design space the process P1 with the following mapping: • the control process CP1 is mapped to the head of FB1 and more specifically to the FB’s ECC. Given that state transition diagram (STD) is used for the specification of the control process the semantics proposed for the ECC have to be in depth examined and compared with those of the traditional STD, • data transformations (p1.1, p1.2, p1.3) are mapped to algorithms in the body of the FB type, • data stores (ds1-1, ds1-2) are mapped to internal variables of the FB type, • the interactions of type E/D or T between the control process (cp1) and the data transformations are mapped to the FB’s internal algorithm activation mechanisms. It can also be seen that the data connections between the FB instances correspond to the data store (ds1) that is used in the upper layer DFD for the communication of P1 with P2. Event connections on the other hand correspond to the event flows, i.e. R/L or S, that are used to model the synchronization of P1 with P2 in the DFD. This modelling approach is based on the distribution of the application’s control logic, a design decision that complicates the system’s expansion, maintenance and testability. To address these parameters an alternative way to model control in DFDs is provided through the centralized-control approach. A control process (CP0) is introduced to capture the control logic in this level of the DFD. This alternative leads to the introduction of the bodyless FB that will be assigned the synchronization and coordination of the FBs that represent the coordinated by cp0 processes in the DFD. But in this case the ECC of a bodyless FB type should not capture the control of execution of FB’s algorithms (i.e. data transformations) but the execution order and synchronization of the coordinated FBs. And the question is if the semantics of ECC, as defined by IEC 61499, are capable to express such synchronizationcoordination. It should be noted here that the composite FB has
IEEE Int. Conf. on Emerging Technologies and Factory Automation, (ETFA’06) Sept 2006, Prague. no head which could be able to capture such coordinationsynchronization logic.
level control. Even though many researchers have already reported encouraging results working with different aspects of the standard, many issues are still open. FESTO MPS was used as a running example in this paper to argue that the FB construct and the diagrams proposed by the standard i.e. the FB network and the ECC, prove insufficient to capture the different aspects of a control application. The semantics of the FB network as defined by the standard are not enough to capture the structure and behaviour of DCAs. To address this problem possible design alternatives were examined in order to be exploited for the generation of a levelled FB network diagram specification. It was also shown that the use of FIDs with a modified ECC can produce more expressive design diagrams that are better understood by control engineers. A prototype control application for the Festo MPS was developed. This application can be downloaded from the Corfu and Archimedes web sites along with an emulator of the Festo MPS that can be used to demonstrate the control application. ACKNOWLEDGEMENTS
Fig. 14. Mapping DFD constructs to FB-network’s constructs.
To examine the extensibility of this mapping in the case of more layers of abstraction, the semantics of composite and subapplication FB types have to be compared and examined versus the requirements of such a mapping. The semantics of the composite FB type as defined by the IEC model are not similar with those of the basic FB type. For example the composite FB type has no associated ECC and its body is not composed of algorithms. Instead a composite FB is considered as an aggregation of interconnected basic FB types or other composite FB types. Thus the behaviour of the composite FB can be obtained from the ECCs of the constituent components and their specific interconnections. This approach is considered a big disadvantage regarding the specification of the composite FB, since it does not provide a means for a clear and formal specification of the composite FB’s behaviour. This is why the composite FB can not be used to represent the higher layer of the DFD diagram of Fig. 14, i.e. the cp0 with the corresponding processes P1 and P2. The composite FB adopts the distributed control approach in the upper layer that is the one that is represented in DFD without the use of the control process cp0. From the above discussion it is clear that the FB paradigm has an advantage over the procedural one concerning reusability, since it allows the re-use of more complex structures that is not supported in the procedural paradigm. However this mapping can not be applied hierarchically to the higher layers and this can be considered as a disadvantage of the FB paradigm compared with the procedural one. VI.
I gratefully thank Evagelia Mpogiatzi for the first prototype implementation of the FESTO MPS control application and Nikolaos Papakonstantinou for developing the FESTO MPS emulator. REFERENCES [1] [2] [3]
[4] [5] [6]
[7] [8] [9] [10]
[11]
[12] [13]
[14] [15]
CONCLUSIONS [16]
Undoubtedly the IEC 61499 standard represents an important step for the exploitation of current software engineering practices in factory automation and mainly in low
[17]
International Electro-technical Commission, (IEC), International Standard IEC61499, Function Blocks, Part 1 - Part 4, IEC Jan. 2005. K. Thramboulidis, “IEC 61499 in Factory Automation”, Inter. Conf. on Industrial Electronics, Technology & Automation, Dec. 10-20, 2005. Stromman, M., S. Sierla, K., Koskinen, “Control Softawre Reuse Strategies with IEC 61499” 10th IEEE Int. Conf. on Emerging Technol. and Factory Automation, (ETFA’05), Catania, Italy, Sept. 2005. Lewis, R., Modeling control systems using IEC 61499, IEE 2001. J.H.Christensen, Design patterns for systems engineering in IEC 61499, Otto-von-Guericke-Universität Magdeburg, Germany, March 2000. Thramboulidis, K., “Development of Distributed Industrial Control Applications: The CORFU Framework”, 4th IEEE Inter. Workshop on Factory Comm. Systems, Vasteras, Sweden, August 2002. Martin-Luther-Universität, http://at.iw.uni-halle.de/~testbeds/index.htm Univer. Stuttgart, Inst. of Ind. Automation and Soft. Engin., http://www. ias.uni-stuttgart.de/forschung/demonstrationsanlagen/mpsanlage.en.html http://alice.stup.ac.ru/~dvn/fb61499/festo/visual_simulation_fbdk/ Cai, X. V., Vyatkin, H. Hanisch, “Design and implementation of a prototype control system according to IEC 61499”, IEEE Int. Conf. on Emerging Technologies and Factory Automation, Lisbon, Sept. 2003. Hussain, T., G. Frey, “Migration of a PLC Controller to an IEC 61499 Compliant Distributed Control System: Hands-on Experiences”, IEEE International Conference on Robotics and Automation (ICRA’05), Barcelona, Spain, April 2005. CORFU web site, http://seg.ece.upatras.gr/Corfu Thramboulidis, K., “Using UML in Control and Automation: A Model Driven Approach”, 2nd IEEE Int. Conf. on Industrial Informatics, 24-26 June, Berlin, Germany, (INDIN´04). Mpogiatzi, E. “Using IEC61499 in control and automation: The FESTO MPS case study” Master thesis, April 2006. (in Greek) Ferrarini, L., C. Veber, “Design and implementation of distributed hierarchical automation and control systems with IEC61499”, 3rd Int. Conf. on Industrial Informatics, Perth, Australia, Aug. 2005. Panjaitan, S. G. Frey, “Funtional Design for IEC61499 distributed control systems using UML activity diagrams”, Int. Conf. on Instrumentation, comuunications and information technology, Indonesia, Aug. 2005. Thramboulidis, K., C. Tranoris, “Developing a CASE Tool for Distributed Control Applications”, The International Journal of Advanced Manufacturing Technology, Vol. 24, No 1-2, July 2004, pp 24-31.
