System-Level Model Integration of Design and Simulation for Mechatronic
Systems Based on SysML
Yue CAO1 Yusheng LIU1,2* Christiaan J.J. PAREDIS2
1
2
State Key Lab. of CAD&CG, Zhejiang University, Hang Zhou, P.R.China 310027
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
integration
of
physical
systems,
sensors,
unambiguously between the engineers and different
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
can correspond to continuous differential equations. Based on
these new constructs, the descriptive design model can be
mapped to the executable analysis model easily.
the “top-down approach” [7], which associates the semantics
of an existing language with the constructs of a general
language by creating extensions to it.
Vanderperren Y. et al discussed two possible integration
For this study, a SysML-based model integration
method is proposed for the design and simulation of
mechatronic system behavior. Here, the extensions are first
2
methods between the UML/SysML and MATLAB/Simulink [8],
i.e. co-simulation and integration based on a common
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
Soriano T. proposed an activity-diagram based method to
represent the Bond-graph based continuous dynamic behavior
of MTSs [9].
A more formal approach for SysML and Modelica
integration is proposed in [16]. In this specification, the
SysML4Modelica profile is proposed to represent the
Modelica constructs. Based on this profile, the analytic
Pop A. et al. [10] proposed the ModelicaML UML
profile as an integration of Modelica [11] and UML that
enables the engineers to specify the requirements, behavior,
and Modelica simulation in a uniform manner. This profile
reuses most of the UML constructs, modifies some of the
SysML diagrams including the Block Definition Diagram
(BDD), Internal Block Diagram (IBD) and Package
Diagram, and creates two new diagrams: the Equation
Diagram to describe the behavior of Modelica classes, and
the Simulation Diagram for modeling the simulation plan,
parameter setting and simulation results.
model can be created. Moreover, the transformation between
the profile constructs and the Modelica language is also
specified, which can facilitate transforming the analytic
model in SysML to the Modelica model which can be
executed in Modelica modeling tools.
In this paper, we have adopted the light-weight
extension approach to create stereotypes in SysML and TGG
based approach to transform these constructs to other
modeling languages, which are inspired by the related
works. However, because of the considerable differences
between the modeling and simulation in Simscape and
Nytsch-Geusen [12] presented the UMLH, a specialized
version of a UML for the graphical description and model-
Modelica, we introduced some totally new stereotypes and
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
develop the Modelica models in a graphical manner.
3. Method Overview
To fulfill the integration of the system design model
Johnson et al. [13-14] introduced an approach for
modeling continuous system dynamics in SysML based on
the language mapping between SysML and Modelica.
Unlike both of the above methods, this approach extends the
semantics of SysML by stereotypes instead of creating a
separate UML profile with new language constructs. It
establishes equivalent SysML constructs for selected
3
and simulation model for MTSs, the first task is to correctly
and effectively model the complex hybrid behavior. As
mentioned in Section 1, SysML provides several behavior
diagrams for the designer to define the behavior model.
However, even with the given diagrams, there are still two
problems. The first problem is that the diagrams are not
sufficient enough to define the discrete/continuous behaviors
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
model more difficult or even impossible. To facilitate the
integration of system design and simulation, a uniformly
Behavior modeling in SysML
 Component modeling
 System modeling
 Hybrid modeling
Behavior
modeling
elements
formalized representation is imperative for hybrid behavior
modeling. Besides hybrid modeling, the behavior model also
represents the behavior execution details which facilitate
transformation to Simscape.
Platform-specific simulation information
modeling in SysML
 Simulation environment parameter
configuration
 Simulation-related parameter setup
Simulation
platform
information
Then, the platform-specific simulation parameters are
modeled. Besides the behavior model created in step 1, to
run the simulation, the simulation configuration parameters
should also be given, e.g. solver types, start/stop time for
Simscape, and the parameters of the physical components,
Mapping between design and
simulation in MOFLON
 Meta-model extraction
 Mapping rule selection
 One-by-one mapping
Mapping rules
e.g. the mass, the spring coefficient, should be indicated as
well. In this step, these parameters are set or adjusted which
provides necessary information for running the simulation in
Simulation model Output
(in XMI format)
Simscape.
After all of the hybrid behavior information and
simulation information are modeled formally, they are
transformed into a specific simulation model to be
conducted in Simscape. The entire process is shown in Fig.
Executing the simulation in Simulink
 Executable Simulink model generation
