SysML-based uniform behavior modeling and automated mapping of design and simulation model for complex mechatronics

Computer-Aided Design 45 (2013) 764–776

Contents lists available at SciVerse ScienceDirect

Computer-Aided Design journal homepage: www.elsevier.com/locate/cad

SysML-based uniform behavior modeling and automated mapping of design and simulation model for complex mechatronics Yue Cao a , Yusheng Liu a,∗ , Hongri Fan a , Bo Fan b a

State Key Lab. of CAD&CG, Zhejiang University, Hangzhou, 310027, PR China

b

School of International and Public Affairs, Shanghai Jiaotong University, Shanghai, 200030, PR China

article

info

Article history: Received 21 August 2011 Accepted 5 May 2012 Keywords: SysML Hybrid behavior modeling System-level behavior Mechatronic system Model transformation

abstract Model-based systems engineering (MBSE) is becoming a promising solution for the design of mechatronic systems with the increasing of complexity. To facilitate system design engineers to express their various behavioral requirements, a uniform behavior modeling approach is proposed based on SysML. A set of new constructs are proposed which compose the uniform behavior modeling profile. Based on the profile, the hybrid behavior of the mechatronic system can be uniformly represented in a multi-view and hierarchical way. Moreover, the language- and tool-dependent simulation related information is also described based on SysML as the complement part of the uniform behavior model, which can be transformed to different simulation platforms based on the triple graph grammar (TGG). In this way, the system-level design of the mechatronic system is simulated and verified automatically in the early design stage. Finally, the method is implemented and an example is given to illustrate the whole process. © 2012 Elsevier Ltd. All rights reserved.

1. Introduction The complexity of mechatronic systems is increasing which integrates multiple physical processes and multiple singular technologies together. System-level design, which considers mechanical, electrical and software components simultaneously, is needed for the development of complex mechatronics at the initial stage [1]. Recently, model-based systems engineering (MBSE) [2] has attracted many researchers’ attention and is becoming a significant method for the system-level design of mechatronic systems. And the standard system modeling language, SysML, has been proposed to support the specification, analysis, design and verification and validation of a broad range of complex systems [3]. Based on the formalized definition for the design requirements from the initial design stage, it provides unambiguous semantic description, supports early-stage simulation and gives a common communication platform between different stakeholders and designers. However, it is obvious that there are great differences between the mechatronic system and other complex systems. The most remarkable two are the multi-domain integration and discrete/continuous hybrid behavior. The intertwined hybrid behaviors of various domains result in the complexity of behavior modeling. Some research has been conducted to adapt MBSE for mechatronic system modeling [4]. However, according to our

∗

Corresponding author. Tel.: +86 57188206681. E-mail address: [email protected] (Y. Liu).

0010-4485/$ – see front matter © 2012 Elsevier Ltd. All rights reserved. doi:10.1016/j.cad.2012.05.001

knowledge, there is no a satisfactory method for SysML based mechatronic system behavior modeling and its integration with different simulation tools. The deficiencies lie in: (1) Only the physical part of the mechatronic system is considered now. Essentially, the mechatronic system is comprised of two parts: the control subsystem and the controlled physical subsystem. The control and software subsystem has become more and more important with the requirement of increasing the product intelligence and flexibility. (2) There is still no uniform behavior modeling framework defined in SysML. Specially, several diagrams are defined to represent the discrete behavior whereas the parametric diagram (PAR) can be used to represent the continuous behavior. However, there is still no uniform framework for complicated discrete/continuous hybrid behavior modeling [5,6]. The consequence is that different system engineers will devise different behavior representations for the same requirement and thus it is not easy to transform them into the simulation models automatically. (3) The integration between system design and simulation of mechatronic systems is still point-to-point, which puts a great burden on the developer. In fact, there is great similarity between different simulation-oriented languages. It is possible to develop a formalized mapping mechanism between the design and different simulation languages. Based on the above analysis, a SysML-based uniform behavior modeling language(UBML) is proposed as a SysML profile for

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

765

2.2. Model integration Nomenclature CA CP DAE DP EC ECC FB IBD MBSE PA PAR SA SPD SysML TGG UBML UML

Command amplifier Command potentiometer Differential algebraic equation Detection potentiometer Execution control Execution control chart Function block Internal block diagram Model-based system engineering Power amplifier Parametric diagram Signal amplifier Sequenced parametric diagram System modeling language Triple graph grammar Uniform behavior modeling language Uniform modeling language

facilitating systems engineers to define behavioral requirements uniformly and to help automate the mapping from design model to simulation model. This paper is organized as follows. Section 2 introduces the related works. Sections 3–6 describe the main parts of this method. Section 7 illustrates the implementation of the whole process with a case study. Section 8 presents the conclusion and future work. 2. Related work In this study, the hybrid behavior modeling and model integration of different languages for system-level design and simulation are two key parts. The following gives their related works respectively.

Since there are a wide range of domain-specific models and corresponding languages for modeling different aspects of the system, a model integration framework is needed for managing the various modeling languages [4]. Here, the languages for the system-level design and simulation, i.e. SysML for system-level design and Modelica [11] and Simscape [12] for system-level simulation are considered. SysML is a general modeling language with strong extensibility, while Modelica and Simscape are typical object-oriented languages for simulating the dynamic behavior of technical systems. Vanderperren and Dehaene discussed two possible integration methods between UML/SysML and Matlab/Simulink [13]. However, only the discrete behavior was considered and the association between the design and simulation model was not considered. Turki and Soriano [14] represented bond graph-based continuous dynamic behavior based on SysML activity diagrams. Pop et al. [15] proposed the ModelicaML as an integration of Modelica and UML which supports specifying the requirements, behavior, and Modelica simulation in a uniform way. Similarly, Nytsch-Geusen [16] presented the UMLH . These approaches created UML constructs representing the same semantics of Modelica ones and used the new created constructs to model the system behavior. Johnson et al. [17,18] introduced a formal approach for modeling continuous system dynamics in SysML based on language mapping between SysML and Modelica. Besides representing the continuous dynamics modeling constructs and method of Modelica in SysML, an approach for integrating the continuous dynamics model with other SysML constructs was also proposed. The dynamic behaviors in SysML and Modelica can be transformed into each other by the model transformation framework VIATRA [19]. Cao et al. also discussed the integration of system-level design and simulation of mechatronic system behavior [5,6] in which the design model in SysML and the simulation model in Simscape can be transformed into each other. Since this kind of approach is based on language mappings, they are restricted to certain simulation languages or tools. The uniform approach applicable to multiple simulation tools has not been proposed.

