SimMechanics, MapleSim

and Dymola: a first look on

three multibody packages
J.J.P. van Boekel
DCT 2009.060

Bachelor Final Project report

Coach(es):

dr. ir. I.J.M. Besselink

Supervisor:

prof. dr. H. Nijmeijer

Technische Universiteit Eindhoven

Department Mechanical Engineering
Dynamics and Control Technology Group
Eindhoven, June 2009

Contents
Abstract

Introduction

1 Building a half-car multibody model

1.1
1.2

Construction of a half-car model . . . . . . . . . . . . . . . . . .

Simulation performance . . . . . . . . . . . . . . . . . . . . . . .

2 Verification & error handling

8
14
16

2.1

Testcase 1: absent connection between joint and car-body . . . .

16

2.2

Testcase 2: mass not specified, equal to zero . . . . . . . . . . . .

18

3 Numerical accuracy

20

3.1

Analytical model . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

3.2
3.3

Simulated model . . . . . . . . . . . . . . . . . . . . . . . . . . .
Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22
25

4 Visualisation of multibody models

27

5 Parametrisation of model variables

30
5.1 Specifying global parameters in Simulink/SimMechanics . . . . . 30
5.2

Specifying global parameters in MapleSim . . . . . . . . . . . . .

31

5.3

Specifying global parameters in Dymola . . . . . . . . . . . . . .

32

5.4

Dymolas Experimentation Package . . . . . . . . . . . . . . . .

32

6 Exporting and interchangeability

35

6.1

MapleSim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

6.2

Dymola . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

7 Closed-loop systems behaviour

38

CONTENTS

8 Dymola Vehicle Dynamics Library

43

8.1
8.2

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adaptability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43
43

8.3
8.4

Visualization . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47
48

9 Conclusion

50

References

53

A SimMechanics windows

54

B MapleSim windows

56

C Dymola windows

59

D MapleSim C-code

65

Abstract
In this report, an comparison between three multibody packages (Simulink/SimMechanics, MapleSim and Dymola) is made in order to check whether or not
MapleSim or Dymola would be an suitable alternative to the now used multibody software SimMechanics. Some important aspects are investigated by using some simple models. A half-car is constructed and analysed from which is
concluded that no big differences in simulation speed are present, but this is
mainly due to the simplicity of the investigated models. Based on two testcases,
an opinion regarding verification and error handling is given. By using a double
pendulum system, a comparison is made based upon the accuracy of all three
packages. This is done by comparing the results that the software gives with
the results of an analytical derived equation of motion. Both MapleSim and
Dymola are offering build-in functionalities for parametrization of model variables which are investigated in this report. It is concluded that most of these
functions could also be accomplished by making a few lines of code in MATLAB. The interchangeability functionalities are also investigated. In MapleSim,
C-code can be exported use in for example MATLAB/Simulink. Dymola offers
a functionality called the DymolaBlock. This block can be used in a Simulink
environment to load a model made in Dymola directly into the Simulink model.
Closed-loop behaviour is checked by means of deliberately miss-aligning two
component of a closed-loop system. It is checked how the software reacts to this
and if and how the error is reported. Finally, the Vehicle Dynamics Library
from Dymola is studied. An example model is investigated and a conclusion
is made regarding adaptability of models. Also, visualization and performance
aspects are discussed.

Introduction
Because of the continuous increase of computer power, the use of simulation
tools is still growing. Multibody software for vehicle dynamics has been gaining
popularity thanks to advantages the use of this type of software brings. Nowadays many companies produce multibody software tools and thanks to this, the
software is still getting better, faster and more reliable.
Until now, Eindhoven University of Technology (TU/e) has primarily been
using the multibody software called SimMechanics which is part of MATLAB/Simulink. This product is very widely used and has a great number of
users around the world. One drawback of SimMechanics is the limited processing speed which makes it nearly impossible to perform real-time simulations.
Another drawback is the lack of modern and fast visualization possibilities. An
overall view concerning SimMechanics is that it lacks development pace over
the past years.
TU/e is exploring alternatives concerning multibody packages that can perform
at least the same tasks as SimMechanics and should be faster regarding computation speeds and offers better possibilities to create code which is used for
real-time capable models. In order to find a possible substitute for SimMechanics, two new multibody packages have been examined.
The first package that is examined and compared to SimMechanics is called
MapleSim (version 1.0). This package is created by the company MapleSoft
and runs on the mathematical engine from Maple (version 12.02). The second
package is called Dymola (version 7.1) and is created by the company Dynasim
AB.
In chapter 1, a simple half-car model is build in all three packages, so that user
friendliness of the software can be examined. Also, different aspects of building
and analyzing a model are treated in this chapter. In chapter 2, the same halfcar model is used to investigate how the packages deal with modelling errors
and how they do inform the user. After this, in chapter 3 a double pendulum
model is constructed. By means of this model, the numerical accuracy of all
three packages is studied. In chapter 4, the visualization possibilities of the
three multibody packages is explored. Chapter 5 deals with the parametrisation
aspect of multibody models. By parametrize specific model variables, a model
can be evaluated by varying some pre-defined model-properties. In chapter 6,
interchangeability is discussed. By exporting models to C-code, this fast and
efficient code can be used to perform for example Hardware In the Loop (HIL)
simulations. Chapter 7 deals with a special but common kind of multibody
5

CONTENTS

systems, so called closed-loop systems. In this chapter we investigate how the

packages deal when components are not fully aligned to each other. Chapter 8
of this report handles the Dymola Vehicle Dynamics Library. Different aspects
of this library are discussed and explained.

Acknowlegments
First of all, special thanks goes to my supervisor Igo Besselink for the help with
the project and creating the report. Furthermore, I want to thank Gos Fischer of CANdiensten, for providing MapleSim and helping me with problems or
questions about MapleSim. Also I want to thank Mike Dempsey of Claytex Services Limited for providing Dymola and helping me with problems or questions
concerning Dymola and the Vehicle Dynamics Library.

Disclaimer
This report is the work of a Bachelor student and does not necessarily
reflect the opinion of the Eindhoven University of Technology in general. The student has previous experience with MATLAB/Simulink,
but no experience with SimMechanics, MapleSim or Dymola at the
start of the project. The student has spent about 15 weeks to study
the different packages and to do the analysis described in this report.

Chapter 1

Building a half-car multibody

model
In this chapter we will consider how models are constructed in both Simulink/SimMechanics, MapleSim and Dymola. In the first section of this chapter, the
Modelica Language is discussed. This language is used to construct models in
both MapleSim and Dymola. In order to give an objective view of all three
packages, in the second section a relative simple half-car model is modeled. Different aspect regarding usability of the software and construction of models are
discussed.

The Modelica Language

Both Dymola and MapleSim make use of the Modelica language. Modelica is
a free object-oriented modeling language with a textual definition to describe
physical systems in a convenient way by differential, algebraic and discrete equations. An example such a textual representation of a model is showed in figure
1.1.
The text in this figure represents a parallel spring-damper component. In the
top of the screen some parameters and input files are stated after which the
actual equation of motion (f = c(s s_unstretched) + ds)
is introduced. One
can easily identify s as being the prolongation of the spring and c and d as being
the stiffness and damping-coefficient of respectively the spring and the damper.
der(s) means the derivative of s, the elongation of the spring.
The Modelica language is suited for multi-domain modeling and involves for
example mechanical, electrical or hydraulic applications. In order to guarantee
the interoperability of the modeling language, a free Modelica Standard Library
is available. Furthermore, more both free and commercial Modelica libraries are
available.
An elaborate description of the Modelica language and a user manual/handbook
can be found in [4].
7

CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL

Figure 1.1: An textual representation of a parallel spring-damper component

1.1

Construction of a half-car model

In order to give an opinion about the user friendliness of all three packages, a
half-car model (illustrated in figure 1.2) is constructed. The model consists of a
sprung car-body mass and two unsprung masses that represents the suspensionand wheel-masses. Two spring-damper components represents the suspension
of the half-car. Tyre-stiffness is introduced by means of a spring between the
road-profile and the unsprung masses.

CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL

The numerical values of the model parameters are:

m_sprung = 700
I_z = 1000

[kg]
[kgm2 ]

k_rear = 25000

[N/m]

k_f ront = 18000

[N/m]

d_rear = 1800

[N s/m]

d_f ront = 1500

[N s/m]

m_unsprung_rear = 45
m_unsprung_f ront = 40
k_tyre = 2e5

