Proceedings of

Report as inappropriate Your report has been received

Shared by: HC120911175445

Tags

Stats

views:: 0
posted:: 9/11/2012
language:: Unknown
pages:: 19

Public Domain

Document Sample

System-Level Model Integration of Design and Simulation for Mechatronic
Systems Based on SysML

Yue CAO1 Yusheng LIU1,2* Christiaan J.J. PAREDIS2
1
State Key Lab. of CAD&CG, Zhejiang University, Hang Zhou, P.R.China 310027
2
Product and Systems Life Cycle Management Center, The G. W. Woodruff School of Mechanical Engineering,
Georgia Institute of Technology Atlanta, Georgia 30332

Abstract: The design of a mechatronic system (MTS) is not a trivial electronics, controls, and computers through the design
task due to the complexity of the systems. The evaluation of various process, from the very start of the design process, thus
design scenarios for the given requirements of a specific MTS is also
enabling complex decision making [1]. It requires a complex
difficult. Currently, model-based systems engineering (MBSE) and the
combination of multiple disciplines such as mechanical,
modeling language SysML provide a novel means for the systematic
design of MTSs. However, the specific requirements of MTS behavior electrical, hydraulic and control to accomplish the entire
modeling, i.e. continuous dynamics or even discrete/continuous hybrid requisite functionality [2]. Additionally, the sub-systems of
behavior modeling, and automatic simulation and evaluation of the different disciplines are interwoven together, which causes
behavior models, are not supported by SysML which intends to create
the design of MTSs to be a difficult task. A new level of
descriptive static design models. Therefore, extension should be made
complexity (i.e., system design) to integrate the mechanical,
for SysML to support detailed hybrid behavior modeling and the
transformation between hybrid models in SysML and executable electrical, electronic, control and software components
simulation models in certain simulation environment. For this study, a together is added to the development of MTSs [3].
meta-model based method is proposed to integrate the system design Generally, MTSs can be regarded as special complex
and simulation models of MTSs. First, a set of stereotypes is defined systems that are characterized by continuous dynamic
to facilitate the designer to explicitly model hybrid dynamic behavior
behavior. Therefore, the methods that are devised for the
based on SysML. The necessary simulation information is also
design of general complex systems can be further
formalized in SysML to support an analysis of the system dynamic
behavior with the aid of simulations. Finally, the SysML-based system specialized for the design of MTSs with the consideration of
dynamic behavior, and the related simulation information are the specific properties of MTSs.
integrated with the platform-specific simulation model through a Currently, model-based systems engineering (MBSE)
bidirectional model transformation approach based on a triple graph
[4] is the mainstream method for complex system design.
grammar (TGG), which facilitates the automatic model consistency
Additionally, a standard systems modeling language, the
and traceability between system design and simulation. Finally, the
proposed method is implemented and illustrated by using a common Systems Modeling Language (OMG SysMLTM) [5], has
example. been established based on unified modeling language
Keywords: SysML; System dynamics; Simscape; Model-based (UML) to support the MBSE by the International Council of
systems engineering; Simulation; Model transformation Systems Engineering (INCOSE) and the Object
Management Group (OMG). One of the greatest advantages
1. Introduction of MBSE is that the knowledge can be expressed and shared
A mechatronic system (MTS) is the synergistic unambiguously between the engineers and different
integration of physical systems, sensors, actuators, stakeholders with the help of the models. Also, the MBSE

1
facilitates dependency tracing between different models and given for SysML to enable it to model hybrid behavior. The
the reuse of knowledge. representation of the related simulation information with
Although SysML supports the specifications, the SysML is also considered. Particularly, SimscapeTM, a multi-
analysis, the design, the verification and the validation of a domain simulation platform developed by the MathWorks
broad range of complex systems, including hardware, Corp., is selected for this study because it is an extension of
software, information, processes, personnel and facilities, it the Simulink product line and is easily accepted and utilized
is still a general-purpose modeling language for complex by its users [6]. Then, the triple graph grammar (TGG)
system modeling. For MTSs modeling, two specific method is introduced to accomplish the integration of a
requirements should be considered. First, the behavior of the SysML-based design model and platform-specific simulation
MTS may be continuous, discrete or event hybrid. model of the MTS.
Therefore, the approach for modeling the three types of This paper is organized as follows: related studies are
behavior should be provided. The other is that it is difficult discussed in Section 2. Section 3 gives an overview of the
to determine if the system is designed correctly to meet proposed method. The details of modeling of the hybrid
different stakeholders’ requirements based only on the behavior model and simulation information are given in
designed static structure models and behavior models. Sections 4 and 5, respectively. Section 6 introduces the
Dynamic simulation is imperative for the verification and detailed integration method including the meta-models of
validation of a system’s behavior. However, the general related modeling languages and mapping rules. The
SysML is not sufficient to meet the requirements. SysML implementation and simulation results are given in Section
provides the capability of modeling discrete behavior with 7. Section 8 summarizes this method and describes the
constructs such as activity diagrams, sequence diagrams and future work.
state machine diagrams, and continuous behavior with the
parametric diagram. However, hybrid behavior cannot be 2. Related Work
modeled. Moreover, the constructs in SysML are intended SysML is a general-purpose modeling language that is
for expressing the descriptive design information, so the only associated with descriptive semantics. However,
detailed execution information necessary for simulation execution semantics are necessary for modeling system
cannot be represented in it as well as by the existing dynamic behavior to avoid ambiguity and to support analysis
extension techniques made on it. Therefore, new constructs and simulation. To associate the execution semantics with
or stereotypes must be defined to model hybrid behavior, as general purpose modeling languages, most of the studies use
well the ability to capture analysis in the form of equations that
the “top-down approach” [7], which associates the semantics
can correspond to continuous differential equations. Based on
of an existing language with the constructs of a general
these new constructs, the descriptive design model can be
language by creating extensions to it.
mapped to the executable analysis model easily.
Vanderperren Y. et al discussed two possible integration
For this study, a SysML-based model integration
methods between the UML/SysML and MATLAB/Simulink [8],
method is proposed for the design and simulation of
i.e. co-simulation and integration based on a common
mechatronic system behavior. Here, the extensions are first