2.1. Hybrid behavior modeling 3. Uniform behavior model Mechatronic systems often exhibit both discrete behavior and time-continuous behavior. Therefore, hybrid behavior modeling is an essential work for mechatronic systems. Generally, the theoretical basis for hybrid behavior modeling is hybrid automata [7], in which the hybrid system is specified as a finite automaton. CHARON extended the hybrid automata to a modular hierarchic automata model [8]. The behavioral hierarchy is represented by modes. However, CHARON is a textual modeling language without standard visual representation. Hybrid UML [9] is a UML extension for the specification of hybrid systems which lifts the constructs with formal semantics of CHARON to the associated constructs in UML syntax. Since there are no continuous behavior modeling constructs provided by UML, the continuous behavior in hybrid UML is still modeled on a textual level. Moreover, the state in this approach has only control interfaces through which it can connect with other states by transitions. However, the data interfaces are not provided. Mechatronic UML [10] is a well-structured component-based specification technique for complex, reconfigurable mechatronic systems. The system behavior is modeled by the hybrid reconfiguration automaton which contains locations connected by transitions. Inside each location, the dynamic internal structure of the hybrid component is modeled by the composition structure diagram. This approach has achieved a tight integration of structure and behavior. However, the continuous behavior has not been explicitly modeled.

As mentioned above, the complexity of behavior modeling of mechatronic systems results from the following two intertwined aspects: (1) Hybrid behavior modeling: mechatronic systems often exhibit discrete behavior, time-continuous behavior, and hybrid behavior. (2) Multiple domain integration: the various involved domains are connected with each other with their own special characteristics. Moreover, the two aspects of complexities are not independent. Therefore, a general set of SysML constructs should be defined to express the domain-specific semantics. In this section, the UBML is defined based on the extension of SysML. The benefits of the UBML are two-fold. The first is to represent the above three types of behavior uniformly for both the control subsystem and the controlled physical subsystem. Therefore, system engineers can express their design intents for behavioral requirements uniformly. The second is to help automate the model transformation between system-level design and simulation models. 3.1. Definition of the UBML There are two extension mechanisms for SysML: the heavyweight method that defines new meta-classes and the light-weight method that creates stereotypes by extending existing constructs. Here, the latter is chosen since it is easy to be implemented by the existing SysML modeling tool.

766

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

Fig. 1. Uniform behavior modeling profile.

The proposed stereotypes composing the UBML are shown in Fig. 1 which include five sub-profiles. Sequenced parametric diagram (SPD) profile: It is extended from the constructs of PAR of SysML. Abstract constructs with general parametric constraining semantics are provided which are used as the foundational mechanism for hybrid behavior modeling. Hybrid behavior profile: It is built on the SPD profile and used to uniformly model the above-mentioned three types of behaviors. Physical profile: It is used to make semantic extensions for the physical systems. Generally, the constitutive equations of the compositive elements and the whole system can be represented similarly for different physical domains, e.g. mechanical and electrical. Therefore, their behaviors can also be described similarly. Control profile: Similar as the physical profile, it is used to assign control domain semantics to SysML constructs. Connection profile: The aim of this profile is for multi-domain integration. It provides several types of connectors to link the components of various domains. The former two are domain-independent sub-profiles used to establish the hierarchical structure of hybrid behavior modeling. The latter three are domain-specific sub-profiles used to establish the semantic nodes and connections of the hybrid behavior modeling. The physical profile is detailed in the next Section 4 whereas the other two are given similarly in Appendices A and B. Noticeably, the meta-model is used to interpret the semantics of each sub-profile of UBML since it is the formal description of modeling constructs. 3.2. SPD profile As mentioned above, the traditional basis for modeling hybrid behavior is the state machine. However, there are at least three shortcomings for it. The first is that the continuous behavior is expressed in textual formats. The second is that the parametric relations between equations and those between the structure and its behavior cannot be modeled explicitly. Thirdly, the state is not an instantiable construct, thus the reusability of states cannot be supported. Based on the above analysis, the constructs of the PAR were selected as the basis for hybrid behavior modeling in our previous work [6]. The detailed introduction of SPD can be found in Cao [6] and its meta-model is shown in Fig. 2. Here, the key element is the serialized constraint block(SCB) that is used to describe the serialized constraint property(SCP) of the block. The other elements in Fig. 2 are all used to support the special semantics of SCPs, which are that they take effect sequentially determined by the dependency relationship sequence. Moreover, the sequence relationship can own a condition that is a Boolean expression on the

Fig. 2. SPD meta-model. : Generalization relationship describing the inheritance between two classes which starts from the subclass and points to the su: Association relationship describing the properties or relations perclass. between 2 elements one of which is navigable. .

properties of the owner block, and a TransTrigger that represents the event flowing in through the port of the block. The sequence can be activated when the condition becomes true and the trigger occurs. 3.3. Hybrid behavior profile The hybrid behavior is comprised of discrete behavior and continuous behavior, which are completely different. Therefore, two groups of stereotypes named as continuous view and discrete view are defined for them in SPD respectively. Here, the view is used to contain an interested set of model elements that shows a certain aspect of the entire system for the target stakeholders. 3.3.1. Continuous view The continuous view is used to describe the time-continuous behavior. Generally, the continuous behavior is often defined by the constitutive equations on the system’s attributes. Among the SysML constructs, the constraint block is suitable for modeling continuous dynamics behavior since it includes constraints to describe differential algebraic equation (DAE) based behaviors and parameters to represent equation variables. Therefore, the continuous behavior is described by binding the parameters with system properties through binding connectors. Based on the above analysis, the ⟨⟨Continuous⟩⟩ stereotype is proposed to represent the DAE-based continuous behavior. As shown in Fig. 3(a), the ⟨⟨Continuous⟩⟩ stereotype is extended from the constraint block of SysML. Meanwhile, the instance of continuous constraint block is modeled by ⟨⟨Action⟩⟩ which is extended from the constraint property. Furthermore, ⟨⟨Independent ⟩⟩ and ⟨⟨Dependent ⟩⟩ stereotypes of parameters are proposed to distinguish the independent and dependent variables of the function since the continuous behavior may be described by causal functions instead of non-causal equations in the common PAR. 3.3.2. Discrete view The discrete view is used to describe the discrete part of the hybrid behavior. Generally, discrete behavior is represented as the state changes of the object through transitions between states in which the key objects are the state and the transition. Based on

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