based on APIs
 Running the simulation and adjusting
parameters
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
to create the expected system dynamic behavior model and
4. SysML-based Uniform Hybrid System
Dynamic Behavior Model
simulation model in SysML that can interact with other
system models such as requirement models, structure
models, etc. By relying on the bidirectional transformation,
the design models in SysML can be transformed into
simulation models in Simscape and simulated automatically
To achieve the design and simulation integration, the
descriptive SysML should be augmented by additional
execution semantics in order to create computational hybrid
behavior model of MTSs which is suitable to transform to
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»
4.1.3 SPD
stereotype.
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
used to describe the relationship between two conditional
constraint properties. Its semantics are the same as the
transition in the state machine, which describes the discrete
state changes separating continuous state evolutions. The
transition can have a condition, which is extended from the
constraint, and a event to trigger the transition. They are
related to activating and deactivating the transition.
6
(conditional) constraint properties that hold nested usages of
constraint blocks as the PAR. Fig. 4 shows a SPD which
describes the hybrid behavior of the ForceSource. The
ForceSource has three states: noforce state in which the
force is always zero; impulse1 in which the force is set to
force1=10N; impulse2 in which the force is set to
force2=100N. The state transitions occur at time 1s and time
4s. At time 1s, the impulse force1 start acting. After 0.1s, the
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
4.2 Definition of Simscape-compatible modeling
components
only nodes of the same type can be connected. Inputs and
outputs define the physical signal ports (the directional ports
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 Simscapecompatible 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
Fig. 5 Domain and Component models
SysML, the block is the most widely used modular unit to
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
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
common
properties,
«through»
and
«across»
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.
Typically, the time to revert to steady state is an essential
behavior
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
10
information
without
any
simulation-related
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
one solver configuration block. It is automatically added to
the Simscape diagram in our approach for automatic
simulation, and the designers are not required to insert it
explicitly. There are two types of converter blocks. The
Simulink-PS Converter block is used to connect Simulink
signal sources to the inputs of the system, e.g., the Force
component. For this study, the force supplied by the Force
component is described directly by the component’s
equations; thus, any external inputs are omitted. The PSSimulink Converter block is used to connect the outputs of
the system to Simulink blocks, such as scopes. Because the
outputs of the system are all generated by the sensors
11
Fig. 10 BDD of the simulation model
Based on the above analysis, a stereotype «simulation»
is defined by extending the block of SysML. It contains the
following three types of information: (1) Configuration
related parameters. For example, the start time and stop time
should be set during the simulation. Two stereotypes
«startTime» and «stopTime» are defined by extending the
value property in SysML. (2) System related parameters.
They are modeled by the «parameter», e.g., the magnitude
of the impulse force is given by the parameter forcePulse.
(3) Sensor. The simulation must contain at least one sensor.
The sensor is modeled by the stereotype «sensor» block with
the same syntax as the common components.
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
simulation, e.g., the value of force is set to 50N.
6. TGG-based Model Transformation
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 designsimulation 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
component in Simscape.
integration
environment.
Using
the
integration
framework, a bidirectional transformation between SysML
and Simscape can be accomplished.
«source» 0..1
Block
0 Block2Component
6.2 Meta-model based correspondence between
Block2Component
(name: String)
0..1
SysML and Simscape
«target»
Component
0..1
The core of the model transformation is the integration
link types between the corresponding elements of the two
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
OMG’s
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.
is
vision
of
model-based
software
A distinguishing characteristic of the TGG is that,
besides the two graphs representing the source and target
meta-models,
it
uses
a
third
graph
to
store
Therefore, a meta-model to formally represent the physical
system and simulation in Simscape should be generated.
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
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
physical
system and
physical
connection
lines
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
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.
properties
of
the
system
block,
connector in the PAR of the simulation model.
«create»
obj1:Block
name:=nam
e
«create»
obj1:Package
name:=name
«create»
«create»
obj2:Componet
Obj3:Block2Component
P
name:=name
«create»
obj2:SimPackage
«create»
obj3:SysPack2SimPack
package
package
package2Elm
package2Elm
PackagedElement
«create»
obj9:Block
name:=nam
e
name:=name
PackagedElement
«create»
obj11:Block2Component
«create»
obj10:Component
name:=name
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,
Fig.14 Part of the Simscape meta-model related to physical system
and simulation modeling
package and block in SysML. Their rules are similar because
there are two levels of transformation. One is defined for the
top-level information transformation and the other is for the
6.3 TGG rules for link types
The TGG rule for each link type is declared below its
name with parameters. Each integration link type can own
(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
transformation of the internal information. Take the block
transformation for example, Fig 15 shows the transformation
rules for the corresponding link types, as shown in Fig. 13.
0 ValueProp2Parameter
ValueProp2Parameter
(name: String, type: String
Value: String, access: String)
0..1
transformed into a parameter if the stereotype is empty.
0..1 «target»
Additionally, it should be transformed into a through
Parameter
variable if the type of stereotype is through, whereas it
0 ValueProp2VariableT
«source»
ValueType
should be transformed into an across variable if the type of
ValueProp2VariableT
(name: String, type: String
Value: String, access: String)
0..1
0 ValueProp2VariableA
0..1
«source»
ValueProperty
The fourth part of the transformation rules consists of
0..1 «target»
ValueProp2VariableA
(name: String, type: String
Value: String, access: String)
0..1
stereotype is across.
0..1
0 ValueProp2VariableTD
equation transformation, which is to transform the
Variable
constraints of SysML to setup functions and equations in
Simscape, as shown. Similar to the third part of the
0..1
transformation rules, the types of the stereotypes are used to
ValueProp2VariableTD
(name: String, type: String
Value: String, access: String)
0..1
0 ValueProp2VariableAD
determine the type that should be selected for the target
0..1
object.
The last part of rules is used to transform the
ValueProp2VariableAD
(name: String, type: String
Value: String, access: String)
inheritance relationship between SysML and Simscape, as
shown in Fig. 17.
(a) Link types
obj4:Block
obj7:Block2Component
Block
Block2Property
ownedProperty
«create»
obj1:ValueProperty
name:=name
visibility:=access
defaultValue:=value
stereotype==”through”
VPropT
vprop
Type
«source»
0..1
Generalization
obj5:Component
component
Component2Var
Variables
«create»
obj6:ValueProp2
VariableT
0..1
General2SimGeneral()
«target»
SimGeneralization
(a) Link types
«create»
obj2:Varibale
name:=name
visibility:=access
obj3:Block
«create»
obj1:Generalization
obj4:Component
obj6:Block2Component
child
Child2GenRel
generalization
«create»
obj5:General2
SimGeneral
child
Child2Rel
generalization
«create»
obj2:SimGeneralization
general
General2Parent
general
«create»
obj3:ValueType
name:=type
General2SimGeneral
(b) Transformation rules
obj7:Block
Fig. 16 Transformation rules for ValueProperty
general
Rel2Parent
parent
obj9:Block2Component
obj8:Component
(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
the corresponding part of the component, as shown in
Fig.16. The key problem is determining the type of
transformed target object. The type of stereotype is used as
the heuristic for the determination. Specifically, it should be
15
With the help of the above-mentioned transformations,
the automatic simulation can be implemented. Specifically,
the design model in SysML is transformed into the Simscape
simulation model, and a series of commands can then be
generated to construct the physical systems. The simulation
MagicDraw 16.5
Simscape 3.2
is then automatically configured and executed in the
system dynamics model
simulation model
(in SysML)
physical system model
simulation information
(in Simscape language
and commands)
Simscape environment by using these generated commands.
By using backward transformation, the modifications in the
SysML
metamodel
(in MOF 2.0)
Consistency checking between the models in SysML and
model transformation is described, as follows:
pre-process
Simscape is also supported. The detailed process for the
TGG
specification
Simscape
metamodel
(in MOF 2.0)
TGG metamodel
(in MOF 2.0)
Operational rules
(in SDM)
post-process
MOFLON 1.3
simulation models are reflected in the design models.
(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
included.
SysML model
(in XMI)
(2) The TGG schema and TGG rules are declared by using
the schema editor and rule editor of the TGG plug-in.
(3) 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
(4) JMI-complaint code is generated from the source metathe
target
meta-model,
Simscape model
(in XMI)
Fig. 18 The entire transformation process
For the input specific model, the code is used by the
TiE in which the integration framework performs different
integration tasks such as forward and backward model
transformation, consistency checking and traceability link
from the FUJABA Tool Suite [26].
model,
TiE 1.3.2
Integration
framework
and
the
maintenance. The entire process is shown in Fig. 18.
TGG
7. Implementation and Examples
specification above.
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 XMIformatted 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
framework for transformation. The “off line” mode of the
framework is used in which the input and output model files
are all in the XMI-format. After the transformation, the
Simscape model file is output, and the links between the
corresponding elements are maintained.
Based on the resulting Simscape model file, postprocessing is conducted for the automatic simulation. The
component models are transformed into .ssc files, and the
library containing these components is built by using the
ssc_build command. From the system and simulation
models, a series of commands can be generated. For
(a)
Simscape representation of MSD model
example, add_block generates the needed components and
adds the component instances to the system, and add_line
connects the components of the system.
(b) Simulation results of velocity (c) Simulation results of position
Fig. 19 Simscape diagram and simulation results
For this study, the system dynamic model (see Figs. 5,
6, 8) and the simulation model (see Figs. 10-12) of the MSD
system in SysML are used as the input models. The spring
rate is set to 1,000 N/m, the damping coefficient is set to 100
N*s/m, and the mass is set to 5 kg. To build the hybrid
behavior model, the impulse force is setup as 50 N and 100
N with an interval of 3s. Throughout the transformation and
post-processing, the model in Simscape is generated and
simulated. The Simscape diagram and simulation results of
the MSD system are shown in Fig. 19 (a). As shown in Fig.
19(b)(c), if it is agitated by the 50 N force, the system will
reach steady state in about 0.5 s and the position disturbance
is about 0.03 m , and if it is agitated by the 100 N force, the
system will reach steady state in about 0.5 seconds although
17
the position disturbance increases to about 0.06 m. From the
converter blocks and Simulink signal suppliers) and detailed
simulation results, the analysts can determine whether the
simulation configurations. Therefore, a more complete
design meets the given requirements. If not, some of the
profile for modeling the Simscape simulation should be
related parameters can be adjusted in the simulation
presented in the future.
environment and then returned, which automatically affects
the corresponding design parameters.
Furthermore, for this study, the modeling and
simulating was restricted to the Simscape simulation tool.
We intend to derive a uniform approach to model and
simulate system dynamics models that are applicable to
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
multiple simulation tools, such as Dymola. To achieve this
goal, more general stereotypes and different mapping rules
need to be defined.
systems and simulations in Simscape. The primary
Acknowledgements
contributions of the method are as follows:
(1) A systematic method was presented to extend SysML
We would like to thank all of the reviewers for their
for modeling the complex hybrid discrete/continuous
comments and suggestions and appreciate the previous
behavior in SysML. The SPD as well as the CCB and
researchers whose work helps us greatly. Also, the authors
transition are defined. Also, the dynamicConnector was
appreciate the support from the 863 High-Technology
also extended to represent the physical lines that
Project of China (No. 2009AA044501).
describe Newton’s second law.
(2) The extension method that represents the simulation
information of the specific simulation platform was
References
[1]
presented, which facilitates the automatic simulation
Automation Systems Conference. 2009.
[2]
process.
was proposed based on a TGG. Using this method, the
[3]
Fisher, J. Model-Based Systems Engineering: A New Paradigm.
INCOSE Insight, 1998, 1(3):
[5]
3-16.
Object Management Group(OMG), 2009. Systems Modeling
Language
automatically. Similarly, the simulation results can also
be fed back into the design model, which can facilitate
Michelle B., David H. System design: new product development
for mechatronics. Aberdeen Group. Benchmark report, 2008, 1.
[4]
system design models of MTSs can be automatically
transformed into simulation tools and performed
Jue ZH. Coupling design theory and method of complex
electromechanical system. China Machine Press. 2007.
(3) A bidirectional transformation framework between the
system-level design model and the simulation model
Kevin Craig, Mechatronics System Design. Motor, Drive, &
specification.
http://www.omg.org
/spec/
SysML/1.2/PDF.
[6]
the model consistency and traceability.
MathWorks Inc., Simscape 3.2, http://www.mathworks. com/
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.
18
[8]
Vanderperren
Y.,
Dehaene
W.
From
UML/SysML
to
Matlab/Simulink: current state and future perspectives. Proc. of
design, automation and test in Europe (DATE). Munich,
[9]
http://www.omgwiki.org/OMGSysML/doku.php?id=sysmlmodelica:sysml_and_modelica_integration
[17] Henzinger TA, Kopke PW, Puri A., et al. What's decidable about
Germany, Mar. 6-10, 2006.
Hybrid Automata: The algorithmic analysis of hybrid systems.
Turki, S., Soriano, T.
Proceedings of 27th Annual ACM symposium on theory of
support.
A SysML extension for bond graphs
5th Int. Conf. on technology and automation,
Thessaloniki, Greece, Oct. 15-16, 2005.
[18] MathWorks
[10] Pop, A., Akhvlediani, D., and Fritzson, P. Towards Unified
Systems
Modeling
with
the
computing, 1995: 373–382.
ModelicaML UML profile.
Inc.
SimscapeTM
3
User’s
Guide.
http://www.mathworks.com/access/helpdesk/help/pdf
_doc/physmod/simscape/simscape_ug.pdf, 2009.
International Workshop on Equation-Based Object-Oriented
[19] Königs, A. Model Integration and Transformation - A Triple
Languages and Tools, Linköping University Electronic Press,
Graph Grammar-based QVT Implementation. Ph.D. thesis,
Berlin, Germany, 2007.
Real-Time Systems Lab, Darmstadt University of Technology,
[11] Modelica
Association.
Modelica
http://www.modelica.org/
Language
Specification.
documents /ModelicaSpec31.pdf ,
2009.
Germany, 2008.
[20] Schürr, A. Specification of Graph Translators with Triple Graph
Grammars. Proceedings of WG'94 Workshop on Graph-
[12] Nytsch-Geusen, C. The Use of UML within the Modelling
Process of Modelica-Models. in International Workshop on
Equation-Based
Object-Oriented
Languages
and
Tools,
Linköping University Electronic Press, Berlin, Germany, 2007.
Theoretic Concepts in Computer Science, 1994: 151-163.
[21] Object Management Group. MOF QVT Final Adopted
Specification. http://www.omg.org/cgi-bin/doc?ptc/ 2005-11-01.
[22] Amelunxen, C., Klar, F., Königs, A., et al. Metamodel-based
[13] Johnson, T. A., Paredis, C. J. J., Burkhart, R. and Jobe, J. M.
Tool Integration with MOFLON. Proceedings of the 30th
Modeling Continuous System Dynamics in SysML. in ASME
International Conference on Software Engineering, New York:
International Mechanical Engineering Congress and Exposition,
ACM Press, 2005: 807-810.
ASME, Seattle, WA. 2007.
[23] Klar, F., Rose, S., and Schürr, A. TiE - A Tool Integration
[14] Johnson, T. A., Paredis, C. J. J., and Burkhart, R. Integrating
Models and Simulations of Continuous Dynamics into Sysml. in
Modelica Conference
Bielefeld, Germany, 2008.
Workshop, 2009, WP09-09: 39-48.
[24] Czarnecki, K., and Helsen, S. Feature-based survey of model
[15] Varró, D. VIATRA: Visual Automated Model Transformation.
Ph.D. thesis, Department of Measurement and Information
Systems, University of Technology and Economics, Budapest,
2003.
transformation approaches. IBM Systems Journal, 2006, 45(3):
621-645.
[25] Object Management Group. Meta Object Facility (MOF) Core
Specification. http://www.omg.org/spec/ MOF/2.0/PDF, 2006.
[16] SysML-Modelica integration working group, 2010. SysML
Modelica
Environment. Proceedings of the 5th ECMDA Traceability
transformation
specification
version
1.0.
19
[26] Fujaba
Core
Development
http://www.fujaba.de
Group,
Fujaba
Tool
Suite,