[kg]
[kg]
[N/m]

Because a variable road height profile is used as an input to simulate the response of the half-car, the vertical tyre force is dependent from both the vertical
position of the unsprung mass as from the height of the road-surface. Therefore,
the vertical tyre force is calculated as the distance between the road and the
unsprung mass multiplied with the vertical tyre stiffness. The resulting signal
is applied to the unsprung mass as a force which is acting in vertical direction.
m_sprung
I_z

Sprung mass
k_rear
d_rear

Spring/damper

m_unsprung_rear

Unsprung mass

k_tyre

Tyre spring

k_front
d_front

m_unsprung_front

k_tyre

Road profile
Figure 1.2: A graphical representation of a half-car model

SimMechanics
In SimMechanics, models are constructed by dragging components from the
Simulink Library Browser into the modeling window. The SimMechanics
model of a half-car is showed in figure 1.3. By clicking a specific component,
parameters and settings can be changed (see figure A.1 in Appendix A for

CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL

10

the car-mass block). In SimMechanics, coordinate frames are attached to the

body. Subsequently, joints are attached between these coordinate frames. A
planar-joint is placed between the car-body and the ground-frame to enable a
2D-motion of the model. The spring and damper are accounted for by attaching
a so-called Joint Spring & Damper to a prismatic joint between the unsprung
mass and the car-body. By attaching a Body-Sensor to a coordinate frame port
of the unsprung mass body, the height of the body can be measured and again be
used as a input signal. Since this component measures the position of the body
in all three directions, the easiest way is to use a so called demux-block. Using
this block, we can specify which components of the signals to use. The number
next to the line between the Body-Sensor and the demux-block indicates that
we are dealing with 3 signals. From the demux-block it is unclear which signals
we selected, so this has to be determined by experimentation. The road-profile
is introduced by specifying a road-height signal (as a function of the horizontal
coordinate) in a 1D look-up-table. Depending on the horizontal position of the
unsprung mass, a road-height is calculated, which is subtracted from the vertical
position of the mass. By multiplying this signal with a constant (tyre-stiffness),
a vertical spring-force is obtained. This force is applied to the unsprung mass
using a Body-Actuator that is connected to the desired coordinate-system of
the body.

Figure 1.3: The half-car model in SimMechanics

CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL

11

Results can be loaded into the MATLAB Workspace by connecting a To Workspaceblock to a specific signal obtained from e.g. a Body-Sensor. During simulation,
signals can be graphically presented using a scope (see figure A.2 which represents the vertical position of the unsprung mass). This scope can be attached
directly to a signal-line and is showed automatically when simulating the model.
When double-clicking a specific component, the parameters-window appears
where also a brief description of the component is found. When right-clicking
a model and choose Help a more elaborate description of the specific model is
showed in a separate screen.

MapleSim
Just like with SimMechanics, components are dragged from the Library Browser
into the modeling screen. As can be seen in figure 1.4 just like SimMechanics,
the model consists of a sprung mass, two unsprung masses, a world frame and
other components needed for simulating the tyre-force. The main difference with
SimMechanics is the construction of coordinate frames. In contrary to SimMechanics where these frames were specified within the body block, in MapleSim
extra frames are constructed by adding so-called Rigid Body Frames. These
blocks can be used to construct a fixed translation and rotation with respect to
another coordinate frame. Another difference with respect to SimMechanics is
how the spring-damper is constructed. Whereas SimMechanics requires the use
of an extra Joint Spring & Damper-block, MapleSim has an option to specify
stiffness and damping directly within the Prismatic Joint-block. Tire stiffness
is accounted for in basically the same way as was done in SimMechanics, again
the demux-block does not specify which signal is extracted. By clicking a component, the Parameters window on the right of the screen displays the possible
parameters that are applicable for the concerning component. An example of
such a screen is given in figure B.1 for one of the unsprung masses. As can
be seen, for this component, mass-properties can be specified as well as some
initial position and orientation properties. A nice feature of MapleSim is the
Components-window (see figure B.2). In this window, a hierarchic view of the
model is given. Using this window, all components that are present in the model
can be seen at a glance. When selecting a component, the connection-ports of
that specific part are displayed. After right-clicking a component and selecting
the Help on ... line, elaborate information about the specific component is
showed in a separate help-window.
As can be seen in figure 1.4, for some specific components MapleSim uses different colors for connection-lines and different connection-port-symbols. By doing
this, its easy to make a distinction between different sort of signals such as
multibody-signals, 1D-mechanical-signals or normal signal lines and between
inputs or outputs. A elaborate explanation about all signals and symbols are
found in the MapleSim user-manual.
Results can be plotted by attaching probes to the connection lines of the model.
In contrast to the probes in SimMechanics, MapleSim cannot live-visualize signals. When attaching a probe, a screen appears in which the desired output
signal(s) can be chosen (see figure B.3). After attaching probes and specify-

CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL

12

Figure 1.4: The half-car model in MapleSim

ing signals, x- and y-axis variables have to be chosen (see figure B.4). After
simulating, a Plot Window appears (see figure B.5). In this window, line and
axis properties can be changed. Also, graph can be exported to various type of
image-formats.

Dymola
In Dymola, the half-car model is constructed in basically the same way as was
done in MapleSim (see figure 1.5). Again, components are dragged from the library into the modeling-window. The car-body is modeled as a bodyShape
which can be interpreted as being a mass with two coordinate-frames, just
like what was done in MapleSim using a body block with two Rigid Body
Frames. By using an Absolute Position-block, we can extract the horizontal
and vertical position signal of the body. Here, we dont need an demux-block
because Dymola directly asks which signal to use when dragging a line from
the Absolute-Position-block (see figure C.1). Parameters can be changed by
double-clicking a component, an example of the parameter-window is showed
in figure C.2 for the car-body. Other than MapleSim and SimMechanics, Dymola shows some parameters such as mass and stiffness/damping directly into
the top-view which is particularly handy when checking the model. By clicking

CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL

13

Info in the parameters-window, an elaborate description of the selected component appears in a new help-window. Like MapleSim, Dymola uses different
colors for connection lines specifying the signal-type.
Similar to MapleSim, Dymola also offers a Component-Browser, showed in
figure C.3. Like MapleSim, the browser represents a hierarchic view of the
components that are present in the model, as well as the connection-ports of a
specific component. By right-clicking a component in the browser and choose
for Info, a similar information-window as discussed above will appear.

Figure 1.5: The half-car model in Dymola

An advantage of Dymola with respect to MapleSim and SimMechanics is that
all input and output signals can be plotted after the model has been simulated.
Therefore, in Dymola no probes have to be attached to the model and no axisproperties have to be specified before simulating a model. If needed, adjusting
the plot characteristics can be done after simulating the model, using the plotsetup-window (see figure C.4).

CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL

1.2

14

Simulation performance

As will be discussed in more detail in section 3.3, when using default simulation
settings, big differences in accuracy can occur. Inevitable, this also influences the
performance and speed of a simulation. Therefore, the same simulation settings
as described in section 3.3 are used, because these settings give basically the
same results with respect to accuracy. By using these simulation settings, a
global indication regarding simulation-speed can be given.
To check performance, the half-car-model is used again. The half-car model is
simulated for 10 seconds. The numerical integrator settings (error tolerances and
algorithms) are adjusted so that they are identical (as far as possible) in all three
packages. The simulations are done with the same 1.86 GHz processor laptop
that is freshly started every simulation to guarantee identical circumstances.
Nevertheless, no strict conclusions concerning simulation-speed can be made
because of the relative simplicity of the half-car model and because of structural
difference between the investigated multi-body packages. An example of this can
be given when we look at the way results are presented; in Dymola all signals
can be accessed after simulation, in SimMechanics and MapleSim distinctive
result-signals have to be chosen prior to simulation.
In SimMechanics, the total simulating time for the half-car model is about 22
seconds. No additional information regarding the time needed for compiling the
model equations and solving the equations is available.
Simulating the half-car model in MapleSim takes approximately 19 seconds in
total from which, according to the status-window, about 7 seconds in used for
compiling the model equations and about 12 seconds is needed for solving the
equations and make data plots.
When we, under similar conditions, simulate the half-car model in Dymola,
we can see that Dymola requires about 13 seconds simulation time. The time
needed for translating the model is about 10 seconds, the residual 3 seconds are
used to integrate the model-equations and process the data.
Another aspect of software-performance that has to be mentioned is startuptime. When we look at MapleSim, the software itself is ready-to-use in about 20
seconds and the half-car model is loaded in about 2 seconds. Dymola requires
10 seconds for initializing and a model is opened in approximately 5 seconds.
Because the slow-loading MATLAB software is needed to use Simulink/SimMechanics, starting-up SimMechanics requires significant more loading-time compared to MapleSim and Dymola. SimMechics is ready-to-use after about 80
seconds (which includes starting MATLAB and Simulink). Opening a model
takes another 8 seconds.
From the preceding experience, we can conclude that Dymola is the fastest
with simulating the half-car model, but the differences with MapleSim and SimMechanics are not significant. Nevertheless, the results give a first indication
regarding the simulation speeds. However, this simple half-car model does not
represent the practical use of a multibody package where much more complicated
models will be created. When we really want to check if major differences in
simulation time would occur, three extensive identical models should be build