(a) Stereotypes for modeling the time-continuous behavior.

767

(b) Stereotypes for modeling the discrete behavior.

Fig. 3. Stereotypes for the discrete and time-continuous behavior.

the above analysis, the ⟨⟨Discrete⟩⟩ stereotype is proposed as shown in Fig. 3(b) based on the stereotyped serialized constraint property of SPD. Moreover, the ⟨⟨State⟩⟩ is extended from the stereotyped serialized constraint property and ⟨⟨Transition⟩⟩ is a dependency relationship and used to connect the states. The activation of the transition obeys the rules defined for the sequence relationship. If the transition is activated, the state change occurs. 3.3.3. View merging and decoupling Since the hybrid behavior is comprised of the discrete behavior and continuous behavior, they should be merged together. In the SPD, the SCBs can have constraint properties(or sub SCBs) which are typed by constraint blocks(or sub SCBs), which determine the hierarchical nature of the SPD. Based on above analysis, the hierarchical state framework is generated if the discrete constraint block is instantiated to a state. On the other hand, it may also have actions typed by the continuous constraint blocks which are used to describe the continuous behavior in this state. Therefore, the continuous behaviors are attached to the discrete behaviors and thus two views are merged together. Noticeably, the discrete constraint block can own either states or actions alternatively. Therefore, the continuous behavior can only be attached on the leaf states in the state hierarchy. Since the two views are loosely coupled, they can be shown separately to facilitate the engineers to focus on different behaviors. 4. Physical profile The physical components are the basic units for constructing the whole system. They are connected through the energy ports to build the physical sub-system. With the consideration that there are various simulation modeling languages, it is necessary to recognize their commonness to facilitate the subsequent model transformation when the design-oriented physical components are constructed. Here, two typical simulation modeling languages, i.e., Simscape and Modelica, are analyzed at first. Then, the general physical modeling method is discussed and the corresponding profile is proposed. 4.1. Commonness analysis of Simscape and Modelica To analyze the commonness of Simscape and Modelica, their meta-models are discussed respectively at first. The Simscape language is a physical modeling language provided by MATLAB whereas Modelica is a freely available, object-oriented language for modeling of large, complex, and heterogeneous physical systems. By analyzing the Simscape language, the related part of metamodel is shown in Fig. 4. The main contents of the Simscape meta-model include three parts. The first part is the component itself which may belong to different domains. The second is to describe the static properties of the component which includes: the Variable that is the physical quantity whose value changes over time; the Parameter whose value is time-constant; Input/output

Fig. 4. The related part of the meta-model of Simscape : Composition relationship describing the part-of-a-whole relationship between two ends.

that transfers physical signals representing the values of physical quantities; and a Node through which the energy flows in/out of the component and which is typed by the domain representing the physical domain the component belongs to. The third part is to describe the behavior of each component which includes: action that includes the setup representing the initial condition of the simulation and the equation representing the equations constraining the internal behavior of the component during the simulation. Similarly, the related parts of the Modelica meta-model is analyzed and shown in Fig. 5. The basic concept is class, which can be restricted to the following specific classes: (1) model that describes the physical system itself or a physical block; (2) type that describes the mathematical data types (e.g. Real, Boolean) or user defined physical data types (e.g. Voltage, Current); (3) connector that defines the physical port type which only contains through and across variables of the specific physical domain. A model can contain components to declare its structure. The behavior of the model is described by equation, which specifies the evolution of the variables, and modification, the initial value assignment of the parameters. The physical system is constructed by connecting the models through their connectors using the connect clause. Moreover, the input/output and parameter in Fig. 5 have the same meanings as those in Fig. 4. By comparing the two languages, the underlying common concepts used for physical system modeling are obtained. Table 1 shows these concepts and the correspondences with the specific modeling elements of the two languages.

768

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776 Table 1 Correspondence between Simscape and Modelica. Concept

Simscape meta-model

Modelica meta-model

Physical system Physical component Variable (Across, Through) Parameter Energy port Input/output Energy type Initial condition Intrinsic equation

Simscape diagram Component Variable (Across, Through) Parameter Node Input/output Domain Setup Equation

Model (with hierarchical structure) Model (no hierarchical structure) Variable (Across, Through) Parameter Member class typed by connector Input/output Connector Modification Equation

Fig. 6. The physical profile.

5. Language- and tool-dependent model for automated simulation Fig. 5. The related parts of the meta-model of Modelica.

4.2. Physical modeling elements The physical systems can be regarded as energy-based systems comprised of components of the same or different domains which are connected by ports according to the generalized Kirchhoff’s law and the law of conservation of energy. The energy transferred among components is described with the through and across variables. Based on the above analysis, a uniform profile named the Physical profile is designed as shown in Fig. 6, which includes four parts. The first part is for the physical components itself. There are two stereotypes: ⟨⟨Physical⟩⟩ used to uniformly model the physical component and ⟨⟨EnergyType⟩⟩ to represent the energy type, which also corresponds to the type of the physical domain and has two properties: the ⟨⟨Across⟩⟩ and ⟨⟨Through⟩⟩ property. The second part is for describing the variables. Besides the above-mentioned across and through variables used to define the variables that change over time, there is another ⟨⟨Intrinsic ⟩⟩ stereotype used to define the time-constant value properties of the physical block. To specify the energy port and also determines the physical domain which the component belongs to, the third part of the physical profile is proposed in which a new stereotype ⟨⟨EnergyPort ⟩⟩ is proposed for energy flowing in/out of the block. Lastly, to assign specific physical semantics to the continuous behavior, two stereotypes are defined: the ⟨⟨Initial⟩⟩ stereotype used to indicate that the action sets the initial condition of the behavior whereas the ⟨⟨IntrinsicEqn⟩⟩ used to represent its internal behavior represented by the constitutive equations.