2
underlying executable language. The intermediate coupling tool Modelica elements, and based on these constructs, the
is considered to establish the communication between the continuous dynamics and their simulation can be modeled in
design model based on UML or SysML and the simulation SysML. The dynamic behavior models can be transformed
model in MATLAB/Simulink. However, only the discrete between SysML and Modelica by using the model
model was considered in their method. With the consideration transformation framework VIATRA [15].
of the importance of the continuous behavior, Turki S. and
A more formal approach for SysML and Modelica
Soriano T. proposed an activity-diagram based method to
integration is proposed in [16]. In this specification, the
represent the Bond-graph based continuous dynamic behavior
SysML4Modelica profile is proposed to represent the
of MTSs [9].
Modelica constructs. Based on this profile, the analytic
Pop A. et al. [10] proposed the ModelicaML UML
model can be created. Moreover, the transformation between
profile as an integration of Modelica [11] and UML that
the profile constructs and the Modelica language is also
enables the engineers to specify the requirements, behavior,
specified, which can facilitate transforming the analytic
and Modelica simulation in a uniform manner. This profile
model in SysML to the Modelica model which can be
reuses most of the UML constructs, modifies some of the
executed in Modelica modeling tools.
SysML diagrams including the Block Definition Diagram
In this paper, we have adopted the light-weight
(BDD), Internal Block Diagram (IBD) and Package
extension approach to create stereotypes in SysML and TGG
Diagram, and creates two new diagrams: the Equation
based approach to transform these constructs to other
Diagram to describe the behavior of Modelica classes, and
modeling languages, which are inspired by the related
the Simulation Diagram for modeling the simulation plan,
works. However, because of the considerable differences
parameter setting and simulation results.
between the modeling and simulation in Simscape and
Nytsch-Geusen [12] presented the UMLH, a specialized
Modelica, we introduced some totally new stereotypes and
version of a UML for the graphical description and model-
modeling formalism. Besides that, the hybrid behavior
based development of hybrid systems in Modelica. This modeling topics have not been discussed by the related model
special form reuses and makes some modifications to the integration works, so a new profile is proposed in this paper to
Class Diagram, Statechart Diagram, and Collaboration provide certain supports to this problem.
Diagram of UML to represent the meanings of the pure
textual constructs of Modelica and help the engineers 3. Method Overview
develop the Modelica models in a graphical manner.
To fulfill the integration of the system design model
Johnson et al. [13-14] introduced an approach for
and simulation model for MTSs, the first task is to correctly
modeling continuous system dynamics in SysML based on
and effectively model the complex hybrid behavior. As
the language mapping between SysML and Modelica.
mentioned in Section 1, SysML provides several behavior
Unlike both of the above methods, this approach extends the
diagrams for the designer to define the behavior model.
semantics of SysML by stereotypes instead of creating a
However, even with the given diagrams, there are still two
separate UML profile with new language constructs. It
problems. The first problem is that the diagrams are not
establishes equivalent SysML constructs for selected
sufficient enough to define the discrete/continuous behaviors

3
of MTSs; therefore, some of the stereotypes must be while the refinement of the simulation models can be
extended to provide the necessary functionalities. The returned to the design by a backward transformation.
second problem is that, the design models may be created in Start
different formalisms e.g. in ACT, STM, or PAR, which
makes the mappings between design model and analysis
Behavior modeling in SysML
model more difficult or even impossible. To facilitate the  Component modeling Behavior
 System modeling modeling
integration of system design and simulation, a uniformly  Hybrid modeling elements

formalized representation is imperative for hybrid behavior
modeling. Besides hybrid modeling, the behavior model also Platform-specific simulation information
modeling in SysML
represents the behavior execution details which facilitate  Simulation environment parameter Simulation
configuration platform
transformation to Simscape.
 Simulation-related parameter setup information
Then, the platform-specific simulation parameters are
modeled. Besides the behavior model created in step 1, to
Mapping between design and
run the simulation, the simulation configuration parameters simulation in MOFLON
 Meta-model extraction
should also be given, e.g. solver types, start/stop time for  Mapping rule selection Mapping rules
 One-by-one mapping
Simscape, and the parameters of the physical components,
e.g. the mass, the spring coefficient, should be indicated as
well. In this step, these parameters are set or adjusted which Simulation model Output
(in XMI format)
provides necessary information for running the simulation in
Simscape.
After all of the hybrid behavior information and Executing the simulation in Simulink
 Executable Simulink model generation
simulation information are modeled formally, they are based on APIs
 Running the simulation and adjusting
transformed into a specific simulation model to be parameters
conducted in Simscape. The entire process is shown in Fig.
Fig. 1 Overview of the proposed method
1. To support the system-level model integration of MTSs, a
large amount of system design knowledge must be
formalized and reused. The first two parts enable designers 4. SysML-based Uniform Hybrid System
to create the expected system dynamic behavior model and
Dynamic Behavior Model
simulation model in SysML that can interact with other
To achieve the design and simulation integration, the
system models such as requirement models, structure
descriptive SysML should be augmented by additional
models, etc. By relying on the bidirectional transformation,
execution semantics in order to create computational hybrid
the design models in SysML can be transformed into
behavior model of MTSs which is suitable to transform to
simulation models in Simscape and simulated automatically
analysis models in specific simulation tools. Particularly, to
enable the extended stereotypes of SysML to represent the

