0% found this document useful (0 votes)
39 views10 pages

Physical Systems Modeling With Modelica

Uso de kinguagem para calculo de vida util de equipamentos

Uploaded by

Argelio Paniago
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
39 views10 pages

Physical Systems Modeling With Modelica

Uso de kinguagem para calculo de vida util de equipamentos

Uploaded by

Argelio Paniago
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

Control Engineering Practice 6 (1998) 501—510

Physical system modeling with Modelica


Sven Erik Mattsson,!,* Hilding Elmqvist," Martin Otter#
!Dept. of Automatic Control, Lund University, Box 118, SE-221 00 Lund, Sweden
"Dynasim AB, Research Park Ideon, SE-223 70 Lund, Sweden
#DLR Oberpfaffenhofen, D-82230 Wessling, Germany
Received 8 October 1997; accepted 9 February 1998

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

1. Introduction Section 3. Section 4 describes the fundamentals of


Modelica, and Section 5 summarizes the more powerful
Mathematical modeling and simulation are emerging constructs. Sections 6 and 7 discuss two industrial ap-
as key technologies in engineering. Relevant com- plications: automatic gearboxes and heat exchangers.
puterized tools, suitable for integration with traditional
design methods, are essential to meet the future needs of
efficient engineering. 2. Background
In September 1996 an international effort started to
design a new language for physical modeling. The main There is a large amount of simulation software on the
objective is to make it easy to exchange models and market. Most languages and model representations are
model libraries, and to allow users to benefit from the proprietary, and were developed for certain tools. There
advances in object-oriented modeling methodology. The are general-purpose tools such as ACSL, SIMULINK
language is called Modelica1. Version 1 was released in and SystemBuild. They are based on the same modeling
Sept. 1997. methodology: input-output blocks as used in the first
The aim of this paper is to give an introduction to standardization effort, CSSL, from 1967 (Strauss, 1967).
Modelica, and to show how it is used in real applications. There are domain-oriented packages: electronic pro-
Section 2 gives background information and the moti- grams (SPICE, Saber), multibody systems (ADAMS,
vation for the design of a new, uniform, standardized DADS, SIMPACK), chemical processes (ASPEN Plus,
representation for models of physical systems. A short SpeedUp), etc. With a few exceptions, all these packages
description of the Modelica design effort is given in are strong in only one domain, and are not capable of
modeling components in other domains in a reasonable
way. This is a major disadvantage, since technical sys-
*Corresponding author. E-mail: [email protected] tems are becoming more and more heterogeneous, with
1 Modelica is a trade mark of the Modelica Design Group. components from many engineering domains.

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

Techniques for general-purpose physical modeling Table 1


have been developed during the last few decades, but The authors of the Modelica definition
have not received much attention from the simulation
Hilding Elmqvist, Dynasim AB, Lund, Sweden
market. The modern approaches build on non-causal Fabrice Boudaud, Gaz de France
modeling, with true equations and the use of object- Jan Broenink, Univ. of Twente, Netherlands
oriented constructs to facilitate the reuse of modeling Dag Brück, Dynasim AB, Lund, Sweden
knowledge. There are already several modeling lan- Thilo Ernst, GMD-FIRST, Berlin, Germany
guages with such support, available from universities and Peter Fritzson, Linköping University, Sweden
Alexandre Jeandel, Gaz de France
small companies. Examples of such modeling languages Kaj Juslin, VTT, Finland
are ASCEND (Piela et al., 1991), Dymola (Elmqvist et al., Matthias Klose, Technical Univ. of Berlin
1996), gPROMS (Barton and Pantelides, 1994), NMF Sven Erik Mattsson, Lund University, Sweden
(Sahlin et al., 1996), ObjectMath (Fritzson et al., 1995), Martin Otter, DLR Oberpfaffenhofen, Germany
Omola (Mattsson et al., 1993), SIDOPS#(Breunese and Per Sahlin, BrisData AB, Stockholm, Sweden
Hubertus Tummescheit, DLR Cologne, Germany
Broenink, 1997), Smile (Kloas et al., 1995), U.L.M. (Jean- Hans Vangheluwe, University of Gent, Belgium
del et al., 1996) and VHDL-AMS (IEEE, 1997). There is
significant experience of using these languages in various
applications. The aim of the Modelica effort is to unify
the concepts of these languages, in order to introduce
a common basic syntax and semantics, and to design
a new unified modeling language for the modeling of
physical systems.