Simulation is one of the most commonly used methods to analyze system behaviors. To perform the simulation, only the behavior model itself is not enough since the uniform behavior model is platform-independent whereas the simulation is dependent on different specific simulation tools. Currently, different simulation modeling languages are used in different simulation tools. For example, Modelica is the used modeling language of Dymola [20] and MapleSim [21] whereas Simscape is for Simulink/Simscape. To support the automatic generation of the simulation model in different tools, the language-specific information also needs to be described in SysML besides the language-independent part of the uniform behavior model as given in Section 4. Moreover, the tool-dependent simulation supplement model is used to describe the properties of different tools. Without loss of generality, the MapleSim and Simulink/Simscape /Stateflow are selected as the typical simulation tools. 5.1. Language-dependent model Besides the common modeling elements provided by the proposed UBML, each modeling language has some specific modeling elements, which should also be represented with other mechanism. Here, the language mapping method presented in [5] is adopted to model the language-specific elements in SysML. The key idea of this method is that, for each modeling element in the specific modeling language, define a corresponding SysML stereotype to represent it. For example, there is a special class named record in Modelica, which is not included in the proposed UBML. Therefore, this element is defined as a stereotype named Record in the language-dependent meta-model of SysML which is specific to Modelica language.

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

769

Fig. 7. The basic model transformation framework.

5.2. Simulation tool-dependent supplement model Firstly, the necessary information for conducting a practical simulation is analyzed. It is obvious that the following four parts of information is imperative for the whole simulation: (1) system behavior to be simulated; (2) parameters of the system; (3) simulation configuration; (4) the variable needed to be observed. Besides the system behavior that is modeled with UBML and language-dependent model, it is found that the parameter setting is also similar in different tools and thus it can uniformly be described in the SysML simulation supplement model based on the comparison of typical simulation tools. However, the simulation configuration and the variable observation method are quite different which must be modeled with the language mapping method presented in [5]. Moreover, with the consideration that separates the unchanged experiment framework from the commonly adjusted parameters between the different iterations of simulation process, the simulation model is divided into two parts in this study: the simulation framework model and the simulation configuration model. The former represents the common framework of the series of simulation experiments and the latter specifies the parameter values of each iteration of simulation. 5.2.1. Simulation framework model The simulation framework model is defined to contain the simulation parameters, the system behavior model to be simulated and the scopes to detect variable values by connecting to proper ports of the components in the system. Here, the system behavior model is created by the uniform behavior modeling method introduced in Section 4. To describe the simulation configuration block, the ⟨⟨Simulation⟩⟩ stereotype is proposed which includes three parts of information. Take Simulink/Simscape/StateFlow as an example, the first part is a ⟨⟨Simulink⟩⟩ stereotype containing simulation parameters such as startTime and stopTime which may have default values. The second part is also a ⟨⟨Simulink⟩⟩ stereotype containing one or more Scopes with data ports used to observe the variables. The third part is the system behavior model itself. 5.2.2. Simulation configuration model The simulation configuration model assigns specific values to the value properties in the simulation framework model. Generally, the parameters can be divided into two kinds: those for the value properties of the defined blocks and those for the system behavior model. The parameter values are uniformly specified in the instances of target blocks. Exactly one instance of the block should be defined to model the specific experiment. 6. TGG based model transformation The uniform behavior model represented by UBML and the language- and tool-dependent model is the static model, which is difficult to be analyzed directly. To support the dynamic iterative simulation automatically, the static model should be transformed into the executable model in the specific simulation environment. With the consideration that both the system-level design modeling

Fig. 8. TGG-based model transformation method.

language and typical simulation modeling languages are all objectoriented, the meta-model based transformation method is adopted here and the basic transformation framework is shown in Fig. 7. It can be seen from Fig. 7 that the key problem here is the definition of meta-models of the source model and the target model as well as the transformation rules between them. After that, the source model can be transformed into target model based on the transformation engine and verse visa. Among all model transformation methods, the TGG-based method is adopted in this study based on the comparison result in Ref. [22]. The TGG based model transformation between the system-level design model and simulation model is shown in Fig. 8. It can be seen from Fig. 8 that the key problem for TGG based model transformation is the TGG based model transformation framework. Based on the framework, the bi-directional transformation can be conducted between SysML-based model and Simulink/ Simscape/StateFlow model, which are both represented by XMI format. Also, the transformation framework is built on the meta-model level which includes four parts: meta-modeling of UBML, language-related model and tool-dependent model, and transformation rules between them. The rules of the meta-model level are used to automate the transformation of the concrete models. Here, the related meta-model of SysML in [18,19] is referred to. Moreover, the Simulink-related meta-model is taken as the example of the target graph without loss of generality, which is detailed in Appendix C based on the work of Ref. [23]. The meta-model of Maple/ MapleSim/Control can be obtained similarly. Therefore, the focus here is the transformation rules. 6.1. TGG schema To build the bidirectional transformation relationship between the proposed uniform behavior model and the simulation model, the correspondence between their elements should be declared at first. Here, the TGG schema is constructed to include the integration link types that represent the correspondences between the elements in the source and target meta-models respectively. To identify the correspondence relationship, different strategies are used for the language-independent and language-dependent parts.

770

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

