+ All Categories
Home > Documents > [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada...

[IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada...

Date post: 08-Dec-2016
Category:
Upload: birgit
View: 218 times
Download: 3 times
Share this document with a friend
6
Supporting integrated development of closed-loop PLC control software for production systems Susanne Rosch, Daniel Schutz, Gulden Bayrak and Birgit Vogel-Heuser Institute of Automation and Information Systems Technische Universitat Minchen, Garching near Munich, Germany Email: {roesch.schuetz.bayrak.vogel-heuser}@ais.mw.tum.de Abstct-In this paper an approach to support the develop- ment process of closed-loop control soſtware for Programmable Logic Controllers (PLC) is shown. To enhance the development process, a fast and reliable data transfer between different tools and models used during different design phases is realized by model transformation. A core model created using the Systems Modeling Language (SysML) and a corresponding model editor based on the Unified Modeling Language (UML) in combination with a newly realized model transformation from the SysML parametric diagram to the Simulink block diagram is used to integrate the information from different engineering tools and models involved during automation engineering design phases. Hence, a consistent process for the development of closed-loop control software is realized. I. INTRODUCTION When designing, simulating and implementing closed-loop control soſtware for PLCs in automation several crucial steps are necessary during the design process. Furthermore, many aspects om a variety of disciplines, such as the geometrical measures om mechanical engineering, the structure of the controlled system from control engineering or the process om process engineering, must be taken into consideration. In each design phase different engineers from different disciplines are involved. However, the phases are not encapsulated and information from prior steps needs to be made available to the ones following. Up to now, manual extraction or transformation of information om one model to another is necessary, making the design phase time-consuming and prone to errors. Following this strain of thought, a core modeling language merging all information of the different phases seems necessary to provide a basis for gathering all information of a system. The Systems Modeling Language (SysML [1]) is a language, where most aspects, that need considering during the design phase of a plant and its software, can be depicted. It is an adaption of the Unified Modeling Language (UML), created to meet system engineers' requirements. Therefore, some diagrams and notations om the UML have been adopted and new diagrams have been defined. The SysML provides constructs to model structure, behavior, parametric coherences, etc. of system blocks [2]. However, SysML cannot replace all other tools in the design process, because some functionality, such as simulations of closed-loop controls, is not provided within SysML and the tools supporting this language. In the development process of the closed-loop control, firstly, the controlled system is modeled. This is an area of expertise of the mechanical engineer. As current research projects show [3], mechanical engineers work well with SysML. The controlled system can be modeled within the parametric diagram, which is useful when modeling physical aspects of the plant, e.g. con- tinuous systems, such as the controlled system of a component. The following development phase is the design and the simu- lation of the closed-loop control. Simulink is widely used and has its strengths in supporting the design and the simulation of closed-loop controls including simple tuning functions of the parameters. It is a graphic extension of MATLAB to enable interactive modeling and simulation of dynamic systems. In the MATLAB/Simulink environment the behavior of physical systems can be described and simulated using mathematical blocks. Simulation is not yet possible using solely SysML tools. The model of the controlled system designed in the prior step in SysML is crucial for the control engineer, and therefore it must be transferred into Simulink. In parallel to modeling the controlled system in SysML, several other production aspects are modeled as well, as for instance the process of a plant. To describe processes the activity diagram can be used. For this diagram among others, editors and code- generators for PLC runtime-systems [4] have been realized successfully. Using these code-generators, the process engineer is enabled to simply model the process in detail in the activity diagram. After having finished this model it is transfered into the PLC-runtime environment. Single steps of a process have to be implemented as a closed-loop control, e.g. the operation of a pump, making the control of the pump flow necessary [5]. A combination of the works mentioned above enables a consistent development process for PLC automation soſtware containing closed-loop controllers. However, to complete this concept and to make modeling a system in SysML as well as in Simulink easier, an automated transformation of the SysML parametric diagram to the Simulink block diagram has been implemented, which is presented in this paper. By these means different engineers are enabled to work in an environment they are comfortable with. The paper is structured as follows. First, related work is discussed. Subsequently, prior work and the missing link in form of a model transformation om SysML to Simulink, stating the mapping rules, is presented. The overall concept is evaluated using an application example from manufacturing automation in section IV. The last section sarizes the paper and gives an outlook on future work. 978-1-4673-2421-2/12/$31.00 ©2012 IEEE 6185
Transcript
Page 1: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics

Supporting integrated development of closed-loop

PLC control software for production systems

Susanne Rosch, Daniel Schutz, Gulden Bayrak and Birgit Vogel-Heuser

Institute of Automation and Information Systems Technische Universitat Mi.inchen, Garching near Munich, Germany

Email: {roesch.schuetz.bayrak.vogel-heuser}@ais.mw.tum.de

Abstract-In this paper an approach to support the develop­ment process of closed-loop control software for Programmable Logic Controllers (PLC) is shown. To enhance the development process, a fast and reliable data transfer between different tools and models used during different design phases is realized by model transformation. A core model created using the Systems Modeling Language (SysML) and a corresponding model editor based on the Unified Modeling Language (UML) in combination with a newly realized model transformation from the SysML parametric diagram to the Simulink block diagram is used to integrate the information from different engineering tools and models involved during automation engineering design phases. Hence, a consistent process for the development of closed-loop control software is realized.

I. INTRODUCTION

When designing, simulating and implementing closed-loop control software for PLCs in automation several crucial steps are necessary during the design process. Furthermore, many aspects from a variety of disciplines, such as the geometrical measures from mechanical engineering, the structure of the controlled system from control engineering or the process from process engineering, must be taken into consideration. In each design phase different engineers from different disciplines are involved. However, the phases are not encapsulated and information from prior steps needs to be made available to the ones following. Up to now, manual extraction or transformation of information from one model to another is necessary, making the design phase time-consuming and prone to errors. Following this strain of thought, a core modeling language merging all information of the different phases seems necessary to provide a basis for gathering all information of a system. The Systems Modeling Language (SysML [1]) is a language, where most aspects, that need considering during the design phase of a plant and its software, can be depicted. It is an adaption of the Unified Modeling Language (UML), created to meet system engineers' requirements. Therefore, some diagrams and notations from the UML have been adopted and new diagrams have been defined. The SysML provides constructs to model structure, behavior, parametric coherences, etc. of system blocks [2]. However, SysML cannot replace all other tools in the design process, because some functionality, such as simulations of closed-loop controls, is not provided within SysML and the tools supporting this language. In the development process of the closed-loop control, firstly, the controlled system is modeled. This is an area of expertise of

the mechanical engineer. As current research projects show [3], mechanical engineers work well with SysML. The controlled system can be modeled within the parametric diagram, which is useful when modeling physical aspects of the plant, e.g. con­tinuous systems, such as the controlled system of a component. The following development phase is the design and the simu­lation of the closed-loop control. Simulink is widely used and has its strengths in supporting the design and the simulation of closed-loop controls including simple tuning functions of the parameters. It is a graphic extension of MATLAB to enable interactive modeling and simulation of dynamic systems. In the MATLAB/Simulink environment the behavior of physical systems can be described and simulated using mathematical blocks. Simulation is not yet possible using solely SysML tools. The model of the controlled system designed in the prior step in SysML is crucial for the control engineer, and therefore it must be transferred into Simulink. In parallel to modeling the controlled system in SysML, several other production aspects are modeled as well, as for instance the process of a plant. To describe processes the activity diagram can be used. For this diagram among others, editors and code­generators for PLC runtime-systems [4] have been realized successfully. Using these code-generators, the process engineer is enabled to simply model the process in detail in the activity diagram. After having finished this model it is transfered into the PLC-runtime environment. Single steps of a process have to be implemented as a closed-loop control, e.g. the operation of a pump, making the control of the pump flow necessary [5]. A combination of the works mentioned above enables a consistent development process for PLC automation software containing closed-loop controllers. However, to complete this concept and to make modeling a system in SysML as well as in Simulink easier, an automated transformation of the SysML parametric diagram to the Simulink block diagram has been implemented, which is presented in this paper. By these means different engineers are enabled to work in an environment they are comfortable with. The paper is structured as follows. First, related work is discussed. Subsequently, prior work and the missing link in form of a model transformation from SysML to Simulink, stating the mapping rules, is presented. The overall concept is evaluated using an application example from manufacturing automation in section IV. The last section sUlmnarizes the paper and gives an outlook on future work.

978-1-4673-2421-2/12/$31.00 ©2012 IEEE 6185

Page 2: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics

II. RELATED WORK

In this section first approaches stating concepts for inte­grated engineering processes are addressed. Following this, related work realizing tool coupling between SysML and Simulink is considered.

A. Integrated engineering through tool support

The support of engineers throughout the different engineer­ing phases of mechatronic systems is a topic addressed by many researchers. Some works, such as the one proposed in this contribution, implement a core model whereas others rather focus on coupling tools along the development process. Thramboulidis et al. [6] and Shah et al. [7] identify SysML as a suitable language for capturing an integrated model of a mechatronic system. In [6] different views of a system are modeled and a central view captures the most important aspects. However, the need for other tools is acknowledged and the development of control code is supported, taking the aspects modeled in SysML into account. In [7] a platform keeping information consistent and on a central location is created. Through model transformation, data from the central model is passed on efficiently to other tools. In the approach presented by Secchi et al. [8] the mechatronic design and development processes are supported by extending the UML using the UML-RT profile to get a holistic view of the system. Using the tool Rose RealTime, code-generation is possible and system characteristics that should be regarded while implementing the PLC-runtime software can be identified. Maurmaier et al. [10] suggest a core model that describes the technical process in an abstract way. From this model the generation of different engineering documents and code through a set of transformation rules is made possible. Se­quences of Operation are the method used by Lennartson et al. [11]. In this way a process is described abstractly to support production processes. However, in the works suggesting a core model introduced in this section, the development of c1osed­loop control software is not explicitly focused and therefore a tool supporting the design of closed-loop controls and im­plementing the software with code-generation of closed-loop control software is not integrated into the concept. In contrast to the approaches mentioned above Lauder et al. [12], Estevez et al. [13] and Biffi et al. [14] do not aim at a core system model but at integrating different tools into the development process through tool coupling. In [14] this is achieved by metamodeling the different models that are used and defining mapping rules in between those tools. Estevez et al. [13] aim at preventing design errors through model checking. With model transformations and cross-checking of models the development process of control systems is supported. Biffi et al. [14] propose a broader concept of coupling tools to support mecha­tronic system development, including project, systems and software engineering but also team communication. Dubinin et al. [15] assist the development of control software explicitly for Distributed Control Systems by Function Block model transformation. By these means the behavior of the system is guaranteed in each execution model. In some of the approaches

focusing merely on tool-coupling instead of on a core model, a tool supporting the design of closed-loop controls is integrated into the tool coupling process, or at least into the concept of the integrated engineering process. However, a core model collecting all information and making it accessible to the engineers, such as the one suggested in this paper, is not a goal of these works and model transformation from SysML to Simulink has not been implemented yet.

B. Coupling SysML and Simulink

In the approach presented in this paper SysML and Simulink are coupled through automated model transformation from the SysML parametric diagramm to the Simulink block diagram. The transformation makes the controlled system modelled in SysML available to the engineers working with Simulink. In [16] the transformation is realized in the opposite direction, bringing information from Simulink diagrams into SysML, to achieve a holistic and complete representation of a sys­tem. This complete representation of a component further completes a core model in SysML. However, an appropriate support for the development of closed-loop controls is not enabled. In context of the AUTOSAR [17] project, a trans­formation of the SysML block diagram, which depicts the structure of a system, into the Simulink block diagram has been realized to transfer the structure of the machine, plant or component into Simulink. The transformation of parametric diagrams is not regarded and therefore the approach does not support the process of developing closed-loop controls. In the ParaMagic [18] plugin constraint blocks are transformed into MATLAB, simulated, and the results carried back to SysML. However, complete diagrams are not transformed and thusly the design phase in Simulink is not fully supported. In conclusion, no complete support of the development process for closed-loop control code for PLC, and more specifically, no mapping rules for the SysML parametric diagram to the Simulink block diagram were identified.

III. CONCEPT

The model transformation of parametric diagrams to Simulink block diagrams complements prior work of the au­thors which is introduced in the following. The tools connected in the development process proposed in this paper for PLC software are shown in Fig. 1. UML diagrams, such as the activ­ity diagram and the state chart diagram, which are also part of the SysML, have been implemented as a UML-Plugin for the PLC progranuning environment CoDeSys [19], creating the so-called technology-editor [4] (Fig. 1). With the technology­editor, the activity diagram is in fact the implementation of the PLC program. The diagram is automatically translated internally for the PLC run-time system (step 3). The different actions in the activity or state diagram are implemented in the IEC 61131-3-conform languages like structured text (ST), but masked within an activity. It is also possible to include Continuous Function Chart (CFC) code into the activities. The implementation of closed-loop controllers is required within some of the acitivties. A manual transfer of the model created

6186

Page 3: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics

SysML-Editor : UMLlIEC61131-3

: Technology-Editor

parametric diagram I activity diagram

CD. ®J� 0. ,-__ =--L ____ ��

Matlab/Simulink

Block Diagram I PLC

run-time system

Fig. l. Models and tool coupling in the development process of closed-loop control software.

in Simulink into the CoDeSys environment is not necessary, because a code generator has been developed and presented in [5], enabling the automatic generation of CFCs from con­trollers in Simulink, taking PLC properties into consideration (step 2). Combining these approaches, the different models in the development process are all supported and linked to a SysML core model, excluding the link between SysML and Simulink. To close the gap between developing PLC c1osed­loop control software a SysML editor for parametric diagrams and Simulink were coupled and the required mapping rules between the models were realized (step 1). The SysML Editor was used because the technology-editor containing the process modeled as an activity diagram does not fully support SysML and its parametric diagram yet.

In the following the transformation of the parametric dia­gram to the Simulink block diagram is presented. Therefore, an introduction of both diagrams is given to demonstrate which elements are of importance for the transformation. Subsequently, the identified mapping rules are explained.

A. Parametric diagram

The SysML diagrams can be structured into behavioral diagrams and structural diagrams. Behavioral diagrams include e.g. activity diagrams, which provide the notational elements to model production processes. Structural diagrams may be used to show structural aspects of a system. In contrast to both, the requirements diagram enables engineers to model system requirements. This diagram could neither be subordinated as a structural nor as a behavioral diagram. The parametric diagram is classified as one of the structural diagrams of SysML. It is a diagram newly created and derived from the internal block diagram, where the structure of components and their connections to one another are shown. The internal block diagram describes the internal structure of a system or component with parts, ports and connectors. In contrast, the parametric diagram describes physical interdependencies (e.g. F = m . a). It enables the engineer to model discrete as well as continuous systems. The parameters of a component are described as attributes of a block within the parametric diagram, the mathematical interdependencies are depicted in textual form as so-called constraints contained in constraint

blocks. In Fig. 2 a parametric diagram, which contains all elements defined for the parametric diagram in the SysML, is shown. "Block 1" contains a part property "B3" with "Block3" as type, a value property "a" and the constraint block property

«block» Block1

«block» B3: Block3

Fig. 2. A basic parametric diagram.

"CB2" of the type "ConstraintBlock2". This constraint block

contains a constraint (c = a· 3 + b) that specifies the value of the output parameter "c".

B. Simulink Block Diagram

The Simulink library offers a selection of standard blocks, both continuous, for instance controllers, and discrete blocks, for instance mathematical operations, etc. Time-varying sys­tems from engineering activities such as controller develop­ment are explicitly supported. The Simulink block diagram may be structured using subsystems. A subsystem may be the system which is controlled, but also a small group of blocks masked with a subsystem.

C. Model Transformation

The scheme of a closed-loop control is shown in Fig. 3. The block, emphasized by the dashed rectangle represents the plant or the process that is controlled. It represents the transformed model and is in the focus of this paper.

Controller

Fig. 3. Scheme of a closed-loop control.

For each element of the parametric diagram, objects with similar characteristics were identified and mapping rules were defined (see Table I). The block and the part property in the parametric diagram are basically the objects that structure the plant and the model. This function is fulfilled by subsystems

in Simulink. Typical subsystems are for instance the controlled system of a plant or a controller. Obvious mapping rules are the port that is transformed into either an in- or an outport, and the connectors which are transformed into lines and branches.

The value property of the parametric diagram is meant to be read out as well as read in. A block allowing the same operations in Simulink is the Data Store Memory Block, when also generating the corresponding Data Store Read and Data

Store Write Blocks. Value properties of a controlled system are all the parameters that influence it. While transforming the

6187

Page 4: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics

TABLE I MAPPING OF MODEL ELEMENTS

Parametric Diagram Simulink Block diagram Block, Part Property Subsystem

Port Inport/ Outport

Connector Line, Branch

Val ue Property Data Store Read, Write and Memory

Constraint Block Embedded MATLAB function

parametric diagram, all three blocks are generated to represent the value property, The physical constraints a component has to maintain are modeled using constraint blocks in the parametric diagram, In Simulink there is a wide variety of blocks that implement mathematical operations. However, the opportunity of importing whole mathematical functions from MATLAB also exists when using the Embedded MATLAB

Function. The Embedded MATLAB Function is an extension of the Fen-Block. When starting a simulation in Simulink an executable file is generated out of this block. Like a constraint

block the Embedded MATLAB Function may have several inputs. For these reasons and to maintain the graphical similar­ity between the transformed models to increase usability, the mapping rule was formulated between these two blocks. For the constraint to be correctly transformed, the constraints have to be formulated according to the MATLAB notation rules, e.g. abs(x) for the absolute value of x and so on. In contrast to this the constraints are usually formulated according to the Object Constraint Languange (OCL) [20] rules. If a specific block of the Simulink standard library is explicitly desired a standard constraint block can be defined in SysML, and the complementing mapping rule can be defined. A block where this was already necessary is a block integrating the input value over the simulation time. In the SysML Editor it is not possible to simulate continuous systems, therefore the simulation time can not be taken into consideration when executing a model within this editor. To generate an executable model in Simulink a standard "integrator block" was defined in SysML and the according mapping rule was formulated. To set this transformation into motion, the modeler simply has to name the modeled constraint block with the standardized name "integrator", of which an example can be found in section IV.

IV. ApPLICATION AND EVALUATION

To demonstrate the design process of implementing a closed-loop control in IEC 61l31-3, components of a labora­tory plant are considered for the development of a closed-loop control. The considered component is a rotary track switch that can be controlled by alternating the input voltage. The track switch has to route products between different conveyors and different angles (see Fig. 4). The parameter desired to adjust is therefore the angle where the track switch should be aligned in order to take in and pass on products.

Fig. 4. The rotary track switch.

A. Application Example

Firstly, the activities within the production process that are performed by the track switch were modeled using the technology-editor. By this the activity diagram modelling the process of a plant was integrated into a CoDeSys PLC envi­ronment (Fig. 5, A: technology-editor - activity diagram). Im­portant process steps in this activity diagram are the activities "turnLeft" and "turnRight" because they need to implement controllers. Following this, the physical interdependencies of the track switch were modeled within a SysML parametric diagram (Fig. 5, B: SysML editor). This model represents the controlled system. To make the information modeled in the parametric diagram available to the control engineer, an automated model transformation of the parametric diagram into a Simulink block diagram was performed (Fig. 5, step 1). The model contains two constraint blocks whose operation is to integrate the input over the simulated time. For this operation a Simulink block does exist in the standard library and an additional mapping rule was defined as described in section III B). To ensure the correct transformation of these blocks, they were named "integrator" as presented previously. The transformed diagram is masked within a Subsystem "track switch" and can be seen in Fig. 5 as the block, which is highlighted by a dashed rectangle (Fig. 5, C: Simulink). This way the controlled system was made available to the control engineer as a template for the complete closed-loop control in Simulink. After having simulated this system, the control engineer included a PID controller into the model (Fig. 5, C:Simulink). Using Simulink, the design and the simulation of the closed-loop control was done in a fast and efficient way, using the support offered by Simulink to tune the PID controller. Having finished design and simulations in Simulink, the controller was transformed into CFC-code (Fig. 5, step 2) and imported into the technology-editor (Fig. 5, A: technology-editor). The elements that were transformed can be seen as the part highlighted by a dashed-dotted rectangle. Subsequently, the process steps modeled earlier in the activity diagram could be associated with the CFC-code (Fig. 5, A: technology-editor). Further on, the relevant parameters of the in- and outputs of the CFC within the activity diagram could

6188

Page 5: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics

« constraint» a : accelAngle

Scope

-

• Simulink

---

c: SimUlink l - =-

--

------------------------------

PID_Controlier 2 fbPID_Controlier

LRlnl LROut1

,

, , , ,

,

, , , ,

D: Technology-editor - CFC' " -----------------------------------------, A: Technology-editor - activity diagram

L-� Subsystem: controlled system track switch 9 Transformation

.- .. L . J Part of Simulink model that is transformed to CFC :" .... ' Activity that is implemented by the CFC closed-loop control

Fig. 5. The transformation and code generation from one tool/model to another in the development process of closed-loop control software

be associated with the hardware of the system and the diagram with its IEC 61131-3 code could be translated internally during runtime.

B. Evaluation

The CFC-code generator and the UML-Plugin have been evaluated extensively in prior work [4], [5]. The model trans­formation between the parametric diagram and the Simulink block diagram has been evaluated for time invariant models as well as for continuous models. Since the SysML edi­tor used for parametric diagrams allows the calculation of discrete models, representing basic mathematical operations, the evaluation could be done by comparing outputs of an original SysML model with the transformed Simulink models. Several outputs, e.g. the energy height of a pump, were

compared to the transformed Simulink models. The outputs were validated in every model transformed. The second way the transformation was evaluated was by first creating the targeted model in Simulink, then creating the complementary model in SysML. The SysML parametric diagram was then transformed and the resulting model could be compared to the template model first created in Simulink. In the evaluation, three of these transformations were evaluated, one being a basic parametric diagram another being the controlled system of a tank system, and no mistakes were found in the models that were transformed. Having evaluated and implemented the transformations and having further on implemented the application example of the track switch in the design phase with constant help of automated transformations, it was shown,

6189

Page 6: [IEEE IECON 2012 - 38th Annual Conference of IEEE Industrial Electronics - Montreal, QC, Canada (2012.10.25-2012.10.28)] IECON 2012 - 38th Annual Conference on IEEE Industrial Electronics

that a development process of PLC-code is possible without the engineers being forced to manually transfer or extract information from models. In this way mistakes in the design phases following prior steps could be avoided and a consistent data flow was guaranteed.

V. CONCLUSION AND OUTLOOK

In this paper an integrated development process to support closed-loop control software development for PLCs has been described. It was shown that the implemented model transfor­mation described combined with prior work can support the engineering process of modeling and implementing c1osed­loop control software nearly throughout the whole process. Several aspects of the plant or machine can be modeled in a SysML core model with the import of additional information from other models. The process of a system is modeled within an activity diagram, controlled systems within a parametric diagram. Information needed from the parametric diagram for designing a closed-loop control can be transferred automati­cally to Simulink, where control engineers are able to design a closed-loop control and make refined tunings of controllers. In the next step the controllers are transferred into PLC-code, namely CFC-code. With the activity diagram, which is in itself the implementation of the PLC-code and is modeled in the technology-editor the program is now complemented by the CFC-implementation of the controllers. To complete the core model, a transformation back from Simulink to SysML, similar as the one realized in [16], but from the Simulink block diagram into the parametric diagram, is a goal desired by the authors. Further on, the integration of the technology editor and other SysML editors, such as the editor for parametric diagrams, is a focus in future work. Another important aspect that still needs to be integrated into the tool-support, is model-checking of the parametric diagram during modelling. To increase the reliability of the model transformation a check of the constraints in respect to MATLAB conformity as mentioned in section IV C is needed. Another aspect desirable in addition to the current transformations is the transmission and the tracking of re­quirements, which can be modeled in the SysML requirements diagram. Requirements such as nominal values or cycle times for the closed-loop controls already defined in the SysML model could be transformed automatically into Simulink, guaranteeing the correct transfer of this data. Furthermore, a central subversion server, where all tools used during the development process can be linked in order to track updates, changes and progressions is a goal pursued by the authors.

REFERENCES

[I] (2012) Systems Modeling Language Specification. [Online]. Available: http://www.omg.orgispec/SysML/

[2] H. Espinoza, D. Cancila, S. Selic, and S. Gerard, "Challenges in Combining SysML and MARTE for Model-Based Design of Embedded Systems," Model Driven Architecture - Foundations and Applications,

Lecture Notes in Computer Science, vol. 5562, pp. 98-113, 2009. [3] Design, implementation and evaluation of a tool-supported method for

the development of agent systems in automation technology, taking into account the usability (KREAagentuse), Deutsche Forschungsgemein­schaft (DFG) funded Project (VO 937/8-1).

[4] D. Witsch and B. Vogel-Heuser, "Close integration between UML and IEC 61131-3: New possibilities through object-oriented extensions," IEEE Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1-6, 2009.

[5] G. Bayrak, D. Renzhin, and B. Vogel-Heuser. "Integration of control loops in an UML based engineering environment for PLC," IEEE

Conference on Emerging Technologies and Factory Automation (ETFA), pp. 1-8,2011.

[6] K. Thramboulidis and A. Buda, "3+ I SysML view model for IEC 61499 Function Block control systems," 8th IEEE International Conference on Industrial Informatics (INDlN), pp.175-180, 2010.

[7] A. A. Shah, D. Schaefer, and C. 1. 1. Paredis, "Enabling multi-view modeling with SysML profiles and model transformations," Proceedings of the 6th International Product Lifecyc/e Management Conference, pp. 527538, 2009.

[8] C. Secchi, M. Bonft\ and C. Fantuzzi, "On the Use of UML for Modeling Mechatronic Systems," IEEE Transactions on Automation Science and Engineering (TASE), vol. 4, no. 1, pp.105-113, 2007.

[9] (2012) Rational Rose RealTime. [Online]. Available: http://www-01. ibm.com/software/awdtools/developer/technical/

[10] M. Maurmaier and P. Gohner, "Model-driven development in industrial automation - Automating the Development of Industrial Automation Systems using Model Transformations," Sixth International Conference on Informatics in Control, Automation and Robotics (ICINCO), 2009.

[II] B. Lennartson, K. Bengtsson, Chengyin Yuan, K. Andersson, M. Fabian, P. Falkman, and K. Akesson, "Sequence Planning for Integrated Product, Process and Automation Design," IEEE Transactions on Automation Science and Engineering (TASE), vol.7, no.4, pp. 791-802, 2010.

[12] M. Lauder, M. Schlereth, S. Rose, and A. Schlirr, "Model-Driven Sys­tems Engineering: State-of-the-Art and Research Challenges," Bulletin of the Polish Academy of Sciences, Technical Sciences, vol. 58, no. 3, pp. 409-422, 2010.

[13] E. Estevez and M. Marcos, "Model based Validation of Industrial Control Systems," IEEE Transactions on Industrial Informatics, vol. 8, no. 2, pp. 302-310, 2012.

[14] S. Bim, A. Schatten, and A. Zoitl, "Integration of heterogeneous engineering environments for the automation systems lifecycle," 7th IEEE International Conference on Industrial Informatics (INDIN), pp. 576-581, 2009.

[15] Y. Dubinin and Y. V yatkin, "Semantics-robust Design Patterns for IEC 61499," IEEE Transactions on Industrial Informatics, vol. 8, no. 2, pp. 279-290, 2012.

[16] A. Qamar, c. During, and 1. Wikander, "Designing Mechatronic Sys­tems, a Model-based Perspective, an Attempt to Achieve SysML­MATLAB/Simulink Model Integration," IEEEIASME International Con­ference on Advanced Intelligent Mechatronics, pp. 1306 - 1311,2009.

[17] G. Sandmann and R. Thompson, "Development of AUTOSAR Software Components within Model-Based Design," SAE World Congress, 2008.

[18] (2011) No Magic Incorporation, ParaMagic Plugln. [Online]. Available: https:llwww.magicdraw.com/paramagic

[19] (2012) 3S Software Solitions, CoDeSys. [Online]. Available: http://www.3s-software.com/

[20] (2012) Object Constraint Language (OCL). [Online]. Available: http://www.omg.orgispec/OCLl2.2/

6190


Recommended