3. The Modelica effort

The Modelica effort started in the continuous-time


domain, since there is a common mathematical frame-
work in the form of differential-algebraic equation (DAE)
systems and there are several existing modeling lan-
guages based on similar ideas. There is also significant
experience of using these languages in various applica-
tions. It was thus appropriate to collect all the knowledge Fig. 1. A simple electrical circuit.
and experience in order to design a new unified modeling
language or neutral format for model representation. The
short-range goal was to design a modeling language 4. Fundamentals of Modelica
based on DAE systems, with some discrete-event features
to handle discontinuities and sampled systems. The de- As an introduction to Modelica, the modeling of
sign should allow an evolution to a multi-formalism, a simple electrical circuit, as defined in Fig. 1, will be
multi-domain, general-purpose modeling language. considered. The system can be broken up into a set of
The activity started in September 1996 as an effort connected standard electrical components. ¹here are
within the ESPRIT project ‘‘Simulation in Europe Basic a voltage source, two resistors, an inductor, a capacitor
Research Working Group (SiE-WG)’’ (see Vangheluwe and a ground point. Models of these components are
et al. (1996) and http://hobbes.rug.ac.be/SiE/). typically available in model libraries. Using a graphical
In February 1997 the Modelica design effort became model editor, a model can be defined by drawing a com-
a Technical Committee of the Federation of European position diagram as shown in Fig. 1, by positioning icons
Simulation Societies, EUROSIM, with Hilding Elmqvist that represent the models of the components and draw-
as chairman of the group. Version 1 of the Modelica ing connections.
language definition was finished in September 1997. The The corresponding Modelica model looks like
authors of the Modelica definition are listed in Table 1. model circuit
The work is now focused on the design of stan- Resistor R1 (R"10);
dard function and model libraries, as well as on tool VsourceAC AC;
development. Capacitor C (C"0.01);
The language definition and other information on Ground G;
the Modelica effort are available on the WWW at Resistor R2 (R"100);
http://www.Dynasim.se/Modelica/. Inductor L (L"0.1);
S.E. Mattsson et al. / Control Engineering Practice 6 (1998) 501—510 503

equation sums to zero at a node. Similar laws apply to flow rates


connect (AC.p, R1.p); // Capacitor circuit in a piping network, and to forces and torques in a
connect (R1.n, C.p); mechanical system. The sum-to-zero equations are
connect (C.n, AC.n); generated when the prefix flow is used in the connector
connect (R1.p, R2.p); // Inductor circuit declarations. In Modelica it is assumed that the value
connect (R2.n, L.p); is positive when the current or the flow is into the
connect (L.n, C.n); component.
connect (AC.n, G.p); Defining a set of connector classes is a good start when
end circuit; developing model libraries for a new application domain.
This composite model specifies the topology of the sys- It promotes compatibility of the component models.
tem to be modeled. It specifies the components, and the A common property of many electrical components is
connections between the components. that they have two pins. This means that it is useful to
The statement ‘‘Resistor R1 (R"10)’’; declares a com- define a ‘‘shell’’ model class
ponent R1 of class Resistor, and sets the default value of
the resistance R to 10. partial model Two Pin
Connections specify interactions between components. ‘‘Shell model with two electrical pins’’
In other modeling languages, connectors are referred to Pin p, n;
as ‘‘cuts’’, ‘‘ports’’ or ‘‘terminals’’. A connector must con- Voltage v;
tain all the quantities needed to describe the interaction. Current i;
The quantities voltage and current are needed for electri- equation
cal components. Their types are declared as v"p.v!n.v;
p.i#n.i"0;
type Voltage"Real (unit"‘‘V’’); i"p.i;
type Current"Real (unit"‘‘A’’); end TwoPin;

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

equation where some PID controllers are replaced with auto-


C*der(v)"i; tuning controllers. It is of course possible just to replace
end Capacitor; those controllers in a graphical user environment, i.e., to
create a new model. The problem with this solution is
where der(v) means the time derivative of v. that two models must then be maintained. Modelica has
A model for the voltage source can be defined as the capability, instead, to just substitute the model class
model VsourceAC ‘‘Sine-wave voltage source’’ of certain components using a language construct at the
extends Two Pin; highest hierarchical level, so that only one version of the
parameter Voltage VA"220 ‘‘Amplitude [V]’’; rest of the model is needed. The use of model class
parameter Frequency f"50 ‘‘Frequency [Hz]’’; parameters to support machine-medium decomposition
protected is illustrated in Section 7.2.
constant Real PI"3.141592653589793; Realistic physical models typically contain discontinu-
equation ities, events and changes of structure. Examples of such
v"VA*sin(2*PI*f*time); phenomena are relays, switches, friction, impact, sampled
end VsourceAC; data systems, etc. Modelica supports such models by
discontinuous and instantaneous equations, and by
The purpose of the ground model a built-in parameter of block classes to enable and dis-
able block components during simulation. The language
model Ground ‘‘Ground’’ elements are powerful enough to also realize, for
Pin p; example, finite state machines and Petri nets. Special
equation design emphasis is given to the synchronization and
p.v"0; propagation of events and the possibility to find consis-
end Ground; tent restarting conditions after an event. Hybrid
is twofold. First, it defines a reference value for the modeling and simulation are illustrated and discussed in
voltage levels. Secondly, the connections will generate Section 6.2.
one Kirchhoff’s current law too many. The ground Algorithms and functions are supported in Modelica for
model handles this by introducing an extra current modeling parts of a system in procedural programming
quantity p.i. style. Constructs for including graphical annotations are
available, in order that icons and model diagrams also
become portable. An extensive Modelica base library
5. More advanced modeling features contains standard variable and connector types to pro-
mote reuse by standardizing on interfaces.
The Modelica language has been introduced by giving
small examples. Model classes and their instantiation
form the basis of hierarchical modeling; connectors and 6. Application: an automatic gearbox
connections correspond to physical connections of com-
ponents. At the lowest level, equations are used to de- The modeling of automatic gearboxes for the purpose
scribe the relations between the quantities of the model. of hardware-in-the-loop simulation will now be dis-
The expressive modeling power of Modelica is large. cussed. A more detailed description is given in Otter
Some of the more powerful constructs are summarized et al. (1997). Comfort standards regarding gearshifts in
below. Modeling of, for example, multi-body systems, automatic gearboxes in vehicles are increasing continual-
control systems and approximations to partial differen- ly. Gearshift comfort is mainly influenced by control of
tial equations is conveniently done by utilizing matrix the switching elements of a gearbox: clutches and free-
equations. Multi-dimensional matrices and the usual wheels. Control is performed mostly by an electronic
matrix operators and matrix functions are thus sup- control unit (ECU). Fine tuning of the ECU and the
ported in Modelica. It is also possible to have arrays of switching elements is essential in order to optimize gear-
components, and to define regular connection patterns. shift comfort.
A typical usage is the modeling of a distillation column Modeling such a system is difficult, since the structure
which consists of a set of trays connected in series. of the system varies during each gearshift: depending on
The use of component arrays for spatial discretization the actual control, different wheels and freewheels are
of distributed-parameter systems is illustrated in engaged or disengaged. The integrator has to be stopped
Section 7.3. and the new structure has to be determined in accord-
So far only component parameters such as the resist- ance with the actual forces imposed on the gearwheels by
ance value have been discussed. The reuse of model the switching elements. In the example treated here, the
library components is further supported by also allowing automatic gearbox has 6 switching elements, leading to
model class parameters. An example is a controlled plant 26"64 possible configurations of the system.
S.E. Mattsson et al. / Control Engineering Practice 6 (1998) 501—510 505

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;

Fig. 2. Composition diagram of vehicle drive train.

Fig. 3. Composition diagram of gearbox ZF4HP22.


506 S.E. Mattsson et al. / Control Engineering Practice 6 (1998) 501—510

The keyword flow implies that the torques should be


summed to zero at connection points.

6.2. A freewheel model

A parallel connection of a clutch and a freewheel leads


to a one-way clutch. This is a variable-structure system
because the two shafts can stick or slip relative to each
other. The number of states is changing during
a transition from stick to slip, and vice versa. This com-
plicates the modeling. It is common practice to use the
additional constraint equation that the relative angular
acceleration vanishes while the clutch or freewheel is
stuck. Since the relative angular velocity is zero when
reaching the stuck state, it remains zero due to this
constraint equation. A freewheel model can be defined as Fig. 4. Switching structure of a freewheel.

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

Fig. 5. Automatically created animation of gear box.

shown in Fig. 2 as an input, generates a differential-


algebraic equation system, and transforms it to state
space form by the use of symbolic manipulation and
graph-theoretical algorithms. The original sorted equa-
tions contain a linear system of 49 simultaneous equa- Fig. 6. A schematics of the heat exchanger unit TS30 with a measure-
tions, due to the shafts connected via rigid gearboxes, and ment logging system.
due to the clutch and freewheel equations. Via tearing
(Elmqvist and Otter, 1994) this system of equations is
reduced to ten linear equations which are solved by
standard numerical procedures whenever the model is has been used to simulate a TS30 unit from Alfa-Laval
evaluated. The final equations can be output in different Thermal for the heating and production of hot tap water
forms, depending on which simulator is to be used. for a one-family house. Fig. 6 contains a schematic dia-
The simulation results can be imported to the 3D gram where the radiator part is left out. In the primary
animation module of Dymola. Dymola presents a 3D circuit, flows hot district heating water, which is used to
view with hidden surfaces removed and shading as shown heat the water in the secondary circuit to produce hot tap
in Fig. 5. Dymola uses the Open GL standard, and water. There is a very good agreement between measured
hardware accelerators on graphics boards. The visual 3D and simulated behavior (Mattsson, 1997).
model is automatically generated from the composition Heat exchangers are very common components in
diagrams of Fig. 2 because the components of the drive- chemical process systems and energy systems, including
train library contain instances of built-in visual shapes power generation and heating and ventilation. To min-
like cylinders and gear wheels. The drive-train compo- imize energy losses, it is important to have optimal sys-
nents have some additional visual parameters, such as tems, where both the static and the dynamic properties of
radius and position along the shaft. the components are adjusted to each other. Typically, the
For real-time simulation, Matlab CMEX code can be static behavior of a heat exchanger is well-known, while
generated and used in the Mathworks Realtime Work- the dynamic behavior of a system of connected valves,
shop. The time for the evaluation of one Euler step was pumps and heat exchangers is less known. Thus, there is
measured as 2.4 ms on a Texas Instruments C40 DSP, a need for dynamic simulation.
and 0.3 ms on a 300 MHz DEC alpha processor (both PC
plugin cards by dSPACE Inc.). A typical gearbox ECU
sampling time is 10 ms. This offers enough margin for 7.1. Basic model structure
model refinement and IO using today’s typical hardware-
in-the-loop simulation processors. The first step of the object-oriented modeling ap-
proach is to identify the ways in which a component can
interact with its environment. Its behavior can then be
7. Application: heat exchanger described either in terms of equations, or as interconnec-
ted components. The modeling approach is hierarchical.
A heat-exchanger model which describes the relations A heat exchanger has two ducts with two ports, to each
between the pressures, the rates and the temperatures of of which other components can be connected. See Fig. 7.
the flows at the four ports of the heat exchanger will be The status at a port of the heat exchanger can be de-
outlined. For clarity, the focus is on heat exchangers scribed by one pressure, one temperature and one vol-
where the media are single-medium liquids. Basic rela- ume flow rate, if single-medium liquid flows are assumed,
tions, which can be found in good standard textbooks, and if there is no interest in describing pressure, temper-
are used to describe the behavior. The complete ature or velocity profiles over the port area. To support
Modelica model is given in Mattsson (1997). The model this, a connector class is defined as
508 S.E. Mattsson et al. / Control Engineering Practice 6 (1998) 501—510

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

The declarations of the component models include 8. Conclusion


hierarchical parameter propagation to set default values
There is a growing need in industry to be able to model
complete, heterogenous systems, such as a vehicle or
a paper machine. Modeling a heterogenous system
means that a general-purpose simulator needs to be used
because the special-purpose simulators are useful in only
one domain like electronics or mechanics.
Using today’s tools, such a modeling task is very
time-consuming because the reuse of models is not well
supported. The general-purpose simulators are based on
Fig. 8. The base model of a heat exchanger. a block-diagram description of the model, i.e., essentially
510 S.E. Mattsson et al. / Control Engineering Practice 6 (1998) 501—510

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).

You might also like