For the specific target modeling language, the languageindependent part of the meta-model is generated first. This part follows the common modeling rules as presented in Section 3. To identify the correspondence relationship for this part, the function and the semantics of each element in both source and target meta-models should be analyzed. Noticeably, the analysis should trace back to the underlying modeling methodology and find the role of the elements played in the modeling process. Here, the simulation model in Simulink can be divided into a hierarchical model including two levels: the system level and the component level. Therefore, the proposed modeling process is separated into two phrases correspondingly. Firstly, the control and physical components are designed and modeled including their structure and behavior. After that, the system can be constructed by selecting and instantiating the proper components from the library and connecting them to build the network. Noticeably, these result models are represented by modeling languages SysML with a UBML profile. For the language-dependent part of the specific modeling language, the correspondence rules already exist during the mapping process since the corresponding modeling elements in SysML are originally generated by language mapping. No additional step is needed to identify them.

Fig. 9. An example of the TGG rule.

6.2. TGG rules With the help of the TGG schema, the corresponding relationship between the target graph and source graph can be identified. However, the TGG schema is declarative, which is not enough to manipulate the graphs. TGG rules are imperative to describe how the source and target models evolve simultaneously. From them, the operational TGG rules are automatically derived which can be applied directly for different model integration tasks. In this study, a TGG rule is abstracted and formalized into a quaternion (OT, PT, BC, CC ). OT is the objective transformation which contains three objects instantiated from the classes in the integration link type definition. We call the objects from the source meta-model and target metamodel as transformable objects. Once one of the transformable objects is created, the other should be added simultaneously. In each rule, there is one and only one OT. PT is the transformation between properties of the transformable objects. The properties of the elements include simple properties typed by primitive types and referring properties typed by other classes in the meta-model. The transformation of simple properties is implemented by sharing the same rule parameters between corresponding properties of the source and target elements. Before creating referring properties, the type classes of the properties and their correspondence should exist. By creating links between the property types and the transformable objects, the property transformation is declared. BC is the belonging condition indicating the existence of the objects which contain transformable objects as their subelements. Before the transformation, the belonged objects and their correspondence should exist. After that, the new created transformable objects are attached to the belonged objects. CC is the constraining condition the transformable objects must satisfy before the transformation works. There are two kinds of conditions. The attribute condition constrains the values of the properties of the elements on which the rule works. And the referring condition indicates that a certain element has referred the transformable objects as its property. Each rule can have none or several BC s, MC s, and PT s. Different TGG rules can be defined by adding different BC, CC, or PT to the OT.

Fig. 10. The automated position control system of the workbench.

Fig. 9 shows an example of the TGG rule between the component instance of the system in UBML and the block of the diagram in Simulink (from top to bottom). Since the component of the system is represented by its part property, the rule works on the Property and the Block element srcObj2 and trgObj2 (2nd level). Both the transformable objects have two properties: the simple attribute name and the referring property type. The PT includes the assignment of the name attribute, and the linkage between Property and Class as well as Block and Chart (2nd and 3rd level). The BC shown in 1st level means that the Class object and the Diagram object should already exit before the transformation while both new created objects should be attached to them after the transformation. The CC shown in 4th level indicates that the Property object should be stereotyped by the PartProperty stereotype which refers the object as its base_Property attribute. 7. Implementation and case study 7.1. The used case To demonstrate the proposed method, a typical complex mechatronic system, i.e., a simplified machine tool with a specific function that controls the workbench position exactly, is used here as shown in Fig. 10. The system driver is a DC servo motor which is used to transfer the electric energy to mechanical energy to rotate the reducer which drives the ball screw. The equivalent circuit of the motor is given in Fig. 11. In turn, the workbench moves back and forth along the guide bar which is driven by the ball screw. Noticeably, how the motor rotates is controlled by the controller whose inputs are from the command potentiometer(CP) and the detection potentiometer(DP). The former is used to specify the needed objective position of the workbench whereas the latter is used to detect the actual one.

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

771

Fig. 13. Block diagram of workbench position control system with PI controller and state feedback controller. Fig. 11. Equivalent circuit of the motor.

Fig. 12. Block diagram of workbench position control.

After the signals of the two potentiometers are compared and amplified by signal amplifier (SA), the result signal is used as the input of the controller. Moreover, the output signal of the controller is amplified by the power amplifier(PA) and then input to the DC servo motor to drive the latter to rotate clockwise or anticlockwise in order to arrive at the specified position finally. The block diagram of the system is shown in Fig. 12. Here, the command amplifier (CA), signal amplifier (SA), and PA are all proportional links and their proportional factors are Kp , Kq , Kg respectively. Similarly, the DP transfers the detected position signal to the voltage signal and can also be regarded as a proportional link whose proportional factor is Kf . Ti and ωi are the torque and rotational velocity output from the motor, reducer and ball screw respectively. Furthermore, to improve the performance of the system, some control strategies are used to further tune the above system. Generally, the following tuning methods are used as shown in Fig. 13: (1) Series correction: a PI controller is added behind the SA. (2) Parallel correction: a local state feedback controller is used to feedback the velocity signal of the workbench before the PA. 7.2. SysML-based modeling The MBSE tool Magic Draw 16.5 [24] with SysML plugin [25] is used to model the system design result. The whole system is represented by one system block named Workbench System, and its internal structure is modeled in the Internal Block Diagram (IBD) as shown in Fig. 14. It can be seen from Figs. 13 and 14 that their connection topologies are very similar except that several sensors, i.e., sensorP and sensorV, are added in Fig. 14 which are ignored in Fig. 13. In addition, the proposed extended stereotypes are all used in the example. The gain, controller, switch, and comparer are defined as ⟨⟨FunctionBlock⟩⟩ stereotypes (Defined in Appendix A); the gear(reducer, ball screw), mass (workbench) are defined as ⟨⟨physical⟩⟩ stereotypes; the velocity sensor and position sensor are defined as ⟨⟨sensor ⟩⟩ stereotypes. Of all the components, the motor is the most complex and important one, which is used to realize energy conversion to transfer the electric energy to rotational mechanical energy. The armature equivalent circuit of the motor can be represented as shown in Fig. 11. Here, La and Ra are the equivalent inductance and resistance of the motor respectively; ua (t ), ia (t ) and Ea (t ) are the armature voltage, current and counter-electromotive force respectively; ω (t ) is the angular velocity of the motor shaft; TL (t )

