fran ç ois e. cellier department of computer science eth zurich switzerland

February 4, 2009Start of Presentation© Prof. Dr. François E. Cellier

3rd MODPROD Workshop – Keynote

Technologies for Creating Easily Maintainable Component

Model Libraries of Complex Physical Systems

François E. Cellier Department of Computer Science

ETH ZurichSwitzerland

http://www.ethz.ch/



• The Modelica Standard Library (SL) is growing at an amazing pace. Whereas originally, the SL was meant as a small add-on created for the convenience of the end user, the library is now growing faster in terms of number of lines of code than the Modelica compilers themselves. Fairly soon, the SL will be larger in size than the compilers managing it.

• Maintaining such a large library has become a daunting task, especially since this is a highly distributed endeavor, i.e., there are many researchers contributing regularly to the SL.

• The developers of Modelica environments have long recognized this problem, and they are meanwhile offering quite sophisticated library management tools, such as version control, scripts for automated upgrading of libraries from one version of Modelica to the next, etc.

http://www.ethz.ch/



• Yet, tools for managing potentially bad models offer only a partial answer to the problem. More important are tools that minimize the complexity of the individual model codes and that support the modeler in making sure that his or her models are correctly reflecting the physics of the underlying physical system to be modeled.

• This presentation offers a discussion of such methodologies.

http://www.ethz.ch/



1. Graphical Modeling• Modeling systems graphically is better than

modeling them by means of equations.• Graphical models are two-dimensional, whereas

equations are one-dimensional.• Hence missing connections can be identified more

easily.• The maintenance of graphical models is

considerably easier than that of equation models.

http://www.ethz.ch/



• Graphical modeling forces the modeler to structure his or her models such that each of them fits entirely onto one screen.

• Some graphical modeling environments offer a virtual canvas over which the physical screen can be shifted.

• Don’t use it! It’s a mistake. A model that doesn’t fit on a screen needs to be restructured.

• A Modelica environment that doesn’t offer a full-fledged graphical front end is not competitive.

http://www.ethz.ch/



2. Bond Graph Modeling• Bond graphs represent the lowest-level graphical

model interface that is still fully object oriented.• Bond graph modeling enables the modeler to model

graphically further down than any other graphical modeling methodology.

• This minimizes the need for using equations, thereby making the so-built libraries easier maintainable.

• Bond graphs do not necessarily offer the best suited GUI for the end user.

http://www.ethz.ch/



3. Model Wrapping• Library designers should make use of the best suited

graphical modeling methodology for representing their models to the end user.

• However, models can use more than one graphical layer.

• There is no need to implement the top graphical layer directly using equation models.

• Model wrapping enables the library designer to interpret one graphical modeling methodology in terms of another lower-level graphical modeling approach, such as a bond graph.

http://www.ethz.ch/



A Crane Crab• Let us look at the following crane crab model:

yprismatic joint

revolutejoint

mass 1

mass 2

rod

x

Prismatic Joint

Revolute Joint

Rod

Mass 2

Mass 1

http://www.ethz.ch/



Multi-body System Representation

http://www.ethz.ch/



Crane Crab Simulation ResultsThe animation needs to be associated with the MBS layer, and not with the bond graph layer. Individual bonds cannot be animated. Consequently, the multi-bond graph is not suitable as a user interface.

http://www.ethz.ch/



Model Wrapping II• Wrapped models contain wrapper models that

convert the upper-layer connectors to the lower-layer connectors, and vice-versa.

• They use the protected keyword to hide the internal lower-layer variables from the simulation. In this way, the set of variables offered for display in the simulation window is identical in both libraries. This is called wrapping the model tight.

• The state select algorithm is used to ensure that the flattened Modelica model will employ the same state variables in both libraries.

http://www.ethz.ch/



An Example• Given the following mechanical system:

http://www.ethz.ch/



An Example II• Using the translational sub-library of the mechanics library

of the BondLib library, this system can be modeled as follows:

http://www.ethz.ch/



The Sliding Mass Model• Let us look at the model of a sliding mass.

The two state variables are the f variable of the inductor model and the output of the internal integrator of the q sensor.

http://www.ethz.ch/



The Sliding Mass Model II• The natural state variables of this

model are the internal variables I.f and sAbs.Integrator1.y. This is inconvenient.

• The user of the model would prefer to use the local variables v and s of the mass model as state variables.

• Modelica can be told to modify the equations such that, if possible, the desired variables are being used as state variables, i.e., show up in the simulation code with a der() operator.

http://www.ethz.ch/



The Sliding Mass Model IV• One question that remains is for

which variables we now have to specify the initial conditions.

• Do we do it for the new state variables s and v, or do we still do it for the natural state variables?

• It turns out that we can do either or, but not both.

• Modelica will use the specified values as start values of an iteration and iterate on the unknown initial values of the new state variables, until it finds a set of initial conditions that is consistent with the information that has been specified by the user.

