- Email: [email protected]
Stateflow and IEC 61499 Function Blocks
Proceedings of the 13th IFAC Symposium on Information Control Problems in Manufacturing Moscow, Russia, June 3-5, 2009
Automated Model Transformation between MATLAB Simulink/Stateflow and IEC 61499 Function Blocks Chia-han (John) Yang and Valeriy Vyatkin Department of Electrical and Computer Engineering, University of Auckland, New Zealand (e-mail: [email protected], [email protected]). Abstract: This paper presents a new method of modelling automation systems based on the combination and mutual transformation of Function Blocks of IEC 61499 and MATLAB Simulink/Stateflow. The ultimate goal of this development is to have a fully automated transformation between models built in the two platforms. The reasons for such transformation are due to the need for a proper validation environment for Function Blocks models and the difficulty in obtaining industrial acceptance in this new design approach. MATLAB Simulink/Stateflow provides a nice environment for modelling and simulation of control and embedded systems. Function Blocks are good for designing control application for complex physically distributed systems. An integrated software environment with transformation ability between these two tools will lead to a solution for the validation need for Function Blocks and also the adoption problems. This paper demonstrates a transformation practice where a Simulink model is transformed into a Function Block model in FBDK. The transformed model still requires some manual modifications to be executed because of the missing algorithm translation from MATLAB language to a language that can be used for algorithms in Function Blocks. This paper also discusses important issues of model transformation, such as semantics mapping, data type mappings and transformation rules. Keywords: Function Block, Simulation, Automation Control, IEC61499, Simulink 1. INTRODUCTION In recent years, several surveys indicated an increasing demand for flexibility and reconfigurability of control system in automation industry, including manufacturing and process industries (Chokshi and McFarlane, 2008, Felcht et al., 2003, Chia-han and Vyatkin, 2008). Investigation on how to meet this demand has begun, and one solution proposed by some researchers is by the use of Distributed Control Systems (DCS). Instead of having a centralised controller as in traditional control systems, DCS introduces a new concept of decentralised system structure, having multiple controllers handling individual devices or subsystems. These controllers may communicate with each other through some communication channel. There are several ways decentralised approach can be achieved. To address this issue, the International Electrotechnical Commission (IEC) has defined a new concept of designing control systems with an eventdriven module named Function Block (FB). It is believed that the Function Block approach can enhance the benefit of flexibility, software reusability and inter-operability, therefore achieving high reconfigurability. This idea has later been illustrated and established as IEC61499 standard (2005). However at the current status of development with Function Block, there are several challenges faced by researchers. One of the problems comes from the complexity of designing decentralised systems. Because of this complexity, it is difficult to ensure the correctness and robustness of the controller design. Our recent work (Vyatkin et al., 2009) emphasised this importance of verifying and validating the design in a closed-loop modelling approach, and it indicated that an integrated software environment for validation and verification is essential for designs based on Function Block. This environment may need to include several tools for simulation and verification, with the aim to help the end-
978-3-902661-43-2/09/$20.00 © 2009 IFAC
users to design a control system in a faster and more accurate way. The closed-loop plant-controller modelling implies the need for systematic development of plant models in function blocks. This process is complex and resource consuming. It would be better to re-use models developed using some established modelling frameworks, or interface such frameworks from the “IEC 61499 world”. Another challenge comes from the system engineering side. As noted in (Peltola et al., 2007), in order to be used in industry the perceived switching cost to Function Blocks need to be less than the perceived benefit. The costs of the change can be very substantial especially in restructuring and retraining to become familiar with the new design approach and new design tools. This problem leads to an idea of linking existing tools and languages with Function Blocks. This is exactly where a transformation process critically comes into play. Designers in control and automation industry are familiar with such tools as MATLAB or LABVIEW. If an automated transformation can be done between models in these existing tools to Function Blocks models, this would seriously improve Function Blocks’ industrial acceptance. Also since there is no readily usable tool for validation and verification of Function Block systems, including such a transformation procedure in our proposed integrated software environment can bring all the benefits together. Function Blocks are good for designing and maintaining controllers for distributed systems with capability of direct deployment, while modelling tools such as MATLAB Simulink/Stateflow are good for simulation and analysis of control systems. The transformation from one platform to another must be done without losing the nature of the models that have been designed in the previous platform.
205
10.3182/20090603-3-RU-2001.0302
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
In this work, MATLAB Simulink/Stateflow is chosen to be the target of transformation. The reasons are that it is a powerful tool in modelling and simulation, and majority of researchers and industrial engineers in control system domain are familiar with it. Also Simulink/Stateflow follows a blockdiagram modelling approach which is very close to the modular approach of Function Blocks. Control systems are normally modelled in a closed-loop way, where there are a “controller” and a “plant” model that describes the behaviour of the physical systems (see Figure 1). The controller sets control inputs of the plant based on the control algorithms and readings of the plant’s sensors. When dealing with validation and verification, it is very important that the systems are validated and verified using such a closed-loop model. For obvious reason, validation and verification of a controller by itself without understanding the resultant behaviours of the plant is not very useful.
1.
Mathematical operation (addition, subtraction, multiplication and division). 2. Input sources (Constants, Pulse Generator) 3. Switch, MUX/DEMUX (data manipulation) 4. “Transfer Function” blocks 5. Gain, Saturation, Abs 6. Memory, Integration, Zero-delay 7. S-function (supports external source written in JAVA or C codes) 8. Visualisation blocks (data display etc) 9. Stateflow (Individual package, but Simulink-based) Simulink is also capable of storing the output results in a data form, which can be used then for analysis or visualisation inside MATLAB. Sample Simulink models can be seen in the following diagrams. Figure 2 is a demo Simulink model provided by Mathworks Inc., representing a simple tank system illustrated in Figure 3.
Figure 1. Closed-loop model. Even though it is possible to just bridge these two software platforms together by using communication sockets (i.e. UDP or TCP/IP), having all models of plant and controller under same platform ensures no conflict in the nature of execution of the controller and plant models. In this paper, we present a perspective of transformation from MATLAB Simulink model to Function Block model while maintaining the nature of the model. For this purpose, Section II describes the semantics of both tools, followed by some transformation guidelines and rules in Section III. Section IV presents the preliminary results of the transformation work. Section V summarises some challenges still unsolved in this transformation practice.
Figure 2. Tank Fill and Empty demo model from MATLAB Simulink
2. SEMANTICS Understanding the semantics of both MATLAB Simulink/Stateflow and Function Blocks is essential for performing model transformation between the two. Here is an overview of these two tools.
Figure 3. A simple tank filling system
2.1 MATLAB Simulink/Stateflow Semantics Simulink is a software package from Mathworks Inc., which provides an environment for simulation and model-based design of dynamic control or embedded systems. It is a tool tightly integrated with MATLAB. It requires MATLAB to run and depends on MATLAB to define and evaluate models. To the best of the authors’ knowledge the developers of MATLAB/Simulink have never defined formal execution semantics of their languages. In order to understand the semantics one has to experiment with the tool. Modelling in Simulink is done by creating a network of “blocks” which are stored in the Simulink library. These blocks in the Simulink library represent common operations for describing and modelling control systems. The blocks include:
Figure 4. (a) An example Stateflow block. (b) The finite state chart inside the Stateflow block Stateflow is an interactive graphical design tool that works with Simulink to model and simulate event-driven systems. Figure 4a shows one example of a Stateflow block, and the encapsulated state charts are shown in Figure 4b. It allows modelling event-driven systems as finite-state machines. But it extends from the traditional Finite State Machine (FSM)
206
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
diagram by allowing hierarchical charts, parallel states, using temporal logic to schedule events. Simulink supports both discrete and continuous simulation through its built-in solvers, and therefore is capable for simulating hybrid systems as well. Also Simulink supports hierarchical structuring of models by grouping the related blocks into subsystems. An example of a subsystem can be seen in Figure 5.
2.2 Function Blocks Semantics As mentioned previously, IEC61499 standard introduces Function Blocks as a new modular way of designing controllers and modelling control systems. It is believed that modelling systems with a Function Blocks network will improve the flexibility, software reusability and reconfigurability in designing distributed control systems (Vyatkin, 2007). Figure 6 shows an example of a function block model of two tank system with a pump and a valve. There are two controllers in this example where one is controlling the pump and the other is controlling the valve. The aim of this tank system is to maintain the water level of tank 1 at a user-specified level. The pump follows a PID control algorithm to pump water from tank 2 to tank 1 if the water level of tank 1 is lower than the specified level. The valve will direct the water from tank 1 back to tank 2 if the level is higher than the specified level.
Figure 5. Subsystem example in Simulink. It is difficult to maintain and manage blocks in Simulink, especially if multi-layered subsystems exist. If a block is duplicated among the system and a change is required to this block, every single duplicated block has to be manually adjusted. This will certainly cause problems when modelling reconfigurable distributed system. Simulink models are simulated by “solvers” which compute the states of the system at successive time steps over a specified time span. This time steps can be fixed or variable. Simulink provides a set of solvers, where each follows a specific approach in solving a model (Ray, 2007). Fixed-step simulation is where the states of the system are calculated at fixed intervals. Variable-step simulation relies on the solver to determine the length of the time steps, and the time steps will vary over time. When the system is changing rapidly, the step size will be decreased, and vice versa. The solvers are generally categorised into continuous solvers and discrete solvers. Continuous solvers compute the state of a system in the current time step by using numerical integration from the state of the system in the previous time step and the state derivatives. Discrete solvers primarily solve only discrete models. They rely on the model blocks to update the discrete states of the models. There is no single method that can solve all types of models. Simulink allows assignment of user-defined priorities to each block in order to determine execution order. But if the priority is not defined, the system automatically assigns priority to each single block. State of each block (i.e. input and output values of the block) will be updated during a single time step of execution, in the order following the priority. More detail information about MATLAB, Simulink and Stateflow can be found from The Mathworks - MATLAB and Simulink for Technical Computing (http://www.mathworks.com).
Figure 6. An example of Function Block network of the two tank system The IEC 61499 standard defines a few design artefacts, such as basic and composite function blocks. A basic Function Block is a single event-driven module. It contains an Execution Control Chart (ECC) which is a finite-state machine. Therefore the basic structure of a basic Function Block is very similar to a single MATLAB Stateflow block. ECC describes the conditions of transitions between states and algorithms associated with each state. An example of a basic Function Block and ECC can be found in Figure 7.
Figure 7. Interface and ECC of the basic Function Block representing a tank system. A Function Block system may have a hierarchical layout through the use of Composite Function Blocks, which describe a subsystem of the entire Function Block network. Execution of Function Blocks is achieved by compiling them into executable code which works in conjunction with some pre-defined libraries. The code generation model plus the libraries are commonly referred to as run-time environment.
207
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
One of its important tasks is to dispatch events among Function Block network. Currently, there are several different run-time environments which are implemented with different execution models. The Function Block Run Time (FBRT) has the longest history. It uses “direct function calls” where an output event triggers the successive Function Blocks in a single thread. However this mechanism may result in stack overflow in case of event feedback loop, or in starvation of some blocks because the execution process of the caller block will be halted until all other function blocks along the event propagation path have completed execution. FBRT is written in Java, and is the built-in run-time of the Function Block Development Kit (FBDK). FORTE run-time relies on an event dispatcher for scheduling function blocks in a sequential order. So all input events will be delivered to their destination blocks in a first-in-first-out queue (FIFO) order. Similarly events are dispatched in the FUBER run-time (Cengic et al., 2006), where FIFO input event queue is used along with additional function block instance queue. Whenever an event is queued in a particular function block, this function block is then added to the instance queue. A scheduler is responsible to execute the queued instance in FIFO order. Cyclic run-times (Lastra et al., 2005, Tata and Vyatkin, 2009) inherits the idea from the traditional cyclic-scan model used in programmable logic controllers (PLC). In them, function blocks are activated periodically after input and output signals are updated. 2.3 Transformation of a closed-loop system The transformation must be done in a way that preserves the natures of the entire system. Taking a closed-loop system for example (see Figure 8), the behaviour of the plant must remain the same in both Simulink and Function Block models. Transforming a single Simulink block to a basic Function Block can be implemented directly as in both cases they can share exactly the same arithmetic interpretation of a model, which need to be captured in the syntax of both languages. The most important and difficult part of this transformation comes on the semantics mapping. If block-toblock transformation is implemented but the execution orders in the two domains are different, the resulting model (especially the “plant” side) may represent completely different systems. How to preserve the properties of the entire system will be the key research focus of this transformation process. Because of this reason, some transformation rules or guidelines must be set.
Figure 8. Closed-loop model transformation between two domains
3. TRANSFORMATION GUIDELINES AND RULES This section will discuss some transformation rules between Simulink/Stateflow and Function Block models (run-time independent). The rules are as follows: Rule 1: Establish a library consisting of corresponding Function Block to each block in the Simulink library. In this work we are mainly interested in those Simulink libraries that are relevant to automation systems applications. MATLAB Simulink provides modelling environment for many other engineering domains such as signal processing, telecommunication, etc. Therefore all the Simulink blocks considered here are those associated with control systems and embedded systems applications. Rule 2: Establish an appropriate translation mechanism between MATLAB modelling language to the languages supported in the Function Block standard (i.e. Structured Text, Java, Ladder Logic Diagrams, etc). Rule 3: Establish event handling mechanism. Function Block is an event-driven module but not all blocks in Simulink are associated with events. When transforming from Simulink to Function Block, it was considered to add two event inputs and two event outputs to such a transformed Function Block (see Figure 9). An initialisation input and output events would be helpful in setting up the initial conditions. A REQ input event is added with association to all data input as for updating any changes in the input side. A CNF output event is added with association to all data output. This output event must be signalled by any “actions” taken in the Function Block in order to notify a possible change in the data output side.
Figure 9. Event and data association after transformation Rule 4: Allow hierarchical layout. The following mappings will be considered: 1. A single Simulink block to a basic Function Block ; 2. A Simulink subsystem block to a composite Function Block ; 3. A Simulink system to a Function Block application ; Rule 5: Match model time in both models. As mentioned previously, Simulink follows a time step for execution. The transformed Function Block model must use the same “time step,” which can be
208
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
achieved by setting the time unit parameter of model FBs. It is illustrated in Figure 10. The model FB is activated by external “clock” signal. If simulation in real time is required (e.g. for animation of some processes) then the E_CYCLE (or RT_E_CYCLE as suggested in (Zoitl, 2008)) FBs can be used as the clock generator.
Table 1. Data Types mapping between Function Blocks (in FBDK) and MATLAB Simulink.
5. RESULTS
Figure 10. FB implementation of a discretized computation of a continuous function F given its derivative dF. Rule 6: Execution order of blocks must be the same in both domains. In other words, the execution priority of each block must be preserved. Rule 7: Continuous data must be carefully considered in the Function Block domain. MATLAB relies on its own continuous solvers for dealing with continuous data. Therefore either such a continuous solver must be created in Function Block environment or a discretization of such continuous data should be performed (resulting in purely discrete data in Function Block domain). The continuous model can be implemented as in Figure 11. Note that such implementation will not work properly in FBDK/FBRT due to the loopback event link.
In this experiment, FBDK is chosen even though its execution semantics has known issues in implementing closed-loop models. . However at such early stage of the development, the idea is just to demonstrate how the transformation can be done. From the technical perspective, the transformation can be done with assistance of some existing APIs associated with MATLAB Simulink and Function Blocks. The work provides a JAVA parser for the Simulink MDL file, and our research group has developed a Function Block to JAVA parser. Combining these two APIs together makes the development of the transformation easier. However the Simulink parser does not allow transformation from JAVA back to MDL file. This will have to be developed later.
Figure 11. FB implementation of a model dependent on a continuous input X. The output function is represented as F(X). The calculation is reactivated by loop back event link. Rule 8: Data types must be mapped correctly. In other words, the models can only contain the data with types that can be implemented in both domains. Rule 9: The models need to be free of errors before performing transformation. Figure 12. Transformation example from a Simulink/Stateflow model to a Function Block model.
4. MAPPING OF DATA TYPES Table of Data Types Mapping between Function Blocks (in FBDK) and MATLAB Simulink/Stateflow at this stage of development is shown in Table 1. The data types circled with the red rectangle are the ones currently usable in both Simulink and FBDK.
At this stage of the development, the transformation of Stateflow blocks has been completed, but the Function Block library for corresponding Simulink blocks has not been fully set up. This is because it is more important to solve the semantic mapping issue. Population of the library will be in the focus of future work. There are two reasons for paying
209
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
specific attention to the transformation of Stateflow. One is that Stateflow is very similar to Function Block as mentioned before. Both of them are event-driven blocks with behaviour described by a finite state machine diagram. Direct block-toblock transformation between the two can be easily implemented. Another reason is that Stateflow has many customizable properties where end users can specify behaviours of the block with algorithm and state charts. Figure 12 shows an example of a Function Block model transformed from a Stateflow-based Simulink model. 6. CHALLENGES AND FUTURE WORK The resulting Function Block system is still not executable yet due to the missing algorithm translation capability. The algorithms coded in MATLAB language (inside Stateflow blocks) cannot be fully automatically translated into readable language in FBDK. This is more of a technical issue to be completed in the near future. However, after some manual algorithm translation and slight modification of the Function Blocks, the system can be visually simulated along with some additional Function Blocks (i.e. Human Machine Interface (HMI) and visualisation) created earlier (see Figure 13).
Function Block Development Kit. Holobloc inc., http://www.holobloc.com. The MathWorks - MATLAB and Simulink for Technical Computing. http://www.mathworks.com. TUM Simulink Library. Lehrstuhl Software and Systems Engineering, http://www4.cs.tum.edu/~ccsm/simulink/. Function blocks: Internatinal Standard IEC61499. International Electrotechnical Commission. CENGIC, G., LJUNGKRANTZ, O. & AKESSON, K. (2006) Formal Modeling of Function Block Applications Running in IEC 61499 Execution Runtime. IEEE Conference on Emerging Technologies and Factory Automation, ETFA '06, p. 1269-1276. Prague, Czech Republic. CHIA-HAN, Y. & VYATKIN, V. (2008) Design and validation of distributed control with decentralized intelligence in process industries: A survey. 6th IEEE International Conference on Industrial Informatics. INDIN '08, p13951400. Daejeon, Korea. CHOKSHI, N. N. & MCFARLANE, D. C. (2008) A distributed coordination approach to reconfigurable process control, Springer, London. FELCHT, U. H., DARTON, R. C., PRINCE, R. G. H. & WOOD, D. G. (2003) The Future Shape of the Process Industries. Chemical Engineering: Visions of the World. Amsterdam, Elsevier Science LASTRA, J. L. M., GODINHO, L., LOBOV, A. & TUOKKO, R. (2005) An IEC 61499 application generator for scan-based industrial controllers. 3rd IEEE International Conference on Industrial Informatics, 2005. INDIN '05, p80-85. Perth, Western Australia.
Figure 13. Simulation from the Function Block model transformed from the Simulink model of the two tank system Here is a summary for future development in this software environment in order to fully complete the transformation procedure: 1. Function Block library for corresponding Simulink Blocks 2. Algorithm translation from MATLAB language to readable language in Function Block tools 3. Display and data collecting functionality in Function Block tools 7. CONCLUSIONS In this paper we considered mutual transformation of Simulink models and IEC 61499 function blocks, aiming at efficient development of closed-loop simulation models for distributed automation systems. Semi-formal transformation rules are presented. A trial software implementation of the transformation from Simulink/Stateflow models to Function Block models has been implemented. REFERENCES 4DIAC-RTE (FORTE): IEC 61499 Compliant Runtime Environment. PROFACTOR Produktionsforschungs GmbH, http://www.fordiac.org.
PELTOLA, J., CHRISTENSEN, J., SIERLA, S. & KOSKINEN, K. (2007) A Migration Path to IEC 61499 for the Batch Process Industry. 5th IEEE International Conference on Industrial Informatics, INDIN'07, Vol. 2, p811-816. Vienna, Austria. RAY, R. (2007) Automated Translation of MATLAB Simulink/Stateflow Models to an Intermediate Format in HyVisual. [Master thesis]: Computer Science Department. Chennai, Chennai Mathematical Insitute. TATA, P. & VYATKIN, V. (2009) Proposing a novel IEC61499 Runtime Framework implementing the Cyclic Execution Semantics. 7th International IEEE Conference on Industrial Informatics INDIN'09. Cardiff, UK. (accepted) VYATKIN, V. (2007) IEC 61499 function blocks for embedded and distributed control systems design, Research Triangle Park, NC, ISA-Instrumentation, Systems, and Automation Society, Triangle Park, USA. VYATKIN, V., HANISCH, H. M., CHENG, P. & CHIA-HAN, Y. (2009) Closed-Loop Modeling in Future Automation System Engineering and Validation. IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, Vol. 39, p17-28. ZOITL, A. (2008) Real Time Execution for IEC 61499 standard compliant applications, ISA-Instrumentation, Systems, and Automation Society, Triangle Park, USA.
210
Automated Model Transformation between MATLAB Simulink/Stateflow and IEC 61499 Function Blocks Chia-han (John) Yang and Valeriy Vyatkin Department of Electrical and Computer Engineering, University of Auckland, New Zealand (e-mail: [email protected], [email protected]). Abstract: This paper presents a new method of modelling automation systems based on the combination and mutual transformation of Function Blocks of IEC 61499 and MATLAB Simulink/Stateflow. The ultimate goal of this development is to have a fully automated transformation between models built in the two platforms. The reasons for such transformation are due to the need for a proper validation environment for Function Blocks models and the difficulty in obtaining industrial acceptance in this new design approach. MATLAB Simulink/Stateflow provides a nice environment for modelling and simulation of control and embedded systems. Function Blocks are good for designing control application for complex physically distributed systems. An integrated software environment with transformation ability between these two tools will lead to a solution for the validation need for Function Blocks and also the adoption problems. This paper demonstrates a transformation practice where a Simulink model is transformed into a Function Block model in FBDK. The transformed model still requires some manual modifications to be executed because of the missing algorithm translation from MATLAB language to a language that can be used for algorithms in Function Blocks. This paper also discusses important issues of model transformation, such as semantics mapping, data type mappings and transformation rules. Keywords: Function Block, Simulation, Automation Control, IEC61499, Simulink 1. INTRODUCTION In recent years, several surveys indicated an increasing demand for flexibility and reconfigurability of control system in automation industry, including manufacturing and process industries (Chokshi and McFarlane, 2008, Felcht et al., 2003, Chia-han and Vyatkin, 2008). Investigation on how to meet this demand has begun, and one solution proposed by some researchers is by the use of Distributed Control Systems (DCS). Instead of having a centralised controller as in traditional control systems, DCS introduces a new concept of decentralised system structure, having multiple controllers handling individual devices or subsystems. These controllers may communicate with each other through some communication channel. There are several ways decentralised approach can be achieved. To address this issue, the International Electrotechnical Commission (IEC) has defined a new concept of designing control systems with an eventdriven module named Function Block (FB). It is believed that the Function Block approach can enhance the benefit of flexibility, software reusability and inter-operability, therefore achieving high reconfigurability. This idea has later been illustrated and established as IEC61499 standard (2005). However at the current status of development with Function Block, there are several challenges faced by researchers. One of the problems comes from the complexity of designing decentralised systems. Because of this complexity, it is difficult to ensure the correctness and robustness of the controller design. Our recent work (Vyatkin et al., 2009) emphasised this importance of verifying and validating the design in a closed-loop modelling approach, and it indicated that an integrated software environment for validation and verification is essential for designs based on Function Block. This environment may need to include several tools for simulation and verification, with the aim to help the end-
978-3-902661-43-2/09/$20.00 © 2009 IFAC
users to design a control system in a faster and more accurate way. The closed-loop plant-controller modelling implies the need for systematic development of plant models in function blocks. This process is complex and resource consuming. It would be better to re-use models developed using some established modelling frameworks, or interface such frameworks from the “IEC 61499 world”. Another challenge comes from the system engineering side. As noted in (Peltola et al., 2007), in order to be used in industry the perceived switching cost to Function Blocks need to be less than the perceived benefit. The costs of the change can be very substantial especially in restructuring and retraining to become familiar with the new design approach and new design tools. This problem leads to an idea of linking existing tools and languages with Function Blocks. This is exactly where a transformation process critically comes into play. Designers in control and automation industry are familiar with such tools as MATLAB or LABVIEW. If an automated transformation can be done between models in these existing tools to Function Blocks models, this would seriously improve Function Blocks’ industrial acceptance. Also since there is no readily usable tool for validation and verification of Function Block systems, including such a transformation procedure in our proposed integrated software environment can bring all the benefits together. Function Blocks are good for designing and maintaining controllers for distributed systems with capability of direct deployment, while modelling tools such as MATLAB Simulink/Stateflow are good for simulation and analysis of control systems. The transformation from one platform to another must be done without losing the nature of the models that have been designed in the previous platform.
205
10.3182/20090603-3-RU-2001.0302
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
In this work, MATLAB Simulink/Stateflow is chosen to be the target of transformation. The reasons are that it is a powerful tool in modelling and simulation, and majority of researchers and industrial engineers in control system domain are familiar with it. Also Simulink/Stateflow follows a blockdiagram modelling approach which is very close to the modular approach of Function Blocks. Control systems are normally modelled in a closed-loop way, where there are a “controller” and a “plant” model that describes the behaviour of the physical systems (see Figure 1). The controller sets control inputs of the plant based on the control algorithms and readings of the plant’s sensors. When dealing with validation and verification, it is very important that the systems are validated and verified using such a closed-loop model. For obvious reason, validation and verification of a controller by itself without understanding the resultant behaviours of the plant is not very useful.
1.
Mathematical operation (addition, subtraction, multiplication and division). 2. Input sources (Constants, Pulse Generator) 3. Switch, MUX/DEMUX (data manipulation) 4. “Transfer Function” blocks 5. Gain, Saturation, Abs 6. Memory, Integration, Zero-delay 7. S-function (supports external source written in JAVA or C codes) 8. Visualisation blocks (data display etc) 9. Stateflow (Individual package, but Simulink-based) Simulink is also capable of storing the output results in a data form, which can be used then for analysis or visualisation inside MATLAB. Sample Simulink models can be seen in the following diagrams. Figure 2 is a demo Simulink model provided by Mathworks Inc., representing a simple tank system illustrated in Figure 3.
Figure 1. Closed-loop model. Even though it is possible to just bridge these two software platforms together by using communication sockets (i.e. UDP or TCP/IP), having all models of plant and controller under same platform ensures no conflict in the nature of execution of the controller and plant models. In this paper, we present a perspective of transformation from MATLAB Simulink model to Function Block model while maintaining the nature of the model. For this purpose, Section II describes the semantics of both tools, followed by some transformation guidelines and rules in Section III. Section IV presents the preliminary results of the transformation work. Section V summarises some challenges still unsolved in this transformation practice.
Figure 2. Tank Fill and Empty demo model from MATLAB Simulink
2. SEMANTICS Understanding the semantics of both MATLAB Simulink/Stateflow and Function Blocks is essential for performing model transformation between the two. Here is an overview of these two tools.
Figure 3. A simple tank filling system
2.1 MATLAB Simulink/Stateflow Semantics Simulink is a software package from Mathworks Inc., which provides an environment for simulation and model-based design of dynamic control or embedded systems. It is a tool tightly integrated with MATLAB. It requires MATLAB to run and depends on MATLAB to define and evaluate models. To the best of the authors’ knowledge the developers of MATLAB/Simulink have never defined formal execution semantics of their languages. In order to understand the semantics one has to experiment with the tool. Modelling in Simulink is done by creating a network of “blocks” which are stored in the Simulink library. These blocks in the Simulink library represent common operations for describing and modelling control systems. The blocks include:
Figure 4. (a) An example Stateflow block. (b) The finite state chart inside the Stateflow block Stateflow is an interactive graphical design tool that works with Simulink to model and simulate event-driven systems. Figure 4a shows one example of a Stateflow block, and the encapsulated state charts are shown in Figure 4b. It allows modelling event-driven systems as finite-state machines. But it extends from the traditional Finite State Machine (FSM)
206
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
diagram by allowing hierarchical charts, parallel states, using temporal logic to schedule events. Simulink supports both discrete and continuous simulation through its built-in solvers, and therefore is capable for simulating hybrid systems as well. Also Simulink supports hierarchical structuring of models by grouping the related blocks into subsystems. An example of a subsystem can be seen in Figure 5.
2.2 Function Blocks Semantics As mentioned previously, IEC61499 standard introduces Function Blocks as a new modular way of designing controllers and modelling control systems. It is believed that modelling systems with a Function Blocks network will improve the flexibility, software reusability and reconfigurability in designing distributed control systems (Vyatkin, 2007). Figure 6 shows an example of a function block model of two tank system with a pump and a valve. There are two controllers in this example where one is controlling the pump and the other is controlling the valve. The aim of this tank system is to maintain the water level of tank 1 at a user-specified level. The pump follows a PID control algorithm to pump water from tank 2 to tank 1 if the water level of tank 1 is lower than the specified level. The valve will direct the water from tank 1 back to tank 2 if the level is higher than the specified level.
Figure 5. Subsystem example in Simulink. It is difficult to maintain and manage blocks in Simulink, especially if multi-layered subsystems exist. If a block is duplicated among the system and a change is required to this block, every single duplicated block has to be manually adjusted. This will certainly cause problems when modelling reconfigurable distributed system. Simulink models are simulated by “solvers” which compute the states of the system at successive time steps over a specified time span. This time steps can be fixed or variable. Simulink provides a set of solvers, where each follows a specific approach in solving a model (Ray, 2007). Fixed-step simulation is where the states of the system are calculated at fixed intervals. Variable-step simulation relies on the solver to determine the length of the time steps, and the time steps will vary over time. When the system is changing rapidly, the step size will be decreased, and vice versa. The solvers are generally categorised into continuous solvers and discrete solvers. Continuous solvers compute the state of a system in the current time step by using numerical integration from the state of the system in the previous time step and the state derivatives. Discrete solvers primarily solve only discrete models. They rely on the model blocks to update the discrete states of the models. There is no single method that can solve all types of models. Simulink allows assignment of user-defined priorities to each block in order to determine execution order. But if the priority is not defined, the system automatically assigns priority to each single block. State of each block (i.e. input and output values of the block) will be updated during a single time step of execution, in the order following the priority. More detail information about MATLAB, Simulink and Stateflow can be found from The Mathworks - MATLAB and Simulink for Technical Computing (http://www.mathworks.com).
Figure 6. An example of Function Block network of the two tank system The IEC 61499 standard defines a few design artefacts, such as basic and composite function blocks. A basic Function Block is a single event-driven module. It contains an Execution Control Chart (ECC) which is a finite-state machine. Therefore the basic structure of a basic Function Block is very similar to a single MATLAB Stateflow block. ECC describes the conditions of transitions between states and algorithms associated with each state. An example of a basic Function Block and ECC can be found in Figure 7.
Figure 7. Interface and ECC of the basic Function Block representing a tank system. A Function Block system may have a hierarchical layout through the use of Composite Function Blocks, which describe a subsystem of the entire Function Block network. Execution of Function Blocks is achieved by compiling them into executable code which works in conjunction with some pre-defined libraries. The code generation model plus the libraries are commonly referred to as run-time environment.
207
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
One of its important tasks is to dispatch events among Function Block network. Currently, there are several different run-time environments which are implemented with different execution models. The Function Block Run Time (FBRT) has the longest history. It uses “direct function calls” where an output event triggers the successive Function Blocks in a single thread. However this mechanism may result in stack overflow in case of event feedback loop, or in starvation of some blocks because the execution process of the caller block will be halted until all other function blocks along the event propagation path have completed execution. FBRT is written in Java, and is the built-in run-time of the Function Block Development Kit (FBDK). FORTE run-time relies on an event dispatcher for scheduling function blocks in a sequential order. So all input events will be delivered to their destination blocks in a first-in-first-out queue (FIFO) order. Similarly events are dispatched in the FUBER run-time (Cengic et al., 2006), where FIFO input event queue is used along with additional function block instance queue. Whenever an event is queued in a particular function block, this function block is then added to the instance queue. A scheduler is responsible to execute the queued instance in FIFO order. Cyclic run-times (Lastra et al., 2005, Tata and Vyatkin, 2009) inherits the idea from the traditional cyclic-scan model used in programmable logic controllers (PLC). In them, function blocks are activated periodically after input and output signals are updated. 2.3 Transformation of a closed-loop system The transformation must be done in a way that preserves the natures of the entire system. Taking a closed-loop system for example (see Figure 8), the behaviour of the plant must remain the same in both Simulink and Function Block models. Transforming a single Simulink block to a basic Function Block can be implemented directly as in both cases they can share exactly the same arithmetic interpretation of a model, which need to be captured in the syntax of both languages. The most important and difficult part of this transformation comes on the semantics mapping. If block-toblock transformation is implemented but the execution orders in the two domains are different, the resulting model (especially the “plant” side) may represent completely different systems. How to preserve the properties of the entire system will be the key research focus of this transformation process. Because of this reason, some transformation rules or guidelines must be set.
Figure 8. Closed-loop model transformation between two domains
3. TRANSFORMATION GUIDELINES AND RULES This section will discuss some transformation rules between Simulink/Stateflow and Function Block models (run-time independent). The rules are as follows: Rule 1: Establish a library consisting of corresponding Function Block to each block in the Simulink library. In this work we are mainly interested in those Simulink libraries that are relevant to automation systems applications. MATLAB Simulink provides modelling environment for many other engineering domains such as signal processing, telecommunication, etc. Therefore all the Simulink blocks considered here are those associated with control systems and embedded systems applications. Rule 2: Establish an appropriate translation mechanism between MATLAB modelling language to the languages supported in the Function Block standard (i.e. Structured Text, Java, Ladder Logic Diagrams, etc). Rule 3: Establish event handling mechanism. Function Block is an event-driven module but not all blocks in Simulink are associated with events. When transforming from Simulink to Function Block, it was considered to add two event inputs and two event outputs to such a transformed Function Block (see Figure 9). An initialisation input and output events would be helpful in setting up the initial conditions. A REQ input event is added with association to all data input as for updating any changes in the input side. A CNF output event is added with association to all data output. This output event must be signalled by any “actions” taken in the Function Block in order to notify a possible change in the data output side.
Figure 9. Event and data association after transformation Rule 4: Allow hierarchical layout. The following mappings will be considered: 1. A single Simulink block to a basic Function Block ; 2. A Simulink subsystem block to a composite Function Block ; 3. A Simulink system to a Function Block application ; Rule 5: Match model time in both models. As mentioned previously, Simulink follows a time step for execution. The transformed Function Block model must use the same “time step,” which can be
208
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
achieved by setting the time unit parameter of model FBs. It is illustrated in Figure 10. The model FB is activated by external “clock” signal. If simulation in real time is required (e.g. for animation of some processes) then the E_CYCLE (or RT_E_CYCLE as suggested in (Zoitl, 2008)) FBs can be used as the clock generator.
Table 1. Data Types mapping between Function Blocks (in FBDK) and MATLAB Simulink.
5. RESULTS
Figure 10. FB implementation of a discretized computation of a continuous function F given its derivative dF. Rule 6: Execution order of blocks must be the same in both domains. In other words, the execution priority of each block must be preserved. Rule 7: Continuous data must be carefully considered in the Function Block domain. MATLAB relies on its own continuous solvers for dealing with continuous data. Therefore either such a continuous solver must be created in Function Block environment or a discretization of such continuous data should be performed (resulting in purely discrete data in Function Block domain). The continuous model can be implemented as in Figure 11. Note that such implementation will not work properly in FBDK/FBRT due to the loopback event link.
In this experiment, FBDK is chosen even though its execution semantics has known issues in implementing closed-loop models. . However at such early stage of the development, the idea is just to demonstrate how the transformation can be done. From the technical perspective, the transformation can be done with assistance of some existing APIs associated with MATLAB Simulink and Function Blocks. The work provides a JAVA parser for the Simulink MDL file, and our research group has developed a Function Block to JAVA parser. Combining these two APIs together makes the development of the transformation easier. However the Simulink parser does not allow transformation from JAVA back to MDL file. This will have to be developed later.
Figure 11. FB implementation of a model dependent on a continuous input X. The output function is represented as F(X). The calculation is reactivated by loop back event link. Rule 8: Data types must be mapped correctly. In other words, the models can only contain the data with types that can be implemented in both domains. Rule 9: The models need to be free of errors before performing transformation. Figure 12. Transformation example from a Simulink/Stateflow model to a Function Block model.
4. MAPPING OF DATA TYPES Table of Data Types Mapping between Function Blocks (in FBDK) and MATLAB Simulink/Stateflow at this stage of development is shown in Table 1. The data types circled with the red rectangle are the ones currently usable in both Simulink and FBDK.
At this stage of the development, the transformation of Stateflow blocks has been completed, but the Function Block library for corresponding Simulink blocks has not been fully set up. This is because it is more important to solve the semantic mapping issue. Population of the library will be in the focus of future work. There are two reasons for paying
209
13th IFAC INCOM (INCOM'09) Moscow, Russia, June 3-5, 2009
specific attention to the transformation of Stateflow. One is that Stateflow is very similar to Function Block as mentioned before. Both of them are event-driven blocks with behaviour described by a finite state machine diagram. Direct block-toblock transformation between the two can be easily implemented. Another reason is that Stateflow has many customizable properties where end users can specify behaviours of the block with algorithm and state charts. Figure 12 shows an example of a Function Block model transformed from a Stateflow-based Simulink model. 6. CHALLENGES AND FUTURE WORK The resulting Function Block system is still not executable yet due to the missing algorithm translation capability. The algorithms coded in MATLAB language (inside Stateflow blocks) cannot be fully automatically translated into readable language in FBDK. This is more of a technical issue to be completed in the near future. However, after some manual algorithm translation and slight modification of the Function Blocks, the system can be visually simulated along with some additional Function Blocks (i.e. Human Machine Interface (HMI) and visualisation) created earlier (see Figure 13).
Function Block Development Kit. Holobloc inc., http://www.holobloc.com. The MathWorks - MATLAB and Simulink for Technical Computing. http://www.mathworks.com. TUM Simulink Library. Lehrstuhl Software and Systems Engineering, http://www4.cs.tum.edu/~ccsm/simulink/. Function blocks: Internatinal Standard IEC61499. International Electrotechnical Commission. CENGIC, G., LJUNGKRANTZ, O. & AKESSON, K. (2006) Formal Modeling of Function Block Applications Running in IEC 61499 Execution Runtime. IEEE Conference on Emerging Technologies and Factory Automation, ETFA '06, p. 1269-1276. Prague, Czech Republic. CHIA-HAN, Y. & VYATKIN, V. (2008) Design and validation of distributed control with decentralized intelligence in process industries: A survey. 6th IEEE International Conference on Industrial Informatics. INDIN '08, p13951400. Daejeon, Korea. CHOKSHI, N. N. & MCFARLANE, D. C. (2008) A distributed coordination approach to reconfigurable process control, Springer, London. FELCHT, U. H., DARTON, R. C., PRINCE, R. G. H. & WOOD, D. G. (2003) The Future Shape of the Process Industries. Chemical Engineering: Visions of the World. Amsterdam, Elsevier Science LASTRA, J. L. M., GODINHO, L., LOBOV, A. & TUOKKO, R. (2005) An IEC 61499 application generator for scan-based industrial controllers. 3rd IEEE International Conference on Industrial Informatics, 2005. INDIN '05, p80-85. Perth, Western Australia.
Figure 13. Simulation from the Function Block model transformed from the Simulink model of the two tank system Here is a summary for future development in this software environment in order to fully complete the transformation procedure: 1. Function Block library for corresponding Simulink Blocks 2. Algorithm translation from MATLAB language to readable language in Function Block tools 3. Display and data collecting functionality in Function Block tools 7. CONCLUSIONS In this paper we considered mutual transformation of Simulink models and IEC 61499 function blocks, aiming at efficient development of closed-loop simulation models for distributed automation systems. Semi-formal transformation rules are presented. A trial software implementation of the transformation from Simulink/Stateflow models to Function Block models has been implemented. REFERENCES 4DIAC-RTE (FORTE): IEC 61499 Compliant Runtime Environment. PROFACTOR Produktionsforschungs GmbH, http://www.fordiac.org.
PELTOLA, J., CHRISTENSEN, J., SIERLA, S. & KOSKINEN, K. (2007) A Migration Path to IEC 61499 for the Batch Process Industry. 5th IEEE International Conference on Industrial Informatics, INDIN'07, Vol. 2, p811-816. Vienna, Austria. RAY, R. (2007) Automated Translation of MATLAB Simulink/Stateflow Models to an Intermediate Format in HyVisual. [Master thesis]: Computer Science Department. Chennai, Chennai Mathematical Insitute. TATA, P. & VYATKIN, V. (2009) Proposing a novel IEC61499 Runtime Framework implementing the Cyclic Execution Semantics. 7th International IEEE Conference on Industrial Informatics INDIN'09. Cardiff, UK. (accepted) VYATKIN, V. (2007) IEC 61499 function blocks for embedded and distributed control systems design, Research Triangle Park, NC, ISA-Instrumentation, Systems, and Automation Society, Triangle Park, USA. VYATKIN, V., HANISCH, H. M., CHENG, P. & CHIA-HAN, Y. (2009) Closed-Loop Modeling in Future Automation System Engineering and Validation. IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, Vol. 39, p17-28. ZOITL, A. (2008) Real Time Execution for IEC 61499 standard compliant applications, ISA-Instrumentation, Systems, and Automation Society, Triangle Park, USA.
210