is the equivalent torque of the loads on the motor shaft. Similarly, its IBD representation can be obtained as shown in Fig. 15. Here, all the components, i.e., resistor, inertia, damper, EMF, voltage source and reference, are based on ⟨⟨physical⟩⟩ stereotype. As mentioned above, control components are modeled as function blocks. Among the components, the Switch1 and Switch2 blocks involve both continuous and discrete behavior. Take Switch1 as the example, the hybrid behavior is described in the SPD as shown in Fig. 16, in which the ECC contains two states. In state 1, the output equals input 1, while in state 2, the output equals input 2. State 1 is the initial state, and after a given time (1 s in this study), switches to state 2 automatically. The state transition is represented by the Transition relationship between ECstates. Besides that, the data relationship is modeled by data connections between parameters of the control algorithm and the data ports of the function block, which describes the variables evolution clearly. Besides the uniform behavior model presented above, the language- and tool-dependent simulation model is also created as shown in Figs. 17–18. Fig. 17 shows the simulation framework model, in which, the simulation configuration block, and some Simulink specific blocks, i.e., scope and derivative, are defined as parts of the simulation block besides the system behavior model defined by ⟨⟨System⟩⟩ stereotype and connected to the target mechatronic system model to detect its variables. Fig. 18 shows an example of the simulation configuration model corresponds to one time of experiment. All parameters specific to this round of simulation can be provided in it. For example, the gain of the CA is set to 10, and the proportional and integral are set to 1.8 and 1/0.553 respectively. 7.3. TGG transformation There are several tools that can be used to implement the TGG based transformation. Here, MOFLON [26] is selected since it can support meta-modeling and TGG specification in a uniform environment. And based on the specification, the Java application to accomplish model transformation and consistency checking can be generated automatically. The TGG transformation process includes two parts [27]. One is about executable rule generation, i.e., specifying the relative meta-models, TGG schema and rules, and generating executable code from them. The other is rule application, i.e., performing the specified model integration task by applying the generated executable code. The process of executable rule generation is as follows (take Simulink as the example of the targeted specific platform): i. The meta-models of the UBML and Simulink are specified using MOFLON’s MOF 2.0 [28] editor; ii. The TGG schema and TGG rules are declared using the schema editor and rule editor of the TGG plug-in. Unlike the traditional TGG approach, some sophisticated concepts are proposed such as link type attributes, generalization for link types, priority of the link type, parameterized rule declaration, and wheredependencies adopted from the QVT standard;

772

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

Fig. 14. IBD representation of the whole system.

Fig. 15. IBD representation of the DC servo motor.

In our specific UBML-Simulink transformation, the transformation can be done in two layers: (a) Language layer: in this layer, the schema and rules describe the correspondences between meta-models of the two languages which follow the guidelines mentioned in Section 6. For example, the transformation between UBML function block and Stateflow chart can be modeled as shown in Fig. 19. (b) Library layer: Simulink provides several libraries which serve the modeling and simulation of different domains. When some of the UBML blocks are transformed into Simulink, the library blocks can be used directly. For example, in our workbench system, the PID block has the same functionality with the PID controller in Simulink and can thus be transferred to it directly by the rule as shown in Fig. 20. This rule is inherited from the general block transformation rule. However, the rule only works for PID block transformation since the name property is specifically set.

Fig. 16. SPD of the control component.

It is obvious that the library layer transformation has a higher priority than that of the language layer, which means if it could find matching library blocks in Simulink, it will do the black-box transformation ignoring the internal properties and behavior of the block while only focusing on interaction ports transformation. Otherwise it will do the ‘‘white-box’’ transformation to build a new user-defined block in Simulink. iii. The TGG specification is automatically translated to a plain MOF meta-model with operational rules specified in the story driven modeling editor which is reused from the FUJABA tool-suit [29]. iv. JMI-complaint code is generated from the source meta-model, the target meta-model, and the TGG specification above. After that, the code is used by the TiE [30] in which the integration framework performs different integration tasks such as forward and backward model transformation, consistency checking and traceability link maintenance.

Fig. 17. The simulation framework model.

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

773

simulation results in Simulink/Simscape/Stateflow and MapleSim are given in Figs. 23 and 24 respectively. It can be seen from the two figures that the simulation results of the position, velocity and acceleration in different platforms are similar. Based on the simulation results, the analysts can determine whether the design meets the given requirements. If not, some of the related parameters can be adjusted in the simulation environment and then returned, which automatically affects the corresponding design parameters. 8. Conclusion and future work

Fig. 18. An example of the simulation configuration model.

Fig. 19. An example of transformation between UBML function block and Stateflow chart.

In this paper, an approach for design-oriented SysML-based uniform behavior modeling method is proposed for mechatronic systems. The main contribution of this work is as follows: (1) A SysML profile for uniform behavior modeling named UBML is proposed which supports the modeling of discrete, timecontinuous and hybrid behavior of multi-domain mechatronic systems in a platform-independent way. Using UBML, the designers can express their requirements for the dynamic behaviors at the initial design stage formally and unambiguously. (2) The commonness of two typical simulation languages, Modelica and Simscape, are analyzed and compared carefully. Based on the analysis, the language-independent behavior modeling stereotype is constructed. (3) The language- and tool-dependent simulation-related information is analyzed elaborately. It is divided into the unchanged part and the adjustable simulation configuration part to improve the reusability of simulation models. (4) A formalized representation of TGG rule is abstracted and given. It is used to facilitate the TGG based model transformation approach between SysML and Simulink/Simscape/ StateFlow and MapleSim based on their meta-models. To make the transformed Simulink or MapleSim model really executable in the simulation tools, more work should be done. The APIs for creating and reading the executable model should be identified and related to the Simulink or MapleSim model generated by model transformation. Moreover, more detailed commonness and differences should be further analyzed systematically for more complex mechatronic systems. Acknowledgments

Fig. 20. An example of transformation between the library-layer elements.

