Physical Systems Modeling With Modelica
Physical Systems Modeling With Modelica
Abstract
A new language, called ModelicaTM, for the modeling of physical systems has been developed in an international effort. The main
objective was to make it easy to exchange models and model libraries. The design approach builds on non-causal modeling with true
ordinary differential and algebraic equations and the use of object-oriented constructs to facilitate the reuse of modeling knowledge.
There are already several modeling languages based on these ideas, available from universities and small companies. There is also
significant experience of using them in various applications. The aim of the Modelica effort was to unify the concepts and to design
a new uniform language for model representation. The paper describes the effort, gives an overview of Modelica, and demonstrates
how Modelica is used in real-world applications: modeling of an automatic gearbox and of a heat exchanger. ( 1998 Elsevier Science
¸td. All rights reserved.
Keywords: Modelica; modeling languages; object-orientation; hierarchical systems; modeling; simulation; differential-algebraic
equations; hybrid models
0967-0661/98/$ — See front matter ( 1998 Elsevier Science Ltd. All rights reserved
PII S 0 9 6 7 - 0 6 6 1 ( 9 8 ) 0 0 0 4 7 - 1
502 S.E. Mattsson et al. / Control Engineering Practice 6 (1998) 501—510
where Real is the name of a predefined type. A real that has two pins, p and n, a quantity, v, that defines the
variable has a set of attributes such as unit of measure, voltage drop across the component, and a quantity, i,
minimum value, maximum value and initial value. that defines the current into the pin p, through the
To simplify the use of Modelica, and to support com- component and out from the pin n. The equations define
patibility, there is an extensive standard library of type common relations between the quantities of a simple
definitions, which is always available with a Modelica electrical component. In order to be useful, a constitutive
translator. The type definitions in this base library are equation must be added. The keyword partial indicates
based on the naming conventions for physical quantities that this model class is incomplete. Between the name of
of the international standards ISO 31-1992, ‘‘General a class and its body a string is allowed. It is treated as
principles concerning quantities, units and symbols’’, and a comment attribute. Tools may display this documenta-
ISO1000-1992, ‘‘SI units and recommendations for the tion in special ways.
use of their multiples and of other units’’. Several of the A model of a resistor can be based on TwoPin. Just
ISO names are long, which make them awkward in add a parameter for the resistance and Ohm’s law to
practical modeling work. For this reason, shorter alias- define the behavior:
names are provided if necessary. The repeated use of the model Resistor ‘‘Ideal resistor’’
name ‘‘ElectricPotential’’ in a model becomes cumber- extends TwoPin;
some, and therefore ‘‘Voltage’’ is also provided as an parameter Resistance R;
alternative. equation
A connector class is defined as R*i"v;
end Resistor;
connector Pin
Voltage v; The keyword parameter specifies that the quantity is
flow Current i; constant during a simulation experiment, but can change
end Pin; values between experiments. A parameter is a quantity,
which makes it simple for a user to modify the behavior
A connection, connect (Pin1, Pin2) , with Pin1 and Pin2 of a model.
of connector class Pin, connects the two pins such that A model for an electrical capacitor is defined in a sim-
they form one node. This implies two equations, namely ilar way
Pin1.v"Pin2.v and Pin1.i#Pin2.i"0. The first equa-
tion indicates that the voltages on both the branches model Capacitor ‘‘Ideal capacitor’’
connected together are the same, and the second corres- extends Two Pin;
ponds to Kirchhoff’s current law saying that the current parameter Capacitance C;
504 S.E. Mattsson et al. / Control Engineering Practice 6 (1998) 501—510
6.1. An automatic gearbox model generated by the (hardware) ECU and fed to the simula-
tion processor via appropriate interfaces like digital IO
Gearshift dynamics can only be simulated if the input- and a CAN bus.
and output-torques of the gearbox represent a real-life Figure 3 shows the Modelica model of the automatic
vehicle maneuver. Therefore, at least the engine and the gearbox ZF4HP22 as a composition diagram. It is set up
longitudinal dynamics of the vehicle have to be modeled. by three standard planetary wheelsets, by shafts includ-
A Modelica model of such a system is given in Fig. 2 as ing wheel inertias, by clutches and by combined
a composition diagram using Dymola’s object diagram clutch/freewheel elements.
editor. Every icon in the composition diagram is an The vehicle drive-train model was built up by connect-
instance of a Modelica class, and represents a component ing basic components, like shafts and clutches. It is
of the drive train. Mechanical flanges of the components straightforward to develop the models for the basic com-
are modeled by Modelica connector classes, and are ponents by using torque balances and constitutive rela-
characterized by small square boxes in the icons. A line tions. The modeling of a freewheel will be discussed in
between two connectors defines a rigid, mechanical coup- more detail, in order to illustrate hybrid modeling in
ling between the respective components. Dashed lines Modelica.
represent directed signal flow connections. All the drive-train components have mechanical
The driving part of the system in Fig. 2 consists of the flanges which are used to connect components rigidly
engine, the torque converter and appropriate inertias. together, and which are defined by the following
The engine and converter are modeled by tables. The Modelica connector class:
driven part incorporates the automatic gearbox, the dif-
ferential gearbox, the wheels, the mass of the car, and connector DriveCut
aerodynamic forces. The component ControlBox repres- AngularVelocity w;
ents the ECU which generates the gearshift signals. For AngularAcceleration a;
offline simulations, simple ramp functions are used. Dur- flow Torque t;
ing hardware-in-the-loop simulations, these signals are end DriveCut;
model FreeWheel
DriveCut p, n;
at the other side of the transition is set to true. The finite
protected
automaton in Fig. 4 is connected to the dynamic model
AngularVelocity wrel ‘‘relative speed’’;
of the freewheel by adding the equation locked"
Torque tc ‘‘constraint torque, if stuck’’;
stuck.state in class FreeWheel. It means that locked is
Boolean locked ‘‘true if stuck’’;
true when and only when the stuck state is active.
equation
The state of the finite automaton does not change
wrel"p.w!n.w;
during integration. If a switching condition becomes true,
0"if locked then p.a!n.a else tc;
the exact time of that event is determined by an iterative
p.t"if locked then!tc else 0;
procedure, and the integration is stopped. The state of
p.t#n.t"0;
the automaton is changed, and the whole model is evalu-
// Switching dynamics.
ated based on the value of the new active state. As
end Free Wheel;
a result, another transition condition may become true.
The first equation determines the relative angular velo- Therefore, the model is evaluated and the finite automa-
city between elements connected by freewheel compo- ton is switched until no condition transition is any longer
nents. The second equation is essential. It states that in true. Mathematically, the procedure can be seen as a fix-
the stuck mode (locked"true) the relative angular accel- point iteration scheme to find a consistent configuration
eration is zero and that in sliding mode the constraint for the restart after an event. Finally the integration is
torque is zero. This is an equation with variable causality, restarted.
and it is not possible to solve it for one of the two The finite automaton in Fig. 4 is simple. It switches
if-branches. It turns out that such equations are always from forward to stuck when the relative speed wrel be-
part of an algebraic loop. The unknown variables in comes non-positive. When the constraint torque tc be-
this equation are determined by a system of algebraic comes positive, sliding occurs again. It is not possible to
equations. switch immediately from stuck to forward because the
The switching between stick and slip is modeled by relative speed is zero at the switching time and the au-
defining the behavior for locked. A finite state machine tomaton would at once switch back to stuck, since the
describing the switching behavior of a freewheel is shown transition condition of toStuck1 is fulfilled. Therefore, it
in Fig. 4. It uses components from a Modelica library for is switched to an intermediate state startForward. The
finite state machines and Petri nets. The details of this switching to forward takes place when the relative speed
library are outside the scope of this paper. The model has becomes greater than an epsilon-bound defined in the
three states: stuck, forward and startForward. These are simulator. When several freewheels or clutches switch at
instances of class place which has one connector with the the same time, it is also possible that the relative acceler-
Boolean variable state. Only one place object is active at ation becomes negative in the startForward state. In such
a time, meaning that its state is true. The transitions are a case the automaton switches back into the stuck state.
described by objects of class transition. The model has
the instances to Stuck1, to Forward etc. The condition 6.3. Real-time simulation
which fires a transition is defined at the transition object
(e.g. wrel 40). Firing a transition means that the active The Modelica translator of the Dymola modeling and
state is set to false, and the state of the object connected simulation environment takes the Modelica model
S.E. Mattsson et al. / Control Engineering Practice 6 (1998) 501—510 507
model BasicLiquid
Pressure p;
Temperature T;
Density rho;
SpecificHeatCapacity c;
end BasicLiquid;
Fig. 7. A conceptual picture of a heat exchanger.
Each actual liquid model must at least contain the
attributes p, T, rho and c, since an actual model must
contain all the public components of the default class.
connector FlowInlet
Note that an actual model need not be constructed by
Pressure p;
inheritance from the default class. Such a requirement
flow VolumeFlowRate q;
would have made it difficult to use models developed at
Temperature T;
various different places. There is just a requirement for
end FlowInlet;
agreement of the names and types of the components.
The heat exchanger interface is defined as In the future there will hopefully be standard models
available in Modelica for many media, in the same way
partial model HEXShell as there are databases for physical properties today.
‘‘Base class for heat exchanger models’’ Medium models may actually be implemented as interfa-
FlowInlet A1, A2, B1, B2 ‘‘Ports’’; ces to such databases.
parameter HEXParameters Pars; For water, it is often sufficient to use constant values
replaceable model LiquidA"BasicLiquid; for density and heat capacity:
replaceable model LiquidB"BasicLiquid;
end HEXShell; model BasicWaterModel"
BasicLiquid (rho"1000, c"4180);
It declares four ports: A1, A2, B1 and B2. The model This it means that rho and c become constant with the
does not assume any specific port to be an inlet or outlet. given values. It is not possible to change these values
Which ports are inlets and which ports that are outlets interactively between simulation runs. To allow this, the
will depend on the actual flows. It is assumed that the model must be declared as
ports A1 and B1 are at one end of the heat exchanger,
and that the ports A2 and B2 are at the other end. For model BasicWaterModel 1"Basic Liquid
example, if there is a flow from A1 to A2 and a flow from (redeclare parameter Density rho"1000,
B1 to B2, then the heat exchanger is operated as a par- redeclare parameter SpecificHeatCapacity
allel-flow heat exchanger. But if the flow in DuctB is c"4180);
from B2 to B1, then the heat exchanger is operated as which turns rho and c into parameters and sets default
a counter-flow heat exchanger. values, which may be changed interactively between
HEXShell declares a structured parameter Pars to simulation runs.
describe physical properties such as dimensions. They are It is important to include information that makes it
identified during the derivation of the behavior. possible to check the validity of a model. A simple ap-
proach is to specify ranges for the variables. The model
7.2. Liquid models for water is not valid when the water is freezing to ice or
boiling to steam. For normal pressures, the condition can
The heat-exchanger model needs models of the liquids be expressed in terms of the temperature, which should
flowing in the two ducts. The model HEXShell defines be between 273 K and 373 K. To include this condition in
two model class parameters, LiquidA and LiquidB, for the model, it is modified as
describing the properties of the media in the two ducts. model BasicWaterModel 2"
The idea is to have a well-defined interface between the BasicLiquid (T(Min"273, Max"373),
descriptions of the heat exchanger and the media to make rho"1000, c"4180);
it easy to modify the heat exchanger to cope with differ-
A more-general condition can be included in the equa-
ent media and descriptions of different complexity. The
tion section by specifying an assertion as
medium models are to be used in the duct models. On the
heat-exchanger level there is no use of medium models, assert condition;
but to make it easier for the user to change medium
models, the classes of the medium models are made into 7.3. Heat exchanger topology
parameters of the heat-exchanger model.
The default class BasicLiquid, specified by the model, Heat exchangers may internally look very different,
can be declared as but the basic idea is to let two media, which flow on the
S.E. Mattsson et al. / Control Engineering Practice 6 (1998) 501—510 509
two sides of the wall, exchange heat through the wall for the parameters of the elements. Some of the para-
without being mixed. The complexity of using partial meters have to be recalculated, since the section parts
differential equations to describe the heat transfer from have other physical dimensions than the heat exchanger
the hot side to the cold side can be avoided, since the itself.
objective is not to describe the internal behavior of the The parameter propagation is only indicated in Fig. 8.
heat exchanger, for example in order to calculate thermal The parameters of the elements of DuctA are set in the
stresses. A common approach which divides the heat following way:
exchanger into a number of slices or sections along the
direction of the flow will be taken. A model of a heat HEXDuctSection
exchanger is defined by putting together a number of DuctA [n]
duct-section models and wall-section models as shown in (Pars(V"Pars.DuctA.V/n, ...),
Fig. 8. redeclare model Liquid"LiquidA),
The model HEXn uses HEXShell as a base class and The declaration first sets the simple parameter Pars.
specifies in addition two arrays of duct-section models and V in terms of the parameters of HEXn. The construct
one array of wall-section models, which are of the same V"Pars.DuctA.V/n means that the default value of
length, parameterized by n. The equation section con- DuctA [i].Pars.V should be set to Pars.DuctA.V/n for
nects the pieces to each other, and to the ports of HEXn. 14i4n. Note, that the right-hand side is resolved in the
scope of HEXn. The declaration also sets an actual
model HEXn
model LiquidA for the replaceable model Liquid.
extends HEXShell;
parameter Integer n ‘‘Number of sections’’;
7.5. Duct-section and wall-section models
HEXDuctSection
DuctA [n]
The duct-section and the wall-section models include
(Pars(V"Pars.DuctA.V/n, ...)),
balance and transportation equations for a lumped com-
redeclare model Liquid"Liquid A),
partment (Mattsson, 1997). The duct-section model can
DuctB [n] (...);
be outlined as
HEXWallSection Wall [n] (...);
equation model HEXDuctSection
connect(A1, DuctA [1].Port1); FlowInlet Port1, Port2;
connect(B1, DuctB [1].Port1); WallConnector Wall;
for i in 1: n!1 loop parameter DuctParameters Pars;
connect(DuctA [i].Port2, DuctA [i#1].Port1); replaceable model Liquid"BasicLiquid;
connect(DuctB [i].Port2, DuctB [i#1].Port1); Liquid L1, L2 ‘‘The liquids at the two ports’’;
end for; Temperature T;
connect(DuctA [n].Port2, A2); Density rho;
connect(DuctB [n].Port2, B2); SpecificHeatCapacity c;
for i in 1: n loop Enthalpy H;
connect(DuctA [i].Wall, Wall [i].WA); equation
connect(DuctB [i].Wall, Wall [i].WB); // Mass balance
end for; // Momentum balance; static pressure drop
end HEXn; // Energy balance
end HEXDuctSection;
7.4. Parameter propagation
an algorithm of how to calculate the derivatives of the also to Clemens Schlegel, DLR, who has been involved in
state variables of the model. The fundamental physical the modeling of the automatic gearbox.
knowledge is not organized in that way. At the lowest
level, mass- and energy-balance equations and phenom-
References
enological equations are stated. At higher hierarchical
levels, technical systems are typically organized as com-
Barton, P., Pantelides, C., 1994. Modeling of combined discrete/con-
ponents with well-defined connections (mechanical, elec- tinuous processes. AIChE J., 40, 966—979.
trical, etc). The object-oriented methodology is very well Breunese, A.P., Broenink, J.F., 1997. Modeling mechatronic systems
suited for this organization. using the SIDOPS#language. In Proceedings of ICBGM’97, 3rd
This demanding scenario motivated the design of the International Conference on Bond Graph Modeling and Simula-
Modelica language for capturing model knowledge in tion, Simulation Series vol. 21(1), pp. 301—306. The Society for
Computer Simulation International.
a form suitable for easy reuse. The ideal scenario is that Elmqvist, H., Brück, D., Otter, M., 1996. Dymola — User’s Manual,
a user who wants to solve a real problem finds a ready- Dynasim AB, Research Park Ideon, Lund, Sweden.
made model in his model library. The second-best option Elmqvist, H., Otter, M., 1994. Methods for tearing systems of equations
is that he is able to develop the desired model by just in object-oriented modeling. In Proceedings of the European Simu-
putting together components from the model library by lation Multiconference, ESM’94, pp. 326—332. The Society for Com-
puter Simulation, Barcelona, Spain.
using a graphical editor. Fritzson, P., Viklund, L., Fritzson, D., Herber, J., 1995. High-level
The gearbox application, a subsystem of a vehicle, mathematical modeling and programming. IEEE Software, 12:3.
illustrates the power of Modelica for modeling, and that IEEE 1997. Standard VHDL Analog and Mixed-Signal Extensions.
the high-level description can be used to generate effi- Technical Report IEEE 1076.1. IEEE.
cient code for real-time, hardware-in-the loop simulation Jeandel, A., Boudaud, F., Ravier, P., Buhsing, A., 1996. U.L.M. Un
Langage de Modélisation, a modelling language. In Proceedings of
by the automatic use of computer algebra. Such a model the CESA’96 IMACS Multiconference. IMACS, Lille, France.
has complicated torque balances, especially since brakes Kloas, M., Friesen, V., Simons M., 1995. Smile — A simulation environ-
and clutches are engaged and disengaged by the elec- ment for energy systems. In Sydow, Ed., Proceedings of the 5th
tronic control unit. These balances and the propagation International IMACS — Symposium on Systems Analysis and Simu-
of events, like a clutch locking, need to be handled in lation (SAS’95), vol 18—19 of Systems Analysis Modelling Simula-
tion, pp. 503—506. Gordon and Breach Publishers.
real-time. Mattsson, S.E., 1997. On modeling of heat exchangers in Modelica. In
The second example, the heat exchanger unit, shows Proceedings of the 1997 European Simulation Symposium (ESS’97),
how Modelica promotes flexible model components. In pp. 127—133. The Society for Computer Simulation, Passau,
particular, it is demonstrated that Modelica indeed sup- Germany.
ports the decomposition of media properties from the Mattsson, S.E., Andersson, M., Aström, K.J., 1993. Object-oriented
modelling and simulation. In Linkens, Ed., CAD for Control Sys-
physical properties of the heat exchanger. It is very easy tems, chapter 2, pp. 31—69. Marcel Dekker Inc, New York.
to change media, or the complexity of media models. Otter, M., Schlegel, C., Elmqvist, H., 1997. Modeling and realtime
The object-oriented, non-causal modeling methodo- simulation of an automatic gearbox using modelica. In Proceedings
logy, on which Modelica is based, has been used in of the 1997 European Simulation Symposium (ESS’97), pp. 115—126.
demanding industrial applications in different domains. The Society for Computer Simulation, Passau, Germany.
Piela, P., Epperly, T., Westerberg, K. Westerberg, A., 1991. ASCEND:
After the introduction of the Modelica language, reusable An object-oriented computer environment for modeling and analy-
model libraries are being developed, the methodology is sis: the Modeling Language. Computers and Chemical Engineering,
being promoted by writing text books and giving courses, 15:1, pp. 53—72.
and several simulation-tool vendors are adapting to Sahlin, P., Bring, A., Sowell, E. F., 1996. The Neutral Model Format for
Modelica in order that model libraries can be exchanged Building simulation, version 3.02. Technical Report. Department of
Building Sciences, The Royal Institute of Technology, Stockholm,
between tools. Sweden
Strauss (ed.), J.C., 1967. The SCi continuous system simulation lan-
guage (CSSL). Simulation 9, 281—303.
Acknowledgements Vangheluwe, H.L., Kerckhoffs, E.J., Vansteenkiste, G.C., 1996. Simula-
tion for the Future: Progress of the ESPRIT Basic Research Work-
ing Group 8467. In Bruzzone and Kerchkhoffs, Eds., Proceedings
The authors would like to thank the other members of of the 1996 European Simulation Symposium (Genoa), pp.
the Modelica Design Group for inspiring discussions, XXIX—XXXIV. Society for Computer Simulation International
and their contributions to the Modelica design. Thanks (SCS).