Fishwick P.A. (editor) Handbook of Dynamic System Modeling
Подождите немного. Документ загружается.
35-16 Handbook of Dynamic System Modeling
fairly easy for them to write models with COST, and, more importantly, to take the component-based
approach to model the system to be simulated. Once a component repository with a wide range of models
is developed, the modeler will be able to construct a simulation just by connecting components obtained
from the component.
COST is a discrete-event simulator written in C++ that embodies a component-oriented modeling
style. At the heart of COST is a component-port model that is distinguished from many developed
component models by the notion of output ports. Our simulation component classification allows us to
extend such a component-port model to make it well suited for discrete-event simulation by introducing
the implicit timestamp mechanism and timers.
The most distinct feature of COST is the component reusability. Components developed for one
simulation can be effortlessly reused in other simulations. With an extensive set of library components,
writing simulation in COST could be as simple as dragging a few components from the library and
connecting them, as some commercial simulators do. The extra advantage of COST is that building
components from scratch is simple.
The only inefficiency of COST simulations comes from the message exchange between components,
which may involve several layers of function calls and a few virtual function table lookups. However, this
is rather the deficiency of the C++ language, not of the underlying component-port model, because
theoretically such overhead can be eliminated during the configuration phase. Had we had a truly
component-oriented language, COST would have achieved perfect efficiency.
References
Austern, M. H., 1999. Generic Programming and the STL. Addison-Wesley, Reading, MA.
Branch, J., Chen, G., and Szymanski, B. K., 2005. ESCORT: Energy-Efficient Sensor Network Communal
Routing Topology Using Signal Quality Metrics. Proceedings of the International Conference on
Networking—ICN 2005, Vol. 3420, pp. 438–448. LNCS, Springer, Berlin.
Chen, G. G., Branch, J. W., and Szymanski, B. K., 2005. Self-Selective Routing for Wireless Ad Hoc
Networks. Proceedings of the IEEE International Conference on Wireless and Mobile Computing,
Networking and Communications WiMob 2005, Vol. 3, pp. 57–64.
Chen, G. G., Branch, J.W., and Szymanski,B.K., 2006. A Self-Selection Technique for Flooding and Routing
in Wireless Ad-Hoc Networks. Journal of Network and Systems Management, 14 (3), 359–380, 2006.
Chen, G. and Szymanski, B. K., 2001. Component-Based Simulation. Proceedings of the. 2001 European
Simulation Multi-Conference, pp. 68–75. SCS Press, Delft, Netherlands.
DEVS, 2004. http://acims.arizona.edu
Fishwick,P. A., 1992. SIMPACK:Getting Started with Simulation Programming in C and C++. Proceedings
of the 1992 Winter Simulation Conference, eds. J. J. Swain, D. Goldsman, R. C. Crain, and J. R. Wilson,
pp. 154–162.
GloMoSim, 2004. http://pcl.cs.ucla.edu/projects/glomosim/
Gomes, F., Franks, S., Unger, B., Xiao, Z., Cleary, J., and Covington, A., 1995. SIMKIT: A High Perfor-
mance Logical Process Simulation Class Library in C++. Proceedings of the 1995 Winter Simulation
Conference, eds. C. Alexopoulos, K. Kang, W. R. Lilegdon, and D. Goldsman, pp. 706–713.
Javasim, 2004. http://www.j-sim.org/
Law, A. M. and Kelton, W. D., 1982. Simulation Modeling and Analysis. McGraw-Hill, New York.
Musser, D. R. and Saini, A., 1996. STL Tutorial and Reference Guide. Addison-Wesley, Reading, MA. ns2,
1990. http://www.isi.edu/nsnam/ns/
Qualnet, 2004. http://www.scalable-networks.com/
ssfnet, 2006, http://www.ssfnet.org/
Zeigler, B. P., Kim, D., and Praehofer, H., 1997. DEVS formalism as a framework for advanced distributed
simulation. Proceedings of the 1st International Workshop on Distributed Interactive Simulation and
Real Time Applications.
V
Case Studies
V-1
36
Multidomain Modeling
with Modelica
Martin Otter
DLR Institute of Robotics and Mechatronics
Hilding Elmqvist
Dynasim AB
Sven Erik Mattsson
Dynasim AB
36.1 Modelica Overview .....................................................36-1
36.2 Modelica Basics ...........................................................36-3
Component Coupling
•
Discontinuous
Systems
•
Relation-Triggered Events
•
Variable
Structure Systems
•
Other Language Elements
36.3 Modelica Libraries ......................................................36-17
36.4 Symbolic Processing of Modelica Models ................. 36-19
Sorting and Algebraic Loops
•
Reduction of Size
and Complexity
•
Index Reduction
•
Example
36.5 Outlook ........................................................................36-25
36.1 Modelica Overview
Modelica
1
is a freely available language to model the dynamic behavior of technical systems based on
schematics. This chapter gives an overview of the language features, free and commercial Modelicalibraries,
as well as symbolic algorithms needed to transform the high-level description of Modelica into a form that
is suited for a numerical integration algorithm.
Modelica is suited for multidomain modeling of large, complex, and heterogeneous technical systems,
for example,
•
mechatronic models in robotics, automotive, and aerospace applications involving mechanical,
electrical, hydraulic, thermal, and control subsystems,
•
process-oriented models with multiphase and multisubstance fluids in pipe networks such as air
conditioning systems, batch processes or machine cooling, and
•
generation, distribution, and consumption of electric power.
Modelica is designed such that it can be utilized in a similar way as an engineer builds a real system:
first trying to find standard components like motors, pumps, and valves from manufacturers’ catalogues
with appropriate specifications and interfaces and only if there does not exist a particular subsystem, a
component model would be newly constructed based on standardized interfaces.
A typical example of a Modelica model, the components of a system model of a vehicle, is sketched in
Figure 36.1 below by screenshots of Modelica schematics and of three-dimensional animations of some
of the vehicle components (component animation can also be specified in a Modelica model based on
primitives and on CAD data).
1
Modelica® is a registered trademark of the Modelica Association.
36-1
36-2 Handbook of Dynamic System Modeling
FIGURE 36.1 Schematics and three-dimensional animations of vehicle components modeled in Modelica. (From
Hubertus Tummescheit Modelon AB, Sweden.)
Multidomain Modeling with Modelica 36-3
Models in Modelica are mathematically described by differential, algebraic, and discrete equations.
2
Modelica is designed such that available, specialized algorithms can be utilized to enable efficient han-
dling of large system models having more than hundred thousand equations. It is suited and used for
hardware-in-the-loop simulations and for embedded control systems. Modelica is not designed for the
direct description of partial differential equations, as, e.g., performed by finite element or computational
fluid dynamics programs. However, results of finite element computations are utilized in Modelica, e.g.,
for the description of flexible bodies.
The Modelica language is a textual specification that describes details of a model on a high level. To
be useful, a Modelica modeling and simulation environment is needed to graphically edit and browse a
textually defined Modelica schematic, to transform the model in a form that is better suited for reliable
integration, to simulate the model, to visualize the simulation results, and to import Modelica models in
other simulation environments such as Simulink
3
(see Chapter 37). A growing number of such Modelica
environments are available commercially and also in the “public domain.” For an actual overview, see
http://www.Modelica.org/tools.
Reuse is a key issue for handling complexity. There have been several attempts to define object-oriented
languages for modeling of technical systems. However, the ability to reuse and exchange models relies on
a standardized format. It was thus important to bring this expertise together to unify concepts and nota-
tions: the Modelica design effort was initiated and headed by Hilding Elmqvist and started in September
1996. The language has been designed by the developers of the object-oriented modeling languages Allan,
Dymola, NMF, ObjectMath, Omola, SIDOPS+, Smile, by computer scientists, and by modeling specialists
from the mechanical, electrical, electronic, hydraulic, pneumatic, fluid, and control domain. The non-
profit Modelica Association was formed in 2000 with Martin Otter as chairman, to manage the continually
evolving Modelica language and the development of the free Modelica standard library. In the same year,
Modelica was used the first time in actual applications. As of 2006, there are more than 1000 users of
Modelica. More details, especially the actual language specification, free Modelica libraries, downloadable
publications, links to Modelica modeling, and simulation environments as well as to Modelica consul-
tants can be found at the Modelica homepage http://www.Modelica.org/. Also books about Modelica are
available, such as Tiller (2001) and Fritzson (2003).
36.2 Modelica Basics
Modelica supports both high-level modeling by composition of components and low-level modeling by
implementing basic components with equations. Models of standard components are typically available
in model libraries. Using a graphical model editor from a Modelica environment, a model can be defined
by drawing a composition diagram (also called schematics) by positioning icons that represent the models
of the components, drawing connections, and giving parameter values in dialogue boxes. Constructs for
including graphical annotations in the Modelica language make icons and composition diagrams portable
between different tools. An example of a compositiondiagram of a simple drive train is shown in Figure 36.2
below.
The system can be decomposed into a set of connected components: an electrical motor, a gear,
a load inertia, and a controller. Every component is represented by an illustrative icon. At the bor-
der of a component icon “connectors” are present. A line drawn between two connectors represents
the actual physical coupling, such as electrical wire, rigid mechanical coupling, or fluid pipe flow.
The textual representation of this Modelica model is (graphical annotations are not shown; from
2
“Discrete” equations are either equations that are active at distinct points in time only (e.g. at a sampling instant)
or equations that are used to compute Integer or Boolean variables.
3
Simulink® is a registered trademark of The MathWorks Inc.
36-4 Handbook of Dynamic System Modeling
Ref
Controller
Motor
Gear
Inertia
J 10
PID
FIGURE 36.2 Modelica schematic of a simple drive train consisting of a controlled motor, a gear, and a load inertia.
i_ref
Resistor
Signalvoltage
Speedsensor W
W
Inductor
emf
k 1.2
R 0.5
L 0.05
Ground
Flange
Inertia
J 0.001
FIGURE 36.3 Modelica schematic of a direct current motor.
these graphical annotations the schematic in Figure 36.2 is constructed by a Modelica schematic
editor):
model MotorDrive
PID controller;
Motor motor;
Gearbox gear (ratio=100);
Inertia inertia(J=10);
equation
connect(controller.y , motor.i_ref);
connect(controller.u2, motor.w);
connect(gear.flange_a, motor.flange);
connect(gear.flange_b, inertia.flange_a);
end MotorDrive;
This is a composite model which specifies the topology of the system to be modeled in terms of components
and connections between the components. The statement “Gearbox gear(ratio=100);” declares
a component gear of model class Gearbox and sets the value of the gear ratio, ratio,to100.
A component model may be a composite model to support hierarchical modeling. The composition
diagram of the model class Motor is shown in Figure 36.3. On the left side, the reference current i_ref
is an input signal, whereas on the right side the flange is a one-dimensional rotational mechanical
connector.
The meaning of connections will be discussed below as well as the description of behavior on the lowest
level using mathematical equations.
Multidomain Modeling with Modelica 36-5
Physical modeling deals with the specification of relations between physical quantities. For the drive
system, quantities such as angle and torque are of interest. Their types are declared in Modelica as
type Angle = Real(quantity="Angle" , unit="rad",
displayUnit="deg");
type Torque = Real(quantity="Torque", unit="N.m");
where Real is a predefined type, which has a set of attributes such as name of quantity, unit of measure,
default display unit for input and output, minimum, maximum, nominal, and initial value. The Modelica
Standard Library, which is a free library developed by the Modelica Association, includes about 450 of
such type definitions based on ISO 31-1992“General principles concerning quantities, units and symbols”
and on ISO 1000-1992 “SI units and recommendations for the use of their multiples and of certain other
units.”
Connections specify interactions between components and are represented graphically as lines between
connectors. A connector should contain all quantities needed to describe the interaction. For example,
node potential v and current i are needed for electrical components. Angle phi and cut-torque tau are
needed for drive train elements:
connector Pin connector Flange
Voltage v; Angle phi;
flow Current i; flow Torque tau;
end Pin; end Flange;
Two connections,
connect(pin1, pin2);
connect(pin1, pin3);
with pin1, pin2, and pin3 of connector class Pin, connects the three pins together at one node. This
implies three equations,
pin1.v = pin2.v
pin1.v = pin3.v
pin1.i + pin2.i + pin3.i = 0
The first two equations indicate that the electrical potentials on the connected branches are the same, and
the third corresponds to Kirchhoff’s current law stating that the current sums to zero at a node. Similar
laws apply to mass flow rates in piping networks and to cut-forces and torques in mechanical systems. The
sum-to-zero equations are generated when the prefix flow is used in the connector declarations. The
Modelica Standard Library includes also connector definitions (details see below).
To build reusable descriptions, partial models can be defined and reused. For example, a common
property of many electrical components is that they have two pins. This means that it is useful to define
an interface model class OnePort, that has two pins, p and n, and a quantity, v, that defines the voltage
drop across the component.
partial model OnePort
Pin p, n;
Voltage v;
equation
v = p.v - n.v;
0 = p.i + n.i;
end OnePort;
The equations define common relations between quantities of a simple electrical component. The equa-
tionsinanequation section are mathematical equations of the form “expression =expression.” The
36-6 Handbook of Dynamic System Modeling
alternative is an algorithm section that contains assignment statements of the form “variable := expres-
sion.” During code generation, equations are sorted and further manipulated, whereas assignment
statements in algorithm sections are not changed (details are given in Section 36.4 below).
The keyword partial indicates that the model is incomplete and cannot be instantiated. To be useful,
a constitutive equation must be added. A model for an inductor extends OnePort by adding a parameter
for the inductance and the appropriate equation:
model Inductor "Idealized inductor"
extends OnePort;
parameter Inductance L "Inductance";
equation
L*der(p.i) = v;
end Inductor;
A string between the name of a class and its body as well at the end of each statement (before the semicolon)
is treated as a description text. Tools may display this documentation in special ways, e.g., in parameter
menus, or as automatic labels in plots. The keyword parameter specifies that the quantity is constant during
a simulation experiment, but can change values between experiments. The built-in operator der(..) defines
the time derivative of the referenced variable.
36.2.1 Component Coupling
An important and difficult design decision is the definition of component interfaces, called “connectors”
in Modelica. One possibility would be to follow the bond graph approach (see, e.g., Karnopp et al., 2000;
Cellier, 1991) that models primarily the energy flow between components. The energy flow, i.e., power P,
is provided as the product of two variables, such as “P =velocity ×force” and the two variables are used
in a connector (one of them has to have the “flow” prefix). This approach is only useful in special cases
and is utilized in Modelica for electrical and magnetic connectors and in the free BondLib library (Cellier
and Nebot, 2005). For other domains, a more general approach is needed that is based on the following
requirements and that includes the bond graph connectors as a special case:
1. A connector should contain an independent set of variables that describes the desired physical effects
in the interface. Usually, mean values over the interface area are used, e.g., a resultant cut-torque.
4
2. When connecting components together, the relevant balance equations and the relevant boundary
conditions for the infinitesimal small connection point must be generated by the Modelica connec-
tion semantics (variables without the flow prefix are equal and the sum of the variables with the
flow prefix is zero).
Typical balance equations are energy balance, mass balance, momentum balance, equilibrium of cut-forces,
and cut-torques. Typical boundary conditions are the equality of position, angle, temperature, or pressure of
the connected components. This last rule guarantees the fundamental requirement that balance equations
are not only fulfilled within a component, but also when components are connected together.
As an example for balance equations, assume that three rotational mechanical flanges f1, f2, and f3
are connected together. With the definition of connector “Flange” above, the following equations are
generated:
f1.phi = f2.phi;
f2.phi = f3.phi;
0 = f1.tau + f2.tau + f3.tau;
4
Variables c
i
in a connector are not independent, if at least one variable c
j
can be computed by algebraic equations,
by differentiation and/or by integration from the other variables c
k
in the connector. In Modelica it is possible to have
a redundant set of variables in a connector. In such a case, there are unnecessary restrictions how components can be
connected together, especially if the connection structure contains a loop.
Multidomain Modeling with Modelica 36-7
The first two equations state the boundary condition that connected absolute flange angles at the connection
point are identical. The last equation states torque equilibrium at the connection point. Other balance
equations are not taken into account for one-dimensional rotational mechanics. From the above equations,
it follows indirectly that also the energy balance is fulfilled, since
P=der(f1.phi)*f1.tau + der(f2.phi)*f2.tau + der(f3.phi)*f3.tau
= der(f1.phi)*(f1.tau + f2.tau + f3.tau)
= der(f1.phi)*0
=0
Note, in bond graph methodology, angular velocity and cut-torque are used as variables here. The dis-
advantage is that a connection with the bond graph connectors does no longer guarantee the equality of
connected angles, as needed, e.g., for servo systems where angles are controlled.
A more complicated example is the connector for multiphase, thermo-fluid pipe flow of one substance
(Elmqvist et al., 2003):
connector FlowPort "Thermo-fluid flow of multi-phase substance"
AbsolutePressure p "Pressure in connection point";
SpecificEnthalpy h "Specific mixing enthalpy";
flow MassFlowRate m_flow "Mass flow in to component";
flow EnthalpyFlowRate H_flow "Enthalpy flow in to component";
end FlowPort;
When using this connector, it is required that the specific mixing enthalpy h in the port is only referenced in
the following equation of a component that computes the enthalpy flow rate H_flow from the upstream
specific enthalpy (= the specific enthalpy in the port, if the fluid flows from the port in to the component,
and the specific enthalpy of a point inside the component, if the fluid flows from the component to
the port):
port.H_flow = port.m_flow*(if port.m_flow > 0 then port.h
else h_in_component);
This approachsolvesthedifficult problem to handle reversing,splitting, and joining flow of connected ports
automatically under the assumption of ideal mixing. More detailed models require special join/splitter
elements where the losses are described. This means that mass and energy balance in a connection point
are always fulfilled independently how components are connected together (the momentum balance is
fulfilled only under some additional assumptions). As an example, let us assume that ports A.port, B.port,
and C.port of the components A, B, and C are connected together. This results in the following equations:
Equations due to "connect(A.port, B.port); connect(A.port,C.port)":
A.port.p = B.port.p = C.port.p;
A.port.h = B.port.h = C.port.h;
0 = A.port.m_flow + B.port.m_flow + C.port.m_flow;
0 = A.port.H_flow + B.port.H_flow + C.port.H_flow;
Equations inside components A, B, C:
A.port.H_flow = A.port.m_flow*(if A.port.m_flow > 0 then A.port.h
else A.h;
B.port.H_flow = B.port.m_flow*(if B.port.m_flow > 0 then B.port.h
else B.h;
C.port.H_flow = C.port.m_flow*(if C.port.m_flow > 0 then C.port.h
else C.h;