7.4. Simulation results in Simulink and MapleSim Based on the TGG transformation, the SysML- based workbench system-level design model can be transferred to the simulation models of Simulink/Simscape/Stateflow or MapleSim, which are shown in Figs. 21 and 22 respectively. Here, the name of each component is given to be the same or similar as the one in the system design model in Fig. 14 to facilitate the readers to understand. Moreover, it can be seen by comparing Figs. 21, 22 and 14 that they have a similar connection topology and thus the transferred simulation model is valid. To obtain the simulation results of the designed workbench system, the parameters are given as follows. The armature inductance of the DC motor is set to 4Ω , and the armature inductance is omitted for simplicity. The torque constant, as well as the back-EMF constant, is set to 0.2 N m/A. Equivalent rotational inertia of the DC motor and load is set to 0.004 kg m2 , rotor damping is set to 0.005 N m s/rad. The total reduction ratio for the reducer and ball screw is set to 4000. The target position for the workbench is set to 0.1 m. Series correction and parallel correction are started from 1 s to show the effect of discrete behaviors. The

We would like to thank all of the anonymous reviewers for their comments and suggestions and appreciate the previous researchers whose work helped us greatly. Also, the authors are appreciative of the support from the 863 High-Technology Project of China (No. 2011AA100804), NSF of China (61173126, 70901052) and Zhejiang Provincial Natural Science Foundation of China (R1110377, Z12F020006). Appendix A. Control profile The control profile is proposed based on the international electric committee(IEC) 61499 function block standard [31]. Fig. A.1 shows the definition of the basic function block (FB). The properties of the FB include the internal data which are used by the control algorithms, and four types of ports as shown in Fig. A.1: the event input/output and data input/output which can be connected correspondingly to transfer event or data between different function blocks. The behavior of the FB is modeled by control algorithms and execution control chart (ECC) as shown in Fig. A.1. ECC is actually a state machine which contains EC states, EC transitions, and EC actions. The EC state is associated to multiple EC actions

774

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

Fig. 21. The transformed simulation model in the Simulink/Simscape/Stateflow platform.

Fig. 22. The transformed simulation model in the MapeSim platform.

Fig. 23. Simulation results for position, velocity and acceleration in Simulink/ Simscape/Stateflow.

representing the control algorithms executed in this state. The EC transition is triggered by the event or Boolean condition. The EC states are connected by EC transitions which describe the state changes of the behavior model. Based on the analysis of FB-related concepts, a SysML profile containing a set of stereotypes are proposed to support the uniform modeling of control system, as shown in Fig. A.2: the

Fig. 24. Simulation results of position, velocity and acceleration in MapleSim.

stereotype ⟨⟨FunctionBlock⟩⟩ is defined for FB whereas another stereotype ⟨⟨CompositeFB⟩⟩ is defined for the composition of the basic function blocks. Both of them are extended from Block. Regarded as an encapsulated object, the FBs communicate with each other through their interfaces modeled by the flow ports in

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

775

Fig. B.1. The connection profile. Fig. A.1. Definition of function block.

used to connect the signal ports of the physical component, the data port and event port of the control component respectively. In addition, two types of special blocks are defined to connect the physical components and the control components: Sensor and Actuator. The sensors are used to detect the values of state variables of the physical blocks by connecting to certain energy ports and sending the values as signals to the control system through its signal ports stereotyped by ⟨⟨SignalPort ⟩⟩ . On the contrary, the actuators are used to receive the control signals from the control system and send execution orders to the physical system. Appendix C. Simulink-related profile Fig. A.2. The proposed control profile.

SysML as shown in Fig. A.2, the ⟨⟨DataPort ⟩⟩ is used to transfer the values of the control signals or the state variables whereas the ⟨⟨EventPort ⟩⟩ is used to transfer the events that trigger transitions. Moreover, the local data of the FB is modeled by ⟨⟨InternalVariable⟩⟩ value property. Noticeably, the kernel parts of the FB are the ECC and the control algorithm. The former is used to describe the discrete part of the hybrid behavior whereas the latter is used to describe the continuous part of the hybrid behavior. As shown in Fig. A.2, the stereotype ⟨⟨ECC ⟩⟩ contains several ⟨⟨ECStates⟩⟩ connected by ⟨⟨ECTransitions⟩⟩ . And the ⟨⟨ControlAlgorithms⟩⟩ are allocated to certain ⟨⟨ECStates⟩⟩ as their ⟨⟨ECActions⟩⟩ . When an ECState is activated, the corresponding control algorithm is invoked. In this way, the discrete behavior and the continuous behavior are integrated together. Appendix B. Connection profile To connect multi-domain components to form the system model, four kinds of connectors are proposed as shown in Fig. B.1: ⟨⟨EnergyConnector ⟩⟩ , ⟨⟨SignalConnector ⟩⟩ , ⟨⟨DataConnector ⟩⟩ and ⟨⟨EventConnector ⟩⟩ . The ⟨⟨EnergyConnector ⟩⟩ stereotype carries certain types of energy and connects energy ports with the same energy type. The implied semantics for this connector is that it must obey the generalized Kirchhoff’s Law and thus both the types of the connected ports must be the same. The other stereotypes ⟨⟨SignalConnector ⟩⟩ , ⟨⟨DataConnector ⟩⟩ and ⟨⟨EventConnector ⟩⟩ are

The Simulink-related profile [32] is obtained based on Agarwal’s work [33] by using the following heuristic rules:

• The meta-model should be able to represent the complete information for creating the real tool-specific model.

• The difference between the tool-specific meta-model and the SysML meta-model should be minimized. Firstly, the common used elements for uniform Simulink modeling are analyzed and summarized as the Common package and shown in Fig. C.1. They can be directly used or extended by other tools based on Simulink. Generally, this package includes two parts: one is the Lib which corresponds to the folder storing the files of user-defined elements or the Simulink built-in library. It contains BlockType which describes the Simulink blocks, and MatlabFunction means the Matlab function in.m file. Both of the two types of elements are reusable. The other part is the Diagram which represents the Simulink model in.mdl file, in which the Block and the Connector linking the blocks together are used as the basic modeling elements. Although Simulink does not explicitly support the type-instance mechanism, the reusability of blocks can be achieved by copying the existing block from a Simulink lib to the new model diagram and renaming it. Noticeably, Matlab Functions can also be reused in defining certain blocks’ behavior. Secondly, the simulation information in Simulink is explicitly modeled to facilitate the simulation configuration and automatic simulation. Similarly, the meta-model of Simulink is analyzed and extracted firstly as shown in Fig. C.2. Here, the Simulation represents a virtual experiment on the digital system modeled by the Diagram. It includes SimConfig storing simulation configuration parameters, and several BlockSettings and ParameterSettings