4
hybrid system dynamic behavior of MTSs, they should not using a PAR. However, modeling of the hybrid behavior is
only represent the designer’s intentions effectively and not performed in SysML. The only referable work which
explicitly, but they should also be designed to facilitate the connects hybrid behavior modeling with UML is the
subsequent transformation with the simulation model, i.e., HybridUML [7]. In this approach, the behavior is modeled
the characteristics of the multi-domain simulation platform by mode, the stereotype of state machine, in which analog
(Simscape, for this study) should be also considered. variables can be updated according to the flow and invariant
Generally, there are two methods for extending SysML: constraints. Since there are no continuous behavior
the “heavy-weight” method and the “light-weight” method. modeling constructs provided by UML, the continuous
The former method creates new constructs for SysML, behavior in Hybrid UML is still modeled on textual level,
whereas the latter method defines stereotypes to extend the e.g. Differential-Algebraic Equations (DAEs).
constructs of SysML. For this study, we chose the latter To enable SysML to explicitly model the hybrid
because it is easy to implement in the existing CASE tools behavior, one option is to use the state machine as the basis
without developing special tools to support the new and to represent the continuous behaviors in the form of
constructs. differential-algebraic equations (DAEs) as actions of the
Based on the above analysis, three types of extensions states such as the modeling approach of HyrbidUML.
are conducted for SysML to provide Simscape-compatible However, there are at least two shortcomings for this
hybrid behavior representation for this study. The first method. One is that the continuous behavior is expressed by
extension is the sequenced parametric diagram (SPD) that is textual formats. Another is that the parametric relationships
extended from the parametric diagram (PAR) of SysML to between the equations and between the structure and its
uniformly describe the hybrid dynamic behavior of MTSs. behavior cannot be modeled explicitly. For this study, a new
The other two extensions are used to define stereotypes to diagram called Sequenced Parametric Diagram (SPD) is
associate specific Simscape semantics (i.e., the functional proposed by extending the PAR of SysML. It retains the
components and the physical network of the system continuous behavior modeling capability of the PAR, and
dynamics) to SysML constructs. Then, Simscape’s physical some new stereotypes are proposed to imitate the STM
network approach is employed to construct the actual constructs for modeling the discrete event-based behavior.
complex system dynamic behavior model. For this approach, Based on this newly created diagram, the hybrid behavior
the system is represented as a network containing functional can be modeled in a hierarchical manner. The core
elements that interact with each other by exchanging energy components of the new diagram are the conditional
through their ports. constraint property and the transition between them.

4.1 SPD-based Hybrid Behavior Model 4.1.1 Conditional constraint property (CCP)
In SysML, the event-based behavior is modeled by the The constraint block of SysML is a special type of
state machine diagram (STM) inherited from the UML, block that can own constraint parameters and constraints. If
while the continuous behavior can be indirectly modeled by it is used as the constraint property of other blocks, it can

5
constrain the owner block’s properties in the PAR. The Specifically, the transition is activated if it satisfies the
equations expressed by the constraints are non-causal. One following conditions: (1) the source conditional constraint
of the characteristics is that each of the constraint properties property of the transition is active; (2) the transition is
in the diagram serves a constraining role simultaneously. triggered by the incoming event, or its conditions become
The CCP is extended from the constraint property. The “true”. Once the transition is activated, the source
special semantics of the CCP is that it does not always go conditional constraint property becomes inactive, while the
into effect to constraint the owner blocks. Only if it is target becomes active. Fig. 3 shows the stereotype definition
“active” does it have the effect of constraining the property of sequence.
of its owner block and describing its current behavior. The
state of the conditional constraint property (i.e., active or
inactive) is determined by the activation of its related
sequences, which are described in the next subsection.
Therefore, the CCP is the counterpart of the state in the state
machine. Besides the semantic extension, the CCP includes
a new tag named default to indicate whether the CCP is the
Fig. 3 Definition of Sequence
default starting point of the behavior. Fig. 2 shows the
definition of the «ConditionalConstraintProperty»
stereotype. 4.1.3 SPD
The SPD is extended from the PAR for modeling the
hybrid automata [17], which is the fundamental basis of
hybrid behavior modeling. The SPD contains conditional
constraint properties to model the locations of hybrid
automata. The constraints of the conditional constraint
property represent the activities in each location. Aside from
the binding connectors inherited from the PAR, there can be
Fig. 2 Definition of CCP
a sequence relationship between the CCP. The SPD is
4.1.2 Sequence
hierarchical because the constraint blocks can have
The sequence that is extended from the dependency is (conditional) constraint properties that hold nested usages of
used to describe the relationship between two conditional constraint blocks as the PAR. Fig. 4 shows a SPD which
constraint properties. Its semantics are the same as the describes the hybrid behavior of the ForceSource. The
transition in the state machine, which describes the discrete ForceSource has three states: noforce state in which the
state changes separating continuous state evolutions. The force is always zero; impulse1 in which the force is set to
transition can have a condition, which is extended from the force1=10N; impulse2 in which the force is set to
constraint, and a event to trigger the transition. They are force2=100N. The state transitions occur at time 1s and time
related to activating and deactivating the transition. 4s. At time 1s, the impulse force1 start acting. After 0.1s, the

