- Email: [email protected]
Model-Based Development Concept for Hybrid Systems to Support Process Engineers in Thermo-Mechanical Process Development
Model-Based Development Concept for Hybrid Systems to Support Process Engineers in Thermo-Mechanical Process Development G. Bayrak*, B. Vogel-Heuser* *Chair of Information Technology in Mechanical Engineering, Technische Universität München, München, Germany,(email:. {Bayrak, vogel-heuser}@itm.tum.de) Abstract: A model-based development concept of hybrid systems in forming technology will be introduced in consideration of usability for process engineers. This is achieved by the combination of an activity diagram and block diagram for hybrid behavior. This concept supports process engineers to execute different series of experiments on the same machinery to gain and explore variable material characteristics of thermo-mechanical forming in a familiar environment. The integration of a closed loop control library which is directly generated from a Simulink model allows to build-up a hybrid system, where the graded properties of the thermo-mechanical process can be adjusted by the process engineer in a simple way. Recent evaluation in Project SFB/TRR30 showed the practicability of this concept. Keywords: Hybrid Systems, Modeling, Continuous Systems, Discrete Systems, State Charts
1. INTRODUCTION In the different fields of application, automation systems are becoming more complex. Most of them contain continuous and discrete behavior and are called hybrid systems. The development of these systems is an interdisciplinary process. Engineers from different disciplines are involved in project phases. Hybrid systems are modeled separately (discrete and continuous systems) in early design phases, i.e. the control engineer models the control engineering part in his familiar development environment, software engineers model processes in a modeling language like the Unified Modeling Language (UML). These individual models must be combined in code-level by programmer (see Fig. 1: “CodeIntegration”). There timing behavior has to be ensured, particularly by closed loop controllers, even after the implementation. The focus of this paper is to develop a concept, which is used in hybrid engineering, to support the design and implementation of hybrid systems in the domain of metal forming in the context of SFB/TRR30. Selecting an appropriate model notation is one of the challenges to engineer the hybrid systems. First the requirements of process engineers (forming technologist) in forming technology will be discussed. From this determined requirements, the superordinate system (discrete, continuous) in a metal forming application will be determined. It is necessary to categorize metal forming in order to provide the appropriate modeling languages and tools. One of the requirements is to enable the flexible sequence of process steps, especially for process engineers. The process engineer who wants to change the procedure of the pilot plant directly for different experiments has to understand the program and control the process. For example, different experimental series can only be realized by the laborious reprogramming of the process steps. If a new controller is being added or an existing controller that is in the program code is changed, this can
lead to inconsistency of (controller) model and code. The modified or newly added controllers can also have a time behavior, which has not been analyzed. This can lead to an unstable behavior. Therefore, the code and model must be synchronized and the model must be analyzed based on its time behavior, and finally the model must be converted back into code or be adjusted for modifications. Such modifications and permanent transformations between models or disciplines of hybrid systems and changes in code are often fault-prone and time consuming. The first goal is to create a hybrid development (see Fig. 1) that is appropriate for both control engineers and process engineers. The second goal is to integrate the environment into existing IEC 61131-3 editors (the standard programming languages for Programmable Logic Controllers, PLC) in order to realize interfaces between process engineers, control engineers, software engineers and programmers. The notation has to support both, continuous and discrete behavior in terms of its usability, and the implementation into PLC as target system (PLC with IEC 61131-3) with the intended time behavior. Additionally, concepts for the verification of the real-time behavior are outlined. We integrate concepts used in hybrid engineering to support the design and implementation of hybrid systems in the domain of metal forming. Therefore we combine activity diagrams with block diagrams usually employed by control engineers. This proposed model-based approach allows a decoupling of the domains: control engineers can develop continuous controllers in their familiar environment and can provide their controller as a function block library. A process engineer on the other hand can integrate these controller function blocks as process step in his design-environment (Technology-Editor) (see Fig.1: Interface between “Process engineer” and “Software engineer” above Library). The
resulting controller library and activity diagram enable the required modular hierarchical design of hybrid systems. Additional programming is not necessary, because behind every graph in the activity diagram lies a corresponding program code.
Tool-Integration
Software engineer Workpiece_heating (Press::)
Quill_back (Quill::)
Control engineer
FB CFC
Code generation [2]
Workpiece_press (Press::)
Activity Library Workpiece_heating (Press::)
Workpiece_press (Press::)
Quill_back (Quill::)
Programmer FB ST ...
Code
Model
Controller
Technology-Editor
UMLEditor [1]
CodeIntegration
Process engineer
Library
Fig. 1. Integration concept of Simulink in Technology-Editor. 2. STATE OF THE ART To distinguish our concept, it is necessary to examine what approaches already exist in the direction of UML and Matlab/Simulink code generator, Matlab/Simulink-UML integration and hybrid modeling and implementation. For the first points (UML and Matlab/Simulink code generator) we would like to refer to the publications of the authors Witsch and Vogel-Heuser (2009) and Bayrak et al. (2007). There are a few approaches about Matlab/Simulink integration in Kühl et al. (2002) and Sjöstedt at al. (2008). For example in Sjöstedt at al. (2008) is presented a procedure for transforming Simulink models to UML composite structure and activity models. But these approaches are not relevant for our concept. UML is not a familiar language for control engineers and specific controller tests (such as stability, time behavior). In our concept the integration will take place internally (see Fig.1: “Code” level); the models are coupled without transformation of the models into the other. The time behavior of both models will be analyzed by simulation on target platform. In the following sub-chapter we discuss the state of the art in particular coupling Simulink and UML models. There are a few approaches and tools to model hybrid systems. A comparison of these tools is presented in Giese and Henkler (2006) and Mosterman (1999). Hooman et al. (2004) combine the continuous-time model of a physical dynamical system in Simulink with a discrete time control algorithm in Rational Rose Real-Time (RT). The focus of this paper is the synchronization between Simulink and Rose-RT and not the implementation into the IEC 61131-3 in consideration of the time behavior in the target code. Chouikha et al. (2000) developed a model-based design approach for hybrid systems using Petri net, which has not been widely accepted and applied in the industry. Thompson
et al. (2007) describe a flexible multi-disciplinary cosimulation environment (Flexicon project) that is developed for the analysis and integration of distributed control systems using IEC 61499. For superordinate control of the discrete part they use Sequential Function Chart (SFC) in ISaGRAF Editor. SFC is used in co-simulation to control the continuous control model in Simulink. The code generations of ISaGRAF and Simulink have different target environments as it focuses on distributed systems. ISaGRAF generates IEC 61131-3 code and Simulink generates C code with Real-Time Workshop (RTW). Indeed it is possible to model SFC in Simulink/Stateflow as shown in Thompson et al. (2007). But this has been avoided in the Flexicon project, because firstly, the tool does not support the generation of PLC code and secondly, it is unfamiliar to automation engineers. In Stauner et al. (2001) a CASE tool prototype for the development of hybrid systems was presented. This includes structure diagrams for the architectural view as well as extended state machines and continuous block diagrams for the specification of the behavioral view on system components. The concept that we will present in this paper was based on this approach. In the following chapter, firstly, we discuss the requirements of modeling hybrid thermo-mechanical processes. Secondly, we develop a concept that has to meet the following requirements: •
Comprehensibility and usability of the modeling notation for process engineers (technology expert for forming).
•
Perpetuation of the familiar development environment for control engineers.
•
Verifying the time behavior of the continuous and discrete part of the system (hybrid time behavior).
•
Online debugging, to provide process engineers with the opportunity to monitor the controller and the process steps in real-time. 3. REQUIREMENT ANALYSIS FOR MODEL-BASED DEVELOPMENT IN THE AREA OF THERMOMECHANICALLY PROCESSES
In Esteva Payet et al. (2003) exist two types of hybrid systems. The question which system (discrete, continuous) is superordinate in metal forming application should be clarified in the context of the SFB. It is necessary to categorize metal forming in order to provide the appropriate modeling languages and tools. Firstly, the classification of hybrid systems is discussed in this chapter. After this, the application “metal forming” of thermo-mechanical processes is presented. In the following sub-chapter the requirements for thermo-mechanical processes are analyzed and finally the modeling approach for these hybrid systems is discussed. 3.1 Classes of Hybrid Systems There are two classes of interaction between discrete and continuous model parts of hybrid systems (Albert (1998) Esteva Payet et al. (2003) and Mostermann (1999)):
1.
The parts of discrete model can start a continuous process by triggered events (in Fig.2, Superordinate-D)
2.
The parts of continuous model can generate discrete events if continuous signal variables exceed threshold values (in Fig.2, Superordinate-C)
This first class is known as batch processes (ANSI/ISA-88 (1995)). The process steps of batch processes are processed successively (discrete), e.g. charging, mixing and tempering. But the process steps can include and start a continuous process, e.g. controller for heating the material to a given temperature. The applications of this area are chemical processes. The second class, i.e. continuous model part includes discrete processes, will start if continuous signal variables exceed threshold values. Superordinate - D state
Superordinate - C
1.
Discrete processing of the process steps on the top control level.
closed loop control
2.
On the second level, controllers have continuous behavior and can be called in top level process steps.
3.
Switching between controller strategies is a discrete action, which is a sub level of the second level (third level), i.e. they can only be called directly from the second level.
distance
heating
5cm
start
t
The aim of the SFB/TRR30 is to adjust selectively graded properties. To set graded properties, it is necessary to design a controller especially for the process steps that have most influence on the graded properties. We designed a controller for inductive heating (Bayrak et al. (2009)). For the modelbased development of hybrid systems, this means that individual process steps may also include controller. Furthermore, it may be necessary to realize various control strategies within one process step and by that switching between several controllers. Switching between different controller strategies is a discrete process. In the beginning of the investigation, we assigned the superordinate role to the control process (see Fig. 2, Superordinate-C). For these requirements, it is necessary to consider the modeling aspects of hybrid systems. Therefore, the following requirements need to be fulfilled:
t 0,15s
state
temperature closed loop control
1200°C
distance pressure
t
t
Fig. 2. Superordinate of Hybrid Systems. In our contribution, we will classify the thermo-mechanically coupled processes that are investigated within SFB/TRR30. We attempt to optimize the local structure of the work piece with regard to the local strain by respective process control. This requires new approaches to model and implement hybrid system control. 3.2 Application Example “Metal Forming” In the metal forming test bed, a shaft with flanges with graded properties is produced. The flange forming consists of four process steps: heating, transforming, forming and cooling (see Fig. 3, with columns’ names work piece conditioning). The metal forming and the other technology test beds were compared (Bayrak et al. (2009)). It was shown that most processes consist of the process steps heating, transforming, forming and cooling, but only the resources are different. Resources are technical compositions/machines, e.g. in one prototype (metal forming) "heating" is realized by inductive heating and in another prototype (friction pressure) by friction heating. These process steps are processed sequentially and discrete but there may be simultaneous processes in parallel. The heating and forming process run in parallel to keep a certain temperature (e.g. friction pressure). An activity diagram of metal forming is shown in Fig. 3. 3.3 Requirement Analysis for thermo-mechanical Processes
If we compare these requirements with the existing hybrid classes (see Fig. 2), it is obvious that the thermo-mechanical processes cannot be easily assigned to only one class. If the controller switching is neglected, the process could be assigned to class 2. One approach for hybrid systems class 2 has been presented in Stauner et al. (2001). The stateflow diagram represents the superordinate process that is assigned to an architecture diagram. Within one state, a controller, which was modeled in Simulink, is invoked. In our proposal this approach is expanded by integrating stateflow block in Simulink (third level), the requirements above can be met successfully. Unfortunately, the approach in Stauner et al. (2001) was not evaluated and not applied in industry. Finally we have to consider the controller switching. Both controllers depend on each other; because they access the same input variables, e.g. set point. Such (dependent) controllers are modeled completely in a Simulink model using the stateflow blocks. The idea is the following: •
If multiple controllers are to run on one resource, this is implemented in Simulink using the stateflow block. For example, the switching from pressure to distance controller in a press can be realized as a controller switch on one resource (in Fig.2, Superordinate-C). The Simulink model is integrated in one process step.
•
However, if controllers (distributed on different resources) are independent, e.g. temperature control in inductive heating, pressure control in press, this will be assigned to a process step, i.e. per controller, one process step.
3.4 Modeling appoarch for Hybrid Classes
The controllers (continuous behavior) are models in Simulink (named block diagram, too). The discrete behavior is usually modeled with stateflow diagram (Harel (1987)). The superordinate of the dynamic behavior in Bayrak et al. (2009) has been modeled by stateflow diagrams too. The aim of the
different requirements, e.g. successful stability analysis and switching without overshoot behavior. For such investigations Simulink is most appropriate. If we assign the controllers to each process step, the risk of overshooting and stability etc. has to be analyzed in the activity diagram of the
Fig. 3. Concept of the Technology-Editor for the production process of metal forming model-based development here is to provide a modeling language that will be accepted by process engineers and fulfills their requirements. In the previous work of our group in Witsch and Schünemann (2009), it was shown that the activity diagram is most appropriate for process engineers. A UML editor (following Technology-Editor) which adapts the UML-based activity diagram to the modeling requirements of process engineers is developed in Witsch and Schünemann (2009). The activity diagram shows the sequence of the process steps, i.e. the activities, and represents the open loop part of the process. Furthermore, the adequacy of the activity diagram for the test bed processes of SFB/TRR30 was evaluated in Bayrak et al. (2009). For this reason, the activity diagram will be chosen for the superordinate control part. The discrete behavior in Simulink to change between control strategies is modeled in stateflow. The stateflow blocks are used to model and simulate the finite state machines (Harel (1987)). The stateflow diagram in Simulink is based on hierarchical state charts with discrete transitions between states. The switching between different continuous controllers with its different equations systems will be realized by stateflow blocks. The whole system behavior during the switching between the controllers has to fulfill
Technology-Editor. Thereby activity diagram should be adequate for process engineers. It is not the responsibility of a process engineer to perform such control related investigations, besides that the activity diagram is not suitable for it. For this reason, both the controller and the related analysis for the controller should be carried out by the control engineer in his familiar development environment namely Simulink. The control engineer will provide a controller library for process engineers. The process engineer only needs to use this library in the Technology-Editor with activity diagram. For this reason Simulink models have to be integrated into the Technology-Editor. The control engineer only needs to click on the controller block in the library to open the closed loop controllers in Simulink. However, the process engineer remains in the familiar environment (Technology-Editor). In the next chapter, the expanded and the integrated Simulink models with stateflow blocks into the Technology-Editor are discussed. 4. EXTENDED CONCEPT OF TCHNOLOGY-EDITOR FOR PROCESS ENGINEERS As mentioned before, the sequence alteration of process steps in process engineering is known as "recipe control of batch
processes". In our pre-project of SFB/TRR30, this concept should be integrated and adapted with our UML-Editor in IEC 61131-3 (Witsch and Vogel-Heuser (2009)) for thermomechanical forming processes. In this project, the requirements were gathered and a concept for our so-called Technology-Editor has been developed in Witsch and Schünemann (2009). Additional requirements of the SFB/TRR30 will be discussed next. It is necessary to execute different series of experiments to gain and explore different material characteristics of thermomechanical forming on the same machinery. One of the requirements for the Technology-Editor is to enable the flexible sequence of process steps, especially for process engineers. The activity diagram is embedded into our UMLeditor and is mapped to ST code the usual internal presentation of CoDeSys code (standard PLC environment). Different experimental series can be realized by simply rearranging the order of activities or by changing parameters in selected activities. Additional programming is not necessary, because behind every graph in the activity diagram lies a corresponding program code. Fig. 3 shows the activity diagram of the metal forming test bed. The four columns of the diagram in Fig.3 separate the set points on the left hand site, which may be selected. The second left column allows to select the measuring devices and to adjust the measurement frequency. The second right column includes the process step activities, which may be arranged flexible by the process engineer under the automatically checked pre-requisite that the machine will be operated safely. These activities may be arranged by drag and drop from library box. 4.1 Mapping of Simulink Models into the Programming language Continuous Function Chart (CFC) It is also impossible to transform a Simulink model into a higher programming language like C for example by RTW. TwinCAT 3 (based on CoDeSys 3.0 with object-oriented extension) can also integrate C code in their environment. The disadvantage of the transformation from graphical into textual language is that the similarity of model and code is lost and the maintenance of the program is difficult. Mostly it is necessary to adjust the program code optimally to the environment or to the changed technical conditions. After a textual transformation of the model into program code, the code may not be changed or the model cannot be or only difficulty synchronized after a code modification. But by a 1:1 graphical transformation of the model into program code, the model can be easily synchronized even after modification of the code, especially as an automatic backtransformation is also possible. In addition, there may be failures, which occur only in the real environment, can directly be corrected in the code and the model will be adapted easily. A code generation that transforms the Simulink model into Continuous Function Chart (CFC) of TwinCAT, which is implemented in most IEC 61131-3 environments and provides similar graphical structure to Simulink, was presented in Bayrak et al. (2007). The similarity between
Simulink model and CFC model allow a direct 1:1 mapping. This is important for reusability, comprehensibility and maintenance of the program code. The correct functionality of the code generator was demonstrated with the help of a real Simulink model from a wind turbine and paper machine. It was shown that the time behavior in Simulink corresponds 99,9 % (coefficient of determination) with the time behavior of the generated code. 4.2 Implementation concept, time behaviour and online debugging In the previous chapter we have described the transformation of Simulink models into CFC code by code generation. The similarity between Simulink model and CFC model allow a direct 1:1 mapping. Therefore, the Simulink model is mapped to CFC (see Fig. 1): one block in Simulink is equivalent to one element in CFC. This is important for the online debugging. Additionally the stateflow block in Simulink (third level) is mapped to the stateflow diagram of the Technology-Editor. The stateflow function block, which integrates the stateflow diagram, is called from CFC. Thereby the stateflow function block needs to be positioned correctly inside of the CFC block. One process step can include one Simulink model (see Fig. 1). The Simulink models (independent controllers) of different process steps may have different cycle times (sample times). The PLC environment CoDeSys supports the generation of multiple IEC tasks (see Smart Software Solutions (2010)). One closed loop controller respectively one Simulink model will be assigned to one task. This is allowed for independent controllers in different process steps. The tasks must be activated and deactivated by a parameter. Controller with the same cycle time can be assigned to the same task. If the process engineer replaces a controller by another from the library then the cycle time of the hardware conditions (for example the fourfold-time) is checked. 5. EVALUATION The expanded concept (combination of process steps and interlocking conditions) of the Technology-Editor was evaluated in SFB/TRR30. The automation hardware of friction pressure is prepared and the Technology-Editor is as far as completed. It is planned to implement/install the Technology-Editor on the metal forming and friction pressure test bed on site. Thereby the approaches which are presented here, i.e., the process steps with controller and process steps with complex controllers, will be evaluated directly on the machine/process. In the metal forming test bed, each of the process steps heating, cooling and forming will contain an independent controller. During the forming process, the work piece cannot be hold at a certain temperature, because the heating of the work piece is completed before the forming starts. The friction pressure test bed has parallel process steps. In this case the transformation is dependent on several parameters, which are influenced from other process steps. The usability from a process engineer point of view and the time behavior will be evaluated in both test beds with its different requirements.
6. CONCLUSION AND OUTLOOK The concept of model-based development includes modeling concepts and languages of discrete and continuous behavior. The combination of both concepts and selected modeling languages support hybrid systems in the domain of forming technology. The focus of this paper is to support the requirements of process engineers in forming technology. The requirements are fulfilled by the definition of three levels. The top level includes the modeling of discrete processing of the process steps, which include the controller with continuous behavior (second level), which includes the switching between controller strategies with discrete action (third level). The control engineer models the controller in a familiar environment and provides a controller library for the process engineer. The necessary interfaces between the process steps with controller and the Simulink model are displayed graphically with using pins in activity diagram. Using multiple tasks, one controller can be attached to one task and therefore the time behavior of the controller is guaranteed. Using the 1:1 implementation from Simulink model to the programming language CFC the online debugging is provided. Recent evaluation by technology experts in SFB showed the practicability of this concept. The usage of this approach will be applied in the next step in Rapid Prototyping; for production of multi-material components. ACKNOWLEDGMENTS This publication is initiated by the research work of the Collaborative Research Center SFB/ TR TRR 30, which is sponsored by the German Research Foundation (DFG). The authors thank the Collaborative Research Center TRR30. REFERENCES Albert, J. (1998). Software-Architektur für virtuelle Maschinen. Ph.D. dissertation, Dept. Mechn. Eng., Technische Universität München, München. ANSI/ISA-88 (1995). S88 standard addressing batch process control. Bayrak, G., Flach, A., and Vogel-Heuser, B. (2009). New Methods of Process Management in the Development of Technological Treatments. In: Steinhoff, K., Maier, H.J. and Biermann D. (eds.), Functional Graded Materials in Industrial Mass Production, pp. 145-153. Rep. of Collaborative Research Centre TRR30. Verlag Wissenschaftliche Scripten, Auerbach. Bayrak, G., Wannagat, A., and Vogel-Heuser, B. (2007). Echtzeit- und Regelungstechnische Aspekte bei der automatischen Transformation zwischen Matlab/Simulink und SPS-basierten Steuerungen. In Holleczek, P., and Vogel-Heuser, B. (eds.), Echtzeit und Mobilität, Part 2, pp. 42-48. Springer, Berlin Heidelberg. Chouikha, M., Decknatel, G., Draht, R., Frey, G., Müller, C., Simon, C., Thieme, J., and Wolter, K. (2000). Petri NetBased Descriptions for Discrete-Continuous Systems. atAutomatisierungstechnik, vol. 48(9), pp. 415-425.
Esteva Payet, S. (2003). Modelling, Control and Supervision for a Class of Hybrid Systems. Ph.D. dissertation, Dept. Elect. Inf. Aut. Eng., Univ. Girona, Girona. Giese, H., and Henkler, S. (2006). A Survey of Approaches for the Visual Model-Driven Development of Next Generation Software-Intensive Systems. Journal of Visual Languages and Computing, 17(6), pp. 528-550. Harel, D. (1987). Statecharts: A Visual Formalism for complex systems. Science of Computer Programming, vol. 3(8), pp. 231-274. J. Hooman, N. Mulyar, L. Posta (2004). Coupling Simulink and UML Models. In: Lankhnech, Y.; Yovine, S. (eds.), FORMATS 2004 and FTRTFT 2004, pp. 304-311. Springer, Heidelberg. Kühl, M., Reichmann, C., Prötel, I., and Müller-Glaser, K.D (2002). From Object-Oriented Modeling to Code Generation for Rapid Prototyping of Embedded Electronic Systems. In: Proc. 13th IEEE Int. Workshop Rapid System Prototyping, pp. 108-114. SFB/TRR30 Transregional Collaborative Research Centre, Process-integrated manufacturing of functionally graded structures on the basis of thermo-mechanically coupled phenomena, funded by the German Research Foundation (DFG). Smart Software Solutions (2010). See also URL http://www.3s-software.com/index.shtml?de_homepage Mosterman, P. J. (1999). An Overview of Hybrid Simulation Phenomena and Their Support by Simulation Packages. In: Vaandrager, F.W. and Van Schuppen, J. H. (eds.), Hybrid Systems: Computation and Control, Vol. 1569 of LNCS, pp. 165-177. Springer-Verlag, Berlin. Sjöstedt, C., Shi, J., Törngren, M., Servat, D., Chen, D., Ahlsten, V., and Lönn, H. (2008). Mapping Simulink to UML in the Design of Embedded Systems: Investigating Scenarios and Structural and Behavioral Mapping. In: OMER 4 Post Workshop Proceedings. Stauner, T., Pretschner, A., and Péter, I. (2001). Approaching a Discrete-Continuous UML: Tool Support and Formalization. In: Proc. UML'2001 workshop on Practical UML-Based Rigorous Development Methods, pp. 242-257. Toronto. Thompson, H. A., Ramos-Hernandez, D. N., Fu, J., Jiang, L., Choi, I., Cartledge, K., Fortune, J., and Brown, A. (2007). A Flexible Environment for Rapid Prototyping and Analysis of Distributed Real-Time Distributed Safety-Critical Systems. Control Engineering Practice, vol. 15(1), pp. 77-94. Witsch D., and Schünemann, U. (2009). UML zur technologieorientierten Spezifikation von. atp– Automatisierungstechnische Praxis, vol. 6, pp. 50-57. Witsch, D., and Vogel-Heuser, B. (2009). Close integration between UML and IEC 61131-3: New possibilities through object-oriented extensions. In: Proc. 14th Int. Conf. Emerging Technologies and Factory Automation, Mallorca.
1. INTRODUCTION In the different fields of application, automation systems are becoming more complex. Most of them contain continuous and discrete behavior and are called hybrid systems. The development of these systems is an interdisciplinary process. Engineers from different disciplines are involved in project phases. Hybrid systems are modeled separately (discrete and continuous systems) in early design phases, i.e. the control engineer models the control engineering part in his familiar development environment, software engineers model processes in a modeling language like the Unified Modeling Language (UML). These individual models must be combined in code-level by programmer (see Fig. 1: “CodeIntegration”). There timing behavior has to be ensured, particularly by closed loop controllers, even after the implementation. The focus of this paper is to develop a concept, which is used in hybrid engineering, to support the design and implementation of hybrid systems in the domain of metal forming in the context of SFB/TRR30. Selecting an appropriate model notation is one of the challenges to engineer the hybrid systems. First the requirements of process engineers (forming technologist) in forming technology will be discussed. From this determined requirements, the superordinate system (discrete, continuous) in a metal forming application will be determined. It is necessary to categorize metal forming in order to provide the appropriate modeling languages and tools. One of the requirements is to enable the flexible sequence of process steps, especially for process engineers. The process engineer who wants to change the procedure of the pilot plant directly for different experiments has to understand the program and control the process. For example, different experimental series can only be realized by the laborious reprogramming of the process steps. If a new controller is being added or an existing controller that is in the program code is changed, this can
lead to inconsistency of (controller) model and code. The modified or newly added controllers can also have a time behavior, which has not been analyzed. This can lead to an unstable behavior. Therefore, the code and model must be synchronized and the model must be analyzed based on its time behavior, and finally the model must be converted back into code or be adjusted for modifications. Such modifications and permanent transformations between models or disciplines of hybrid systems and changes in code are often fault-prone and time consuming. The first goal is to create a hybrid development (see Fig. 1) that is appropriate for both control engineers and process engineers. The second goal is to integrate the environment into existing IEC 61131-3 editors (the standard programming languages for Programmable Logic Controllers, PLC) in order to realize interfaces between process engineers, control engineers, software engineers and programmers. The notation has to support both, continuous and discrete behavior in terms of its usability, and the implementation into PLC as target system (PLC with IEC 61131-3) with the intended time behavior. Additionally, concepts for the verification of the real-time behavior are outlined. We integrate concepts used in hybrid engineering to support the design and implementation of hybrid systems in the domain of metal forming. Therefore we combine activity diagrams with block diagrams usually employed by control engineers. This proposed model-based approach allows a decoupling of the domains: control engineers can develop continuous controllers in their familiar environment and can provide their controller as a function block library. A process engineer on the other hand can integrate these controller function blocks as process step in his design-environment (Technology-Editor) (see Fig.1: Interface between “Process engineer” and “Software engineer” above Library). The
resulting controller library and activity diagram enable the required modular hierarchical design of hybrid systems. Additional programming is not necessary, because behind every graph in the activity diagram lies a corresponding program code.
Tool-Integration
Software engineer Workpiece_heating (Press::)
Quill_back (Quill::)
Control engineer
FB CFC
Code generation [2]
Workpiece_press (Press::)
Activity Library Workpiece_heating (Press::)
Workpiece_press (Press::)
Quill_back (Quill::)
Programmer FB ST ...
Code
Model
Controller
Technology-Editor
UMLEditor [1]
CodeIntegration
Process engineer
Library
Fig. 1. Integration concept of Simulink in Technology-Editor. 2. STATE OF THE ART To distinguish our concept, it is necessary to examine what approaches already exist in the direction of UML and Matlab/Simulink code generator, Matlab/Simulink-UML integration and hybrid modeling and implementation. For the first points (UML and Matlab/Simulink code generator) we would like to refer to the publications of the authors Witsch and Vogel-Heuser (2009) and Bayrak et al. (2007). There are a few approaches about Matlab/Simulink integration in Kühl et al. (2002) and Sjöstedt at al. (2008). For example in Sjöstedt at al. (2008) is presented a procedure for transforming Simulink models to UML composite structure and activity models. But these approaches are not relevant for our concept. UML is not a familiar language for control engineers and specific controller tests (such as stability, time behavior). In our concept the integration will take place internally (see Fig.1: “Code” level); the models are coupled without transformation of the models into the other. The time behavior of both models will be analyzed by simulation on target platform. In the following sub-chapter we discuss the state of the art in particular coupling Simulink and UML models. There are a few approaches and tools to model hybrid systems. A comparison of these tools is presented in Giese and Henkler (2006) and Mosterman (1999). Hooman et al. (2004) combine the continuous-time model of a physical dynamical system in Simulink with a discrete time control algorithm in Rational Rose Real-Time (RT). The focus of this paper is the synchronization between Simulink and Rose-RT and not the implementation into the IEC 61131-3 in consideration of the time behavior in the target code. Chouikha et al. (2000) developed a model-based design approach for hybrid systems using Petri net, which has not been widely accepted and applied in the industry. Thompson
et al. (2007) describe a flexible multi-disciplinary cosimulation environment (Flexicon project) that is developed for the analysis and integration of distributed control systems using IEC 61499. For superordinate control of the discrete part they use Sequential Function Chart (SFC) in ISaGRAF Editor. SFC is used in co-simulation to control the continuous control model in Simulink. The code generations of ISaGRAF and Simulink have different target environments as it focuses on distributed systems. ISaGRAF generates IEC 61131-3 code and Simulink generates C code with Real-Time Workshop (RTW). Indeed it is possible to model SFC in Simulink/Stateflow as shown in Thompson et al. (2007). But this has been avoided in the Flexicon project, because firstly, the tool does not support the generation of PLC code and secondly, it is unfamiliar to automation engineers. In Stauner et al. (2001) a CASE tool prototype for the development of hybrid systems was presented. This includes structure diagrams for the architectural view as well as extended state machines and continuous block diagrams for the specification of the behavioral view on system components. The concept that we will present in this paper was based on this approach. In the following chapter, firstly, we discuss the requirements of modeling hybrid thermo-mechanical processes. Secondly, we develop a concept that has to meet the following requirements: •
Comprehensibility and usability of the modeling notation for process engineers (technology expert for forming).
•
Perpetuation of the familiar development environment for control engineers.
•
Verifying the time behavior of the continuous and discrete part of the system (hybrid time behavior).
•
Online debugging, to provide process engineers with the opportunity to monitor the controller and the process steps in real-time. 3. REQUIREMENT ANALYSIS FOR MODEL-BASED DEVELOPMENT IN THE AREA OF THERMOMECHANICALLY PROCESSES
In Esteva Payet et al. (2003) exist two types of hybrid systems. The question which system (discrete, continuous) is superordinate in metal forming application should be clarified in the context of the SFB. It is necessary to categorize metal forming in order to provide the appropriate modeling languages and tools. Firstly, the classification of hybrid systems is discussed in this chapter. After this, the application “metal forming” of thermo-mechanical processes is presented. In the following sub-chapter the requirements for thermo-mechanical processes are analyzed and finally the modeling approach for these hybrid systems is discussed. 3.1 Classes of Hybrid Systems There are two classes of interaction between discrete and continuous model parts of hybrid systems (Albert (1998) Esteva Payet et al. (2003) and Mostermann (1999)):
1.
The parts of discrete model can start a continuous process by triggered events (in Fig.2, Superordinate-D)
2.
The parts of continuous model can generate discrete events if continuous signal variables exceed threshold values (in Fig.2, Superordinate-C)
This first class is known as batch processes (ANSI/ISA-88 (1995)). The process steps of batch processes are processed successively (discrete), e.g. charging, mixing and tempering. But the process steps can include and start a continuous process, e.g. controller for heating the material to a given temperature. The applications of this area are chemical processes. The second class, i.e. continuous model part includes discrete processes, will start if continuous signal variables exceed threshold values. Superordinate - D state
Superordinate - C
1.
Discrete processing of the process steps on the top control level.
closed loop control
2.
On the second level, controllers have continuous behavior and can be called in top level process steps.
3.
Switching between controller strategies is a discrete action, which is a sub level of the second level (third level), i.e. they can only be called directly from the second level.
distance
heating
5cm
start
t
The aim of the SFB/TRR30 is to adjust selectively graded properties. To set graded properties, it is necessary to design a controller especially for the process steps that have most influence on the graded properties. We designed a controller for inductive heating (Bayrak et al. (2009)). For the modelbased development of hybrid systems, this means that individual process steps may also include controller. Furthermore, it may be necessary to realize various control strategies within one process step and by that switching between several controllers. Switching between different controller strategies is a discrete process. In the beginning of the investigation, we assigned the superordinate role to the control process (see Fig. 2, Superordinate-C). For these requirements, it is necessary to consider the modeling aspects of hybrid systems. Therefore, the following requirements need to be fulfilled:
t 0,15s
state
temperature closed loop control
1200°C
distance pressure
t
t
Fig. 2. Superordinate of Hybrid Systems. In our contribution, we will classify the thermo-mechanically coupled processes that are investigated within SFB/TRR30. We attempt to optimize the local structure of the work piece with regard to the local strain by respective process control. This requires new approaches to model and implement hybrid system control. 3.2 Application Example “Metal Forming” In the metal forming test bed, a shaft with flanges with graded properties is produced. The flange forming consists of four process steps: heating, transforming, forming and cooling (see Fig. 3, with columns’ names work piece conditioning). The metal forming and the other technology test beds were compared (Bayrak et al. (2009)). It was shown that most processes consist of the process steps heating, transforming, forming and cooling, but only the resources are different. Resources are technical compositions/machines, e.g. in one prototype (metal forming) "heating" is realized by inductive heating and in another prototype (friction pressure) by friction heating. These process steps are processed sequentially and discrete but there may be simultaneous processes in parallel. The heating and forming process run in parallel to keep a certain temperature (e.g. friction pressure). An activity diagram of metal forming is shown in Fig. 3. 3.3 Requirement Analysis for thermo-mechanical Processes
If we compare these requirements with the existing hybrid classes (see Fig. 2), it is obvious that the thermo-mechanical processes cannot be easily assigned to only one class. If the controller switching is neglected, the process could be assigned to class 2. One approach for hybrid systems class 2 has been presented in Stauner et al. (2001). The stateflow diagram represents the superordinate process that is assigned to an architecture diagram. Within one state, a controller, which was modeled in Simulink, is invoked. In our proposal this approach is expanded by integrating stateflow block in Simulink (third level), the requirements above can be met successfully. Unfortunately, the approach in Stauner et al. (2001) was not evaluated and not applied in industry. Finally we have to consider the controller switching. Both controllers depend on each other; because they access the same input variables, e.g. set point. Such (dependent) controllers are modeled completely in a Simulink model using the stateflow blocks. The idea is the following: •
If multiple controllers are to run on one resource, this is implemented in Simulink using the stateflow block. For example, the switching from pressure to distance controller in a press can be realized as a controller switch on one resource (in Fig.2, Superordinate-C). The Simulink model is integrated in one process step.
•
However, if controllers (distributed on different resources) are independent, e.g. temperature control in inductive heating, pressure control in press, this will be assigned to a process step, i.e. per controller, one process step.
3.4 Modeling appoarch for Hybrid Classes
The controllers (continuous behavior) are models in Simulink (named block diagram, too). The discrete behavior is usually modeled with stateflow diagram (Harel (1987)). The superordinate of the dynamic behavior in Bayrak et al. (2009) has been modeled by stateflow diagrams too. The aim of the
different requirements, e.g. successful stability analysis and switching without overshoot behavior. For such investigations Simulink is most appropriate. If we assign the controllers to each process step, the risk of overshooting and stability etc. has to be analyzed in the activity diagram of the
Fig. 3. Concept of the Technology-Editor for the production process of metal forming model-based development here is to provide a modeling language that will be accepted by process engineers and fulfills their requirements. In the previous work of our group in Witsch and Schünemann (2009), it was shown that the activity diagram is most appropriate for process engineers. A UML editor (following Technology-Editor) which adapts the UML-based activity diagram to the modeling requirements of process engineers is developed in Witsch and Schünemann (2009). The activity diagram shows the sequence of the process steps, i.e. the activities, and represents the open loop part of the process. Furthermore, the adequacy of the activity diagram for the test bed processes of SFB/TRR30 was evaluated in Bayrak et al. (2009). For this reason, the activity diagram will be chosen for the superordinate control part. The discrete behavior in Simulink to change between control strategies is modeled in stateflow. The stateflow blocks are used to model and simulate the finite state machines (Harel (1987)). The stateflow diagram in Simulink is based on hierarchical state charts with discrete transitions between states. The switching between different continuous controllers with its different equations systems will be realized by stateflow blocks. The whole system behavior during the switching between the controllers has to fulfill
Technology-Editor. Thereby activity diagram should be adequate for process engineers. It is not the responsibility of a process engineer to perform such control related investigations, besides that the activity diagram is not suitable for it. For this reason, both the controller and the related analysis for the controller should be carried out by the control engineer in his familiar development environment namely Simulink. The control engineer will provide a controller library for process engineers. The process engineer only needs to use this library in the Technology-Editor with activity diagram. For this reason Simulink models have to be integrated into the Technology-Editor. The control engineer only needs to click on the controller block in the library to open the closed loop controllers in Simulink. However, the process engineer remains in the familiar environment (Technology-Editor). In the next chapter, the expanded and the integrated Simulink models with stateflow blocks into the Technology-Editor are discussed. 4. EXTENDED CONCEPT OF TCHNOLOGY-EDITOR FOR PROCESS ENGINEERS As mentioned before, the sequence alteration of process steps in process engineering is known as "recipe control of batch
processes". In our pre-project of SFB/TRR30, this concept should be integrated and adapted with our UML-Editor in IEC 61131-3 (Witsch and Vogel-Heuser (2009)) for thermomechanical forming processes. In this project, the requirements were gathered and a concept for our so-called Technology-Editor has been developed in Witsch and Schünemann (2009). Additional requirements of the SFB/TRR30 will be discussed next. It is necessary to execute different series of experiments to gain and explore different material characteristics of thermomechanical forming on the same machinery. One of the requirements for the Technology-Editor is to enable the flexible sequence of process steps, especially for process engineers. The activity diagram is embedded into our UMLeditor and is mapped to ST code the usual internal presentation of CoDeSys code (standard PLC environment). Different experimental series can be realized by simply rearranging the order of activities or by changing parameters in selected activities. Additional programming is not necessary, because behind every graph in the activity diagram lies a corresponding program code. Fig. 3 shows the activity diagram of the metal forming test bed. The four columns of the diagram in Fig.3 separate the set points on the left hand site, which may be selected. The second left column allows to select the measuring devices and to adjust the measurement frequency. The second right column includes the process step activities, which may be arranged flexible by the process engineer under the automatically checked pre-requisite that the machine will be operated safely. These activities may be arranged by drag and drop from library box. 4.1 Mapping of Simulink Models into the Programming language Continuous Function Chart (CFC) It is also impossible to transform a Simulink model into a higher programming language like C for example by RTW. TwinCAT 3 (based on CoDeSys 3.0 with object-oriented extension) can also integrate C code in their environment. The disadvantage of the transformation from graphical into textual language is that the similarity of model and code is lost and the maintenance of the program is difficult. Mostly it is necessary to adjust the program code optimally to the environment or to the changed technical conditions. After a textual transformation of the model into program code, the code may not be changed or the model cannot be or only difficulty synchronized after a code modification. But by a 1:1 graphical transformation of the model into program code, the model can be easily synchronized even after modification of the code, especially as an automatic backtransformation is also possible. In addition, there may be failures, which occur only in the real environment, can directly be corrected in the code and the model will be adapted easily. A code generation that transforms the Simulink model into Continuous Function Chart (CFC) of TwinCAT, which is implemented in most IEC 61131-3 environments and provides similar graphical structure to Simulink, was presented in Bayrak et al. (2007). The similarity between
Simulink model and CFC model allow a direct 1:1 mapping. This is important for reusability, comprehensibility and maintenance of the program code. The correct functionality of the code generator was demonstrated with the help of a real Simulink model from a wind turbine and paper machine. It was shown that the time behavior in Simulink corresponds 99,9 % (coefficient of determination) with the time behavior of the generated code. 4.2 Implementation concept, time behaviour and online debugging In the previous chapter we have described the transformation of Simulink models into CFC code by code generation. The similarity between Simulink model and CFC model allow a direct 1:1 mapping. Therefore, the Simulink model is mapped to CFC (see Fig. 1): one block in Simulink is equivalent to one element in CFC. This is important for the online debugging. Additionally the stateflow block in Simulink (third level) is mapped to the stateflow diagram of the Technology-Editor. The stateflow function block, which integrates the stateflow diagram, is called from CFC. Thereby the stateflow function block needs to be positioned correctly inside of the CFC block. One process step can include one Simulink model (see Fig. 1). The Simulink models (independent controllers) of different process steps may have different cycle times (sample times). The PLC environment CoDeSys supports the generation of multiple IEC tasks (see Smart Software Solutions (2010)). One closed loop controller respectively one Simulink model will be assigned to one task. This is allowed for independent controllers in different process steps. The tasks must be activated and deactivated by a parameter. Controller with the same cycle time can be assigned to the same task. If the process engineer replaces a controller by another from the library then the cycle time of the hardware conditions (for example the fourfold-time) is checked. 5. EVALUATION The expanded concept (combination of process steps and interlocking conditions) of the Technology-Editor was evaluated in SFB/TRR30. The automation hardware of friction pressure is prepared and the Technology-Editor is as far as completed. It is planned to implement/install the Technology-Editor on the metal forming and friction pressure test bed on site. Thereby the approaches which are presented here, i.e., the process steps with controller and process steps with complex controllers, will be evaluated directly on the machine/process. In the metal forming test bed, each of the process steps heating, cooling and forming will contain an independent controller. During the forming process, the work piece cannot be hold at a certain temperature, because the heating of the work piece is completed before the forming starts. The friction pressure test bed has parallel process steps. In this case the transformation is dependent on several parameters, which are influenced from other process steps. The usability from a process engineer point of view and the time behavior will be evaluated in both test beds with its different requirements.
6. CONCLUSION AND OUTLOOK The concept of model-based development includes modeling concepts and languages of discrete and continuous behavior. The combination of both concepts and selected modeling languages support hybrid systems in the domain of forming technology. The focus of this paper is to support the requirements of process engineers in forming technology. The requirements are fulfilled by the definition of three levels. The top level includes the modeling of discrete processing of the process steps, which include the controller with continuous behavior (second level), which includes the switching between controller strategies with discrete action (third level). The control engineer models the controller in a familiar environment and provides a controller library for the process engineer. The necessary interfaces between the process steps with controller and the Simulink model are displayed graphically with using pins in activity diagram. Using multiple tasks, one controller can be attached to one task and therefore the time behavior of the controller is guaranteed. Using the 1:1 implementation from Simulink model to the programming language CFC the online debugging is provided. Recent evaluation by technology experts in SFB showed the practicability of this concept. The usage of this approach will be applied in the next step in Rapid Prototyping; for production of multi-material components. ACKNOWLEDGMENTS This publication is initiated by the research work of the Collaborative Research Center SFB/ TR TRR 30, which is sponsored by the German Research Foundation (DFG). The authors thank the Collaborative Research Center TRR30. REFERENCES Albert, J. (1998). Software-Architektur für virtuelle Maschinen. Ph.D. dissertation, Dept. Mechn. Eng., Technische Universität München, München. ANSI/ISA-88 (1995). S88 standard addressing batch process control. Bayrak, G., Flach, A., and Vogel-Heuser, B. (2009). New Methods of Process Management in the Development of Technological Treatments. In: Steinhoff, K., Maier, H.J. and Biermann D. (eds.), Functional Graded Materials in Industrial Mass Production, pp. 145-153. Rep. of Collaborative Research Centre TRR30. Verlag Wissenschaftliche Scripten, Auerbach. Bayrak, G., Wannagat, A., and Vogel-Heuser, B. (2007). Echtzeit- und Regelungstechnische Aspekte bei der automatischen Transformation zwischen Matlab/Simulink und SPS-basierten Steuerungen. In Holleczek, P., and Vogel-Heuser, B. (eds.), Echtzeit und Mobilität, Part 2, pp. 42-48. Springer, Berlin Heidelberg. Chouikha, M., Decknatel, G., Draht, R., Frey, G., Müller, C., Simon, C., Thieme, J., and Wolter, K. (2000). Petri NetBased Descriptions for Discrete-Continuous Systems. atAutomatisierungstechnik, vol. 48(9), pp. 415-425.
Esteva Payet, S. (2003). Modelling, Control and Supervision for a Class of Hybrid Systems. Ph.D. dissertation, Dept. Elect. Inf. Aut. Eng., Univ. Girona, Girona. Giese, H., and Henkler, S. (2006). A Survey of Approaches for the Visual Model-Driven Development of Next Generation Software-Intensive Systems. Journal of Visual Languages and Computing, 17(6), pp. 528-550. Harel, D. (1987). Statecharts: A Visual Formalism for complex systems. Science of Computer Programming, vol. 3(8), pp. 231-274. J. Hooman, N. Mulyar, L. Posta (2004). Coupling Simulink and UML Models. In: Lankhnech, Y.; Yovine, S. (eds.), FORMATS 2004 and FTRTFT 2004, pp. 304-311. Springer, Heidelberg. Kühl, M., Reichmann, C., Prötel, I., and Müller-Glaser, K.D (2002). From Object-Oriented Modeling to Code Generation for Rapid Prototyping of Embedded Electronic Systems. In: Proc. 13th IEEE Int. Workshop Rapid System Prototyping, pp. 108-114. SFB/TRR30 Transregional Collaborative Research Centre, Process-integrated manufacturing of functionally graded structures on the basis of thermo-mechanically coupled phenomena, funded by the German Research Foundation (DFG). Smart Software Solutions (2010). See also URL http://www.3s-software.com/index.shtml?de_homepage Mosterman, P. J. (1999). An Overview of Hybrid Simulation Phenomena and Their Support by Simulation Packages. In: Vaandrager, F.W. and Van Schuppen, J. H. (eds.), Hybrid Systems: Computation and Control, Vol. 1569 of LNCS, pp. 165-177. Springer-Verlag, Berlin. Sjöstedt, C., Shi, J., Törngren, M., Servat, D., Chen, D., Ahlsten, V., and Lönn, H. (2008). Mapping Simulink to UML in the Design of Embedded Systems: Investigating Scenarios and Structural and Behavioral Mapping. In: OMER 4 Post Workshop Proceedings. Stauner, T., Pretschner, A., and Péter, I. (2001). Approaching a Discrete-Continuous UML: Tool Support and Formalization. In: Proc. UML'2001 workshop on Practical UML-Based Rigorous Development Methods, pp. 242-257. Toronto. Thompson, H. A., Ramos-Hernandez, D. N., Fu, J., Jiang, L., Choi, I., Cartledge, K., Fortune, J., and Brown, A. (2007). A Flexible Environment for Rapid Prototyping and Analysis of Distributed Real-Time Distributed Safety-Critical Systems. Control Engineering Practice, vol. 15(1), pp. 77-94. Witsch D., and Schünemann, U. (2009). UML zur technologieorientierten Spezifikation von. atp– Automatisierungstechnische Praxis, vol. 6, pp. 50-57. Witsch, D., and Vogel-Heuser, B. (2009). Close integration between UML and IEC 61131-3: New possibilities through object-oriented extensions. In: Proc. 14th Int. Conf. Emerging Technologies and Factory Automation, Mallorca.