Technologies for Creating Easily Maintainable Component Model Libraries of Complex Physical Systems

1
Technologies for Creating Easily Maintainable
Component Model Libraries of Complex Physical
Systems
François E. Cellier Department of Computer
Science ETH ZurichSwitzerland
2

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

3

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

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

5

• 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.
• Dont use it! Its a mistake. A model that
  doesnt fit on a screen needs to be restructured.
• A Modelica environment that doesnt offer a
  full-fledged graphical front end is not
  competitive.

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

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

8
A Crane Crab

• Let us look at the following crane crab model

9
Multi-body System Representation
10
Crane Crab Simulation Results
The 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.
11
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.

12
An Example

• Given the following mechanical system

13
An Example II

• Using the translational sub-library of the
  mechanics library of the BondLib library, this
  system can be modeled as follows

14
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.
15
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.

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

17
Wrapping Tightly Protected Variables

• Lets 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.

18
An Example III
19
2D Simulation of 1D Models II
MultiBondLib
BondLib
20
Translation Logs
Wrapped 1D mechanical bond graph model
Wrapped 2D mechanical bond graph model
21
Simulation Logs
22
Simulation Results
23
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.

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

25
Multiple Modeling Interfaces in BondLib
26
Thermal Modeling in BondLib (Biosphere 2)
27
Spice Implementation in BondLib
28
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.

29
Multiple Interfaces in MultiBondLib
30
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.

31
Graphical Modeling in ThermoBondLib
32
4. Multiple Implementations

• We can never be absolutely sure that our
  libraries dont 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.

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

34
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 arent being violated during the
  simulation.

35
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 arent being violated
  during the simulation.

36
Conclusions

• In this presentation, I have looked at a number
  of features that can help create safer models

1. graphical modeling
2. bond graph modeling
3. model wrapping
4. multiple implementations
5. derived data types
6. assertions

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