Abstract— This paper presents a work underdone with the

intention of filling the gap between system-level designs and

simulations in the context of mechatronics. High levels system

designs and specifications that usually expressed in SysML are

not sufficient to verify the performance of dynamical systems

because SysML is only capable of descriptive semantics. In other

words, it cannot generate executable simulations. Engineers

often use separate simulation tools (e.g., Matlab/Simulink) for

evaluating the system performance. In this sense, we propose a

modeling and simulation approach using stereotypes and

specializations of SysML standards to facilitate mechatronics

system design. As a merit, descriptive SysML models are

integrated with simulation models (e.g. Simulink and Simscape)

in a single execution environment. We demonstrate the approach

along with an illustrative example of a mobile robotic platform.

I. INTRODUCTION

From control engineers‟ viewpoints, the design of control system dynamics works well using a model-based design approach with a widely-used design software and simulation tool, (e.g. Matlab/Simulink). Simulink uses graphical block diagrams, whose syntax is familiar to control engineers [1]. However they often lack understanding of how to provide proper design specifications which leads to inconsistent system specifications. In contrast, systems engineers are capable of preparing those specifications in a highly manageable way from high levels design to the detailed design expressed in SysML [2]. As a consequence, system-level designs and system-level simulations are disjoint. In this paper, we present a practical solution with the intention of filling the gap between systems design and system simulation in the context of mechatronics. In order to do that, we combine different modeling languages and simulation tools that are initially independent. In particular, the OMG‟s SysML for system-level design, the Matlab‟s Simscape extension for modeling the physical systems and its components [3], and the Matlab‟s Simulink extension to obtain an executable simulation of the designed system [4]. A UML-based modeling tool (e.g. Rational® Rhapsody® of IBM) is used to define system models (i.e. .rpy files) based on the SysML profile [5]. Both system-level and simulation

Manuscript received May 14th, 2013.

Mohd Azizi Abdul Rahman is with Graduate School of Engineering,

Shibaura Institute of Technology, 3-7-5 Toyosu, Kotoku, Tokyo 135-8548

Japan and University Technology of Malaysia (phone:+81-3-5859-8209;

fax: +81-3-5859-8201; e-mail: m710501@ shibaura-it.ac.jp).

Makoto Mizukawa, is with Department of Electrical Engineering,

Shibaura Institute of Technology, 3-7-5 Toyosu, Kotoku, Tokyo 135-8548

Japan(phone:+81-3-5859-8209;fax:+81-3-5859-8201;e-mail:

mizukawa@sic.shibaura-it.ac.jp).

models are integrated and auto-simulated in the Simulink environment.

For mechatronics systems design, Cao et al. [6] recently introduced a mixed-behavior system design using SysML with Stateflow and Simscape for system-level simulation. A meta-modeling graph-based model transformation method has been extensively carried out to link the system-level design with the simulation. Apart from that, a model‟s semantic extension was proposed based on the UML [7] stereotypes mechanism which we partly adopt in our approach. However, a graph-based model transformation technique is not covered in this paper. We use a model-referencing technique where we wrap a sub-model produced using Simscape and Simulink into a black-box that is compliance with SysML models. The wrapped model is then synced with the main design model in SysML. Model integration presented here is simpler compared to the model transformation work in [6]. The advantage is no ill-formulated meta-modeling concept is considered in our approach but it restricts only to the MathWorks products.

Venderperren and Dehaene [8], and Kawahara et al. [1] discussed a co-simulation method using UML/SysML and Matlab/Simulink, in which a software-based tool adapter is used to integrate the UML/SysML model and the simulation model in Simulink. This method has been implemented in the design of UAV flight control system for virtual prototyping [9]. We seek to investigate the potential of leveraging SysML in the field of control and systems engineering.

The remainder of the paper is organized as follows. Section II presents the proposed method with the aid of a running example. The system modeling and whole subsystems model composition are presented in greater detail in Section III. Section IV briefly discusses the implementation of model integration, and how the models are kept in sync. Simulation results including discussion and conclusion are drawn in Section V.