6
action stops. The same action sequence is experienced by Specifically, the domain type is used to specify the type of
the impulse force2. the components’ ports.
To describe the domain and component models clearly,
there are two types of properties defined in Simscape:
declaration and implementation. The declaration includes
nodes, inputs and outputs, parameters, and variables,
whereas the implementation includes setup functions and
equations. Nodes, inputs and outputs are used to describe
the interfaces of the components that connect to each other.
For component models, they are usually treated as
encapsulated objects; they can only interact with other
components through their interfaces. There are two types of
interfaces defined in Simscape: physical conserving ports
and physical signal ports. Nodes represent the physical
conserving ports through which energy flows in and out of
Fig. 4 SPD describing the ForceSource behavior the components. Nodes are typed with domain models, and
only nodes of the same type can be connected. Inputs and
4.2 Definition of Simscape-compatible modeling
outputs define the physical signal ports (the directional ports
components
carrying physical signals with units that represent the values
4.2.1 Analysis of Simscape’s behavior modeling of certain variables). Variables and parameters are used to
Besides hybrid behavior modeling, the ultimate goal of describe the intrinsic properties of the component.
this approach is to support automatic simulation. In this Specifically, variables are the physical quantities whose
paper, the Simscape simulation language is selected. To values change over time. In Simscape, there are two types of
facilitate the model integration of the SysML and Simscape, variables defined to describe the system dynamic behavior:
it is beneficial to devise the SysML-based behavior through and across. Each domain defines the through and
modeling constructs that are compatible with those of across variables specific to the physical domain (e.g., the
Simscape. Therefore, it is necessary to clearly describe the linear velocity v and force f for the translational domain). If
behavior modeling approach of Simscape. Generally, there the domain is used to type a port, the variables characterize
are two types of models formally described by the Simscape the energy flow through that port. Each component declares
modeling language [18]: domain and component. The and uses variables defined by its domain to describe its
former is used to describe the physical domains, e.g., DAE-based internal behavior. Parameters are the physical
translational, rotational and electrical. The latter is used to quantities whose values are constant over the time of
describe the physical modeling components, e.g., mass, execution. The purpose of the domain parameters is to
spring, damper, which are the basic elements of the system. propagate the same parameter values to all or some of the

7
components in the domain. For the components, the
parameters enable the user to adjust their values during the
simulation according to different design alternatives.
Furthermore, the implementation is used to represent
the internal behavior. The setup function executes once at
the beginning of the simulation and describes the initial
conditions of the behavior. The equation executes
throughout the simulation and represents the internal
behavior of the component in mathematical models such as
the DAE.
For the domain model, only the variables and
parameters are defined, and thus its functionality is only to
define a specific domain and is not for a detailed component.

4.2.2 Extension of SysML for defining Simscape-
compatible modeling components
Because it is based on the UML, SysML has the strong
capability of extending new modeling constructs and the
modeling capability by the stereotype mechanism. In
SysML, the block is the most widely used modular unit to Fig. 5 Domain and Component models

describe the complex system, which can represent both Corresponding to the variables and parameters as

logical and physical objects. Therefore, it is suitable to be properties of a component model in Simscape, there are

extended to represent both components and domains. value properties of a block in SysML, which are typed to

Domain models do not have internal behavior, so the value types to indicate their types. Therefore, the value

«domain» stereotype is used to indicate the specific property in SysML is extended to describe the variable and

semantics. An inheritance relationship can exist between the parameter. Furthermore, to distinguish variables from the

components. For this case, the child component inherits all other common properties, «through» and «across»

of the public and protected properties from its parent. This stereotypes are defined. For example, in Fig. 5, the value

relationship is modeled by the generalization relationship in property m of the Mass block represents the mass of the

SysML, which describes the relationship from a specialized component, and it is typed by the value type kg. Moreover,

block to a general block. Fig. 4 shows the models of the the Translational domain and the Translational Component

Translational domain, and the Mass, Spring and Damper block both have the v and f variables associated with their

components, which are specialized from the general corresponding stereotypes.

component Translational Component.

8
In SysML, the flow port is used to describe the connection lines include: (1) It can only connect ports of the
interfaces of a block. Therefore, nodes, inputs and outputs same type; (2) It can only carry energy, and the ports
are all modeled by flow ports in SysML. Specifically, flow connected with it must obey Kirchhoff’s law, which means
ports stereotyped with «energyPort» are used to represent that each of their across variables has the same value, and
the physical conserving port, which is bidirectional and only the sum of all of their through variables is zero.
allows energy to pass through it (e.g., the energy ports r and
c of the Translational Component block in Fig. 5). The
«signalPort» stereotype is used to indicate the physical
signal port that only transfers physical signals (e.g., in Fig.
11, the signal ports V and F of the MSDSensor block output
the detected values as signals).
The setup function and equation are the implementation
parts of Simscape. In SysML, both of them are represented
by constraints of the block, which describe the rules that the Fig. 6 MSD system
value properties of the block must obey. The «initial» Since the system is also an object, it is modeled by a
stereotype is used to distinguish the setup function from SysML block with the «system» stereotype to indicate that it
other constraints that are true all of the time. For example, in is composed of other components and its inner parts are
Fig. 6, the constraint f==m*v.der represents Newton’s accessible by the outside. The system block is defined in a
second law, which determines the motion of the Mass block, BDD that also declares each component of the system as
and v=init_v describes the initial condition of the motion. It part properties of the system block. The mass-spring-
should be noted that the constraints could be written in any damper (MSD) system shown in Fig. 6 is used as an
language. Here, we use the Simscape language for the example. The MSD system is typically used to analyze the
convenience of an automatic simulation. continuous dynamic behavior of the suspension system on a
car. A mass is connected to a spring and a damper that are
4.3 Modeling of system continuous dynamic connected in parallel. An impulse force acts on the mass.
behavior Typically, the time to revert to steady state is an essential
After the fundamental modeling components are feature of the designed system. Fig. 7 shows the MSD
prepared, they are then combined to form the system hybrid system that is composed of a Mass, Spring, Damper, and
dynamic behavior model. The key problem is modeling the Force component (which supplies an impulse force to the
connection between the components that can depict the system), and a Reference component is used as the fixed
semantics. For this study, to specify these special semantics, reference point.
the stereotype «dynamicsConnector» is defined to extend
the general connector of SysML to model the physical
connection line. The special semantics of the physical