CHAPTER 1. BUILDING A HALF-CAR MULTIBODY MODEL

15

in all three packages. What we can conclude regarding start-up time is that
Simulink/SimMechanics needs significantly more time to start than MapleSim
and Dymola. The start-up time differences between MapleSim and Dymola are
in the order of seconds, in favour of Dymola.

Chapter 2

Verification & error handling

When constructing complex models, its important that possible modelling errors can be traced efficiently. Therefore, error-messages given by the software
should be clarifying in order to localize the error.
In order to check error-messages and verification, two half-car model (see chapter
1) test-cases are examined in which we deliberately cause an error. In the first
case, we forget to attach one of the prismatic joints to the car-body. In the
second case, we dont specify a mass-value to the car body. In both cases we
investigate how the three packages react and how they report the error. The
question can we efficiently trace the fault by looking to the error-message? is
answered after that.

2.1

Testcase 1: absent connection between joint

and car-body

SimMechanics
When performing testcase 1 to the SimMechanics model, an error-message as
showed in figure 2.1 appears. The message is not directly indicating where the
fault occurs in the model, but from the fact that there is, however, a Groundblock present in the model we can conclude that somewhere, the rest of the
model is not connected to it.

MapleSim
If we look at the error-message which is produced in MapleSim (see figure 2.2) we
see a error-message which is explained by means of an error in the mathematic
calculation. From this message we havent got a clue where to find the fault and
what causes it. Because of these cryptic error messages, in practice its very
hard to construct a model for the first time because no clear information about

16

CHAPTER 2. VERIFICATION & ERROR HANDLING

17

Figure 2.1: SimMechanics error message belonging to testcase 1

the location and characteristic of the fault is given when the model contains an
error.

Figure 2.2: MapleSim error message belonging to testcase 1

Dymola
When performing the same testcase in Dymola, an error-message like figure
2.3 appears. From the sentences "Connector frame-b of joint object is not connected" and "Connector frame-b of line force object is not connected" it becomes
very clear what was done wrong and where the fault is located in the model.

CHAPTER 2. VERIFICATION & ERROR HANDLING

18

Figure 2.3: Dymola error message belonging to testcase 1

2.2

Testcase 2: mass not specified, equal to zero

SimMechanics
When looking at the error-message produced by SimMechanics (see figure 2.4),
from just reading the message that the mass of the car body is not specified.

Figure 2.4: SymMechanics error message belonging to testcase 2

MapleSim
In MapleSim, a value which is obliged (such as the mass of a body) cannot be
deleted. When trying to escape the default value, it is changed into a value of
1 [kg].

Dymola
When in Dymola deliberately a mass-value is not specified, the program does
not produces an error-message. Apparently, a default value is chosen if no
value is specified. When we look at the plots to check this, we indeed can see
that Dymola uses a default value of 1 [kg] for the mass of the car-body, without
informing the user. This can be a bit tricky, because the behavior of the half-car

CHAPTER 2. VERIFICATION & ERROR HANDLING

19

becomes completely different. What we do see is that the mass-value indicated

in the top-screen of the model is changed into m which indicates that no numeric
value for the mass of the car-body has been chosen.

Chapter 3

Numerical accuracy
In order to check the numerical accuracy of all three packages a relative simple
2D double pendulum model is modeled. By comparing the resulting motion
induced by two initial conditions (for both 1 and 2 ) with an analytical derived
equation, the software accuracy can be checked. A schematic drawing of the
analysed double pendulum is showed in figure 3.1. The masses m1 , m2 and also
the length l1 and l2 of the pendulum are kept constant in all simulations. The
initial condition are also kept constant and will be 1 = pi
4 and 2 = 0.

l_1

1
m_1

l_2

m_2

Figure 3.1: The double pendulum reference model

3.1

Analytical model

The double pendulum system will be analysed by hand using the Langrangian
method (3.1).
20

CHAPTER 3. NUMERICAL ACCURACY

d
T
T,q T,q + V,q = (Qnc )
dt

21

(3.1)

Where the generalized coordinates are chosen to be:

q=

   
q1

= 1
q2
2

(3.2)

1 T
q Mq
2

(3.3)

and the kinetic energy:

T =

with M the mass-matrix of the system:

M=

n
X

mi (ri,q )T ri,q

(3.4)

i=1

where ri,q represents the derivative of the position vector of mass mi with
respect to the generalized coordinates (3.2).
The mass-matrix becomes:


(m1 + m2 )l12
m2 l1 l2 (cos1 cos2 + sin1 sin2 )
M=
m2 l1 l2 (cos1 cos2 + sin1 sin2 )
m2 l22
(3.5)


and using this result the kinetic energy T becomes:

T =

2
2
1
1
m1 l1 1 + m2 (l12 1 + l22 2 + 2l1 l2 1 2 cos(1 2 ))
2
2

(3.6)

Because no springs are involved in the system the potential energy becomes:
V = U in (q) + V ex (q) = V ex (q)

(3.7)

V = m1 gl1 cos1 m2 g(l1 cos1 + l2 cos2 )

(3.8)

and thus becomes:

And because no non-conservative forces are involved:

Qnc = 0

(3.9)

When vector equation (3.1) is evaluated and then rewritten to 1 and 2 as a

function of 1 , 2 , 1 and 2 (angles and angular-velocity of both generalized
cordinates), two second order differential equations of motion are obtained:

CHAPTER 3. NUMERICAL ACCURACY

22

2
1 = m2 gsin2 B m2 l2 2 A Cgsin1




2
m2 l1 1 AB / Cl1 m2 l1 A2

(3.10)

2
2 = m2 l2 2 AB + Cgsin1 cos(1 + 2 )+




2
Cl1 1 A + Cgsin2 / Cl2 m2 l2 B 2

(3.11)

With:

A = sin(1 2 )
B = cos(1 2 )
C = (m1 + m2 )
Using Matlabs ODE45 integration method, differential equations (3.10) and
(3.11) are solved numerically. The results are plotted as 1 against 2 in figure
3.2 for 0 t 5s.

Figure 3.2: Plot of the double pendulum motion

3.2

Simulated model

The double pendulum system is modeled in all three multibody packages. By

using the same parameters and initial conditions as in the analytical model, an
indication regarding the accuracy of all three programs can be made.

CHAPTER 3. NUMERICAL ACCURACY

23

SimMechanics
First off all, the double pendulum is modeled in SimMechanics. The model
consists of a world reference, two point masses and two revolute joints. Two
initial conditions are given via the Joint Initial Condition component in which
the intitial angles 1 and 2 are specified.

Figure 3.3: Visualisation of double pendulum in SimMechanics

Figure 3.4: Model of double pendulum

in SimMechanics

MapleSim
The double pendulum is also modeled in MapleSim. Again, the model consists of
a world reference, two bodys with zero inertia (point masses) and two revolute
joins. The initial conditions are given within the joint-block in contrary to
SimMechanics which uses an extra Initial Condition attached to the joint.

Dymola
Finally, the double pendulum is modeled in Dymola. As in SimMechanics and
MapleSim, the model again consists of a world reference, two bodys and two
revolute joints. The initial conditions are (as in MapleSim) specified within the
joints.

CHAPTER 3. NUMERICAL ACCURACY

24

Figure 3.5: Model of double pendulum in MapleSim

Figure 3.6: Visualisation of double pendulum in Dymola

Figure 3.7: Model of double pendulum

in Dymola

CHAPTER 3. NUMERICAL ACCURACY

3.3

25

Comparison