θ

s

x

y

fr

fl

Physical System

m, Ib, rc

{x, y, θ}

InputXd, Yd, θd

Controller

{ul, ur}

Figure 1. A mobile robotic system, MRS

Modeling and Design of Mechatronics System with SysML,

Simscape and Simulink

Mohd Azizi Abdul Rahman and Makoto Mizukawa

2013 IEEE/ASME International Conference onAdvanced Intelligent Mechatronics (AIM)Wollongong, Australia, July 9-12, 2013

978-1-4673-5320-5/13/$31.00 ©2013 IEEE 1767

II. SYSTEM OF INTEREST

Physical systems and their behavior are usually defined in terms of mathematical expressions. In this paper, a simplified mechatronics system as shown in Fig. 1 is used as a running example, which mainly consists of four parts: the mobile platform with embedded actuator and sensor, a control system, the kinematic constraint, and the input system (i.e., Xd, Yd, and θd). The chassis is a symmetrical round-shaped mobile platform with two-wheel differentially driven mechanism, and one passive wheel that is placed in front of the platform for stability. A rotational sensor is embedded with the wheels.

The physical properties of the system are the mass (m), chassis radius (rc), and moment of inertia about vertical axis (Ib). The motion on a horizontal plane with the kinematic constraint of the system is represented by [10]:

cos sx

sin*sy

where, x and y denote the position on the Cartesian coordinate system. The following equations show mathematical representations of the system:

vs

)( lr ffvm

clrb rffI

)(

Note that these representations reflect Newton‟s second-order law of motion and the energy-based Euler-Lagrange formulation where s, v, θ and ω represent the motion trajectory, linear velocity, heading angle, and angular velocity respectively. fr and fl denote the applied forces to the right- and left-wheel of the mobile platform respectively. The measured variables such as (x, y, and θ) will be compared to the desired input (Xd, Yd, and θd) and be fed back to the control system for low-level motion control.

III. SYSTEMS MODEL DEFINITION IN SYSML

SysML is a graphical language used to enable systems engineering activities (e.g. requirements analysis). It has been standardized based on UML. It has nine diagrams suitable for various complex systems design to support the specification, design, analysis, validation and verification including system hardware/software, personnel, information as well as facilities [11].

The descriptive SysML model needs to be translated into executable simulation models. Toward this end, the SysML‟s

model requires some semantic extensions to support the translation. For SysML model extension, we use the UML stereotype mechanism [12], [13]. It is a powerful way to extend a SysML element by the UML meta-class modeling [12]. Stereotypes are visually spotted by looking at the keyword within a set of double chevrons (e.g., <<Stereotype>>).

Based on the information above, we decide to model the system in SysML using a component-based approach, in which the main system (e.g. MRS) is first decomposed into a small piece of subsystems with their associated functions. To design the Simulink and Simscape simulation models, a lightweight model extension is implemented on the selected SysML model element. A set of new stereotypes is defined to associate the SysML model with the new model element capability. We then apply the physical modeling approach to build an energy-based physical system network. The physical modeling network is considered as a group of interrelated components that are linked to one another through their energy ports [14].

A. SysML-Simulink for Causal Model

A SysML‟s block is the most utilized element for describing both logical and physical objects of complex systems [2]. The definition of Simulink behavior models is described associate to the input and control system. The model element that can be stereotyped is a standard SysML block taken from its meta-model. Fig. 2 shows a newly-defined stereotype with a type of specialization (e.g. extend). It becomes a special block that happens to be a Simulink block (SB) representation. Semantically, the stereotype SB when it is applied to a SysML block, it is referenced as a Simulink sub-model. Therefore, the SB represents a sub-system in the Simulink model. Apart from semantic extension, the SB adds tagged values for information in the Simulink model base [15].

Instead of describing the system behavior, the component of systems also needs to be modeled. Fig. 3 illustrates a block definition diagram (BDD) showing the subsystems of input and controller apply the SB stereotype in SysML. Input variables and a flow port (e.g. OUT) are defined in the input block while several variables and flow ports are defined in the controller block for SysML-Simulink equivalent models. At this stage, we can import Simulink blocks as a sub-model into SysML.

Figure 2. Newly-defined SysML block for Simulink model, SB.

1768

Input«Block,S imulinkBlock»

Values

Xd:real_T=meter

Yd:real_T=meter

Theta:real_T=rad

Ports

Out:real_T

Out

Controller«Block,S imulinkBlock»

Values

ex:real_T=meter

ey:real_T=meter

etheta:real_T=rad

Ports

IN:real_T

ul:real_T

ur:real_T

x:real_T

y:real_T

theta:real_T

theta

ul

ur

y

x

IN

=

=

SysML Simulink

[Xd,Yd,Theta]

Input

Simulink

IN

x

y

theta

ur

ul

Controller

Figure 3. Simulink model definition in SysML

B. SysML-Simscape for Acausal Model

Basically, the Simscape declarative language has two model types [16-17]:

1. A domain model (e.g. translational.ssc).

domain translational variables %Declaration Section v = {1,'m/s'};%velocity end variables(Balancing = true) f = {1,'N'};%force end end

2. A component model (e.g. tSensor.ssc).

component tSensor %Translational Sensor nodes %Declaration Section T = Custom.translational;%T:right end outputs V = {0,'m/s'};%V:left port end parameters init_s = {0,'m'};%Initialize end variables v = {0,'m/s'}; s = {0,'m'}; end function setup%Implementation section across(v, T.v,[]);

s = init_s; end equations s.der == T.v; V == T.v; end end

In brief, domain files describe physical domains correspond to the port types (e.g., electrical, rotational, hydraulic, and translational) while component files describe physical components that users intend to model (e.g., resistors, capacitors, and inductors) in corresponding to the Simscape block. More details on the Simscape model structure can be found in [3], [16-17]. Note that Simscape is conceptually more specific to acausal physical dynamics theory, but it fits into Matlab/Simulink. Consequently, Simscape models can be integrated with other Simulink models in the same simulation environment.

Again, the SysML block is semantically extended to represent the Simscape domain and component files in SysML. Since domain files have no internal behavior and have only physical variables declaration, the stereotype <<SimscapeDomain>> is defined relatively to its semantic. Fig. 4 illustrates the newly-defined domain models such as Translational and Rotational, and Fig. 5 shows the Simscape component, „Dynamic‟ with its equivalent model defined in SysML. The physical component is clearly stereotyped with <<SimscapeComponent>>. To save space, we show only one example of Simscape components for a proof-of-concept Simscape language implementation. It is assumed the other Simscape components like kinematic, force, and sensor implement the same concept of the Simscape language.

A SysML block has a value property compartment to define system variables, parameters, and other properties correspond to Simscape. For example, the stereotype <<Parameters>> defines the mass property of the physical component with the value type of kilogram. The nodes of the components are modeled by utilizing the SysML‟s flow port. The stereotype, <<ePort>> is merely defined to replicate a bi-directional conserving port in Simscape to allow energy-based elements pass through it. The control system applies the force energy to both wheels via conserving ports T and R. A sensor can be used to monitor variable changes, and send them as signal-flow via signal ports, „<<sPort>>‟. The stereotype, <<sPort>> is defined by extending the standard SysML‟s flow port, refer Fig. 8.

1769

Rotational«Block,S imscapeDomain»

domain rotational

variables

w = {1,'rad/s'};%Across

end

variables(Balancing = true)

t = {1,'N*m'};%Through

end

end

Translational«Block,S imscapeDomain»

domain translational

variables

v = {1,'m/s'};%Across

end

variables(Balancing = true)

f = {1,'N'};%Through

end

end

Figure 4. Definition of Simscape domain models.

=

Simscape

Dynamics

T

R

Dynamic

Dynamic«Block,S imscapeC omponent»

Values

«Parameters» m:Kilogram=2.0

«Parameters» Ib:KilogramMeterSquared=0.156

«Parameters» rc:Meter=0.1

«Initial» init_s:Meter

«Initial» init_theta:Radian

«Variables» fl:Newton

«Variables» fr:Newton

«Variables» v:MeterPerSecond

«Variables» w:RadianPerSecond

«Variables» s:Meter

«Variables» theta:Radian

Constraints

«Equations» {{eqn0} T.v == s.der;}

«Equations» {{eqn1} R.w == theta.der;}

«Equations» {{eqn2} m*T.v.der == fr + fl;}

«Equations» {{eqn3} Ib*R.w.der == (fr- fl)*rc;}

«Function» {{setup0} through(fl,T.f,[ ]);}

«Function» {{setup1} through(fr,T.f,[ ]);}

«Function» {{setup2} across(w,R.w,[ ]);}

«Function» {{setup3} across(v,T.v,[ ]);}

«Function» {{setup4} s = init_s;}

«Function» {{setup5} theta = init_theta;}

Ports

R:Rotational

T:Translational R

«flowPort,Nodes,ePort»T

Figure 5. Definition of Simscape dynamic component in SysML

In Fig. 5, one of the constraints (e.g. „R.w==

theta.der‟) represents a derivative of theta, while a

constraint (e.g. „theta=init_theta‟) declares the

initialization setup for the heading angle. The constraint

defined for the equations conforms to the Modelica language [18]. Note that the operator „==‟, means a symmetric

mathematical relationship between left- and right-hand operands evaluated continuously throughout the simulation process.

C. System Model Composition

Constructing a physical system network requires another extension for a new stereotype to represent the composition of the main system. Fig. 6 shows the definition of Structured Simulink Block (SSB) extended from standard SysML‟s block. In this case, SSB tags several values to a Simulink‟s root block of the system to be simulated. The tag values clarify settings for simulation in the Simulink environment.

Systems model composition is accomplished by merging

every component in the SysML diagram. As seen in Figs. 7-8,

the MRS in Fig. 1 is modelled with BDD and the internal

block diagram (IBD). Now, the MRS block is stereotyped

with SSB for simulation context. IBD represents an internal

connection of the system‟s structure. Furthermore, the BDD

shows a collection of components of the entire system with

the part-of relationship. In Fig. 7, the MRS block comprises

of the Simulink‟s causal components such as controller and

input, and four Simscape‟s acausal components such as

dynamic, force, sensor, as well as the kinematic constraint.

For connecting these components, we use standard

SysML‟s connector to connect ports which has the same type.

Note that a special connector for energy-based ports is

required to convey the energy and it must conform to the

Kirchoff‟s Law. To achieve that, a connector with the

stereotype „<<eLink>>‟ (see Fig. 8) is defined based on the

UML‟s link metaclass to represent an energy connector in

Simscape. Semantically, it connects only ports with the same

domain conform to the Kirchoff‟s rule [6].

Since Simscape is a Simulink extension toolbox, all

Simscape components can implement the SB stereotype (see

the red block in Fig.7). By definition, Fig. 8 shows an exact

view of the entire system composition. However, it‟s still a

descriptive model unless the system model can be executed.

To this end, we implement a java-based plug-in for Rhapsody

in order to automate the simulation process.

Figure 6. Newly-defined SysML block for structured Simulink block, SSB

1770

Figure 7. Structure model in BDD

Figure 8. Internal structure model in IBD

IV. MODEL INTEGRATION

This section discusses the implementation of Rhapsody®

control system designer (CSD) [5]. The CSD framework

offers systems engineers to improve co-design by utilizing the

Rhapsody-Simulink interface (RSI) profile where Simulink

and Simscape models can be imported as a wrapped Simulink

diagram in Rhapsody [15]. A java-based plug-in is used to

control the application programming interfaces (APIs) for

both Rhapsody and Matlab tools. Consequently, the

integration of Rhapsody and Simulink tools can be achieved.

To use this facility, users must add the Simulink profile (e.g.

Simulink.sbs) into the Rhapsody environment prior to

importing the Simulink and Simscape sub-models. We use

model referencing method (see Fig.9) in which after

designing the system model in SysML, we import the pre-

designed Simulink and Simscape sub-models into Rhapsody

using the tool‟s menu „Import/Sync Simulink Model‟. As

depicted in Fig. 9, the Simscape model is wrapped to be a

Simulink diagram (e.g. Simscape.mdl) along with the

auxiliary components such as Simulink-PS and PS-Simulink

signal converters, and one local solver configuration. These

elements are available from the standard Simulink library.

On the other side, the Simulink model comprises of input and

controller components with a scope to display the simulated

result to engineers. As a result of using model referencing

technique, only ports are visible while detail components and

its connection are hidden as shown in Fig. 10.

Figure 9. Model referencing technique for simulation [7].

Figure 10. Simulation model definition in IBD.

1771

For synchronization, both system and simulation models

are synced using RSI and a series of Matlab APIs (e.g.

create_model.m) is automatically generated in the MATLAB

directory. This framework is developed based on Rhapsody‟s

plug-in mechanism in which the Rhapsody‟s APIs and

methods are used to access the Rhapsody data (e.g., model

elements, classes, ports, etc.). Models synchronization

process is shown in Fig. 11.

To verify the system performance, a simulation model has

to be executed in order to see if the system behaves as

expected. To this end, after syncing process is done, we

export Fig. 10 to the Simulink environment by choosing an

„Open Referenced Model and Simulate‟ function available in

the Rhapsody context menu. The execution process is shown

in the Matlab command window, and the „MRS_Rhap.mdl’

model is automatically generated (see Fig.12). If design

changes are made, the referenced model in SysML is also

updated.

V. DISCUSSION AND CONCLUSION

As shown in Fig. 13, a series of simulation results are

obtained only for a proof-of-concept model verification. The

results show simulated outputs of theta (radian) versus time

(s) when the mass was varied to 2.0, 1.5, and 1.0 kg

respectively. Figs. 13(a1) - 13(c1) illustrate the outputs when

Ib is set to 0.16 kgm2, and rc is 0.04m. In contrast, simulation

results in Figs. 13(a2) – 13(c2) demonstrate the outputs when

we reduce Ib to 0.03 kgm2, but rc remains unchanged. By

comparison, the controller compensates the heading error and

quickly settles to the steady-state condition. Engineers are

encouraged to perform more simulation study and do the

analysis by manipulating other parameters. From the

methodological aspect, model integration presented here is

simpler compared to the model transformation work done in

[6]. No ill-formulated meta-modeling concept was considered

in our approach.

In this study, we presented a modeling and simulation

method for designing system-level and simulation using

SysML, Simulink and Simscape. In this approach, the high-

level system models that usually expressed in SysML and the

Simulink/Simscape simulation models were integrated,

generated and performed the simulation automatically. This

effort gives benefits to systems and control engineers to

speed up the design and development process [19].

However, this paper only considers modeling and

simulation work restricted to the Mathworks tools. In the near

future, we intend to evaluate our high level system models

based on different simulation tools for comprehensive

systems design applicable to the mechatronics system.

Model Syncronizer(Rhapsody Simulink Interface)

Physical Systems Modeling & Simulation Tools

SysML Tool

Rhapsody V8.0

System Structure Model

in SysML

Simulink 7.6

Signal-flow Sub-Model

Simscape 3.4

Energy-flow Sub-Model

.mdl

.rpy

Figure 11. The synchronization process

Figure 12. Auto-generated simulatable diagram in Simulink window.

(a1) mass=2.0kg (b1) mass=1.5kg (c1) mass=1.0kg

(a2) mass=2.0kg (b2) mass=1.5kg (c2) mass=1.0kg

Figure 13. Simulation plots

1772

ACKNOWLEDGMENT

The usage of Rational® Rhapsody® software is supported

by the IBM® Academic Initiative program. Many thanks to

Hiroshi Ishikawa and Takashi Sakairi of IBM Research –

Tokyo Laboratory for their help and constructive comments.

REFERENCES

[1] R. Kawahara, et al., “Verification of embedded system‟s specification

using collaborative simulation of SysML and Simulink models,” in

Proc. Intl. Conf. on Model Based Systems Engineering, pp. 21-28,

Haifa, 2009.

[2] Object Management Group, “Systems modeling language

specification,” http://www.omg.org/spec/SysML/1.2/pdf

[3] Mathworks Inc., “Simscape 3.4,”

http://www.mathworks.com/products/simscape

[4] Mathworks Inc., “Simulink 7.6,”

http://www.mathworks.com/products/simulink

[5] IBM Corporation, “Rational® Rhapsody® version 8,”

http://www.ibm.com/developerworks/rational/library/rhapsody_release

-v8/release.html

[6] Y. Cao, Y. Liu, and C.J.J. Paredis, “System-level model integration of

design and simulation for mechatronic systems based on SysML,”

Mechatronics, vol.21, no.6, pp.1063-1075, 2011

[7] Object Management Group, “Unified modeling language

specification,” http://www.omg.org/spec/UML/2.3/pdf

[8] Y. Venderperren, and W. Dehaene, “From uml/sysml to

matlab/simulink: current state and future,” presented at the 2006

Design, Automation and Test in Europe (DATE) Conf., Munich,

Germany.

[9] X. H, Liu, and Y. F. Cao, “Design of UAV flight control system

virtual prototype using Rhapsody and Simulink,” in Proc. Intl. Conf.

on Computer Design and Applications, Qinhuangdao, 2010.

[10] R. Siegwart, I. R. Nourbakhsh, and D. Scaramuzza, Introduction to

Autonomous Mobile Robots: Intelligent Robotics and Autonomous

Agents series. 2nd editions. Massachusetts: The MIT Press, 2009.

[11] S. Friedenthal, A. Moore, and R. Steiner, A Practical Guide to SysML:

The Systems Modeling Language. MA: The Morgan Kaufman/OMG

Press, 2009, chapter 3.

[12] J. Holt, and S. Perry, SysML for Systems Engineering: Professional

Applications of Computing series, 1st Edition. London: The IET, 2007.

[13] K. Berkenkoutter, S. Bisanz, u. Hannemann, and J. Paleska,

“HybridUML profile for uml2.0,” Int. J. Software Tools Technol.

Transfer, vol. 8, no. 2, pp. 167-176, 2006.

[14] J. V. Amerongen, and P. Breedveld, “Modeling of physical systems for

the design and control of mechatronic systems: IFAC professional

brief,” Annu. Review in Control, vol. 27, no. 1, pp. 87-117, 2003.

[15] IBM Corporation, “Rational® Rhapsody® user‟s guide,”

http://publib.boulder.ibm.com/infocenter/rsdp/v1r0m0/topic/com.ibm.

help.download.rhapsody.doc/pdf75/userguide.pdf

[16] Mathworks Inc., “Simscape language fundamentals,”

http://www.mathworks.com/help/toolbox/physmod/simscape/simscape

_lang.pdf

[17] Mathworks Inc., “Simscape user‟s guide,”

http://www.mathworks.com/help/pdf_doc/physmod/simscape/simscap

e_ug.pdf

[18] Modelica Association, “Modelica language specification,”

http://www.modelica.org/documents/Modelicaspec31.pdf

[19] Mohd Azizi Abdul Rahman, and Makoto Mizukawa, “Model-based

development and simulation for robotic systems with sysml, simulink

and simscape profiles,” Int. J. Adv Robotic Sy, vol. 10, no. 112, pp. 1-

12, 2013.

1773