9
Similarly, the interaction behavior among the
components can also be modeled in a Parametric Diagram,
as shown in Fig. 9, which can then be modeled in the SPD.
The constraint block KirchhoffLaw is the mathematical
description of Kirchhoff’s law. By using the binding
connectors that enforce the equality of the two ends, the
ports of the components are connected to the parameters of
the KirchhoffLaw block, which constrains their values.
Comparing Fig. 8 and Fig. 9, the two diagrams are very
similar. The PAR can be considered as a refinement of the
IBD, which explicitly expresses the underlying Kirchhoff’s
law of semantics.

Fig. 7 BDD of the MSD system behavior model

Fig. 9 PAR of the MSD system behavior model

Fig. 8 IBD of the MSD system behavior model
5. Modeling Simulation in SysML
First, the IBD shown in Fig. 8 is used to establish an Simulation is typically used to evaluate the dynamic
interconnection of the components. The energy ports are behavior of the system. To automate the simulation of the
connected by physical connection lines, which represent the system dynamics model, the design model is not sufficient
exchange of energy flows. enough since it contains only the essential physical
dynamics information without any simulation-related

10
information, such as the values of certain parameters. through their physical signal ports, this type of block and the
However, there are no constructs for simulation modeling in corresponding scopes can be automatically added to the
SysML. In this section, a formal approach for representing Simscape diagram by connecting to the sensors’ output
the complete simulation information is given and is used to ports. To represent a complete simulation, the parameter
automate the simulation in Simscape. settings of the system and simulation configuration as well
as the sensors used to observe variables must be explicitly
5.1 Analysis of the simulation in Simscape modeled.
Generally speaking, the simulation process in Simscape
can be divided into four steps: (1) Physical system modeling. 5.2 SysML-based simulation modeling
Each of the components and their related connections are
modeled in the Simscape diagram; (2) Ancillary simulation
information modeling. In contrast with a Modelica-based
simulation in a platform such as Dymola, these sensors are
used to detect and output certain variable values, and other
simulation related blocks should be added manually to the
diagram; (3) Simulation parameter setting. The simulation
configuration parameter and simulation environment
parameter should first be set up; (4) The simulation running.
The simulation related blocks in Step (2) include a
solver configuration block, Simulink-Simscape converter
blocks, scopes, and other Simulink blocks to generate
signals. For each Simscape simulation, there must be exactly
Fig. 10 BDD of the simulation model
one solver configuration block. It is automatically added to
Based on the above analysis, a stereotype «simulation»
the Simscape diagram in our approach for automatic
is defined by extending the block of SysML. It contains the
simulation, and the designers are not required to insert it
following three types of information: (1) Configuration
explicitly. There are two types of converter blocks. The
related parameters. For example, the start time and stop time
Simulink-PS Converter block is used to connect Simulink
should be set during the simulation. Two stereotypes
signal sources to the inputs of the system, e.g., the Force
«startTime» and «stopTime» are defined by extending the
component. For this study, the force supplied by the Force
value property in SysML. (2) System related parameters.
component is described directly by the component’s
They are modeled by the «parameter», e.g., the magnitude
equations; thus, any external inputs are omitted. The PS-
of the impulse force is given by the parameter forcePulse.
Simulink Converter block is used to connect the outputs of
(3) Sensor. The simulation must contain at least one sensor.
the system to Simulink blocks, such as scopes. Because the
The sensor is modeled by the stereotype «sensor» block with
outputs of the system are all generated by the sensors
the same syntax as the common components.

11
Fig. 10 shows an example of the definition of the
SysML-based simulation definition by MSDSimulation.
The simulation (which represents an experiment of the
continuous system dynamic behavior) is modeled by the
«simulation» block. Here, to detect the variable values, the
sensor is connected to certain components through their
energy ports. Due to Kirchhoff’s law and the equations of
the sensor itself, the target variable values can be computed
and then output through the sensor’s signal ports. As shown
in Fig. 11, the sensor is connected to the mass component.
The sensor detects the values of the velocity and position
of the mass, and outputs them through its two signal ports
V and F. Furthermore, the parameters defined in the
Fig. 12 PAR of the simulation model
simulation model can be associated with the components of
the system and the sensors to adjust their parameter values.
As shown in Fig. 12, the parameters can be set for the 6. TGG-based Model Transformation
simulation, e.g., the value of force is set to 50N. The two previous sections discussed the hybrid
behavior modeling and platform-specific simulation
information modeling that can be used to prepare a sufficient
amount of information for the system dynamic behavior
simulation. However, there is currently no tool to support the
simulation of SysML-based hybrid behavior. It should be
transferred to a specific simulation platform (i.e., Simscape,
for this study). Meanwhile, the adjusted parameters in the
simulation environment can also be fed back into the
SysML-based system design model to facilitate the
Fig.11 IBD of the simulation model
designer’s evaluation and improvement. Therefore, the
bidirectional model transformation is a pillar of design-
simulation integration by which the design models in SysML
and the simulation models in Simscape are transformed. For
this study, a method that is based on the triple graph
grammar (TGG) formalism [20] and combined with useful
concepts from QVT [21] proposed by Königs [19] is adapted
and supports bidirectional model transformation, consistency