In this section the absolute errors of the different packages with respect to the analytical model are examined. By choosing very small absolute and relative error
tolerances (1e-9) for solving the stated ODEs (3.10) and (3.11), this numerical
solution can be interpreted as the exact solution of the double-pendulum problem and therefore differences with respect to the exact solution can be fully
attributed to errors made by the multibody package.

Default integrator settings

First, a comparison is made based on the default settings of the three multibody
packages. Only the simulation time and the number of time-steps is adjusted
(in order to compare the results).
Absolute error in 1

2.5

x 10

Absolute error in 2

SimMechanics
MapleSim
Dymola

x 10

SimMechanics
MapleSim
Dymola

1.5
1

error [rad]

error [rad]

0.5

0
1
0.5
2
1

1.5
0

0.5

1.5

2.5

3.5

time [s]

Figure 3.8: Absolute error on 1

4.5

3
0

0.5

1.5

2.5

3.5

time [s]

Figure 3.9: Absolute error on 2

As can be seen in the preceding plots, the absolute error of Dymola is much
greater than that of Simulink and MapleSim. This can be explained if we look at
the simulation settings. Where Simulink and MapleSim both are using a default
error tolerance (for both absolute and relative error) of 1e-7, Dymola uses an
error tolerance of 1e-4. As well, by default Dymola uses a different numerical
method for solving ODEs, namely the Dassl-algorithm, where Simulink and
MapleSim both use an algorithm based on the Runga-Kutta-method (for nonstiff systems). As can be seen, the absolute error for all three packages does not
exceed 3 103 [rad].

4.5

CHAPTER 3. NUMERICAL ACCURACY

26

Manual setup
In this section similar settings as those of SimMechanics and MapleSim are
choosen. The same error tolerance (1e-7) is chosen as well as a solver based on
the Runga-Kutta method is used in all three packages. When choosing similar
settings, we can check if the absolute errors stay small and see if the errors of
all three packages are in the same order of magnitude.
Absolute error in 1

x 10

Absolute error in 2

SimMechanics
MapleSim
Dymola

x 10

3
1

error [rad]

error [rad]

0
2
1

3
0

SimMechanics
MapleSim
Dymola

0.5

1.5

2.5

3.5

time [s]

Figure 3.10: Absolute error on 1

4.5

4
0

0.5

1.5

2.5

3.5

time [s]

Figure 3.11: Absolute error on 2

According to figure 3.10 and 3.11 the absolute error of Dymola is lowered with
a factor 1e4. This was expected from the fact that the error tolerance in Dymola was lowered to 1e-7 (in consensus with tolerances used in MapleSim and
Simulink). Also, a Dormand-Prince method (member of the Runga-Kutta
solver) was now used for solving the ODEs. The absolute error for both 1 and
2 now stays within 3 107 [rad] for all three packages. What is notable is that
the Dymola result is more noisy compared to the other packages and SimMechanics still has the smallest error, but is difficult to make a conclusion from
this: although the three packages use a member of the Runga-Kutta method
for solving the differential equations, the solvers still are not 100% comparable.

4.5

Chapter 4

Visualisation of multibody
models
An important aspect of multibody-software is visualization. With the help of
a visualization screen, the assembly of a constructed model can be checked as
well as the motion of the model that is being simulated. Possible errors that
were made constructing the model (especially when it comes to composition of
bodies) are noticed at a glance. Especially when first using multibody-software,
such composition-errors are easily made and very hard to find if only plotted
data is produced. The same half-car-model used in chapter 1 is used here to
examine the visualization-aspect.

SimMechanics
SimMechanics offers different ways of visualizing models. First of all, a default
view can be used in which only centers-of-gravity, coordinate-frames and
body-geometries (geometries according to specified coordinate-frames) (see figure 4.1). Since the R2008b-release of Matlab, SimMechanics offers an option
to attach user-made .stl-graphics to bodies. In figure 4.2 this was done for
the half-car-model by attaching simple rectangles to the sprung mass and the
two unsprung masses. Graphics cannot be attached to joints or spring-damper
components.
During a simulation, the model can be turned, panned and zoomed to investigate
a particular component. The animation can be stored into a .avi-file.

MapleSim
A big drawback of the current MapleSim release is that it does not include any
visualization functionality. Therefore verification of a constructed model can
only be done by checking plots, no visual inspection of the modelled system is
possible.

27

CHAPTER 4. VISUALISATION OF MULTIBODY MODELS

Figure 4.1: Visualization of the half-car

model in SimMechanics

28

Figure 4.2: Visualization of the half-car

model using user-defined .stl-graphics

It has to be mentioned that as of may 2009, a new MapleSim version is released

(MapleSim 2.0). In this version, a powerful new visualization functionality is
introduced. Because of the time-limitation to which this analysis is bound,
this new functionality will not be covered here. However, the new MapleSim
2.0 visualization environment was tested briefly and from the first sight, the
visualization functionality is working very smooth and responsive.

Dymola
Dymola also offers a visualization functionality, see figure 4.3 for the half-carmodel. Nevertheless, its far more elaborate than that of SimMechanics. Where
in SimMechanics no visualizations can be attached to components other than
bodies, Dymola has a build-in visualisation for springs, dampers and joints, and
by changing animation-parameters, the way components are displayed in the
visualization can be changed. An example is given in figure C.5 where settings
can be made for the spring-damper component. Again, the model can be turned,
panned and zoomed similar to SimMechanics. One thing that is notable when
using the Dymola visualization mode, is that it is working much smoother than
that of SimMechanics. Especially when moving and zooming a model during a
simulation, it is much more responsive and graphics are of much higher quality
in comparison with SimMechanics visualization-mode.

CHAPTER 4. VISUALISATION OF MULTIBODY MODELS

Figure 4.3: Visualization of the half-car model in Dymola

29

Chapter 5

Parametrisation of model
variables
An important aspect of multibody software is parametrisation of the model.
By assigning global parameters to a model, multiple individual components
can inherit the specified value of this parameter. Therefore, multiple modelparameters can be adjusted by just altering one global-parameter.
Another important application of parametrisation is model-optimization. By
varing pre-defined parameters, physical models can be simulated for various configuration and by analysing the result an optimal value for a certain parameter
can be chosen.

5.1

Specifying global parameters in Simulink/SimMechanics

In SimMechanics, global parameters values are specified in the MATLAB workspace

and called from the model block-parameters. By constructing a m-file with all
parameter-values and calling the SimMechanics model directly from this m-file,
parameter values can be set and modified (see figure 5.1).

Figure 5.1: An m-file which runs the model with predefined global parameters

30

CHAPTER 5. PARAMETRISATION OF MODEL VARIABLES

5.2

31

Specifying global parameters in MapleSim

In MapleSim, global parameters are assigned by clicking the parameters button

which displays the Global Parameters view (see figure 5.2). After assigning
some global parameters, the parameter name and default value are displayed in
the parameters pane.

Figure 5.2: The Global Parameters view

Now, for example a global parameter called M can be assigned as a variable to
a individual component and therefore inherit the value of the global parameter
M. Not only single global parameters can be assigned to model variables, but
also functions of global parameters can be assigned to model parameters.
MapleSim offers an application called the Parameter Optimization Template.
This template (which opens in MapleSims mathematical engine Maple) can
be used to test different settings of the model by varying specified global parameters. For each global parameter, a range of values can be specified (see
figure 5.3) for which the model is simulated after which the simulation result is
visualised in a plot automatically. The defined global parameters can also be
assigned to a Maple procedure to perform further analysis tasks.

Figure 5.3: A part of the Parameter Optimization Template

CHAPTER 5. PARAMETRISATION OF MODEL VARIABLES

5.3

32

Specifying global parameters in Dymola

Just like MapleSim, Dymola also offers a possibility to specify global

parameteters and assign values to them. In Dymola however, parameters can be
assigned as being real physical quantities such as length, time, volume, etc. By
dragging a physical variable into the Modelica Text Representation, a window
appears in which a discription, name and value can be assigned to a parameter
(see figure 5.4) as well as some other parameter settings which is basically the
same as was done in MapleSim.

Figure 5.4: The physical parameter declaration window

After specifing some global parameters and assigning values to the parameters,
similar to MapleSim global parameters can be assigned to components parameters that inherits the numeric value of the global parameter. Dymola also offers
the possibility to assign the parameter from a drop-down menu which is handy
when many parameters are specified or when the exact name of the parameter
is not known. After entering the Dymola Simulation screen, global parameter
values can be varied between simulations.

