M

Multi-domain Modeling andSimulation

Martin OtterInstitute of System Dynamics and Control,German Aerospace Center (DLR), Wessling,Germany

Abstract

One starting point for the analysis and designof a control system is the block diagramrepresentation of a plant. Since it is nontrivialto convert a physical model of a plant intoa block diagram, this can be performedmanually only for small plant models. Basedon research from the last 40 years, more andmore mature tools are available to achieve thistransformation fully automatically. As a result,multi-domain plants, for example, systemswith electrical, mechanical, thermal, and fluidparts, can be modeled in a unified way andcan be used directly as input–output blocksfor control system design. An overview of thebasic principles of this approach is given, andit is shown how to utilize nonlinear, multi-domain plant models directly in a controller.Finally, the low-level “Functional MockupInterface” standard is sketched to exchangemulti-domain models between many differentmodeling and simulation environments.

Keywords

Block diagram � Differential-algebraicequation (DAE) system � Flow variable �Functional Mockup Interface (FMI) � Inversemodels � Modelica � Modia �Object-oriented modeling � Potentialvariable � Stream variable � Symbolictransformation � VHDL-AMS

Introduction

Methods and tools for control system analysisand design usually require an input–output blockdiagram description of the plant to be controlled.Apart from small systems, it is nontrivial toderive such models from first principles ofphysics. Since a long time, methods and tools areavailable to construct such models automaticallyfor one domain, for example, a mechanicalmodel, an electronic, or a hydraulic circuit. Thesedomain-specific methods and tools are, however,only of limited use for the modeling of multi-domain systems.

In the dissertation (Elmqvist 1978), a suitableapproach for multi-domain, object-orientedmodeling has been developed by introducing amodeling language to define models on a highlevel based on first principles. The resultingdifferential-algebraic equation (DAE) systemsare automatically transformed with proper algo-rithms in a block diagram description with inputand output signals based on ordinary differentialequations (ODEs), where the algebraic variables

© Springer-Verlag London Ltd., part of Springer Nature 2019J. Baillieul, T. Samad (eds.), Encyclopedia of Systems and Control,https://doi.org/10.1007/978-1-4471-5102-9 140-2

2 Multi-domain Modeling and Simulation

have been eliminated and all derivatives areexplicitly solved for.

In 1978, computers were not powerful enoughto apply this method on systems with more asa few hundred equations. In the 1990s the tech-nology has been substantially improved, manydifferent modeling languages appeared (and alsodisappeared), and object-oriented modeling wasintroduced in commercial simulation environ-ments.

In Table 1, an overview of the most importantstandards, languages, and tools in the year 2019for multi-domain modeling is given:

• The Modelica language is a standard fromthe Modelica Association (2017). Thefirst version was released in 1997. The