12
checking, traceability, and JMI-compliant code generation. component, the transformation rule should generate the link
The approach is implemented as a TGG plug-in for type between the block and component), they are only
MOFLON [22], a meta-modeling framework with graph required to use the parent link type without defining another
transformations. Additionally, the specific integration tasks rule to refer to the child link type. Fig. 13 shows the
are performed by the integration framework in TiE [23], a integration link types between the block in SysML and the
tool integration environment. Using the integration component in Simscape.
framework, a bidirectional transformation between SysML
and Simscape can be accomplished. 6.2 Meta-model based correspondence between
SysML and Simscape
«source» 0..1 0 Block2Component 0..1 «target»
Block
Block2Component
Component The core of the model transformation is the integration
(name: String)
link types between the corresponding elements of the two
0..1 0..1
0 Block2ComponentP meta-models. To transform the hybrid system dynamic
Block2ComponentP
(name: String) behavior model (including the component model and system
model) and simulation information based on SysML into the
Fig. 13 Link types between block and component
Simscape model, the corresponding elements in Simscape
must be determined. Only the component models are
6.1 TGG based model transformation schema formally represented by the Simscape modeling language,
Motivated by model driven architecture (MDA), which and the mappings between the related elements in SysML
is OMG’s vision of model-based software system and Simscape were presented in Section 4.2. For the
development, several model transformation approaches have physical system and simulation, no formal constructs are
been proposed [24]. For this study, the TGG based model provided, and they can only be created by users in the
transformation approach presented in Schürr [20] is adopted. graphical Simscape environment or through Simulink
It includes two parts: the TGG schema and the TGG rules. commands in the MATLAB command line environment.
A distinguishing characteristic of the TGG is that, Therefore, a meta-model to formally represent the physical
besides the two graphs representing the source and target system and simulation in Simscape should be generated.
meta-models, it uses a third graph to store the Fig. 14 shows the related subgraph of the Simscape
correspondence between the elements of the source and meta-model for the physical system and simulation
target meta-models, which is represented by the integration information modeling. To model the physical system, the
link type. There are two link types with generalized System element contains component instances that consist of
relationships: the first one represents the correspondence the physical system and physical connection lines
between a plain block and a component, and the second one connecting these component instances. For simulation
is used if these elements are contained in a package. If these modeling, the Simulation element contains attributes of the
types of links are used by others (e.g., to represent the simulation configuration (startTime, stopTime, the sensors,
correspondence between the properties of a block and the system to be simulated, connection lines that connect the

13
system with sensors and parameter settings that set the forward transformation, only the block without any
parameters of the system’s component instances). These stereotypes can be transformed by this rule, or to initiate the
elements can be mapped to system hybrid dynamic behavior parameter values of the rule, e.g., the parameter name of the
and simulation modeling elements in SysML. For example, rule is assigned by the name of the source element (for a
the System maps to the «system» block, ComInstance to the forward transformation, this means the block; for a
part properties of the system block, Physical backward transformation, this means the component). For
ConnectionLine to the «dynamicsConnector», Simulation to the target, it is used to initiate the attributes of the target
the «simulation» block, and ParameterSetting to the binding element.
connector in the PAR of the simulation model. «create» «create» «create»
obj1:Block obj2:Componet
Obj3:Block2Component
name:=nam P name:=name
e

«create» «create» «create»
obj1:Package obj2:SimPackage
obj3:SysPack2SimPack
name:=name name:=name

package package
package2Elm package2Elm
PackagedElement PackagedElement

«create» «create» «create»
obj9:Block obj10:Component
obj11:Block2Component
name:=nam name:=name
e

Fig. 15 Transformation rules for block

From the declarative TGG rules, several operational
graph grammar rules are derived and used by the rule
application mechanism to perform certain model integration
tasks. Specifically, five types of TGG rules are considered
for this study for the corresponding link types.
The first part consists of the TGG rules for the domain,
package and block in SysML. Their rules are similar because
Fig.14 Part of the Simscape meta-model related to physical system
and simulation modeling there are two levels of transformation. One is defined for the

6.3 TGG rules for link types top-level information transformation and the other is for the
transformation of the internal information. Take the block
The TGG rule for each link type is declared below its
transformation for example, Fig 15 shows the transformation
name with parameters. Each integration link type can own
rules for the corresponding link types, as shown in Fig. 13.
(at most) one TGG rule that describes how the source and
target models evolve simultaneously. The source and target
elements can contain value specifications. For the source, it
is used as the condition to restrict the candidates, e.g., in the

14
0 ValueProp2Parameter 0..1 «target» transformed into a parameter if the stereotype is empty.
ValueProp2Parameter Parameter Additionally, it should be transformed into a through
(name: String, type: String
Value: String, access: String)
0..1 variable if the type of stereotype is through, whereas it
«source» 0 ValueProp2VariableT should be transformed into an across variable if the type of
ValueType ValueProp2VariableT
(name: String, type: String stereotype is across.
0..1 0..1
Value: String, access: String)
The fourth part of the transformation rules consists of
0 ValueProp2VariableA 0..1 «target»
«source» 0..1 equation transformation, which is to transform the
ValueProperty ValueProp2VariableA Variable
(name: String, type: String constraints of SysML to setup functions and equations in
Value: String, access: String)
Simscape, as shown. Similar to the third part of the
0..1 0 ValueProp2VariableTD 0..1
transformation rules, the types of the stereotypes are used to
ValueProp2VariableTD
(name: String, type: String
Value: String, access: String)
determine the type that should be selected for the target
0..1 0..1 object.
0 ValueProp2VariableAD

ValueProp2VariableAD The last part of rules is used to transform the
(name: String, type: String
Value: String, access: String) inheritance relationship between SysML and Simscape, as
(a) Link types shown in Fig. 17.
«source» 0..1 General2SimGeneral 0..1 «target»
obj4:Block obj5:Component Generalization SimGeneralization
obj7:Block2Component General2SimGeneral()

Block component
Block2Property Component2Var (a) Link types
ownedProperty Variables
«create»
obj1:ValueProperty «create» obj3:Block obj4:Component
«create» obj6:Block2Component
obj2:Varibale
name:=name
obj6:ValueProp2 name:=name child child
visibility:=access
VariableT Child2GenRel Child2Rel
defaultValue:=value visibility:=access
generalization generalization
stereotype==”through” «create»
«create» «create»
VPropT obj5:General2
vprop obj1:Generalization SimGeneral obj2:SimGeneralization
Type
general general
«create» General2Parent Rel2Parent
obj3:ValueType general
parent
name:=type (b) Transformation rules obj7:Block obj8:Component
obj9:Block2Component
Fig. 16 Transformation rules for ValueProperty
(b) Transformation rules
The second part of the transformation rules consists of Fig. 17 Transformation rules for generalization
the transformation of the SysML flowport into Simscape, the
node of the component. The third part of the transformation
6.4 Model transformation process
rules is used to transform the ValueProperty of the block into
With the help of the above-mentioned transformations,
the corresponding part of the component, as shown in
the automatic simulation can be implemented. Specifically,
Fig.16. The key problem is determining the type of
the design model in SysML is transformed into the Simscape
transformed target object. The type of stereotype is used as
simulation model, and a series of commands can then be
the heuristic for the determination. Specifically, it should be

15
generated to construct the physical systems. The simulation MagicDraw 16.5 Simscape 3.2
system dynamics model physical system model
is then automatically configured and executed in the simulation model simulation information
(in SysML) (in Simscape language
Simscape environment by using these generated commands. and commands)

By using backward transformation, the modifications in the
MOFLON 1.3
simulation models are reflected in the design models. SysML
TGG
Simscape
metamodel metamodel
specification
Consistency checking between the models in SysML and (in MOF 2.0) (in MOF 2.0)

post-process
pre-process
Simscape is also supported. The detailed process for the TGG metamodel
(in MOF 2.0)
model transformation is described, as follows: Operational rules
(in SDM)
(1) The meta-models of SysML and Simscape are specified
by using MOFLON’s MOF 2.0 editor [25]. For SysML, JMI-complaint
code
JMI-complaint
code
JMI-complaint
code
only the portion of the meta-model related for the
system dynamic behavior and simulation modeling are
TiE 1.3.2
included. SysML model
Integration
Simscape model
(in XMI) (in XMI)
framework
(2) The TGG schema and TGG rules are declared by using
Fig. 18 The entire transformation process
the schema editor and rule editor of the TGG plug-in.
For the input specific model, the code is used by the
(3) The TGG specification is automatically translated to a
TiE in which the integration framework performs different
plain MOF meta-model with operational rules specified
integration tasks such as forward and backward model
in the story driven modeling editor, which is reused
transformation, consistency checking and traceability link
from the FUJABA Tool Suite [26].
maintenance. The entire process is shown in Fig. 18.
(4) JMI-complaint code is generated from the source meta-
model, the target meta-model, and the TGG
specification above. 7. Implementation and Examples
In this section, the automatic generation of the
simulation model based on a forward model transformation
is used as an example. To perform this transformation task, a
source model should be prepared. The tool that we used for
SysML modeling is MagicDrawTM 16.5, which exports the
model files in the UML XMI 2.1 format. Therefore, some
pre-processing is required to produce the SysML XMI-
formatted model files. This is done by using another model
transformation between UML and SysML, and the process is
similar to the transformation between SysML and Simscape.
Note that this pre-processing is required due to the modeling
tool’s functionality and is independent of our approach.

16
The SysML model file is then input into the integration For this study, the system dynamic model (see Figs. 5,
framework for transformation. The “off line” mode of the 6, 8) and the simulation model (see Figs. 10-12) of the MSD
framework is used in which the input and output model files system in SysML are used as the input models. The spring
are all in the XMI-format. After the transformation, the rate is set to 1,000 N/m, the damping coefficient is set to 100
Simscape model file is output, and the links between the N*s/m, and the mass is set to 5 kg. To build the hybrid
corresponding elements are maintained. behavior model, the impulse force is setup as 50 N and 100
Based on the resulting Simscape model file, post- N with an interval of 3s. Throughout the transformation and
processing is conducted for the automatic simulation. The post-processing, the model in Simscape is generated and
component models are transformed into .ssc files, and the simulated. The Simscape diagram and simulation results of
library containing these components is built by using the the MSD system are shown in Fig. 19 (a). As shown in Fig.
ssc_build command. From the system and simulation 19(b)(c), if it is agitated by the 50 N force, the system will
models, a series of commands can be generated. For reach steady state in about 0.5 s and the position disturbance
example, add_block generates the needed components and is about 0.03 m , and if it is agitated by the 100 N force, the
adds the component instances to the system, and add_line system will reach steady state in about 0.5 seconds although
connects the components of the system. the position disturbance increases to about 0.06 m. From 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. Conclusions and Future Work
For this study, we proposed an approach for integrating
the system dynamic behavior design model and simulation
information in SysML with the corresponding physical
systems and simulations in Simscape. The primary
(a) Simscape representation of MSD model
contributions of the method are as follows:
(1) A systematic method was presented to extend SysML
for modeling the complex hybrid discrete/continuous
behavior in SysML. The SPD as well as the CCB and
transition are defined. Also, the dynamicConnector was
also extended to represent the physical lines that
describe Newton’s second law.
(b) Simulation results of velocity (c) Simulation results of position
Fig. 19 Simscape diagram and simulation results

17
(2) The extension method that represents the simulation References
information of the specific simulation platform was [1] Kevin Craig, Mechatronics System Design. Motor, Drive, &
presented, which facilitates the automatic simulation Automation Systems Conference. 2009.
process. [2] Jue ZH. Coupling design theory and method of complex

(3) A bidirectional transformation framework between the electromechanical system. China Machine Press. 2007.
[3] Michelle B., David H. System design: new product development
system-level design model and the simulation model
for mechatronics. Aberdeen Group. Benchmark report, 2008, 1.
was proposed based on a TGG. Using this method, the
[4] Fisher, J. Model-Based Systems Engineering: A New Paradigm.
system design models of MTSs can be automatically INCOSE Insight, 1998, 1(3): 3-16.
transformed into simulation tools and performed [5] Object Management Group(OMG), 2009. Systems Modeling

automatically. Similarly, the simulation results can also Language specification. http://www.omg.org /spec/
SysML/1.2/PDF.
be fed back into the design model, which can facilitate
[6] MathWorks Inc., Simscape 3.2, http://www.mathworks. com/
the model consistency and traceability.
products/simscape.
However, this simulation modeling approach is only a [7] Berkenkötter, K., Bisanz, S., Hannemann, U., and Peleska, J.
simplified version that lacks the constructs to model some of HybridUML Profile for UML 2.0. International Journal on
the simulation related blocks (e.g., Simulink-Simscape Software Tools for Technology Transfer, 2006, 8(2): 167-176.

converter blocks and Simulink signal suppliers) and detailed [8] Vanderperren Y., Dehaene W. From UML/SysML to
Matlab/Simulink: current state and future perspectives. Proc. of
simulation configurations. Therefore, a more complete
design, automation and test in Europe (DATE). Munich,
profile for modeling the Simscape simulation should be
Germany, Mar. 6-10, 2006.
presented in the future. [9] Turki, S., Soriano, T. A SysML extension for bond graphs
th
Furthermore, for this study, the modeling and support. 5 Int. Conf. on technology and automation,

simulating was restricted to the Simscape simulation tool. Thessaloniki, Greece, Oct. 15-16, 2005.
[10] Pop, A., Akhvlediani, D., and Fritzson, P. Towards Unified
We intend to derive a uniform approach to model and
Systems Modeling with the ModelicaML UML profile.
simulate system dynamics models that are applicable to
International Workshop on Equation-Based Object-Oriented
multiple simulation tools, such as Dymola. To achieve this Languages and Tools, Linköping University Electronic Press,
goal, more general stereotypes and different mapping rules Berlin, Germany, 2007.
need to be defined. [11] Modelica Association. Modelica Language Specification.
http://www.modelica.org/ documents /ModelicaSpec31.pdf ,
2009.
Acknowledgements [12] Nytsch-Geusen, C. The Use of UML within the Modelling
We would like to thank all of the reviewers for their Process of Modelica-Models. in International Workshop on
comments and suggestions and appreciate the previous Equation-Based Object-Oriented Languages and Tools,
Linköping University Electronic Press, Berlin, Germany, 2007.
researchers whose work helps us greatly. Also, the authors
[13] Johnson, T. A., Paredis, C. J. J., Burkhart, R. and Jobe, J. M.
appreciate the support from the 863 High-Technology
Modeling Continuous System Dynamics in SysML. in ASME
Project of China (No. 2009AA044501). International Mechanical Engineering Congress and Exposition,
ASME, Seattle, WA. 2007.

18
[14] Johnson, T. A., Paredis, C. J. J., and Burkhart, R. Integrating [20] Schürr, A. Specification of Graph Translators with Triple Graph
Models and Simulations of Continuous Dynamics into Sysml. in Grammars. Proceedings of WG'94 Workshop on Graph-
Modelica Conference Bielefeld, Germany, 2008. Theoretic Concepts in Computer Science, 1994: 151-163.
[15] Varró, D. VIATRA: Visual Automated Model Transformation. [21] Object Management Group. MOF QVT Final Adopted
Ph.D. thesis, Department of Measurement and Information Specification. http://www.omg.org/cgi-bin/doc?ptc/ 2005-11-01.
Systems, University of Technology and Economics, Budapest, [22] Amelunxen, C., Klar, F., Königs, A., et al. Metamodel-based
2003. Tool Integration with MOFLON. Proceedings of the 30th
[16] SysML-Modelica integration working group, 2010. SysML International Conference on Software Engineering, New York:
Modelica transformation specification version 1.0. ACM Press, 2005: 807-810.
http://www.omgwiki.org/OMGSysML/doku.php?id=sysml- [23] Klar, F., Rose, S., and Schürr, A. TiE - A Tool Integration
modelica:sysml_and_modelica_integration Environment. Proceedings of the 5th ECMDA Traceability
[17] Henzinger TA, Kopke PW, Puri A., et al. What's decidable about Workshop, 2009, WP09-09: 39-48.
Hybrid Automata: The algorithmic analysis of hybrid systems. [24] Czarnecki, K., and Helsen, S. Feature-based survey of model
th
Proceedings of 27 Annual ACM symposium on theory of transformation approaches. IBM Systems Journal, 2006, 45(3):
computing, 1995: 373–382. 621-645.
TM
[18] MathWorks Inc. Simscape 3 User’s Guide. [25] Object Management Group. Meta Object Facility (MOF) Core
http://www.mathworks.com/access/helpdesk/help/pdf Specification. http://www.omg.org/spec/ MOF/2.0/PDF, 2006.
_doc/physmod/simscape/simscape_ug.pdf, 2009. [26] Fujaba Core Development Group, Fujaba Tool Suite,
[19] Königs, A. Model Integration and Transformation - A Triple http://www.fujaba.de
Graph Grammar-based QVT Implementation. Ph.D. thesis,
Real-Time Systems Lab, Darmstadt University of Technology,
Germany, 2008.