5.4

Dymolas Experimentation Package

Similar to MapleSims Parameter Optimization Template, Dymola offers a

library called the Experimentation Package (see figure 5.5). The Experimentation Package provides several ways of analyzing the behavior of a model. The
main functions are perturbParameters, sweepParameter, sweepOneParameter,
sweepTwoParameters and MonteCarloAnalysis.
By choosing the perturbParameters-function, we can check the behavior of a
model by pertubating from a nominal value of a parameter. After choosing the
parameters to perturb and the percent change of pertubation from the nominal
value, a plot can be created which (after selecting the variable to plot) displays
the response of the selected variable when varying a parameter. The vertical
displacement response of a mass-spring system is plotted in figure 5.6 where
both stiffness of the spring and the mass were pertubated 20% from the nominal
value.
Another way of varying one parameter and check the resulting behavior of the
model is done by choosing the sweepParameter-function. With this function,

CHAPTER 5. PARAMETRISATION OF MODEL VARIABLES

33

Figure 5.5: The Experimentation Package library

one parameter can be varied over a specified interval by selecting the number
of (equidistant) values between this interval. The resulting output variable can
again be plotted in a specified time interval, for every parameter value specified.
Some other methods for analysing a response are available, explanation and
functionality of these methods can be found in the Dymola user manual.
To study the dependence of one response with respect to two parameters at the
end of the integration interval, the function sweepTwoParameters is to be used.
The setup is almost identical to sweepParameter and sweepOneParameter.
The only difference is that two dependency variables are to be selected instead.
Consequently, a 3D-plot is generated for each output-variable.
Last but not least, a Monte Carlo Analysis can be used to analyse parameter
behaviour. The Monte Carlo Analysis is widely used to explore the behavior of
a model when the input parameters are multidimensional. For the exact usage
and application of this function, the reader is referred to the Dymola manual.
Off course, the functionalities regarding parameter-variation offered by MapleSim
and Dymola, as discussed in this chapter are effective when it is necessary to vary
parameters and investigate behaviour. Nevertheless, in MATLAB/Simulink
most of the results acquired by these functionalities can also be accomplished
by just making some loops in an MATLAB m-file, in which the model is called
(see figure 5.1) and where also a range of values for specified parameters can be
used.

CHAPTER 5. PARAMETRISATION OF MODEL VARIABLES

Figure 5.6: Vertical displacement of the point-mass

34

Chapter 6

Exporting and
interchangeability
MATLAB/Simulink is used in all sorts off disciplines. In practice, multibody
dynamics often have to cooperate with other engineering disciplines (like electrical engineering, systems engineering, control, etc.). Besides, the fact that
MATLAB/Simulink is known by much TU/e students, the possibility to export
the multibody model to MATLAB/Simulink is highly appreciable and of great
interest.
In both MapleSim and Dymola, the model is exported to C-code. Thanks to
the compactness of this code and because its numerically very efficient due to
symbolic preprocessing, the code can be used to do real-time simulations or use
it in HIL (Hardware In the Loop) applications.

6.1

MapleSim

In MapleSim, C-code is generated directly from the model equations by using

MapleSims mathematical engine, Maple 12. In this Code Generation Template
variables can be assigned, inputs and output can be specified and parameter values can be changed. In the Model Equations window (see figure 6.1) the model
equations can be explored as well as the models parameters, initial conditions,
probes and other information.
In order to investigate the generated C-code and check if it is understandable
even without knowledge of the model from which it arise from, an very simple
(point)mass-spring system is modeled. By using distinct values for the mass
(1.000123 [kg]), stiffness off the spring (1.23456789 [N/m])and the initial position
off the mass (3.33445 [m] in vertical direction), we can easily identify them in
the C-code which is found in appendix A.
Firstly, some output and state variables are specified. We notice from the comment on line 17-31 that Probe1 is specified as an output variable. Some other
variables from the model are specified as state variables. On line 146 we can
35

CHAPTER 6. EXPORTING AND INTERCHANGEABILITY

36

Figure 6.1: The Model Equations window