http://www.ethz.ch/



Wrapping Tightly – Protected Variables• Let’s now look at the expanded view of

the equation layer of the spring model.• I manually placed the keyword

protected in front of the declarations of variables to the inside of the wrapper models.

• The effect of this measure is to prevent these variables from being displayed in the simulation window.

• In this way, the model parameters will look exactly the same in the simulation window as using the corresponding model of the standard library.

• The model has been wrapped tightly.

http://www.ethz.ch/



An Example III

The initial conditions were calculated correctly.

Due to information hiding (protected variables), only those variables external to the wrapper models are visible.

http://www.ethz.ch/



2D Simulation of 1D Models II

Prismatic joints need to accompany the masses in order to limit their degrees of freedom to one.

BondLib

MultiBondLib

http://www.ethz.ch/



Translation LogsW

rapp

ed 1

D m

echa

nica

l bon

d gr

aph

mod

el Wrapped 2D

mechanical bond graph m

odel

http://www.ethz.ch/



Simulation Logs

http://www.ethz.ch/



Simulation Results

http://www.ethz.ch/



Efficiency Considerations• The following table compares the efficiency of the

simulation code obtained using the multi-body library contained as part of the standard Modelica library with that obtained using the 3D mechanics sub-library of the multi-bond graph library.

http://www.ethz.ch/



BondLib

• Beside from the standard 1D bond graph elements, BondLib offers additionally wrapped sub-libraries for electrical analog circuits; for mechanical 1D translational and rotational motions; a heat transfer sub-library; and a small hydraulics sub-library.

• The electrical sub-library contains in addition a full implementation of Spice.

http://www.ethz.ch/



Multiple Modeling Interfaces in BondLib

http://www.ethz.ch/



Thermal Modeling in BondLib (Biosphere 2)

http://www.ethz.ch/



Spice Implementation in BondLib

http://www.ethz.ch/



MultiBondLib• Beside from the standard 2D and 3D mechanical multi-bond

graph elements, MultiBondLib offers additionally wrapped sub-libraries for planar mechanical motions and for 3D mechanical motions including fully automated animation.

• These wrapped sub-libraries are equivalent in power and efficiency to the multi-body system library contained as part of the Modelica standard library.

• In addition, MultiBondLib offers separate sub-libraries for planar mechanics; the possibility to model elastic and inelastic impacts between 3D bodies; as well as the possibility of modeling gravitational pools, such as needed for the simulation of planetary systems. These features are not currently available in the Modelica standard library.

http://www.ethz.ch/



Multiple Interfaces in MultiBondLib

http://www.ethz.ch/



ThermoBondLib• The ThermoBondLib library was designed for

modeling convective flows (simultaneous flows of mass, volume, and heat) using thermo-bond graphs.

• There are currently no wrapped thermo-bond graph sub-libraries available yet.

• In the future, such wrapped sub-libraries will be added to replicate features of the media and fluid sub-libraries of the Modelica standard library.

http://www.ethz.ch/



Graphical Modeling in ThermoBondLib

http://www.ethz.ch/



4. Multiple Implementations• We can never be absolutely sure that our libraries don’t

contain errors, or that neither the model compiler nor the simulation engine contain bugs.

• To reduce the likelihood of such errors, it is useful to have multiple implementations available.

• By comparing the simulation results of the standard library with those of the three bond graph libraries, we can verify the correctness of the libraries.

• By comparing the simulation results of e.g. Dymola with those of OpenModelica, we can verify the correctness of the model compilers and simulation engines.

http://www.ethz.ch/



5. Unit Checking• It is now possible to declare correct measurement

units in Modelica.• This feature helps dramatically in debugging

models of physical systems.• Bond graph models are generic (multi-domain), and

therefore cannot declare measurement units.• For this reason, it must be possible to inherit

measurement units downwards from the higher to the lower layers of the model architecture.

• It is important that OpenModelica support unit checking in order to be competitive.

http://www.ethz.ch/



5. Derived Data Types• In newer versions of Modelica, it is possible to declare

derived data types, such as variables with a reduced range.

• It is important that OpenModelica verifies that such constraints aren’t being violated during the simulation.

http://www.ethz.ch/



6. Assertions• In newer versions of Modelica, it is possible to declare

assertions, representing a generalization of the derived data types mentioned earlier.

• It is important that OpenModelica verifies that also these constraints aren’t being violated during the simulation.

http://www.ethz.ch/



Conclusions• In this presentation, I have looked at a number of

features that can help create safer models:1. graphical modeling2. bond graph modeling3. model wrapping4. multiple implementations5. derived data types6. assertions

• Together they offer means for creating Modelica libraries that are safer to use and easier to maintain.

http://www.ethz.ch/

fran ç ois e. cellier department of computer science eth zurich switzerland

Documents