776

Y. Cao et al. / Computer-Aided Design 45 (2013) 764–776

Fig. C.1. Common package of the Simulink meta-model.

Fig. C.2. Simulation-related meta-model of Simulink.

adjusting the parameter values of the blocks. AdjustablePar is a general element which is the base element of ChartData in the Stateflow meta-model and Parameter in the Simscape meta-model since only the values of these two types of elements can be adjusted by users in the Simulink simulation. References [1] Michelle B, David H. System design: new product development for mechatronics. Boston (MA): Aberdeen Group. Benchmark Report. 2008. p. 1. [2] Fisher J. Model-based systems engineering: a new paradigm. INCOSE Insight 1998;1(3):3–16.

[3] Object Management Group. Systems modeling language specification. 2009. http://www.omg.org/spec/SysML/1.2/PDF. [4] Paredis CJJ, Johnson TA. Using OMG’s SysML to support simulation. In: Proc. of the 2008 winter simulation conf. 2008. [5] Cao Y, Liu Y, Paredis CJJ. Integration of system-level design and analysis models of mechatronic system behavior based on SysML and Simscape. In: ASME int. DETC&CIE. 2010. [6] Cao Y, Liu Y, Paredis CJJ. System-level model integration of design and simulation for mechatronic systems based on SysML. Mechatronics 2010; 21(6):1063–75. 2011. [7] Alur R, Courcoubetis C, Halbwachs N, et al. The algorithmic analysis of hybrid systems. Theoretical Computer Science 1995;138:3–34. [8] Alur R, Dang T, Esposito J, et al. Hierarchical modeling and analysis of embedded systems. Proceedings of the IEEE 2003;91(1):11–28. [9] Berkenkötter K, Bisanz S, Hannemann U, et al. HybridUML profile for UML 2.0. International Journal on Software Tools for Technology Transfer 2006;8(2): 167–76. [10] Burmester Sven, Giese Holger, Tichy Matthias. Model-driven development of reconfigurable mechatronic systems with mechatronic UML. In: Model driven architecture: foundations and applications. Lecture notes in computer science (LNCS), vol. 3599. Springer Verlag; 2005. p. 47–61. [11] Modelica Association. Modelica language specification. 2009. http://www.modelica.org/documents/ModelicaSpec31.pdf. [12] MathWorks Inc., SimscapeTM 3 user’s guide. 2009. http://www.mathworks. com/access/helpdesk/help/pdf_doc/physmod/simscape/simscape_ug.pdf. [13] Vanderperren Y, Dehaene W. From UML/SysML to Matlab/Simulink: current state and future perspectives. In: Proc. of design, automation and test in Europe. DATE. 2006. [14] Turki S, Soriano T. A SysML extension for bond graphs support. In: 5th int. conf. on technology and automation. 2005. [15] Pop A, Akhvlediani D, Fritzson P. Towards unified systems modeling with the modelicaML UML profile. In: International workshop on equation-based object-oriented languages and tools. Berlin (Germany): Linköping University Electronic Press; 2007. [16] Nytsch-Geusen C. The use of UML within the modelling process of modelicamodels. In: International workshop on equation-based object-oriented languages and tools. Berlin (Germany): Linköping University Electronic Press; 2007. [17] Johnson TA, Paredis CJJ, Burkhart R, Jobe JM. Modeling continuous system dynamics in SysML. In: 2007 ASME int. mechanical eng. congress and exposition. Seattle (WA): ASME; 2007. [18] Johnson TA, Paredis CJJ, Burkhart R. Integrating models and simulations of continuous dynamics into SysML. In: Modelica conf. 2008. 2008. [19] Varró D. VIATRA: visual automated model transformation. Ph.D. Thesis. Budapest: Department of Measurement and Information Systems. University of Technology and Economics. 2003. [20] http://www.3ds.com/products/catia/portfolio/dymola. [21] http://www.maplesoft.com/products/maplesim/index.aspx. [22] Königs A. Model transformation with triple graph grammars. In: Proc. of model transformations in practice workshop at MODELS conf. 2005. [23] Agarwal A, Simon G, Karsai G. Semantic translation of Simulink/Stateflow models to hybrid automata using graph transformations. In: Int. workshop on graph transformation and visual modeling techniques. 2004. [24] https://www.magicdraw.com/what_is. [25] https://www.magicdraw.com/sysml. [26] Amelunxen C, Klar F, Königs A, Rötschke T, Schürr A. Metamodel-based tool integration with MOFLON. In: Proc. of the 30th int. conf. on software eng.. New York: ACM Press; 2008. p. 807–10. [27] Königs A. Model integration and transformation—a triple graph grammarbased QVT implementation. Ph.D. Thesis. Germany: Real-Time Systems Lab, Darmstadt University of Technology. 2008. [28] Object Management Group. Meta object facility (MOF) core specification. 2006. http://www.omg.org/spec/MOF/2.0/PDF. [29] Fujaba Core Development Group. Fujaba tool suite. http://www.fujaba.de. [30] Klar F, Rose S, Schürr A. TiE—a tool integration environment. In: Proc. of the 5th ECMDA traceability workshop. vol. WP09-09. 2009. p. 39–48. [31] International Electrotechnical Commission. Tech. rep., 2005. 61499-1: Function Blocks—Part 1: Architecture. R [32] MathWorks Inc., Simulink⃝ 7 user’s guide. 2009. http://www.mathworks. com/access/helpdesk/help/toolbox/simulink/sl_using.pdf. [33] Agarwal A, Simon G, Karsai G. Semantic translation of Simulink/Stateflow models to hybrid automata using graph transformations. In: Int. workshop on graph transformation and visual modeling techniques. 2004.