identify our mass and stiffness (both are multiplied by 108 . As can bee seen
from the code, even for simple code as this its hard to identify parameters if
the exact value of these parameters is not known. For this part of the code, it
would be very handy if it had some more elaborate comment specifying which
parameters are being used an what expressions are being solved (expressed symbolical). In the lower part of the code initial conditions are specified in which
the initial position of the mass is found.
Alternatively, MapleSim also offers a so called Connectivity Toolbox. This
toolbox enables users to export MapleSim models directly to Simulink. Models
are automatically converted to S-function blocks which are directly usable in
Simulink. Because this functionality is not a build-in feature of MapleSim and
requires the installation of extra software, it has not been examined in this
report.

6.2

Dymola

Similar to MapleSims Connective Toolbox, Dymola offers a functionality to

communicate with MATLAB/Simulink called the Dymola-Simulink interface.
Unlike the Connective Toolbox from MapleSim, this is a build-in feature of
Dymola. To use this function, the user should include a Dymola-folder in the
MATLAB search path that contains some m-files. After this folder is included, a
Dymola-Simulink interface block called DymolaBlock appears in the Simulink
Library browser (see figure 6.2). This block with the Dymola logo represents
the model that is made using Dymola. The DymolaBlock is a shield around
an S-function MEX block, i.e., the interface to C-code generated by Dymola
for the Modelica model. After compiling the model, the lines left and right of
the DymolaBlock are replaced by ports that can be connected to all sorts off

CHAPTER 6. EXPORTING AND INTERCHANGEABILITY

37

Simulink-components.

Figure 6.2: Simulink Library containing the DymolaBlock

By double-clicking the DymolaBlock, a Graphical User Interface (GUI) is displayed (see figure C.6). Using this GUI the DymolaBlock can be configured
which involves specifing the Modelica model, compiling the model into a Simulink
MEX file, selecting compiler options, setting and resetting parameters and start
values, etc.
Dymola also offers some M-files that can be used to analyse and run models
constructed with Dymola using MATLAB. These M-files run a program called
Dymosim. Dymosim essentially is a stand-alone program without any graphical user interface which reads the experiment description from an input file,
performs one simulation run, stores the result in an output file and terminates.
By using some pre-defined functions found in the M-files bundled with Dymola,
output can be imported into MATLAB as plots, and signals can be extracted
from files made by Dymosim. Also by specifying an input function, parameters
can varied.

Chapter 7

Closed-loop systems
behaviour
Closed-loop (or closed-chain) systems are a special, but common kind of multibody systems. These type of systems require so called cut-joints to take care of
the closed loop. An extra step has to be taken when the equations of motion are
compiled. The problem with modeling closed loop systems lies in the fact that
the model can exhibit configuration singularities. Consequently, the solution of
the kinematic analysis of such a system may, at a certain configuration, either
not exists or not be unique. When modeling complex systems it is not always
clear to see where and when these singularities occur. Therefore, in this chapter
a simple 2D 3-link closed loop mechanism is introduced (see figure 7.1) in which
the right ground-frame deliberately placed 0.0001 meter sideways with respect
to the lower-end of the right link. This issue occurs in lots of multibody systems
that contain a closed-loop, where two specific bodies are attached together (or
to the ground-frame) and do not exactly align with each other.

Lateral position error of 0.0001 m

Figure 7.1: A 2D 3-link closed loop mechanism

38

CHAPTER 7. CLOSED-LOOP SYSTEMS BEHAVIOUR

39

SimMechanics
As can be seen in figure 7.2, the closed-loop system as discussed above is modeled
in SimMechanics. In this figure, we can see that a little red cross appears in one
of the joints which means that this joint is used as a cut-joint. By assigning a
cut-joint in every independent closed-loop, the problem is solved in a standard
way, taking into account that a closed loop is present in the system. A cut-joint
is chosen automatically by SimMechanics but other joints can be specified as
being the preferred cut-joint. After placing the right ground-block 0.0001 meters
to the side (with respect to the lower coordinate frame of the vertical bar and
simulating the model, we observe that no error-messages appears. Only after
positioning the ground-block as much as 0.1 meter to the side, an error message
as seen in figure 7.3 appears. From this we can conclude that SimMechanics
is using a tolerance when working with closed-loop systems. This means that
the problem found in closed-loop modeling as stated in the introduction above,
only occurs when bodies are seriously miss-aligned.

Figure 7.2: The closed-loop mechanism modeled in SimMechanics

MapleSim
When simulating the modeled closed-loop system in MapleSim (see figure 7.4)
and constructing the ground-frame 0.0001 meters sideways (as explained in the
introduction above) a error-message appears. The error-message is viewed in
figure 7.5. The same conclusions can be made as discussed in section 2.1: from
this message we cannot identify the problem. According to the description in
the error-message we can only conclude that the problem is acting in R4 which
is identified as the revolute-joint on the lower-right of the model, but nothing is
mentioned about composition faults or a possible closed-loop error.

CHAPTER 7. CLOSED-LOOP SYSTEMS BEHAVIOUR

40

Figure 7.3: SimMechanics closed loop error message

Dymola
First of all, when modeling a closed-loop mechanism in Dymola (see figure 7.6),
the program advises you to use a so-called RevolutePlanarLoopConstraintjoint in stead of the normal Revolute-joint. This joint allows you to model
closed-loop systems without having problems that are caused by singularities
in the mathematical description of the model. How this is done exactly in Dymola, can be found in the user-manual. This feature can be compared with
the SimMechanics environment where (for closed-loop systems) a cut-joint is
automatically introduced. When simulating the stated model (with the right
ground-frame positioned miss-aligned) Dymola behaves differently in comparison with SimMechanics: the placement of the right mass lower coordinate is
changed so that it meets the stated positioning of the right ground-frame. By
applying initial conditions to the revolute-joints, this problem can be tackled.
After applying these initial conditions and placing the ground frame 0.0001 meters sideways, an error message as can be seen in figure 7.7 appears. In this
message screen, the reason that causes the error is shown as well as possible
solutions (removing one of the initial conditions from the revolute joints). It
is not explicitely perceived that we are dealing with a closed-loop system, but
from the hints stated in the error-message, we can conclude that the fault has
to be found in the initial composition of the model.

CHAPTER 7. CLOSED-LOOP SYSTEMS BEHAVIOUR

Figure 7.4: The closed-loop mechanism modeled in MapleSim

Figure 7.5: MapleSim closed loop error message

41

CHAPTER 7. CLOSED-LOOP SYSTEMS BEHAVIOUR

Figure 7.6: The closed-loop mechanism modeled in Dymola

Figure 7.7: Dymola closed loop error message

42

Chapter 8

Dymola Vehicle Dynamics

Library
At the Eindhoven University of Technology, an important application of the
multibody package is vehicle dynamics. Because of the drawbacks considering
visualisation and speed of MATLAB/Simulink a fast vehicle dynamics package is
highly appreciated. A free Modelica-based vehicle dynamics library is available,
but this library is very limited and no further development on this library is
done. A more extensive commercial vehicle dynamics library is available and
is designed and maintained by Modelon AB, the same company that produces
Dymola. Here, version 1.3 of the Vehicle Dynamics Library is used.

8.1

Introduction

The Dymola Vehicle Dynamics Library offers is, as with all Dymola libraries,
based on the Modelica language which means that the details of the separate
vehicle components are fully open to the user and gives more experienced users
possibilities to adapt or design their own components. As was also mentioned in
chapter 1, additional Modelica libraries can be be used so that multiple engineering domains such as control, hydraulics, powertrains and electrical system can
be covered. Besides some ready-made components like suspensions, brakes and
powertrain components, the Vehicle Dynamics Library also includes a 3D road
builder, a number of open- and closed-loop driver models, athmosphere-blocks
and some state-of-the-art tyre models such as Rill and Pacejka.

8.2

Adaptability

In nearly all cases, academic usage of multibody packages and in particular a

vehicle dynamics library requires modeling custom (suspension-) components or
editing existing components. Consequently, a component should be intuitively
and clear. To check this, a ready-made Trailing Arm suspension is firstly
43

CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY

44

looked as a component itself. Adjustable settings and parameters are discussed

after which the underlying methodology is checked.

Figure 8.1: The Trailing Arm block

Figure 8.2: Expanded view of the Trailing Arm suspension

As can be seen in figure 8.1, the Trailing Arm block has got four frame connections (rectangular ports), four spring-damper connections (square ports) that
can be used to specify the position of both damper and spring mounts in the
upright, see also figure 8.3, and one hub-flange (the rectangle with an circle
inside) for attaching the wheel. By using the dotted lines in figure 8.1 and from
the discription found when hovering over the ports, it is obvious how to attach
the suspension to the chassis and connecting the wheels to the suspension.
By clicking the Trailing Arm block, various parameters and settings considering
the geometry of the suspension can be modified. As can be seen in figure 8.3, the
meaning of specific parameters is very clear thanks to the elaborate discription
and the drawing on the right.
When we look to the underlying components of the Trailing Arm-block in
figure 8.3, we can firstly identify all of the nine ports discussed above. Secondly,
two suspension links can be seen as well as a joint connected to one of the links.
Thirtly, we see a spring and damper which are attached to the other suspension
link. By clicking a component, again different parameters such as mass and
inertia for the link and stiffness and damping coefficients for the spring and
damper can be adjusted.
When going deeper into the LowerArm-link, we can see a number of parts, as
can be seen in figure 8.4. We can see two FixedTranslations and three Rods.
The three Rods-components are identified as being the three links of which
the Lowerarm consists of. Again, different characteristics of the Rods can be
adapted such as mass, inertia and geometry properties. In this case, geometry
properties are constructed by declaring a function of some global parameters
specified in second-level LowerArm-block (which again are functions of parameters specified in the top-level Trailing Arm-block). An examle of this can be

CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY

45

Figure 8.3: The Trailing Arm parameters window

found in figure 8.4 where we can see that the position vector of link1 is specified as r = r0J1 r0B (see the top of the figure) where both r0J1 and r0B are
specified in the one level higher LowerArm block (not visualized here). Both
FixedTranslations are needed to specify the position of the two Rods relative
to both mounting-frames.
Finally, when looking into the lowest-level link1-block (see figure 8.5), we
find two elementary Modelica-blocks, namely a body-block which specifies the
mass- and interia-properties whereas the frameTranslation-block represents the
position-vector of the rod. Parameters from both blocks are inherited from
higher-level components.

CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY

Figure 8.4: The LowerArm-block

Figure 8.5: The link1-block

46

CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY

47

The hierarchic structure discussed above is (in a clarifying way) showed in the
Component Browser (see figure 8.6). In this browser, all the different components with their specific ports can be found. By clicking on it, the component
opens in the modeling-window. By right-clicking a component, parameters can
be changed without opening the specific component. From the preceding text
it can be concluded that the vehicle component that was looked at (the Trailing Arm suspension) is fairly understandable when going deeper into the model.
Parameters and settings can be adapted easily. Also, it can be seen that the different rods and links are easily identified and therefore their composition could
be changed easily. The lowest level components are simple standard Modelica
components which would make it possible to construct a suspension-part from
scratch.

Figure 8.6: The Dymola Component Browser

8.3

Visualization

A powerful aspect of Dymolas Vehicle Dynamics Library is the visualization of models. Many basic ready-made components found in the library offer
the possibility to be visualized while running the simulation. Some of the 3dimensional illustrations used to visualize the components are deformable and
movable. Thanks to this, springs for example can be visualized realistically. A
number of properties of the 3D visualization such as color (material finish) and
dimensions can also be changed (see figure C.7 for a spring-damper-component).

CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY

48

Also road-surfaces can be visualized. During a simulation, models can be turned

and scaled.
In figure 8.7 a visualization of a 3D-car model is shown. Figure 8.8 shows a
detailed view of the suspension.

Figure 8.7: Visualization of a car

Figure 8.8: Detailed view of the suspension with spring-damper, wheel and
brake

8.4

Performance

Due to the fact no other similar vehicle-models are available in the other packages, its hard to make conclusions considering simulation-performance. Other
than that, comparable settings regarding the used algorithm and error-tolerances
have to be chosen to give an objective view on the performance aspect.
To check performance, lets take the VehicleDynamics.Examples.GettingStarted.GettingStartedexample model of a typical mid-size car provided standard in the library which

CHAPTER 8. DYMOLA VEHICLE DYNAMICS LIBRARY

49

performs a pre-defined steering-action. Among other things, the model consists of a tabular-data-suspension, an Tabular89Bakker-tire-model, elaborate
mass- and inertia-properties, a flat road profile and an open-loop driver. On a
1.86 GHz processor laptop, a ten second simulation of this model requires in
total about 150 seconds (using the Radau IIa - order 5 stiff algorithm with an
error-tolerance of 0.0001). According to Dymolas Messages-window, about 20
seconds is needed for integrating the model equations; the rest of the simulationtime is uses to compile the model-equations needed for integration. Under same
circumstances and with the same computer, SimMechanics requires about 4.5
minutes (270 seconds) which is almost a factor 2 in time to simulate a much
less-complicated vehicle model, which indicates that when speed is concerned,
Dymolas Vehicle Dynamics Library is performing very well, considering the
complexity of the simulated vehicle-model. Another aspect that has to be mentioned is that with Dymola, no output variables have to be chosen before simulating the model. In the Variable Browser (see figure C.8) all variables can be
plotted afterwards.

Chapter 9

Conclusion
As always, new software takes time to get used to. However, the longer you
work with a software package, the clearer it gets. Off-course, due to the limited timespan that was involved for the project and because three multibody
packages had to be learned and examined, only some global aspect were investigated. Also, because only very simple multibody models were used to check for
simulation performance, just a small amount of the actual capabilities all of the
three packages was utilized and no significant differences in performance occur.
Therefore, its hard to draw a conclusion concerning simulation performance just
from the results obtained from these simple models. Nevertheless, the overall
feel of speed and performance when using both MapleSim and Dymola is much
better compared to SimMechanics. This can already be seen when just looking
at the startup time: Simulink/SimMechanics takes up to a factor 4 more time
compared to MapleSim or Dymola.
When looking at verification and error handling, we have seen some big differences. From the error-messages produced by MapleSim it was very hard to
identify the location of the fault that was made because of the mathematical
based error messages. In SimMechanics and Dymola, most of the times the location of the fault was specified or became clear from the error-message window.
When numerical accuracy is concerned, no significant differences were observed
although the error produced by Dymola stayed the highest when we compared
it to those of SimMechanics and Dymola.
A major drawback of the investigated MapleSim multibody package in contrary
to SimMechanics and Dymola was the absence of a visualization environment.
This made it very hard to verify models and check motion behaviour. Dymola
does offer an elaborate visualization functionality.
When parametrisation is concerned, all three packages have their own way of
dealing with it. However, the methods used in MapleSim and Dymola could
also be accomplished in MATLAB/Simulink with some lines of code which, in
practice, turns outs to be the easiest method.
In Dymola, models can be exported to MATLAB/Simulink easily by using the
DymolaBlock. MapleSim offers a possibility to export a model to C-code.
50

CHAPTER 9. CONCLUSION

51

This C-code was almost free from comments which made it hard to understand
without having knowlege of the actual model.
By investigating a simple closed-loop model, conclusions about how the model
reacts to small deviations in composition were drawn. In both SimMechanics
and Dymola, it was fairly clear from the error-message screens where the fault
occured and what was done wrong. In MapleSim however, is was unclear what
caused the error which makes it hard to solve the problem.
Finally, the Dymola Vehicle Dynamics Library was investigated. It offers many
pre-defined componenents and tyre-models. Also, components are fairly easy
to understand and adapted. Moreover, a nice and elaborate visualization functionality is available. When the simulation performance is compared to a (much
simpler) SimMechanics car-model, it can be also concluded that this Vehicle
Dynamics Library also performs well regarding simulation speed.

Summary
In order to summarize the opininon regarding the three multibody packages, a
table is made which containts the most important aspects discussed in the preceding chapters. The Chapter-column indicates in which chapter the specific
aspect is discussed.
Table 9.1: Summary table

CHAPTER 9. CONCLUSION

52

Recommendations
Off-course, because this conclusion is only based on the use of some simple
models, a more thoroughly investigation would be necessary to investigate all
the functionalities and give a more founded opinion. Nevertheless, an important
aspect of multibody software is verification and error handling and according
to this, it can be concluded that MapleSim is a less-suitable alternative for
SimMechanics. In MapleSim 2 this aspect has not been improved, in contrary
to the visualization functionality which is performing very well. The Vehicle
Dynamics Library has proved itself to be a powerful application and therefore
would be of great interest for the TU/e.
When we take into account all the preceding observations, it has to be concluded
that Dymola would be a suitable alternative to SimMechanics and can be used
in cooperation with other applications written or modelled in Simulink and
MATLAB.

References
[1] I.J.M. Besselink a.o. Introduction to automotive technology lecture notes,
2007.
[2] Bram de Kraker & Dick H. van Campen. Mechanical Vibrations. Shaker
Publising BV Maastricht, 2001.
[3] W. Kortm and R.S. Sharp, editors. Multibody computer codes in vehicle
system dynamics. Swets & Zeitlinger B.V., Amsterdam/Lisse, 1993.
[4] Modelica. Modelica - A Unified Object-Oriented Language for Physical Systems Modeling, 2000.
[5] N. van de Wouw. Multibody dynamics lecture notes, 2007.

53

Appendix A

SimMechanics windows

Figure A.1: The car-mass parameters window in SimMechanics

54

APPENDIX A. SIMMECHANICS WINDOWS

55

Figure A.2: A scope visualizing the vertical position of the unsprung mass

Appendix B

MapleSim windows

Figure B.1: The MapleSim parameters-window

56

APPENDIX B. MAPLESIM WINDOWS

Figure B.2: The MapleSim components-window

Figure B.3: The MapleSim probe-properties-window

57

APPENDIX B. MAPLESIM WINDOWS

Figure B.4: Editing the axis variables

Figure B.5: The MapleSim Plot Window

58

Appendix C

Dymola windows

Figure C.1: Selecting the signal to use

Figure C.2: Dymolas parameter-window for the car-body

59

APPENDIX C. DYMOLA WINDOWS

Figure C.3: Dymolas Component-Browser

Figure C.4: Adjusting plot characteristics

60

APPENDIX C. DYMOLA WINDOWS

Figure C.5: Animation settings for the spring-damper

61

APPENDIX C. DYMOLA WINDOWS

Figure C.6: The DymolaBlock GUI

62

APPENDIX C. DYMOLA WINDOWS

63

Figure C.7: Visualization-parameters window of a spring-damper-component

APPENDIX C. DYMOLA WINDOWS

Figure C.8: A part of the Variable Browser

64

Appendix D

MapleSim C-code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

DO NOT EDIT MANUALLY!

A u t o m a t i c a l l y g e n e r a t e d by Maple .
Created On : Thu May 07 1 3 : 1 1 : 5 2 2 0 0 9 .
Model Name : Main
/

#include <math . h>

#include <m a l l o c . h>

/
V a r i a b l e D e f i n i t i o n f o r simDerOut and simOut :

Output v a r i a b l e ( s ) :

MAPLE_y[ 0 ] = Probe1_r_0_1_ ( t )

State variable ( s ) :

MAPLE_x[ 0 ] = DFPSubsys1inst_x_RB1 ( t )

MAPLE_x[ 1 ] = DFPSubsys1inst_y_RB1 ( t )

MAPLE_x[ 2 ] = DFPSubsys1inst_z_RB1 ( t )

MAPLE_x[ 3 ] = DFPSubsys1inst_vx_RB1 ( t )

MAPLE_x[ 4 ] = DFPSubsys1inst_vy_RB1 ( t )

MAPLE_x[ 5 ] = DFPSubsys1inst_vz_RB1 ( t )

/
/ I n t e r n a l R o u t i n e s . Do not modify ! /
void DecompC( long n , double A, long i p )

65

APPENDIX D. MAPLESIM C-CODE

34
35
36

{
long i , j , k ,m;
double t ;

37
38
39
40
41

i p [ n1]=1;
f o r ( k=0;k<n1;k++) {
m=k ;
f o r ( i=k+1; i <n ; i ++)
i f ( f a b s (A[ i n+k ] )>f a b s (A[mn+k ] )
) m=i ;
i p [ k]=m;
i f ( m!=k ) i p [ n1]= i p [ n 1 ] ;
t=A[mn+k ] ; A[mn+k]=A [ ( n+1)k ] ; A [ ( n+1)
k]= t ;
i f ( t ==0.0 ) { i p [ n1]=0; return ; }
t =1.0/ t ;
f o r ( i=k+1; i <n ; i ++) A[ i n+k]=A[ i n+k ] t ;
f o r ( j=k+1; j <n ; j ++) {
t=A[mn+j ] ; A[mn+j ]=A[ kn+j ] ; A[
kn+j ]= t ;
i f ( t !=0.0 )
f o r ( i=k+1; i <n ; i ++) A[ i n+
j ]+=A[ i n+k ] t ;
}
}
i f (A[ nn1]==0.0) i p [ n1]=0;

42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75

66

}
void MultiSolveC ( long n , double A, long ip , long nb ,
double b )
{
long i , j , k ,m;
double t ;
i f ( n>1 ) {
f o r ( j =0; j <n1; j ++) {
m=i p [ j ] ;
f o r ( k=0;k<nb ; k++) {
t=b [mnb+k ] ; b [mnb+k]=b [
j nb+k ] ; b [ j nb+k]= t ;
f o r ( i=j +1; i <n ; i ++) b [ i nb
+k]+=A[ i n+j ] t ;
}
}
f o r ( j=n1; j >0; j ) {
f o r ( k=0;k<nb ; k++) {
b [ j nb+k]=b [ j nb+k ] /A [ ( n
+1) j ] ;
t=b [ j nb+k ] ;
f o r ( i =0; i<=j 1; i ++) b [ i

APPENDIX D. MAPLESIM C-CODE

67

nb+k]+=A[ i n+j ] t ;
}

76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

}
}
f o r ( k=0;k<nb ; k++)
b [ k]=b [ k ] /A [ 0 ] ;
}

/ Function : s i m J a c o b i a n
=================================================
Abstract :

f ( t , x , J)
/
void s i m J a c o b i a n ( double t , double MAPLExx, double Jac ,
long Jac_cn )
{
long t i 1 , t i 2 ;
f o r ( t i 1 =1; t i 1 <=4; t i 1 ++)
f o r ( t i 2 =1; t i 2 <=6; t i 2 ++)
Jac [ ( t i 1 1) Jac_cn+t i 2 1] = 0 . ;
Jac [ 2 ] = 1.;
Jac [1+ Jac_cn ] = 1.;
Jac [5+2 Jac_cn ] = 1.;
Jac [4+3 Jac_cn ] = 1.;

93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120

/ Function : simRes
=================================================
Abstract :

f ( t , x , R)
/
void simRes ( double t , double MAPLExx, double Resd )
{
Resd [ 0 ] = MAPLExx [ 2 ] ;
Resd [ 1 ] = MAPLExx [ 1 ] ;
Resd [ 2 ] = MAPLExx [ 5 ] ;
Resd [ 3 ] = MAPLExx [ 4 ] ;
}

/ Function : simOut
=================================================
Abstract :

f (N, t , x , x d o t )
/

APPENDIX D. MAPLESIM C-CODE

void simOut ( long N, double t , double MAPLExx, double

MAPLEdx)

121
122

{
MAPLExx [ 6 ] = MAPLExx [ 0 ] ;
i f ( N<1 ) {
return ;
}
MAPLEdx [ 0 ] = 0 . ;
MAPLEdx [ 1 ] = 0 . ;
MAPLEdx [ 2 ] = 0 . ;
MAPLEdx [ 3 ] = 0 . ;
MAPLEdx [ 4 ] = 0 . ;
MAPLEdx [ 5 ] = 0 . ;

123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159

160
161
162
163
164

68

/ Function : simDerOut
=================================================
Abstract :

f (N, t , x , x d o t )
/
void simDerOut ( long N, double t , double MAPLExx, double
MAPLEdx)
{
MAPLExx [ 6 ] = 0 . ;
i f ( N<1 ) {
return ;
}
MAPLEdx [ 3 ] = 123456789.MAPLExx[ 0 ] / 1 0 0 0 1 2 3 0 0 . ;
MAPLEdx [ 4 ] = 0 . ;
MAPLEdx [ 5 ] = 0 . ;
MAPLEdx [ 0 ] = MAPLExx [ 3 ] ;
MAPLEdx [ 1 ] = MAPLExx [ 4 ] ;
MAPLEdx [ 2 ] = MAPLExx [ 5 ] ;
}

/ Function : s i m I n i t i a l i z e
====================================================
Abstract :

A l l o c a t e space .
/
void s i m I n i t i a l i z e ( double MAPLE_y, double MAPLE_x,
double MAPLE_dx, double MAPLE_u, double
MAPLE_params)
{
MAPLE_x = m a l l o c ( 6 s i z e o f ( double ) ) ;
MAPLE_dx = m a l l o c ( 6 s i z e o f ( double ) ) ;
MAPLE_y = m a l l o c ( 1 s i z e o f ( double ) ) ;
}

APPENDIX D. MAPLESIM C-CODE

165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203

204
205
206
207

69

/ Function : s i m G e t S i z e s
====================================================
Abstract :

Return s i z e s o f v e c t o r s .
/
void s i m G e t S i z e s ( int size_y , int size_x , int size_u ,
int size_params )
{
size_u = 0 ;
size_x = 6 ;
size_y = 1 ;
size_params = 0 ;
}
/ Function : s i m I n i t i a l C o n d i t i o n s
===========================================
Abstract :

I n i t i a l i z e the s t a t e s .
/
void s i m I n i t i a l C o n d i t i o n s ( double MAPLE_x)
{
MAPLE_x[ 0 ] = 0 . 3 3 3 4 4 5 e1 ;
MAPLE_x[ 1 ] = 0 . 0 e0 ;
MAPLE_x[ 2 ] = 0 . 0 e0 ;
MAPLE_x[ 3 ] = 0 . 0 e0 ;
MAPLE_x[ 4 ] = 0 . 0 e0 ;
MAPLE_x[ 5 ] = 0 . 0 e0 ;
}
/ Function : s i m I n i t i a l i z e P a r a m e t e r s
========================================
Abstract :

I n i t i a l i z e the parameters .
/
void s i m I n i t i a l i z e P a r a m e t e r s ( double MAPLE_params)
{
}
/ Function : simOutputs
=======================================================
Abstract :

y = f ( t , x , u , p)
/
void simOutputs ( double MAPLE_y, double t , double
MAPLE_x, double MAPLE_u, double MAPLE_params)

APPENDIX D. MAPLESIM C-CODE

208
209
210

{
double MAPLE_s [ 7 ] ;
MAPLE_s [ 0 ]
MAPLE_s [ 1 ]
MAPLE_s [ 2 ]
MAPLE_s [ 3 ]
MAPLE_s [ 4 ]
MAPLE_s [ 5 ]
MAPLE_s [ 6 ]

211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230

231
232
233
234
235

248
249
250
251

=
=
=
=
=
=
=

MAPLE_x [ 0 ] ;
MAPLE_x [ 1 ] ;
MAPLE_x [ 2 ] ;
MAPLE_x [ 3 ] ;
MAPLE_x [ 4 ] ;
MAPLE_x [ 5 ] ;
MAPLE_y [ 0 ] ;

simOut ( 7 , t , MAPLE_s, MAPLE_dx) ;

MAPLE_y[ 0 ] = MAPLE_s [ 6 ] ;
}

/ Function : s i m D e r i v a t i v e s
=================================================
Abstract :

xdot = g ( t , x , u , p)
/
void s i m D e r i v a t i v e s ( double MAPLE_dx, double t , double
MAPLE_y, double MAPLE_x, double MAPLE_u, double
MAPLE_params)
{
double MAPLE_s [ 7 ] ;
MAPLE_s [ 0 ]
MAPLE_s [ 1 ]
MAPLE_s [ 2 ]
MAPLE_s [ 3 ]
MAPLE_s [ 4 ]
MAPLE_s [ 5 ]
MAPLE_s [ 6 ]

236
237
238
239
240
241
242
243
244
245
246
247

70

=
=
=
=
=
=
=

MAPLE_x [ 0 ] ;
MAPLE_x [ 1 ] ;
MAPLE_x [ 2 ] ;
MAPLE_x [ 3 ] ;
MAPLE_x [ 4 ] ;
MAPLE_x [ 5 ] ;
MAPLE_y [ 0 ] ;

simDerOut ( 7 , t , MAPLE_s, MAPLE_dx) ;

}

/ Function : simTerminate
====================================================
Abstract :

Free s p a c e .
/
void simTerminate ( double MAPLE_y, double MAPLE_x,
double MAPLE_dx, double MAPLE_u, double
MAPLE_params)

APPENDIX D. MAPLESIM C-CODE

252
253
254
255
256

{
f r e e (MAPLE_x) ;
f r e e (MAPLE_dx) ;
f r e e (MAPLE_y) ;
}

71