Download
1 / 36
360 likes | 374 Views
Technologies for Creating Easily Maintainable Component Model Libraries of Complex Physical Systems. Fran ç ois E. Cellier Department of Computer Science ETH Zurich Switzerland.
E N D
Technologies for Creating Easily Maintainable Component Model Libraries of Complex Physical Systems François E. Cellier Department of Computer Science ETH ZurichSwitzerland
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.
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.
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. 1. Graphical Modeling
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.
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. 2. Bond Graph Modeling
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. 3. Model Wrapping
Let us look at the following crane crab model: Prismatic Joint Mass 1 Revolute Joint Rod Mass 2 A Crane Crab
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.
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. Model Wrapping II
Given the following mechanical system: An Example
Using the translational sub-library of the mechanics library of the BondLib library, this system can be modeled as follows: An Example II
Let us look at the model of a sliding mass. The Sliding Mass Model The two state variables are the f variable of the inductor model and the output of the internal integrator of the q sensor.
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. The Sliding Mass Model II
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. The Sliding Mass Model IV
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. Wrapping Tightly – Protected Variables
The initial conditions were calculated correctly. Due to information hiding (protected variables), only those variables external to the wrapper models are visible. An Example III
Prismatic joints need to accompany the masses in order to limit their degrees of freedom to one. 2D Simulation of 1D Models II MultiBondLib BondLib
Translation Logs Wrapped 1D mechanical bond graph model Wrapped 2D mechanical bond graph model
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.
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. BondLib
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. MultiBondLib
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. ThermoBondLib
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. 4. Multiple Implementations
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. 5. Unit Checking
In newer versions of Modelica, it is possible to declare derived data types, such as variables with a reduced range. 5. Derived Data Types • It is important that OpenModelica verifies that such constraints aren’t being violated during the simulation.
In newer versions of Modelica, it is possible to declare assertions, representing a generalization of the derived data types mentioned earlier. 6. Assertions • It is important that OpenModelica verifies that also these constraints aren’t being violated during the simulation.
In this presentation, I have looked at a number of features that can help create safer models: Conclusions • graphical modeling • bond graph modeling • model wrapping • multiple implementations • derived data types • assertions • Together they offer means for creating Modelica libraries that are safer to use and easier to maintain.