language is accompanied with the Model-ica Standard Library (https://github.com/modelica/ModelicaStandardLibrary) – anopen-source Modelica library with about 1600model components and 1350 functions frommany domains. There are several free andcommercial software tools supporting theModelica language and the Modelica StandardLibrary.

• The VHDL-AMS language is a standard fromIEEE (IEEE 1076.1-2017 2017), first releasedin 1999. It is an extension of the widely usedVHDL hardware description language. Thislanguage is especially used in the electronicscommunity.

• There are several (proprietary) vendor-specificmodeling languages, notably EcosimPro and

Multi-domain Modelingand Simulation, Table 1Multi-domain modelingand simulationenvironments

Environments supporting the Modelicar Language Standard (https://www.modelica.org/)

Altair Activater https://solidthinking.com/product/activate

ANSYSr Twin Builder https://www.ansys.com/products/systems

Dymolar https://www.dymola.com/

JModelica.org https://jmodelica.org/

MapleSim https://www.maplesoft.com/products/maplesim/

MWorks http://en.tongyuan.cc/

OpenModelica https://www.openmodelica.org/

OPTIMICAr Compiler Toolkit https://www.modelon.com/

Simcenterr Amesim https://www.plm.automation.siemens.com

SimulationXr https://www.simulationx.com/

Wolfram SystemModeler https://www.wolfram.com/system-modeler/

Environments supporting the VHDL-AMS Standard (https://standards.ieee.org)

AMS Designer https://www.cadence.com/

ANSYSr Twin Builder, Simplorerr https://www.ansys.com/products/systems

Saber https://www.synopsys.com

SMASHr https://www.dolphin-integration.com

SystemVisionr https://www.mentor.com/products/sm/

Environments supporting vendor-specific multi-domain modeling languages

EcosimPror https://www.ecosimpro.com/

gPROMS https://www.psenterprise.com/products/gproms

Simscape https://www.mathworks.com/products/simscape

20-sim https://www.20sim.com/

Open-source environments supporting other multi-domain modeling languages

Modia https://github.com/ModiaSim

Multi-domain Modeling and Simulation 3

M

gRPOMS for modeling of thermodynamicprocesses, Simscape from MathWorks as anextension to Simulinkr, MAST the underlyingmodeling language of Saber (Mantooth andVlach 1992), and the language of 20-sim,which supports bond graphs (Karnopp et al.2012). Bond graphs are a special graphicalnotation to define multi-domain systems basedon energy flows. It was invented in 1959 byHenry M. Paynter.

• Modia and its supporting packages form anopen-source prototyping platform based onthe Julia programming language (Bezansonet al. 2017). Modia is the name of a Juliapackage that supports a modeling languagecalled “Modia language” as a domain-specificextension of Julia and provides algorithmsto symbolically transform Modia models intoDAE systems that can be numerically solvedby standard DAE integrators. The Modia lan-guage and the new algorithms used in theModia package are intended as inspirationfor the development of the next Modelicageneration.

In section “Modeling Language Principles”, theprinciples of multi-domain modeling based ona modeling language are summarized. In sec-tion “Models for Control Systems”, it is shownhow such models can be used not only for sim-ulation but also as components in nonlinear con-trol systems. Finally, in section “The FunctionalMockup Interface”, an overview about a low-level standard for the exchange of multi-domainsystems is described.

Modeling Language Principles

Schematics: The Graphical ViewModelers nowadays require a simple to usegraphical environment to build up models. Withvery few exceptions, multi-domain environmentsdefine models by schematic diagrams. A typicalexample is given in Fig. 1, showing a simpledirect current electrical motor in Modelica.

In the lower left part, the electrical circuitdiagram of the DC motor is visible, consistingmainly of the armature resistance and inductance

heatCapacitor

thermalCond convection

const

inductor

resistor

−+

ground

emf

signalVoltage

iSensor

motorInertia loadInertiagear

fixedTemp

T=20

deg�C

k=20

k=1.016

J=0.00025 J=100ratio=105

L=0.061

R=13.8

C

A

GcG=G

Multi-domain Modeling and Simulation, Fig. 1 Modelica schematic of DC motor with mechanical load and heatlosses

4 Multi-domain Modeling and Simulation

of the motor, a voltage source, and component“emf” to model in an idealized way the electro-motoric forces in the air gap. On the lower rightpart, the motor inertia, a gear box, and a loadinertia are present. In the upper part, the heattransfer of the resistor losses to the environmentis modeled with lumped elements.

A component, like a resistor, rotational inertia,or convective heat transfer, is shown as an icon inthe diagram. On the border of a component, smallrectangular or circular signs are present repre-senting the “physical ports.” Ports are connectedby lines and model the (idealized) physical or sig-nal interaction between ports of different compo-nents, for example, the flow of electrical currentor heat or the rigid mechanical coupling. Com-ponents are built up hierarchically from othercomponents. On the lowest level, components aredescribed textually with the respective modelinglanguage (see section “Component Equations”).

Coupling Components by PortsThe ports define how a component can interactwith other components. A port contains a defi-nition of the variables that describe the interfaceand defines in which way a tool can automaticallyconstruct the equations for the connections. Atypical scenario is shown in Fig. 2 where the portsof the three components A, B, C are connectedtogether at one point P.

When cutting away the connection lines, theresulting system consists of three decoupled com-ponents A, B, C and a new component aroundP describing the infinitesimally small connectionpoint. The balance equations and the boundaryconditions of the respective domain must hold atall these components. When drawing the connec-tion lines, enough information must be availablein the port definitions so that the tool can con-struct the equations of the infinitesimally smallconnection points automatically.

To summarize, the component developer isresponsible that the balance equations and bound-ary conditions are fulfilled for every component(A, B, C in Fig. 2), and the tool is responsible thatthe balance equations and boundary conditionsare also fulfilled at the points where the compo-nents are connected together (P in Fig. 2). As a

consequence, the balance equations and bound-ary conditions are fulfilled in the overall modelcontaining all components and all connections.

In order that a tool can automatically constructthe equations at a connection point, every portvariable needs to be associated to a port variabletype. In Table 2, some port variable types ofModelica are shown. Hereby it is assumed thatu1; u2; : : :; un; y; v1; v2; : : : ; vn; f1; f2; : : :, fn,s1, s2; : : : ; sn are corresponding port variablesfrom different components that are connectedtogether at the same point P.

Port variable types “input” and “output” definethe usual signal connections in block diagrams.“Potential variables” and “flow variables” areused to define standard physical connections. Forexample, an electrical port contains the electricalpotential and the electrical current at the port,and when connecting electrical ports together, theelectrical potentials are identical, and the sum ofthe electrical currents is zero; see Table 2. Theseequations correspond exactly to Kirchhoff’s volt-age and current laws. “Stream variables” areused to describe the connection semantics ofintensive quantities in bidirectional fluid flow,such as specific enthalpy or mass fraction. Here,the idealized balance equation at a connectionpoint states, for example, that the sum of theport enthalpy flow rates is zero and the port

A B

C

P

PA B

C

Multi-domain Modeling and Simulation, Fig. 2Cutting the connections around the connection point Presults in three decoupled components A, B , C and anew component around P describing the infinitesimallysmall connection point

Multi-domain Modeling and Simulation 5

M

Multi-domain Modeling and Simulation, Table 2 Some port variable types in Modelica

Port variable type Connection semantics

Input variables ui , output variable y u1 D u2 D : : :D un D y (exactly one output variablecan be connected to n input variables)

Potential variables vi v1 D v2 D : : :D vn

Flow variables fi 0 DPfi

Stream variables si (with associated flow variables fi ) 0 DPfi Osi I Osi D

(smix if fi > 0

si if fi � 0

.0 DPfi /

Multi-domain Modelingand Simulation, Table 3Some port definitions fromModelica

Domain Port variables

Electrical analog Electrical potential in [V] (pot.)electrical current in [A] (flow)

Electrical multiphase Vector of electrical ports

Electrical quasi-stationary Complex electrical potential (pot.)complex electrical current (flow)

Magnetic flux tubes Magnetic potential in [A] (pot.)magnetic flux in [Wb] (flow)

Translational (one-dimensional mechanics) Distance in [m] (pot.)cut-force in [N] (flow)

Rotational (one-dimensional mechanics) Absolute angle in [rad] (pot.)cut-torque in [Nm] (flow)

Two-dimensional mechanics Position in x-direction in [m] (pot.)position in y-direction in [m] (pot.)absolute angle in [rad] (pot.)cut-force in x-direction in [N] (flow)cut-force in y-direction in [N] (flow)cut-torque in z-direction in [Nm] (flow)

Three-dimensional mechanics Position vector in [m] (pot.)transformation matrix in [1] (pot.)cut-force vector in [N] (flow)cut-torque vector in [Nm] (flow)

One-dimensional heat transfer Temperature in [K] (pot.)heat flow rate in [W] (flow)

One-dimensional thermo-fluid pipe flow Pressure in [Pa] (pot.)mass flow rate in [kg/s] (flow)spec. enthalpy in [J/kg] (stream)mass fractions in [1] (stream)

enthalpy flow rate is computed as the product ofthe mass flow rate (a flow variable fi ) and thedirectional specific enthalpy si , which is eitherthe (yet unknown) mixing-specific enthalpy smix

when the flow is from the connection point tothe port or the specific enthalpy si in the portwhen the flow is from the port to the connectionpoint. More details and explanations are availablefrom Franke et al. (2009). In Table 3 some of theport definitions are shown that are provided by

the Modelica Standard Library and the PlanarMe-chanics library.

Component EquationsImplementing a component in a modeling lan-guage means to define the ports of the componentand to provide the equations describing the rela-tionships between the port variables. For exam-ple, an electrical capacitor with constant capac-itance C can be defined by the equations in theright side of Fig. 3.

6 Multi-domain Modeling and Simulation

0 = += −

=

Multi-domain Modeling and Simulation, Fig. 3Equations of a capacitor component

Such a component has two ports, the pins“p” and “n,” and the port variables are the elec-trical currents ip; in flowing into the respectiveports and the electrical potentials vp; vn at theports. The first component equation states thatif the current ip at port “p” is positive, then thecurrent in at port “n” is negative (therefore, thecurrent flowing into “p” is flowing out of “n”).Furthermore, the two remaining equations statethat the derivative of the difference of the portpotentials is proportional to the current flowinginto port “p.”

One important question is how many equa-tions are needed to describe such a component?For an input–output block, the answer is sim-ple: all input variables are known, and for allother variables, one equation per unknown isneeded. Counting equations for physical compo-nents, such as a capacitor, are more involved: therequirement that any type of component connec-tions shall always result in identical numbers ofunknowns and equations of the overall systemleads to the following counting rule (for a proof,see Olsson et al. 2008):

1. The number of potential and the number offlow variables in a port must be identical.

2. Input variables and variables that appear dif-ferentiated are treated as known variables.

3. The number of equations of a component mustbe equal to the number of unknowns minus thenumber of flow variables.

In the example of the capacitor, there are fiveunknowns (ip , in, vp; vn, du/dt) and two flowvariables (ip , in). Therefore, 5� 2 D 3 equationsare needed to define the component in Fig. 3.

type Voltage = Real (unit="V");type Current = Real (unit="A");

connector PinVoltage v;

flow Current i;end Pin;

model Capacitorparameter Real C(unit="F");Pin p,n;Voltage u;

equation0 = p.i + n.i;u = p.v – n.v;C*der(u) = p.i;

end Capacitor;

Multi-domain Modeling and Simulation, Fig. 4Modelica model of capacitor component

subtype voltage is real;subtype current is real;nature electrical is

voltage acrosscurrent throughelectrical_ref reference;

entity CapacitorInterface ISgeneric(C: real);port (terminal p, n: electrical);

end entity CapacitorInterface;architecture SimpleCapacitor of

CapacitorInterface isquantity u across i through p to n;

begini == C*u’dot;

end architecture SimpleCapacitor;

Multi-domain Modeling and Simulation, Fig. 5VHDL-AMS model of capacitor component

Modeling languages are used to provide a tex-tual description of the ports and of the equationsin a specific syntax. For example, in Modelica thecapacitor from Fig. 3 can be defined as shown inFig. 4 (keywords of the language are written inboldface). In VHDL-AMS the capacitor modelcan be defined as shown in Fig. 5.

One difference between Modelica and VHDL-AMS is that in Modelica, all equations need tobe explicitly given, and port variables (such asp.i) can be directly accessed in the model (Fig. 4).

Multi-domain Modeling and Simulation 7

M

Instead, in VHDL-AMS (and some other model-ing languages), port variables cannot be accessedin a model, and instead via the “quantity .. across.. through .. to ..” construction, the relationshipsbetween the port variables are implicitly definedand correspond to the Modelica equations “0 Dp.iC n.i” and “uD p.v � n. v.”

Simulation of Multi-domain SystemsCollecting all the component equations of amulti-domain system model together with allconnection equations results in a DAE system:

0 D f.Px; x;w; y;u; t / (1)

where t 2 R is time, x.t/ 2 Rnx is a vector

which contains variables that appear differenti-ated, w.t/ 2 R

nw is a vector of algebraic vari-ables, y.t/ 2 R

ny is a vector of output variables,u.t/ 2 R

nu is a vector of input variables, andf 2 R

nxCnwCny is a vector of functions thatrepresent the right-hand sides of the equationsof the DAE system. The equations in (1) can besolved numerically with an integrator for DAEsystems; see, for example, Brenan et al. (1996).For DAEs that are linear in their unknowns, acomplete theory for solvability is available basedon matrix pencils, see, for example, Brenan et al.(1996), and also reliable software for their analy-sis (Varga 2000).

Unfortunately, only certain classes of nonlin-ear DAEs can be directly solved numerically in areliable way. For example, there are DAEs whereno unique solution exists anymore when the step-size of the integrator approaches zero. For suchsystems step-size control is difficult, and numer-ical integration may easily fail. Domain-specificsoftware, as, e.g., for mechanical systems, trans-forms the underlying DAE system into a formthat can be more reliably solved using domain-specific knowledge. Hereby, certain equations ofthe DAE system are analytically differentiated,and special integration methods are used to solvethe resulting overdetermined set of DAEs. Inmulti-domain simulation software, the followingapproaches are used:

(a) The DAE system (1) is directly solvednumerically using an implicit integrationmethod, such as a linear multistep method.Typically, all VHDL-AMS simulators usethis approach.

(b) The DAE system (1) is symbolically trans-formed in a form that is equivalent to a setof ODEs, and then either explicit or implicitODE or DAE integration methods are usedto numerically solve the transformed system.The transformation is usually based on thealgorithms of Pantelides (1988) and of Matts-son and Soderlind (1993) or some variantsof them and might require to analyticallydifferentiate equations. Typically, Modelica-based simulators, but also EcosimPro, usethis approach.

For many models both approaches can be appliedsuccessfully. There are, however, systems whereapproach (a) is successful and fails for (b) or viceversa.

DAEs (1) derived from modeling languagesusually have a large number of equations but withonly a few unknowns in every equation. In orderto solve DAEs of this kind efficiently, both with(a) or (b), typically graph theory and/or sparsematrix methods are utilized. For method (b) thefundamental algorithms have been developed byElmqvist (1978) and later improved in furtherpublications. For a recent survey and comparisonof some of the algorithms, see Frenkel et al.(2012).

Solving the DAE system (1) means to solvean initial value problem. In order that integrationcan be started, a consistent set of initial variablesPx0 D Px .t0/ ; x0 D x .t0/ ; w0 D w .t0/ ; y0 Dy .t0/ ; and u0 D u .t0/ has to be determined firstat the initial time t0 which is a nontrivial task. Forexample, often (1) shall start in steady state, thatis, it is required that Px0 WD 0 and therefore at theinitial time (1) is required to satisfy

0 D f .0; x0; w0; y0; u0; t0/ (2)

(2) is an algebraic system of nonlinear equationsin the unknowns x0, w0, y0; and u0. These arenx C nw C ny equations for nx C nw C ny C nu

8 Multi-domain Modeling and Simulation

unknowns. Therefore, nu further conditions mustbe provided (usually some elements of u0 and/ory0 are fixed to desired physical values). Solving(2) for the unknowns is also called “DC operat-ing point calculation” or “trimming.” Nonlinearequation solvers are based on iterative methodsthat require usually a sufficiently accurate initialguess for all unknowns. In a large multi-domainsystem model, it is not practical that reasonableinitial values must be provided for every DAEvariable and therefore methods are needed tosolve (2) even if generic guess values in a libraryare provided that might be far from the solutionof the system at hand.

For analog electronic circuit simulations, alarge body of theory, algorithms, and software isavailable to solve (2) based on homotopy meth-ods. The basic idea is to solve a sequence ofnonlinear algebraic equation systems by startingwith an easy to solve simplified system, char-acterized by the homotopy parameter � D 0.This system is continuously “deformed” until thedesired one is reached at � D 1. The solutionat iteration i is used as guess value for iterationiC1, and at every iteration, the solution is usuallycomputed with a Newton–Raphson method. Thesimplest such approach is “source stepping”: theinitial guess values of all electrical componentsare set to “zero voltage” and/or “zero current.”All (voltage and current) sources start at zero,and their values are gradually increased until thedesired source values are reached. This methodmay not converge, typically due to the severenonlinearities at switching thresholds in logicalcircuits.

There are several, more involved approaches,called “probability-one homotopy” methods. Forthese method classes, proofs exist that they con-verge for all initial conditions globally with prob-ability one (so practically always). These algo-rithms can only be applied for certain classesof DAEs; see, for example, the “variable stimu-lus probability-one homotopy” of Melville et al.(1993).

Although strong results exist for analog elec-trical circuit simulators, it is difficult to generalizethem to the large class of multi-domain systemscovered by a modeling language. In Modelica

a “homotopy” operator was introduced into thelanguage (Sielemann et al. 2011) in order that alibrary developer can formulate simple homotopymethods like the “source stepping” in a compo-nent library. A generalization of probability-onemethods for multi-domain systems was devel-oped in the dissertation of Sielemann (2012)and was successfully applied to air distributionsystems described as one-dimensional thermo-fluid pipe flow.

Models for Control Systems

Models for AnalysisThe multi-domain models from section “Mod-eling Language Principles” can be utilized toevaluate the properties of a control system bysimulation. Also control systems can be designedby nonlinear optimization where at every opti-mization step one or several simulations of aplant model are executed. Furthermore, modelingenvironments usually provide pre- and/or post-processing methods to linearize the nonlinearDAE system (1) around a steady-state operatingpoint or an operating point along the simulationtrajectory

x .t/ � xop C Δx.t/; w.t/ � wop C Δw.t/;y.t/ � yop C Δy.t/; u.t/ � uop C Δu.t/

(3)resulting in

ΔPxred D A Δxred C B ΔuΔy D CΔxred C D Δu

(4)

where xop;wop; yop; anduop define the operat-ing point, Δxred is a vector consisting of elementsof Δx, vector Δw is eliminated by exploiting thealgebraic constraints, and A, B, C, and D areconstant matrices. Simulation tools provide linearanalysis and synthesis methods on this linearizedsystem and/or export it for usage in an envi-ronment such as Julia, Maple, Mathematicar,MATLABr, or Pythonr.

Multi-domain models might also be useddirectly in nonlinear Kalman filters, movinghorizon estimators, or nonlinear model predictive

Multi-domain Modeling and Simulation 9

M

control. For example, the company ABB is usingmoving horizon estimation and nonlinear modelpredictive control based on Modelica models inits product OPTIMAXr to significantly improvethe start-up process of power plants (Franke andDoppelhamer 2006), for the control of virtualpower plants and for other purposes.

Inverse ModelsA large body of literature exists about the theoryof nonlinear control systems that are based oninverse plant models; see, for example, (Isidori1995). Methods such as feedback linearization,nonlinear dynamic inversion, or flat systems usean inverse plant model in the control loop. How-ever, a major obstacle is how to automaticallyutilize an inverse plant model in a controller with-out being forced to manually set up the equationsin the needed form which is not practical forlarger systems. Modeling languages can solvethis problem as discussed below.

Nonlinear inverse models can be utilized invarious ways in a control system. The simplestapproach, as feed forward controller, is shown inFig. 6. Under the assumption that identical equa-tions (1) are used for the plant and the inverseplant model (but the plant model has u as inputand y as output, whereas the inverse plant modelhas y as input and u as output) and start at thesame initial state, then from the construction,the control error e is zero and y D yref;filt, soy is identical to the low-pass filtered referencesignals. In other words, y � yref for referencesignals that have a frequency spectrum below thecutoff frequency of the low-pass filters. Sincethe assumption is actually not fulfilled, there willbe a nonzero control error e, and the feedbackcontroller has to cope with it. This controllerstructure with a nonlinear inverse plant modelhas the advantage that the feed forward part isuseful over the complete operating range of theplant.

Various other structures with nonlinear plantmodels are discussed in Looye et al. (2005),such as compensation controllers, feedback lin-earization controllers, and nonlinear disturbanceobservers. In Olsson et al. (2017), a Modelicaextension is defined to directly construct (sam-

pled data) feedback linearization controllers from(continuous-time) Modelica plant models. Fur-thermore, integration algorithms are proposed tosolve nonlinear inverse models with hard real-time requirements.

It turns out that nonlinear inverse plantmodels can be generated automatically withthe techniques that have been developed formodeling languages; see section “ModelingLanguage Principles.” In particular, constructingan inverse model from (1) means that the inputsu are defined to be outputs, so they are no longerknowns but unknowns, and outputs y are definedto be inputs, so they are no longer unknownsbut knowns. The resulting system is still a DAEsystem and can therefore be handled as any otherDAE system. Therefore, defining an inversemodel with a modeling language just requiresexchanging the definition of input and outputsignals. In Modelica, this can be graphicallyperformed with the nonstandard input–outputblock from Fig. 7. This block has two inputs andtwo outputs and is described by the equations:

low passfilters

inverse plantmodel

feedbackcontroller

plant

, ,

−

Multi-domain Modeling and Simulation, Fig. 6Controller with inverse plant model in the feed forwardpath. The inverse plant model needs usually alsoderivatives of yref as inputs. These derivatives areprovided by appropriate low-pass filters

u1 u2 y1 y2

Multi-domain Modeling and Simulation, Fig. 7Modelica InverseBlockConstraint block

10 Multi-domain Modeling and Simulation

Multi-domain Modelingand Simulation, Fig. 8Inversion of a second-ordersystem in Modelica

filter

f_cut=10w=0.1

2secondOrder

u1 D u2I y1 D y2I

From a block diagram point of view, this looksstrange. However, from a DAE point of view,this just states constraints between two input andtwo output signals. In Fig. 8, it is shown how thisblock can be used to invert a simple second-ordersystem: the output of the low-pass filter is con-nected to the output of the second-order system(note, a direction connection of this kind violatesthe input–output block semantics, but an indirectconnection via the InverseBlockConstraint blockis possible) and therefore this model computesthe input of the second-order system, from theinput of the filter by inverting the second-ordersystem.

A Modelica environment will generate fromthis type of definition the inverse model, therebydifferentiating equations analytically and solvingalgebraic variables of the model in a different wayas for a simulation model. The whole transforma-tion is nontrivial, but it is just the standard methodused by Modelica tools as for any other type ofDAE system.

The question arises whether a solution of theinverse model exists or is unique and whether themodel is stable (otherwise, it cannot be appliedin a control system). In general, a nonlinearinverse model consists of linear and/or nonlinearalgebraic equation systems and of linear and/ornonlinear differential equations. Therefore, froma formal point of view, the same theorems asfor a general DAE system applies, see Brenanet al. (1996). Furthermore, all these equationsneed to be solved with a numerical method. Forsome classes of systems, it can be shown thata unique mathematical solution exists and thatthe system is stable. However, in general, onecannot expect that it is possible to provide such a

proof for complex inverse plant models. In somecases it is possible to approximate the plant modelso that its inverse is guaranteed to be stable. Inmore involved cases, it might only be possibleto perform simulations at many operating pointsto show that the probability of a stable inversemodel is high. Note, nonlinear inverse plant mod-els have been successfully utilized by automaticgeneration from a Modelica plant model, in par-ticular for robots, satellites, aircrafts, vehicles,and thermo-fluid systems.

The Functional Mockup Interface

Many different types of simulation environmentsare in use. One cannot expect that a genericapproach as sketched in section “ModelingLanguage Principles” will replace all theseenvironments with their rich set of domain-specific knowledge, analysis, and synthesisfeatures. Practically, all simulation environmentsprovide a vendor-specific interface in orderthat a user can import components that are notdescribable by the simulation environment itself.Typically, this requires to provide a componentas a set of C or Fortran functions with a particularcalling interface. In the control community, themost widely used approach of this kind is theS-Function interface from the MathWorks, whereSimulink is used as integration platform, andmodel components from other environments areimported as S-Functions.

In 2010 the vendor-independent standard“Functional Mockup Interface 1.0” was devel-oped, followed by a significantly improvedversion 2.0 in 2014 (Modelica Association 2014).An again significantly improved version 3.0is under development as of June 2019 (see

Multi-domain Modeling and Simulation 11

M

https://fmi-standard.org/faq/). FMI is a low-levelstandard for the exchange of models betweendifferent simulation environments. This standardallows to exchange only the model equations(called “FMI for Model Exchange”) and/orthe model equations with an embedded solver(called “FMI for Co-Simulation”). This standardwas quickly adopted by many simulationenvironments, and in 2019 there are more than130 tools that support it (for an actual listof tools, see https://fmi-standard.org/tools/).In particular Modelica environments exportModelica models in this format, and therefore,Modelica multi-domain models can be importedin other environments with low effort.

A software component which implements theFMI is called Functional Mockup Unit (FMU).An FMU consists of one zip file with extension“.fmu” containing all necessary components toutilize the FMU either for Model Exchange, forCo-Simulation, or for both. The following sum-mary is an adapted version from Blochwitz et al.(2012):

1. An XML-file contains the definition of allexposed variables of the FMU, as well asother model information. It is then possible torun the FMU on a target system without thisinformation, that is, without unnecessary over-head. Furthermore, this allows determining allproperties of an FMU from a text file, withoutactually loading and running the FMU.

2. A set of C-functions is provided to executemodel equations for the Model Exchange caseand to simulate the equations for the Co-Simulation case. These C-functions can beprovided either in binary form for differentplatforms or in source code. The differentforms can be included in the same model zipfile.

3. Further data can be included in the FMU zipfile, especially a model icon (bitmap file),documentation files, maps and tables neededby the model, and/or all object libraries orDLLs that are utilized.

The main application area of FMI is offlinesimulation, but it is also used for (soft) real-time

applications, see, for example, the direct supportof FMI in the real-time systems of dSPACE(https://www.dspace.com). In Brembeck (2019) anonlinear (continuous-time) Modelica model of ahighly maneuverable electric vehicle is used asstarting point of a dedicated tool chain to gener-ate automatically (sampled data) FMUs used asdiscrete-time prediction models for an extendedmoving horizon state estimator and an extendedKalman filter.

Summary and Future Directions

Multi-domain modeling based on a DAE descrip-tion and defined with a modeling language is anestablished approach, and many tools support it.This allows to conveniently define plant modelsfrom many domains for the design and evalua-tion of control systems. Furthermore, nonlinearinverse plant models can be easily constructedwith the same methodology and can be utilizedin various ways in nonlinear control systems.

Current research focuses on the support ofthe complete life cycle: defining requirementsof a system formally on a “high level,”considerably improving testing by checking theserequirements automatically when evaluating asystem design by simulations, see, for example,Bouskela and Jardin (2018), and providingcomplete tool chains to embedded systems.For example, in the European ITEA projectEMPHYSIS (embedded systems with physicalmodels in the production code software; https://itea3.org/project/emphysis.html), the varianteFMI of FMI is being developed in the years2017–2021 so that whole tool chains from multi-domain modeling environments to productioncode on automotive electronic control unitsand other embedded devices with hard real-time requirements become feasible. This willallow convenient and fast target code generationof nonlinear controllers, optimization-basedcontrollers, extended and unscented Kalmanfilters, or moving horizon estimators from multi-domain models.

Furthermore, the methodology itself is furtherimproved. Especially, with the prototyping

12 Multi-domain Modeling and Simulation

platform Modia (Elmqvist et al. 2017), newdirections are evaluated, such as hybrid 2Dschematic/3D graphical user interfaces, closeintegration of complex data structures withequation-based modeling (e.g., to model mul-tiphase, multicomponent fluids or collisionhandling of 3D mechanical systems), improvedand new symbolic transformation algorithms(Otter and Elmqvist 2017), code generation forlarge models, support of multi-domain Diracimpulses, and changing the number of equationsduring simulation.

Cross-References

�Computer-Aided Control Systems Design:Introduction and Historical Overview

�Descriptor System Techniques and SoftwareTools

�Extended Kalman Filters� Feedback Linearization of Nonlinear Systems� Interactive Environments and Software Tools

for CACSD�Model Building for Control System Synthesis�Modeling of Dynamic Systems from First Prin-

ciples�Model-Predictive Control in Practice�Moving Horizon Estimation�Nonlinear Filters

Bibliography

Bezanson J, Edelman A, Karpinski S, Shah V (2017) Julia:a fresh approach to numerical computing. SIAM Rev59:65–98. https://doi.org/10.1137/141000671

Blochwitz T, Otter M, Akesson J, Arnold M, ClaußC, Elmqvist H, Friedrich M, Junghanns A, Mauss J,Neumerkel D, Olsson H, Viel A (2012) FunctionalMockup Interface 2.0: the standard for tool indepen-dent exchange of simulation models. In: Proceedingsof the 9th international modelica conference, Munich,3–5 Sept 2012, pp 173–184. https://doi.org/10.3384/ecp12076173

Bouskela D, Jardin A (2018) A new temporal lan-guage for the verification of cyber-physical systems.In: 2018 annual IEEE international systems con-ference (SysCon). https://doi.org/10.1109/SYSCON.2018.8369502

Brembeck J (2019) Nonlinear constrained moving hori-zon estimation applied to vehicle position estima-tion. Sensors 2019, 19, 2276. https://doi.org/10.3390/s19102276

Brenan KE, Campbel SL, Petzold LR (1996) Numeri-cal solution of initial-value problems in differential-algebraic equations. SIAM, Philadelphia

Elmqvist H (1978) A structured model language forlarge continuous systems. Dissertation. ReportCODEN:LUTFD2/(TFRT–1015), Department ofAutomatic Control, Lund Institute of Technology,Lund. https://lup.lub.lu.se/search/ws/files/4602422/8570492.pdf

Elmqvist H, Henningsson T, Otter M (2017) Innovationsfor future modelica. In: Proceedings of the 12th inter-national modelica conference, Prague. https://doi.org/10.3384/ecp17132693

Franke R, Doppelhamer J (2006) Online applicationof modelica models in the industrial IT extendedautomation system 800xA. In: Proceedings of the6th international modelica conference, Vienna, 4–5Sept 2006, pp 293–302. https://modelica.org/events/modelica2006/Proceedings/sessions/Session3c2.pdf

Franke R, Casella F, Otter M, Sielemann M, Mattsson SE,Olsson H, Elmqvist H (2009) Stream connectors – anextension of modelica for device-oriented modeling ofconvective transport phenomena. In: Proceedings of the7th international modelica conference, Como, pp 108–121. https://doi.org/10.3384/ecp09430078

Frenkel J, Kunze G, Fritzson P (2012) Survey of appro-priate matching algorithms for large scale systemsof differential algebraic equations. In: Proceedings ofthe 9th international modelica Conference, Munich,3–5 Sept 2012, pp 433–442. https://doi.org/10.3384/ecp12076433

IEEE 1076.1-2017 (2017) IEEE standard VHDL analogand mixed-signal extensions. Standard of IEEE. https://standards.ieee.org/standard/1076 1-2017.html

Isidori A (1995) Nonlinear control systems, 3rd edn.Springer, Berlin/New York

Karnopp DC, Margolis DL, Rosenberg RC (2012) Systemdynamics: modeling, simulation, and control of mecha-tronic systems, 5th edn. Wiley, Hoboken

Looye G, Thummel M, Kurze M, Otter M, Bals J (2005)Nonlinear inverse models for control. In: Proceedingsof the 4th international modelica conference, Hamburg,7–8 Mar 2005, pp 267–279. https://modelica.org/events /Conference2005 /online proceedings /Session3 /Session3c3.pdf

Mantooth HA, Vlach M (1992) Beyond spice with saberand MAST. In: IEEE international symposium on cir-cuits and systems, San Diego, vol 1, 10–13 May 1992,pp 77–80

Mattsson SE, Soderlind G (1993) Index reduction indifferential-algebraic equations using dummy deriva-tives. SIAM J Sci Comput 14:677–692

Melville RC, Trajkovic L, Fang SC, Watson LT (1993)Artificial parameter homotopy methods for the DC

Multi-domain Modeling and Simulation 13

M

operating point problem. IEEE Trans Comput AidedDes Integr Circuits Syst 12:861–877. https://doi.org/10.1109/43.229761

Modelica Association (2014) Functional mock-up inter-face for model exchange and co-simulation, Version2.0. https://fmi-standard.org/downloads/

Modelica Association (2017) Modelica – a unified object-oriented language for systems modeling. Languagespecification, Version 3.4. https://www.modelica.org/documents/ModelicaSpec34.pdf

Olsson H, Otter M, Mattsson SE, Elmqvist H (2008)Balanced models in modelica 3.0 for increased modelquality. In: Proceedings of the 6th internationalmodelica conference, Bielefeld, pp 21–33. https://www.modelica.org/events/modelica2008/Proceedings/sessions/session1a3.pdf

Olsson H, Mattsson SE, Otter M, Pfeiffer A, Brger C,Henriksson D (2017) Model-based embedded controlusing Rosenbrock integration methods. In: Proceedingsof the 12th international modelica conference, Prague.https://doi.org/10.3384/ecp17132517

Otter M, Elmqvist H (2017) Transformation of differentialalgebraic array equations to index one form. In: Pro-ceedings of the 12th international modelica conference,Prague. https://doi.org/10.3384/ecp17132565

Pantelides CC (1988) The consistent initialization ofdifferential-algebraic systems. SIAM J Sci Stat Comput9:213–233

Sieleman M (2012) Device-oriented modeling and simu-lation in aircraft energy systems design. Dissertation,Dr. Hut. ISBN:978-3-8439-0504-6

Sielemann M, Casella F, Otter M, Clauß C, Eborn J,Mattsson SE, Olsson H (2011) Robust initializationof differential-algebraic equations using homotopy. In:Proceedings of the 8th international modelica confer-ence, Dresden. https://doi.org/10.3384/ecp1106375

Varga A (2000) A descriptor systems toolbox for Matlab.In: Proceedings of CACSD’2000 IEEE internationalsymposium on computer-aided control system design,Anchorage, 25–27 Sept 2000, pp 150–155. https://ieeexplore.ieee.org/iel5/7209/19415/00900203.pdf