ARTICLE

International Journal of Advanced Robotic Systems

Model-Based Development and

Simulation for Robotic Systems with
SysML, Simulink and Simscape Profiles
Regular Paper

Mohd Azizi Abdul Rahman1,2,* and Makoto Mizukawa3

1 Graduate School of Engineering, Shibaura Institute of Technology, Tokyo, Japan
2 University of Technology Malaysia, Kuala Lumpur International Campus, Malaysia
3 Department of Electrical Engineering, Shibaura Institute of Technology, Tokyo, Japan
* Corresponding author E-mail: M710501@shibaura-it.ac.jp
 
Received 30 May 2012; Accepted 17 Dec 2012

DOI: 10.5772/55533

© 2013 Rahman and Mizukawa; licensee InTech. This is an open access article distributed under the terms of the Creative
Commons Attribution License (http://creativecommons.org/licenses/by/3.0), which permits unrestricted use,
distribution, and reproduction in any medium, provided the original work is properly cited.

Abstract In system‐level design, it is difficult to achieve a  Keywords  Model  Based  Development,  Robotic  System‐

system  verification  which  fulfils  the  requirements  of  Level  Design,  OMG  SysML™,  Simulink®,  IBM® 
various  stakeholders  using  only  descriptive  system  Rational® Rhapsody®, Simscape™ 
models.  Descriptive  system  models  using  SysML  alone 
are  insufficient  for  system  behaviour  verifications  and 
 
engineers  always  use  different  simulation  tools  (e.g.,  the  1. Introduction 
Mathworks  Simulink  or  Modelica  Dymola)  to  analyze 
Robots  can  be  regarded  as  complex  systems  due  to  the 
systems  behaviour.  It  is  a  good  idea  to  combine 
collection  of  interrelated  components  and  systems 
descriptive  and  simulation  models.  This  paper  presents  engineering  principles  are  required  in  their  design  [1]. 
the  development  of  a  collaborative  design  framework  Moreover,  the  integration  of  components  from  the  very 
which  brings  SysML,  Simulink,  and  Simscape  profiles  beginning  of  the  design  process  can  result  in  extremely 
within  the  domain  of  robotics.  A  conceptual  design  complicated  design  decisions.  A  combined  operation  of 
method  is  proposed  to  support  execution  models  for  multiple  domains  such  as  mechanical,  electrical,  control 
simulation.  In  brief,  the  descriptive  SysML  system‐level  and  software  is  needed  to  manage    all  the  system 
model  is  interpreted  into  the  system‐level  simulation  functionalities. To help engineers deal with the increasing 
models  (e.g.,  Simulink  and  Simscape).  We  then  use  a  complexity  in  systems  design,  a  model‐based  approach 
plugin‐based  model  integration  technique  to  keep  both  can  be  adopted.  Model‐based  system  engineering 
models  in  sync  for  automatic  simulation.  A  simulation  (MBSE),  a  recent  development,  has  become  an  accepted 
study  is  performed  to  evaluate  the  system.  To  illustrate  approach  for  designing  complex  systems  [2].  MBSE  has 
the design of this system, we present a simulated closed‐ been introduced as a mainstream method which involves 
loop system.  a  fundamental  shift  from  traditional  document‐centric 

www.intechopen.com Mohd Azizi Abdul Rahman and Makoto Mizukawa: Int Model-Based
J Adv RoboticDevelopment
Sy, 2013, Vol.and
10,Simulation
112:2013 1
for Robotic Systems with SysML, Simulink and Simscape Profiles
 approaches to computerized model‐based approaches [3].  aspects  need  a  new  conceptual  framework  for  multi‐
In  addition  to  MBSE,  a  graphical‐based  language  for  system  integration  in  the  later  stages  of  development. 
enabling  systems  engineering  activities,  the  OMG  Recent contributions to the development of robot systems 
SysML™ [4] has been standardized based on  UML [5]  in  that use the potential of SysML language are presented in 
support of the MBSE framework. Using MBSE in systems  [11]  for  the  design  of  a  space  robotics  system,  in  [12]  for 
design,  engineers  can  solve  systems  engineering  the  software  development  process  of  a  mobile  robot  and 
problems  by  expressing  multiple  views  that  can  in  [13]  for  a  SysML‐based  robot  systems  design  for 
transform  stakeholders’  requirements  into  detailed  manipulation  tasks.  We  seek  to  investigate  the  potential 
specifications with the aid of models [6].   uses of SysML in the field of robotics, control and systems 
  engineering.  
In  this  paper,  we  propose  a  comprehensive  system‐level   
design  workspace  for  robotics  in  conjunction  with  the  SysML  was  developed  as  a  general‐purpose  modelling 
simulation  of  continuous  system  dynamics.  The  primary  language  that  is  only  capable  of  descriptive  semantics. 
modelling  languages  are  introduced,  such  as    SysML™  Executable  semantics  are  required  for  the  design  of  the 
for  systems  engineering  activities,  Simscape™  [7],  the  simulation  and  its  analysis.  Associating  executable 
declarative language for physical systems modelling and  semantics  with  SysML  descriptive  semantics  can  be 
also  Simulink®  [8],  Matlab’s  extension  product  that  realized  by  developing  an  extension  to  the  UML  model 
allows  the  modelling  and  simulation  of  continuous  element  [14].  Johnson  et  al.  [15‐16]  proposed  a  formal 
processes using block diagrams. For this study, the UML  technique  for  modelling  continuous  system  dynamics  in 
modelling    tool,  the  IBM®  Rational®  Rhapsody®  SysML  through  language  mapping  between  SysML 
software [9] is used to design system‐level models based  constructs  and  the  declarative  Modelica  [17]  language.  
on  the  SysML  profile.  The  simulation  environment  is  set  The mapping method uses the extension of SysML model 
to Simulink. In brief, the system model of the robot is first  elements through the stereotypes mechanism rather than 
described  using  SysML  to  represent  the  continuous‐time  formulating totally new language constructs. As a result, 
dynamics  behaviour  of  the  system.  A  new  set  of  compatible SysML constructs are established for selected 
stereotypes  is  created  in  order  to  provide  distinctive  Modelica  elements  in  representing  the  continuous 
model  semantics  in  support  of  Simulink‐  and  Simscape‐ dynamics  modelling  constructs,  as  well  as  their 
compatible  models.  A  subsystem  that  contains  simulation  model  in  SysML.  Venderperren  and  Dehaene 
components, for example, actuators, sensors, and the base  [18],  and  Kawahara  et  al.  [19]  discussed  a  co‐simulation 
platform  is  then  modelled  based  on  a  physical  system  approach  using  UML/SysML  and  Matlab/Simulink,  in 
modelling  approach  using  a  Simscape  language.  Lastly,  which a software‐based coupling tool is used to combine 
all  the  models  are  integrated  and  synchronized  with  the  the  UML/SysML  model  and  the  simulation  model  in 
system‐level  simulation  model  and  be  executed  in  the  Simulink.   
Simulink window automatically.   
  For  mechatronic  system  behaviour,  Turki  and  Soriano 
The remainder of the paper is organized as follows. Some  [20]  proposed  a  method  for  representing  continuous 
related  works  are  reviewed  in  section  2  which  consider  dynamics  behaviour  using  a  bond  graph  based  on  the 
continuous  behaviour  modelling  and  systems  model  extension  of  SysML  activity  diagrams.  Furthermore,  Cao 
integration of different languages. Section 3 describes the  et al. [14] recently introduced a mixed‐behaviour system‐
proposed  method  with  the  aid  of  a  case  study.  The  level  design  using  SysML,  and  Stateflow  and  Simscape 
modelling  of  the  continuous  system  dynamics  and  the  for  system‐level  simulation.  In  addition,  a  model 
whole model composition are presented in greater detail  semantic extension is carried out based on the stereotypes 
in section 4. Section 5 briefly discusses model integration  mechanism  [21].  Based  on  the  above  information,  we 
and  how  the  models  are  kept  in  sync,  including  believe  that  the  system‐level  design  and  simulation 
implementation and simulation results. Last but not least,  technologies which use the potential of SysML, Simulink 
section  6  gives  a  summary  of  the  proposed  method  and  and Simscape could offer promising solutions for robotics 
describes some possible future works.             and its applications.  

2. Related Research   3. Method 

For  this  section,  related  works  on  continuous  behaviour  This  section  describes  the  methodology  used  in  the 
modelling,  model  semantics  extension  and  systems  system‐level  modelling,  simulation  and  control  of  a 
model  integration  of  different  languages  are  reviewed.  wheeled  mobile  robot.  From  control  engineering 
According  to  Bruninyckx  [10],  robotics  is  a  field  of  perspectives,  the  design  of  control  dynamic  systems 
integration  rather  than  a  fundamental  science,  so  it  works well using a model‐based design (MBD) approach 
contributes to complex systems integration. In that sense,  with a widely‐used design software and simulation, (e.g., 
robotic  systems  that  typically  consist  of  multi‐domain  Matlab/Simulink).  Simulink  uses  block  diagrams,  whose 

2 Int J Adv Robotic Sy, 2013, Vol. 10, 112:2013 www.intechopen.com

syntax is familiar to control engineers [19]. However, they  width  (wd),  and  the  robot’s  base  moment  of  inertia  (Ib) 
often  lack  understanding  of  how  to  provide  proper  about  the  vertical  axis.  The  following  shows 
specifications  for  the  system  they  design  which  leads  to  mathematical representations of the system: 
unmanageable  and  inconsistent  system  specifications.  In 

contrast, system engineers are capable of preparing those 
  s                                             (1) 
specifications  in  a  highly  manageable  way  from  the 
conceptual  abstraction  design  to  the  detailed  design.  
Therefore,  our  proposed  framework  will  let  the  system                                                (2) 
and  domain  experts  (e.g.,  systems  design  engineers, 

software  developers  and  control  engineers)  collaborate    m  v   t r  t l  / rw                              (3) 
from  the  first  until  the  last  development  stages  within  a 
unified workspace.   
  2   b  rc   / w d  t r  t l                        (4) 
3.1 A Brief Overview of the method 
Note  that  the  representation  reflects  Newton’s  second‐
A significant trend in contemporary systems engineering  order  law  of  motion  and  the  energy‐based  Euler‐
practice  is  model‐based  designs,  which  make  use  of  Lagrange  formulation  where  s,  v,  θ,  and  ω  represent  the 
explicit models to define activities in the life cycle of the  robot’s  displacement,  forward  velocity,  orientation  and 
design  and  development  of  products  [22].  To  create  angular velocity respectively. tr and tl denote the applied 
system‐level  design  and  simulation  models,  we  need  to  torques  to  the  right  and  left  wheel  of  the  robot, 
define  the  system  structure  and  its  behaviour  respectively. 
(continuous‐time).  SysML provides several constructs for 
defining  the  system’s  structure  and  behaviour.  For  this  y
ex, ey, eθ s
study,  the  Simulink‐  and  Simscape‐related  models  are  xd, yd, θd t
semantically  defined  in  SysML  to  obtain  a  newly  Controller θ
tl x
compatible  structure  and  simulatable  models.  The 
tr
continuous  system  behaviour  will  then  be  assigned  to  a 
SysML  block  by  referencing  the  Simulink  and  Simscape  x, y, θ
 
models from the block.  
Figure 1. Closed‐loop wheeled mobile robot system 
 
A  plugin‐based  model  integration  is  performed  to  sync  Furthermore,  the  robot’s  motion  on  a  horizontal  plane 
the  SysML  design  model  with  the  Simulink‐  and  with  the  kinematics  constraint  of  the  system  is 
Simscape‐compatible  model,  and  thus  generate  the  represented by the following equations [23]: 
simulatable model automatically. Prior to that, simulation 
properties  need  to  be  configured,  (e.g.,  the  solver  type,    x  s  cos( )                                      (5) 
solver  name,  and  start/stop  time).  The  proposed  method 
is illustrated by using a wheeled mobile robot system.    y  s  sin( )                                      (6) 

3.2 An example system  where,  (x,  y)  denotes  the  robot’s  position  in  the  X‐Y 
reference  frame.  The  measured  variables  (x,  y,  θ)  will  be 
The physical system and its behaviour are usually formed  compared to the desired input and fed to the controller as 
in  terms  of  differential  equations.  In  this  paper,  a  the error term (e.g., e = [ex, ey, eθ]T = [xd‐x, yd‐y, θd‐θ]T). The 
simplified closed‐loop system, as shown in Fig.1, is used  control  algorithm  is  simplified  by  the  following 
as  a  case study.  The  system simply  consists  of  two  main  equations: 
subsystems  and  several  components:  the  robot  base  (i.e., 
including its body dynamics and kinematics components)  de
with  embedded  actuators  and  sensors  (e.g.,  both    u l  K 1  e  K 2   e  dt  K 3                   (7) 
dt
translational and rotational sensors), a control system and 
the  desired  input  in  the  form  of  a  position  in  the  X‐Y  de
u r  K 1  e  K 2   e  dt  K 3                   (8) 
coordinate system and the desired orientation (e.g., xd, yd,  dt
 
θd). The robot base is a symmetrical round‐shaped mobile 
platform  with  two  actuated  wheels  and  one  passive  where,  ul  and  ur  denote  the  controller  left‐  and  right‐
wheel (not shown in the figure) that is placed in front of  output, respectively. K1, K2, and K3 represent the tunable 
the platform for stability.    coefficients  for  controller  gains.    The  objective  of  the 
  controller  is  to  provide  appropriate  torques  (tl,  tr)  to  be 
The physical properties of the robot platform are the mass  applied to the robot for motion. Therefore, the robot will 
(m), the radius of robot’s base from the centre of the robot  be controlled based on the torques applied to the left‐ and 
platform  (rc),  the  robot’s  wheel  radius  (rw),  the  robot’s  right‐side of the wheels.    

www.intechopen.com Mohd Azizi Abdul Rahman and Makoto Mizukawa: Model-Based Development and Simulation 3
for Robotic Systems with SysML, Simulink and Simscape Profiles
 4. System Definition View in SysML    method  because  it  is  more  easily  implemented  in  our 
current SysML tool. 
The SysML’s block is the most utilized model element for   
describing  both  logical  and  physical  objects  of  complex  Based  on  the  above  analysis,  we  choose  to  model  the 
systems [4]. It is the basic construct of the SysML model.  system  in  SysML  using  a  component‐based  approach,  in 
For  conceptual  system‐level  definition,  the  closed‐loop  which  the  closed‐loop  system  is  first  decomposed  into 
system  as  shown  in  Fig.1  is  firstly  defined  in  a  several components  with their associated functions. The 
hierarchical  way  using  the  SysML  block  definition  extension  of  the  model  is  then  implemented  on  SysML 
diagram  (BDD).  This  is  shown  in  Fig.2  where  the  blocks  to  design  the  Simulink‐  and  Simscape‐compatible 
‘ClosedLoopSystem’  block  is  viewed  as  a  basis  for  the  models.  Thus,  a  set  of  new  stereotypes  is  defined  to 
simulation of the main structure of the system. As we can  associate  the  SysML  constructs  with  the  new  model 
see, the ‘ClosedLoopSystem’ block is composed of one or  element  capability.  As  a  result,  the  design  and  analysis 
more  ‘SimulinkSubsystem’,  and  one  or  more  models  of  the  system  are  prepared  and  we  apply  the 
‘SimscapeSubsystem’.  Note  that  the  subsystem  block  is  physical  system  modelling  approach  to  construct  an 
directly composed to the system block by using the black‐ energy‐flow  physical  system  network.  The  physical 
diamond‐arrow  relation.  Down  to  the  component  level,  modelling  network  is  considered  as  a  group  of 
the  ‘SimulinkSubsystem’  is  made  up  of  zero  or  more  interrelated  subsystems  and/or  components  that  are 
‘Input’  and  one  or  more  ‘Controller’  blocks.  The  linked to one another through their energy ports [25].  
‘SimscapeSubsystem’  is  made  up  of  one  ‘Body’,  one  or 
more  ‘Actuator’,  one  or  more  ‘Sensor’  and  zero  or  more  4.1 SysML‐Simulink Model Compatibility  
‘Kinematics’ blocks. 
In  this  subsection,  the  definition  of  the  SysML‐Simulink 
«block» compatibility  model  is  illustrated      with  regards  to  the 
ClosedLoopSyst em
input and controller components.  
::SimulationContext::

4.1.1 SimulinkBlock (SB) Stereotype 
subsys1 1..* subsys2 1..*

«block» «block» This  section  briefly  describes  the  concept  of  the  SysML 
SimulinkSubsyst em SimscapeSubsystem
model  extension  in  defining  the  SysML‐Simulink 
comp1 * comp2 1..* comp3 1 comp4 * comp5 1..* comp6 1..*
compatible model. As mentioned earlier in section 4, it is 
«block» «block» «block» «block» «block» «block»
based  on  the  stereotype  mechanism  that  tailors  the 
Input Controller Body Kinematics Sensor A ctuator SysML  meta‐model  to  create  a  new  model  element.  The 
  concept  of  meta‐modelling  is  briefly  described  in  [24]. 
Figure 2. Conceptual system definition view  The  element  that  needs  to  be  stereotyped  is  a  standard 
SysML block taken from the meta‐model. Fig.3 shows the 
The  SysML  descriptive  model  needs  to  be  defined  as  definition  of  a  new  stereotype  extended  to  support 
executable models, which can then be translated into the  Simulink  models.  It  introduces  two  blocks  associated 
analysis model for use in the simulation tool. Toward this  with a specialization relation (the solid arrow), known as 
end,  SysML  model  definition  and  its  semantic  extension  the extension relationship, (e.g., <<extend>>). It should 
should  be  done  in  order  to  support  the  behavioural  be  noted  that  the  standard  SysML  block  now  becomes  a 
design models and the integration of a simulation model.  special  block  that  happens  to  be  a  Simulink  reference 
For extension of the SysML model, we use the stereotype  model  representation.  Specifically,  the  semantics  of  the 
mechanism [21, 24]. The stereotype mechanism is widely  SB, when it is applied to a SysML block, will be referred 
adopted to semantically extend the SysML model and is a  to  a  Simulink  model  encapsulation.  Therefore,  the  SB 
powerful  way  to  define  a  new  SysML  model  element  by  represents  a  wrap  model  in  Simulink.  Apart  from 
tailoring  the  UML  meta‐model  [24].  Stereotypes  are  semantic  extension,  the  SB  stereotype  declares  tagged 
visually spotted by looking at the keyword within a set of  values  with  which  to  indicate  auxiliary  properties  of  the 
double chevrons (e.g., <<stereotype>>).  Simulink  model.  For  example,  the  ‘URI’  property  that 
  provides  a  link  to  the  Simulink  model  files.  Optionally, 
A model semantic extension can be carried out using two  tagged  values  can  be  used  to  add  information  to  the 
techniques  [14]:  either  the  “heavy‐weight”  or  the  “light‐ model base, specific to the domain or platform [26].  
weight”  approach.  By  comparison,  the  first  approach   
develops  totally  new  constructs  for  the  SysML  profile,  Fig.4  shows  a  BDD  that  illustrates  the  “Input”  and 
while  the  second  technique  simply  creates  a  new  profile  “Controller”  blocks.  As  we  can  see,  both  components 
of  stereotypes  based  on  the  UML’s  meta‐class  for  apply  the  SB  stereotype.  Equations  (7)‐(8)  are  properly 
extending  the  SysML  model  element  [20].  However,  the  described in the “Controller” block (shown by the use of 
first method requires a distinctive tool to support the new  the  stereotype,  <<Algorithm>>)  along  with  its  gain 
construct  [21].  For  this  reason,  we  apply  the  second  parameters,  error  variables  (shown  by  the  stereotype, 

4 Int J Adv Robotic Sy, 2013, Vol. 10, 112:2013 www.intechopen.com

<<Error>>)  and  data  ports,  while  the  system  input  element.  The  latter  model  type  is  used  to  define  the 
information is appropriately defined in the “Input” block  physical  component  that  users  intend  to  model  in 
which  consists  of  input  variable  values  and  a  single  corresponding  to  the  Simscape  block  (e.g.,  resistors, 
output data port.    capacitors,  inductors,  and  etc).  It  is  essential  to 
understand  the  basic  file  format  for  the  domain  and 
«block» component  models.  Examples  of  both  domain  and 
SysML
component files are shown below: 
 
<<extend>> 1. The domain model for RotationaL.ssc 
«S tereoty pe»
 
SimulinkBlock domain RotationaL %Declaration section
  variables
Figure 3. Definition of SB  w = {1,‘rad/s’};%Across variable
end
«block,S imulinkBlock» «block,S imulinkBlock» variables
Input Controller
t = {1,‘N*m’};%Through variable
Values
Values end
«Input» xd:real_T=m «Error» ex:real_T
end
«Input» yd:real_T=m «Error» ey:real_T
«Input» thetad:real_T=rad «Error» etheta:real_T
«Gain» K1:real_T
Ports «Gain» K2:real_T 2. The component model for sensor.ssc 
out:real_T «Gain» K3:real_T  
component sensor %Declaration section
Ports
in:real_T nodes
theta:real_T R = CLib.RotationaL;%Energy port
ul:real_T T = CLib.TranslationaL;%Energy port
ur:real_T end
x:real_T
y:real_T
outputs
Constraints
S = {0,‘m’};%Signal port
«Algorithm» {ul = [K1,K2,K3]*[ex;ey;etheta]};
A = {0,‘rad’};%Signal port
«Algorithm» {ur = [K1,K2,K3]*[ex;ey;etheta]};
end
 
parameters
Figure 4. Simulink‐related model definition in SysML  Init_theta = {0,‘rad’};%Initialize
Init_s = {0,‘m’};%Initialize
The  constraint  compartment  can  be  used  to  describe  end
system  equations  either  in  the  continuous  or  discrete 
behaviour.  Note  that  not  only  a  model  element  is  variables
extended  but  also  all  the  information  contained  in  the  w = {0,‘rad/s’};%Across var
v = {0,‘m/s’};%Across var
block.  For  example,  the  stereotype,  <<Gain>> emulates  theta = {0,‘rad’};%Across var
the  tunable  parameters  of  the  controller  while  the  ports  s = {0,‘m’};%Across var
extend the standard SysML flow port applicable to the in‐ end
port and out‐port of the Simulink‐compatible model.  The 
function setup %Implementation section
data  type  is  assigned  as  the  real  value,  for  example, 
across(w, R.w,[]);
“real_T”.  across(v, T.v,[]);
s = init_s;
4.2 SysML‐Simscape Model Compatibilty  theta = init_theta;
end
4.2.1 Simscape Language Overview 
equations
In  this  section,  we  give  an  overview  of  the  Simscape  s.der == T.v;
language.  We  use  the  Simscape  language  to  customize  S == s; %Displacement measure
theta.der == R.w;
our  system  components  rather  than  using  an  existing  A == theta; %Angle measure
Simscape  foundation  library.  Basically,  there  are  two  end
model  types,  the  domain  and component  files,  available  in  end 
the Simscape language [27]. The former is used to define   
the  physical  system  domain  (e.g.,  electrical,  rotational,  A  Simscape  file  separates  the  model  description  into  the 
translational,  hydraulic,  etc)  and  corresponds  to  the  port  following  properties:  the  declaration  and  implementation 
types, in which the component exchanges the energy‐type  sections.  The  declaration  section,  which  imitates  the 

www.intechopen.com Mohd Azizi Abdul Rahman and Makoto Mizukawa: Model-Based Development and Simulation 5
for Robotic Systems with SysML, Simulink and Simscape Profiles
 Matlab  class  declaration  method,  includes  member  between  the  function  setup  process  and  the  variable 
classes  such  as  nodes,  inputs  and/or  outputs,  parameters,  initialization  process.  For  example,  the  constraint  “R.w
and  variables  for  both  domain  and  component  files.  Note  == theta.der”,  represents  the  time  derivative  of  the 
that  for  the  domain  file,  only  variables  and  sometimes  orientation  angle,  which  gives  a  solution  to  the  angular 
parameters (optional) are declared so that their function is  velocity  variable,  on  the  other  hand,  the  constraint 
to  establish  a  domain  rather  than  a  detailed  component.  “theta == init_theta”, declares the initial condition 
In  contrast,  the  implementation  section  includes  only  the  setup  for  the  orientation  angle.  In  Fig.6,  the  kinematics, 
setup  function  and  equations  for  the  component  file.  In  the  actuator  and  sensor  blocks  are  stereotyped  with 
setup function, the component is prepared for simulation  <<Comp>> similar to the ‘Body’ block. The kinematics for 
and  it  is  executed  once  for  each  component  during  the  the  system  is  described  based  on  equations  (5)  and  (6). 
model  compilation  process  whereas  the  equations  section  The  actuated wheels  receive  control outputs  through  the 
declares  the  component  equations  that  are  executed  signal  ports  (i.e.,  tr  and  tl),  and  apply  the  torque  to  both 
throughout  the  simulation.  Therefore,  the  implementation  wheels of the robot via the energy port, T. The sensor can 
section is utilized to establish an equation‐based internal  be  used  to  detect  the  state  variables  changes,  and  send 
behaviour  of  the  system.  More  detail  on  the  Simscape  them  as  data  via  the  signal  port.  For  the  Simscape 
model structure, can be found in references [7] and [27].  subsystem  block,  the  stereotype  <<SimscapeBlock>> 
  (see Fig.8) is introduced as an extended SysML block that 
Although  Simscape  is  conceptually  more  specific  to  the  applies  the  same  concept  and  property  for  the  SB. 
physical  system  theory,  it  can  fit  to  the  general  concept  Therefore, all Simscape‐related blocks can also apply the 
used  in  Matlab/Simulink.  Thus,  it  allows  for  Simscape  SB stereotype. 
models  to  be  combined  with  other  models  in  the  same 
«Domain» «Domain»
Simulink environment.   Ro tat io na L T r a nsla tiona L

Attributes Attributes
4.2.2 SysML Model Extension for Simscape  
«Through» t:real_T=N*m «Through» f :real_T=N
«Across» w:real_T=rad/s «Across» v :real_T=m/s
The  SysML  block  is  again  semantically  extended  to 
represent  the  domain  and  component  model  in  Simscape.  «bl ock,Comp»

Since  the  domain  model  has  no  internal  behaviour,  the  B ody

stereotype  <<Domain>> is  newly  defined  relative  to  its  Values

«Nodes» RotationaL:real_T=R
semantics  [14].  Fig.5  illustrates  the  newly  defined 
«Nodes» TranlationaL:real_T=T
‘TranslationaL’ and ‘RotationaL’ domains, and the ‘Body’ 
«Parameters» m:real_T=k g
component  block.  The  physical  component  is  clearly  «Parameters» rc:real_T=m
defined by the stereotype, <<Comp>>. «Parameters» wd:real_T=m
  «Parameters» Ib:real_T=k gms^2

A  SysML  block  has  value  properties,  which  are  referred  «Init» init_s:real_T=m
«Init» init_theta:real_T=rad
to  as  value  types.  These  are  utilized  to  define  system 
«Across» w:real_T=rad/s
variables,  parameters,  constants  and  other  properties  of  «Across» v :real_T=m/s
component  models  in  Simscape.  The  stereotypes  such  as  «Across» s :real_T=m
<<Across>> and  <<Through>>  are  created  for  «Across» theta:real_T=rad

physical  system  domain  variables  [25],  and  to  «Through» f :real_T=N

«Through» t:real_T=Nm
differentiate  variables  among  other  common  properties. 
For  example,  the  stereotype  named  <<Parameters>>  Ports
defines  the  mass  property  of  the  physical  component  energy port_R:in_out
with the value type, kilogram.   energy port_T:in_out

  Constraints
The  nodes,  inputs  and  outputs  of  the  component  are  «Setup» through(f ,T.f ,[ ]);
modelled  by  utilizing  the  SysML’s  flow  port.  In  SysML,  «Setup» through(t,R .t,[ ]);
the  ‘eneryport’  is  defined  to  replicate  the  Simscape  bi‐ «Setup» ac ross(v ,T.v ,[ ]);

directional  conserving  port  which  allows  only  energy‐ «Setup» ac ross(w,R .w,[ ]);
«Setup» s = init_s ;
based elements to pass through it. It is based on the non‐
«Setup» theta = init_theta;
atomic  flow  port  where  multiple  items  can  exchange  «Equations» T.v = = s.der;
energy through the ports. As mentioned in 4.2.1, the setup  «Equations» R.w = = theta.der;
and  equations  properties  are  for  the  implementation  part  «Equations» m*T.v .der = = f ;

of  the  Simscape  model.  They  are  represented  as  «Equations» 2*Ib*rc *R.w.der/wd = = t;

constraints in SysML and describe the syntax with which   
the  attributes  of  objects  should  comply.  Thus,  the  Figure 5. Definition of Simscape domain models and the body 
stereotype  <<Init>>  has  been  defined  to  distinguish  component 

6 Int J Adv Robotic Sy, 2013, Vol. 10, 112:2013 www.intechopen.com

The  syntax  used  in  the  setup  function  and  the  equation  corresponding  to  the  Simulink  root  block  of  the  system 
section conform to the Simscape language [27]. Note that  that  we  intend  to  simulate.  The  tags  clarify  all  the 
writing the equations with the operator ‘= =’, means that  information  related  to  the  parameter  settings  for  the 
they do not constitute the assignment operator but rather  simulation environment.    
a  symmetrical  mathematical  relationship  exists  between   
both  left‐  and  right‐hand  operands,  and  they  are  Model  composition  is  accomplished  by  linking  every 
evaluated  continuously  throughout  the  simulation  component  in  the  SysML  internal  block  diagram  (IBD). 
process.  Apart  from  that,  the  value  unit  at  both  the  left‐  As seen in Fig.8, the overall system (e.g., remodelled from 
and  right‐hand  sides  must  be  commensurate,  otherwise  the  BDD  in  Fig.2)  is  now  translated  into  the  IBD  (see 
the expression issues an error message. In general, all the  Fig.9).  To  illustrate  the  connection  between  the 
domain.ssc  and  component.ssc  files  are  packaged  into  one  components, we use the standard SysML link to connect 
folder named, for example, +CustomLibrary and are stored  ports  which  have  the  same  type.  Note  that  a  special 
in the Matlab directory. To build the Simscape block, we  connector  for  energy‐based  ports  is  required  to  convey 
need to issue a Matlab command (e.g., ssc_build) to create  energy that conforms to Kirhoff’s law. To achieve this, an 
a  library  for  a  new  set  of  components.  In  our  case,  we  extended  SysML  connector  with  the  stereotype 
utilize  the  Matlab  external  application  programming  <<energyBind>>  is  defined  based  on  the  physical 
interface (API) to invoke a Matlab/Simulink process with  connector in Simscape. It should be borne in mind that it 
the  Matlab  commands  including  the  ssc_build  command  connects  only  ports  with  the  same  domain  and  it  must 
as suggested in [19]. The next section describes how each  conform  to  Kirchoff’s  rule,  i.e.,  each  of  their  across 
of the components is composed to create a network of the  variables  has  a  similar  value,  and  the  sum  of  all  the 
physical system model.   through variables is definitely zero [14].  
«block,C omp» «block,C omp» «block,C omp»
Kinematics Actuator Sensor

Values Values Values

«Nodes» RotationaL:real_T=R «Nodes» RotationaL:real_T=R «Nodes» RotationaL:real_T=R «block»
«Nodes» TranslationaL:real_T=T
«Across» s:real_T=m
«Nodes» TranslationaL:real_T=T
«Parameters» rw :real_T=m
«Nodes» TranslationaL:real_T=T
«Init» init_s:real_T=0m
SysML
«Across» theta:real_T=rad «Through» t:real_T=Nm «Init» init_theta:real_T=0rad
«Init» init_s:real_T=m «Through» f:real_T=N «Across» s:real_T=m
«Init» init_theta:real_T=rad «Across» theta:real_T=rad

Ports
Ports
Ports
<<extend>>
energyport_R:in_out
energyport_R:in_out energyport_R:in_out
energyport_T:in_out
energyport_T:in_out energyport_T:in_out
signalport_tl:In
signalport_x:Out signalport_A:Out «Stereotype»
signalport_tr:In
signalport_y:Out signalport_S:Out StructuredSimulinkBlock
Constraints
Constraints Constraints
«Setup» across(v,T.v,[ ]);
«Setup» through(f,[ ],T.f);
«Setup» s = init_s; Tags
«Setup» through(t,[ ],R.t);
«Setup» across(w ,R.w ,[ ]); «Setup» theta = init_theta;
«Setup» s = init_s;
«Equations» f = = (tr+tl)/rw ;
«Equations» t = = (tr - tl);
«Equations» theta.der = = R.w ; DiagramForSimulink:RhpString
«Setup» theta = init_theta; «Equations» s.der = = T.v;
«Equations» T.v = = s.der; «Equations» A = = theta;
MatlabExePath:RhpString
«Equations» R.w = = theta.der;
«Equations» x = = s*cos(theta);
«Equations» S = = s;
Parameters:RhpString
«Equations» y = = s*sin(theta);
SampleTime:RhpString=0.01
  SolverName:RhpString
Figure 6. Definition of kinematics, actuator, and sensor  SolverType:RhpString
components  StartTime:RhpString=0.0
StopTime:RhpString=10.0
4.3 System‐level Model Composition 

In  this  subsection,  the  entire  design  model  is  assembled 

 
by  joining  the  Simulink  and  Simscape  models  to  build  a 
physical network model.  Figure 7. Definition of SSB 

4.3.1 StructuredSimulinkBlock (SSB) Stereotype 
«block,StructuredSimulinkBlock»

Another  SysML  semantics  extension  is  required  to  ClosedLoopSyst em

create a new model element with which to represent the  ::SimulationContext::

composition model of the main structure (i.e., the entire 
subsys1 1..* subsys2 1..*
closed‐loop system). The Simulink and Simscape models 
«block,Simulink Block» «block,SimscapeBlock»
need  to  be  encapsulated  as  parts  of  the  main  structure  SimulinkSubsyst em SimscapeSubsystem

block.  To  this  end,  a  new  class  model  is  created  to 
represent another Simulink sub‐model. Fig.7 introduces  comp1 * comp2 1..* comp3 1 comp4 * comp5 1..* comp6 1..*

the  definition  of  the  SSB  which  is  extended  from  the  «block,Comp»
Input
«block,Comp»
Controller
«block,Comp»
Body
«block,Comp»
Kinematics
«block,Comp»
Sensor
«block,Comp»
A ctuator
standard  SysML block  applicable  to  a  new  class  model.   
In  this  case,  the  SSB  applies  the  tagged  value  Figure 8. A remodelled BDD with the new stereotypes applied 

www.intechopen.com Mohd Azizi Abdul Rahman and Makoto Mizukawa: Model-Based Development and Simulation 7
for Robotic Systems with SysML, Simulink and Simscape Profiles
 ibd [«StructuredSimulinkBlock» block] ClosedLoopSystem [Simulation Context]

1..* subsys1:SimulinkSubsystem 1..* subsys2:SimscapeSubsystem

dataport_uL 1..* comp6:Actuator

dataport_uL
ul:real_T
signalport_tl
* comp1:Input 1..* comp2:Controller dataport_uR
dataport_uR
signalport_tr
* comp4:Kinematics
energyport_T energyport_R
ur:real_T
in:real_T
out:real_T energyport_T energyport_R
energyport_T
1 comp3:Body

energyport_R «energyBind»

signalport_x signalport_y
theta:real_T y:real_T x:real_T 1..* comp5:Sensor
dataport_x dataport_x
energyport_T
energyport_R
dataport_y dataport_y

dataport_A signalport_A
dataport_theta

dataport_S signalport_S

 
Figure 9. IBD showing the connection of components and subsystems.

In  Fig.8,  the  ‘ClosedLoopSystem’  block  is  stereotyped  «block,S tructuredS imulinkBlock» «block,spsC onv erter»
ClosedLoopSystem
with the SSB. The IBD represents the internal connection  S_PS
1..*
of  the  system  behaviour.  Furthermore,  the  IBD  shows  ::SimulationContext:: sps Ports

every  single  component  of  the  subsystem  as  part  of  the  in:In
out:Out
properties  of  the  ‘ClosedLoopSystem’  block.  By  Tags
definition,  the  IBD  clearly  illustrates  the  logical  view  of  DiagramForSimulink:RhpString «block,pssC onv erter»
the  entire  system  composition.  However,  it  may  be  seen  MatlabExePath:RhpString PS_S
Parameters:RhpString=step-size
as  a  static  view  unless  the  system  behaviour  can  be  1..* Ports
SampleTime:RhpString=0.01 pss
executed. Toward  this  end,  the  simulation model  should  SolverName:RhpString=ode15s
in:In
out:Out
be designed for a complete execution of the model.   SolverType:RhpString=variable-step
  StartTime:RhpString=0.0
«block,solv er»
StopTime:RhpString=10.0 solver
4.3.2 SysML‐based Simulation Model  1
Solver

Ports
A  simulation  can  be  used  to  anticipate  the  behaviour  of  energyport:in_out
scope
the  system  to  evaluate  its  performance.  In  SysML,  a 
construct  for  modelling  simulation  information  is  not  «block,scope»
1..* Scope
explicitly  provided;  thus  a  method  for  establishing  the 
Ports
simulation  information  is  needed  to  set  up  the 
IN:In
configuration in the Simulink environment. According to   
Cao  et  al.,  the  simulation  process  in  Simulink  has  four  Figure 10. Simulation model in SysML 
steps  [14]:  (1)  System  design  modelling,  in  which  every 
element is defined as standard Simulink and/or Simscape   
blocks  and  then  the  components  are  composed  in  the  For  this  study,  steps  (1)‐(3)  are  explicitly  modelled  in 
Simulink  diagram  by  connecting  them.  (2)  Auxiliary  SysML  in  order  to  prepare  the  system‐level  simulation 
elements  for  simulation  modelling,  for  instance,  the  model.  It  is  worth  noting  that  at  least  one  local  solver 
Simulink  scope  component  that  can  be  used  to  monitor  needs  to  be  configured  for  each  simulation  in  Simscape 
the  variable  changes.  (3)  Simulation  parameters  and  it is  manually  added  by the  designers. In  Fig.10,  we 
configuration.  This  task  must  be  done  to  set  up  the  make  up  some  new  blocks  such  as  the  ‘S_PS’  and  ‘PS_S’ 
simulation  parameters  or  simply  a  global  solver.  (4)  converters,  the  ‘Solver’  and  the  ‘Scope’  in  order  to 
Lastly, the execution of the simulatable model. In step (2),  illustrate the auxiliary elements of the simulation model. 
we model the simulation‐related components such as the  The  block  ‘ClosedLoopSystem’  shows  the  global 
scope,  local  solver  and  Simulink‐Simscape  signal  simulation  settings.  Asides  from  the  start/stop  time,  the 
converters.   solver  name  and  its  type  also  need  to  be  defined.  In 
 

8 Int J Adv Robotic Sy, 2013, Vol. 10, 112:2013 www.intechopen.com

 ibd [«StructuredSimulinkBlock» block] ClosedLoopSystem [Simulation Context]

1..* subsys1:SimulinkSubsystem 1..* subsys2:SimscapeSubsystem

dataport_x 1..* :Actuator in 1 :PS_S out dataport_x

in 1 :S_PS out
signalport_tr
x:real_T 1..* :Controller
dataport_uR dataport_uR
ur:real_T
in 1 :S_PS out dataport_y
* :Inp signalport_tl in 1 :PS_S out
out:real_T in:real_T energyport_R energyport_T

dataport_uL «energyBind»
ul:real_T
* :Kinematics
dataport_uL
dataport_y 1 :Body energyport_T
y:real_T
energyport_T signalport_x 1..* scope
in 1 :PS_S out
energyport_R energyport_R IN
signalport_y
dataport_A
theta:real_T

1 :Solver
«energyBind»
energyport
energyport_T energyport_R
1..* :Sensor dataport_S
signalport_A

dataport_theta
signalport_S

 
Figure 11. IBD for the simulation context 

SysML,  the  block  ‘Solver’  represents  a  local  simulation  simulatable component (e.g., “ClosedLoopSystemComp”) 

solver.  The  blocks  such  as  ‘S_PS’  and  ‘PS_S’  are  used  as  and  each  component  contains  several  configuration  files.  It 
intermediate  elements,  which  alter  the  Simulink  data  to  is  used  to  build  and  simulate  the  model  [26].  The 
the  Simscape  physical  signal  and  vice  versa.  To  display  configuration  file  includes  a  description  of  the  classes  of 
the  simulation  output,  we  create  the  scope  block  as  the code generation and several settings for building the 
having  a  single  input  data  port.  It  can  be  used  to,  for  model. Therefore, it must be set to an active mode.  
example,  identify  the  value  of  the  orientation  angle  and   
display it to engineers for analysis. Fig. 11 shows the IBD  The  SysML  model  file  (.rpy),  Simulink  model  file  (.mdl) 
of the whole system and it is ready to be executed.   and  Simscape  model  file  (.ssc  file  is  wrapped  to  be  .mdl) 
are  imported  into  the  RSI  engine,  and  a  series  of  Matlab 
5. Design and Simulation Models in Sync   commands (e.g., create_model.m) is then generated to build 
the full‐featured simulatable model. The RSI framework is 
5.1 Model Integration Workspace 
developed  to  use  the  java‐based  plugin  (i.e.,  a  plugin  for 
This  section  describes  how  SysML’s  design  models  and  Rhapsody), in which the java class and interface are used to 
its  simulation  models  can  be  integrated  and  synced.  We  access the Rhapsody data (e.g., model elements, classes, the 
implement a plugin‐based plant integration workspace in  SysML  port,  etc).    The  plugin  project  file  is  then 
Rhapsody®  [26],  which  is  a  development  framework  for  compressed  into  a  java  archive  (e.g.,  ‘.jar’)  for  the  RSI 
systems engineers to improve collaborative designs using  engine. The whole sync process is shown in brief in Fig.12.  
Rhapsody®‐Simulink® integration (RSI). In other words,  «block,framew ork»
RSI
tools  integration  between  Rhapsody®  and  Simulink™  1 SysML 1 Rhapsody COM API 1 Simulink_Simscape
can be achieved.  Attributes Attributes MDL:RhpString=.mdl

 
RPY:RhpString=.rpy java_lib:RhpString=rhapsody.jar SSC:RhpString=.mdl

Operations
Operations
In  SysML,  multiple  Simulink  and  Simscape  models  are 
Operations
export():void
export():void export():void

encapsulated  and  be  referenced  as  a  Simulink  diagram  in_out in_out in_out

which  can  interact  with  the  Rhapsody  objects,  parts,  or 

INOUT

other  Simulink  blocks  [28].  Briefly,  a  builder  class  inOut

1 Plugins
InOut
Operations
containing  part  of  the  Rhapsody  and  Simulink  blocks  is  sync():void
build():void
created and from this builder class, a model file (e.g., the 
inout
‘.mdl’ file) can be created in which the SysML blocks are  IO
Components
referenced  to  the  Matlab  S‐function.  Consequently,  (1)  a 
1

Attributes
create_model mdl
simulation  component  package,  and  (2)  its  relative  Configurations:RhpString

Operations

configuration  files  are  then  created  to  prepare  for  the  create():void
:Simulink Env
model  execution.  In  Rhapsody,  the  simulation  component   
setup  is  a  level  of  organization  which  defines  the  Figure 12. SysML‐Simulink Model Integration 

www.intechopen.com Mohd Azizi Abdul Rahman and Makoto Mizukawa: Model-Based Development and Simulation 9
for Robotic Systems with SysML, Simulink and Simscape Profiles
 5.2 Implementation and Discussion  output  responses  for  a  variety  of  controller  coefficients 
tuning  exercises.  As  for  comparison,  the  controller  can 
To validate  our  work, these  models  have to  be  executed in  compensate  the  orientation  error  efficiently  and  settle  to 
order to see if the system performs as expected. To this end,  an acceptable setpoint in a short time. It should be borne 
the  system  design  model  (see  Fig.8)  and  the  simulation  in  mind  that  the  results  are  shown  just  to  prove  the 
model (see Fig.11) are evaluated. Once the model integration  practical  use  of  our  system‐level  design  framework  and 
process  is  completed,  the  Simulink‐  and  Simscape‐
methodology.  For  more  simulation  and  analysis, 
subsystem  models  can  be  generated  by  applying  the 
engineers have the option of manipulating other variables 
‘generate and simulate’  function    available  in  the 
or parameters within the system. 
Rhapsody context menu. The execution process is shown in   

the  Matlab  command  window  and  the  generated  model 

(e.g.,  “ClosedLoopSystem.mdl”)  is  auto‐simulated  in  the 
Simulink environment. If changes are made to the generated 
model,  it  will  be  automatically  synced  with  the  updated 
version. The generated model is depicted in Fig.13.  
 
In Fig.14, the simulation results are obtained for a simple 
system  analysis.    The  results  show  a  series  of  system 
responses to the robot orientation angle in setpoint when 
the  robot  mass  is  3.76kg,  and  the  desired  input  is  set  to 
(xd, yd, θd) = (0.25m, 0.25m, π/4rad). Simulation results in 
Fig.14 (a‐f) depict the orientation angle when parameters 
such  as  Ib,  rc,  wd,  and  rw  were  fixed  to  0.01kgm2,  0.04m,   
0.091m, and 0.032m respectively. The results demonstrate  Figure 13. Auto‐generated model in the Simulink window 

(a) (b) (c)

(d) (e) (f)

 
Figure 14. Simulation results via scopes

10 Int J Adv Robotic Sy, 2013, Vol. 10, 112:2013 www.intechopen.com

6. Conclusion  Tokyo  for  their  constructive  comments  and  fruitful 
discussion.  We  also  would  like  to  thank  Danai 
In  this  paper,  we  attempted  to  develop  a  different  Phaoharuhansa  and  Prof.  Akira  Shimada  who  have 
perspective for system‐level design and simulation models  helped in the technical discussion. 
especially  for  robotics  by  using  the  SysML  (as  the  front‐
end),  Simulink  and  Simscape  profiles.  For  this  approach,  8. References 
the  SysML  design  model  and  the  Simulink/Simscape‐
compatible models were created, synced and generated to  [1]  C. Schlegel, A. Steck, D. Brugali and A. Knoll, “Design 
carry  out  the  simulation  automatically.  This  preliminary  Abstraction  and  Processes  in  Robotics :  From  Code‐
effort can assist system designers and control engineers in  Driven to Model‐Driven Engineering,” Proceedings of  
collaborating  as  a  team,  from  the  first  until  the  last  of  the  Simulation, Modeling and Programming for Autonomous 
development  stages,  in  order  to  speed  up  the  design  and  Robots (SIMPAR), Darmstadt, 2010, pp. 324‐335. 
testing processes.   [2]  J. Fisher, “Model‐Based Systems Engineering : A New 
  Paradigm,” INCOSE Insight, vol. 1(3), pp. 3‐16, 1998. 
In  our  method,  the  Simulink‐compatible  model  was  first  [3]  S.A.  Friedenthal,  “SysML:  Lessons  from  Early 
defined to represent the continuous‐time behaviour of the  Applications  and  Future  Directions,”  INCOSE 
physical  system.  A  method  for  extending  the  SysML  Insight, vol. 12(4), pp. 10‐12, 2009. 
semantics  was  then  adopted  to  create  a  new  set  of  [4]  Object  Management  Group.  (2010).  Systems  Modeling 
stereotypes  and  their  tagged  values.  This  was  done  by  Language Specification. Available:  
extending the standard SysML block in conjunction with    http://www.omg.org/spec/SysML/1.2/pdf/ 
its  behavioural  model.  We  introduced  the  SB  and  SSB  [5]  Object  Management  Group.  (2010).  Unified  Modeling 
stereotypes to correspond to the standard Simulink block  Language Specification. Available:  
diagram and the Simulink environment respectively.    http://www.omg.org/spec/UML/2.3/pdf/ 
  [6]  T.A.  Johnson,  Integrating  Models  and  Simulations  of 
Secondly, to enable an automatic simulation, we defined a  Continuous  Dynamic  System  Behaviour  into  SysML 
SysML‐based  simulation  model  for  use  in  the  Simulink  (Masters  Dissertation  of  Georgia  Institute  of 
environment. The simulation modelling approach has been  Technology). Atlanta: Georgia, 2008. 
proposed  to  model  the  simulation‐related  components  [7]  MathWorks  Inc.  (2011).  Simscape  Language 
such as the signal converter, the local solver, the scope and  Fundamental. Available: 
the  simulation  parameters  setting.  Note  that  the  physical    http://www.mathworks.com/help/toolbox/physmod/
system  modelling  is  not  a  trivial  matter  because  if  the  simscape/simscape_language.pdf/ 
physical  model  is  too  concrete,  then  the  simulation  and  [8]  MathWorks  Inc.  (2011).  Simulink.  Available: 
design space exploration become expensive and it can even  http://www.mathworks.com/products/simulink/ 
be  difficult  to  detect  problems.  Therefore,  an  abstract  [9]  IBM Corporation. (2011). Rational® Rhapsody® Version 
model  is  more  preferable  during  the  conceptual  stage  of  7.6. Available: 
development; however abstraction of real physical systems    http://www.ibm.com/developerworks/rational/librar
needs  deep  understanding  of  the  physical  phenomenon  y/rhapsody_release‐v7.6/release.html/ 
[19].  For  this  study,  we  attempt  to  provide  a  specific  [10] H.  Bruyninckx,  “Robotics  Software :  The  Future 
SysML‐based  model  profile  for  the  design  and  simulation  Should  Be  Open,”  IEEE  Robotics  &  Automation 
of  robotic  systems.  However,  this  paper  considers  only  Magazine, vol. 15(1), pp. 9‐11, 2008. 
modelling  and  simulation  works  restricted  to  the  [11] S.  Chhaniraya,  C.  Saaj,  M.  Althoff‐Kotzias,  I.  Ahrns 
MathWorks tools. In the future, we intend to evaluate our  and  B.  Maediger,  “Model  Based  System  Engineeing 
design  models  based  on  different  modelling  and  for  Space  Robotics  Systems,”  Proceedings  of  
simulation tools. Apart from that, we plan to integrate the  Symposium  on  Advanced  Space  Technologies  in  Robotics 
system‐level  design  and  analysis  models  using  SysML’s  and Automation, Noordwijk, 2011. 
parametric diagram for engineering analysis. 
[12]M.A.  Abdul  Rahman,  et  al.,  (2011).  Model‐Driven 
 
Development  of  Intelligent  Mobile  Robot  Using  Systems 
At the time of writing this paper, we are in the process of 
Modeling  Language  (SysML).  Mobile  Robots  ‐  Control 
developing  a  unified  modelling  framework  for  a 
Architectures,  Bio‐Interfacing,  Navigation,  Multi  Robot 
comprehensive system and software design applicable to 
Motion  Planning  and  Operator  Training,  Dr.  Janusz 
robotics, something which is considered rare.    
Bȩdkowski  (Ed.),  ISBN:  978‐953‐307‐842‐7,  InTech. 
7. Acknowledgments   Available: http://www.intechopen.com/books/mobile‐
robots‐control‐architectures‐bio‐interfacing‐
The  usage  of  Rational®  Rhapsody®  software  is  navigation‐multi‐robot‐motion‐planning‐and‐
supported by the IBM® Academic Initiative collaboration  operator‐training/model‐driven‐development‐of‐
program.  The  authors  wish  to  express  their  gratitude  to  intelligent‐mobile‐robot‐using‐systems‐modeling‐
Hiroshi  Ishikawa  and  Takashi  Sakairi  of  IBM  Research‐ language‐sysml‐ 

www.intechopen.com Mohd Azizi Abdul Rahman and Makoto Mizukawa: Model-Based Development and Simulation 11
for Robotic Systems with SysML, Simulink and Simscape Profiles
 [13] K.  Ohara,  T.  Takubo,  Y.  Mae  and  T.  Arai,  “SysML‐ [22] S. Bensalem, F. Ingrand and J. Sifakis, “Autonomous 
Based Robot System Design for Manipulation Tasks,”  Robot  Software  Design  Challenge,”  Proceedings  of 
Proceedings  of    Intl.  Conf.  on  Advanced  Mechatronics,  Sixth  IARP‐IEEE/RAS‐EURON  Joint  Workshop  on 
Osaka, 2010, pp. 522‐527.  Technical  Challenge  for  Dependable  Robots  in  Human 
[14] Y.  Cao,  Y.  Liu  and  C.J.J.  Paredis,  “System‐Level  Environments, Pasadena, 2008. 
Model  Integration  of  Design  and  Simulation  for  [23] R.  Siegwart,  I.R.  Nourbakhsh  and  D.  Scaramuzza, 
Mechatronics  Systems  Based  on  SysML,”  Introduction  to  Autonomous  Mobile  Robots :  Intelligent 
Mechatronics, vol. 21(6), pp. 1063‐1075, 2011.  Robotics  and  Autonomous  Agents  series,  2nd  Edition. 
[15]  T.A. Johnson, C.J.J. Paredis, R. Burkhart and J.M. Jobe,  Massachusetts: The MIT Press, 2009. 
“Modeling  Continuous  System  Dynamics  in  SysML,”  [24] J.  Holt  and  S.  Perry,  SysML  for  Systems  Engineering: 
Proceedings  of  ASME  Intl.  Mechanical  Engineering  Professional  Applications  of  Computing  series,  1st 
Congress and Exposition, Seattle, 2007, pp. 1‐9.  Edition. London: The IET, 2007. 
[16] T.A.  Johnson,  C.J.J.  Paredis  and  R.  Burkhart,  [25] J.V.  Amerongen  and  P.  Breedveld,  “Modeling  of 
“Integrating  Models  and  Simulations  of  Continuous  Physical  Systems  for  The  Design  and  Control  of 
Dynamics into SysML,” Proceedings of  Modelica Conf.,  Mechatronic  Systems :  IFAC  Professional  Brief,” 
Bielefeld, 2008.  Annual Reviews in Control, vol. 27(1), pp. 87‐117, 2003. 
[17] Modelica  Association.  (2011).  Modelica  Language.  [26] IBM  Corporation.  (2010).  Rational®  Rhapsody®  User 
Available: http://www.modelica.org/  Guide. Available:  
[18]  Y.  Venderperren  and  W.  Dehaene,  “From    http://publib.boulder.ibm.com/infocenter/rsdp/v1r0m
UML/SysML  to  Matlab/Simulink :  Current  State  and  0/topic/com.ibm.help.download.rhapsody.doc/pdf75/
Future Perspectives,” Proceedings of Design, Automation  UserGuide.pdf/ 
and Test in Europe (DATE) Conf., Munich, 2006.  [27] MathWorks  Inc.  (2011).  Simscape™  User’s  Guide. 
[19] R.  Kawahara,  et  al.,  “Verification  of  Embedded  Available: 
System’s  Specification  Using  Collaborative  http://www.mathworks.com/help/pdf_doc/physmod
Simulation  of  SysML  and  Simulink  Models,”  /simscape/simscape_ug.pdf/ 
Proceedings  of  Second  Intl.  Conf.  On  Model  Based  [28] X.H.  Liu  and  Y.F.  Cao,  “Design  of  UAV  Flight 
Systems Engineering, Haifa, 2009, pp. 21‐28.  Control  System  Virtual  Prototype  Using  Rhapsody 
[20] S.  Turki  and  T.  Soriano,  “A  SysML  Extension  for  and Simulink,” Proceedings of Intl. Conf. On Computer 
Bond Graphs Support,” Proceedings of Fifth Intl. Conf.  Design and Applications, Qinhuangdao, 2010. 
On Technology and Automation, Thessaloniki, 2005.   
[21] K.  Berkenköutter,  S.  Bisanz,  U.  Hannemann  and  J.   
Paleska,  “HybridUML  Profile  for  UML2.0,”  Int  J   
Softw  Tools  Technol  Transfer,  vol.  8(2),  pp.  167‐176, 
2006. 

12 Int J Adv Robotic Sy, 2013, Vol. 10, 112:2013 www.intechopen.com