Modelica

Paradigm declarative language 1997 Cross-platform Modelica License Version 2 .mo www.modelica.org ActionScript, OCaml, Java

Modelica - a freely available, object-oriented language for modeling of large, complex, and heterogeneous systems. It is suited for multi-domain modeling, for example, mechatronic models in robotics, automotive and aerospace applications involving mechanical, electrical, hydraulic control and state machine subsystems, process oriented applications and generation and distribution of electric power. Models in Modelica are mathematically described by differential, algebraic and discrete equations. No particular variable needs to be solved for manually. A Modelica tool will have enough information to decide that automatically. Modelica is designed such that available, specialized algorithms can be utilized to enable efficient handling of large models having more than one hundred thousand equations. Modelica is suited and used for hardware-in-the-loop simulations and for embedded control systems.

Overview of Modelica

Modelica is a freely available, object-oriented language for modeling of large, complex, and heterogeneous physical systems. From a user’s point of view, models are described by schematics, also called object diagrams. The Modelica language is a textual description to define all parts of a model and to structure model components in libraries, called packages. An appropriate Modelica simulation environment is needed to graphically edit and browse a Modelica model (by interpreting the information defining a Modelica model) and to perform model simulations and other analysis. Basically, all Modelica language elements are mapped to differential, algebraic and discrete equations. There are no language elements to describe directly partial differential equations, although some types of discretized partial differential equations can be reasonably defined, e.g., based on the finite volume method and there are Modelica libraries to import results of finite-element programs.

History

The Modelica design effort was initiated in September 1996 by Hilding Elmqvist. The goal was to develop an object-oriented language for modeling of technical systems in order to reuse and exchange dynamic system models in a standardized format. Modelica 1.0 is based on the PhD thesis of Hilding Elmqvist and on the experience with the modeling languages Allan, Dymola, NMF, ObjectMath, Omola, SIDOPS+, and Smile. Hilding Elmqvist is the key architect of Modelica, but many other people have contributed as well. In September 1997, version 1.0 of the Modelica specification was released which was the basis for a prototype implementation within the commercial Dymola software system. In year 2000, the non-profit Modelica Association was formed to manage the continually evolving Modelica language and the development of the free Modelica Standard Library. In the same year, the usage of Modelica in industrial applications started. This table presents the timeline of the Modelica specification history:

Release Release Date Highlights
1.0 1997, September First version to model continuous dynamic systems.
1.1 1998, December Language elements to model discrete systems (pre, when)
1.2 1999, June Interface to C and Fortran, inner/outer for global variables, refined semantics of event handling
1.3 1999, December Improved semantics for inner/outer connections, protected elements, array expressions.
1.4 2000, December Removed declare-before-use rule, refined package concept, refined when-clause
2.0 2002, July Initialization of models, standardization of graphical appearance, functions with mixed positional and named arguments, record constructor, enumerations
2.1 2004, March Overdetermined connector to model 3-dim. mechanical systems, enhanced redeclaration of submodels, array and array indices of enumerations
2.2 2005, February Expandable connector to model signal buses, conditional component declarations, arrays with dynamic size changes in functions
3.0 2007, September Clean-up version: specification newly written, type system and graphical appearance refined, language flaws fixed, balanced model concept to detect model errors in a much better way
3.1 2009, May Stream connector to handle bi-directional flow of fluid, operator overloading, mapping model parts to execution environments (for use in embedded systems)
3.2 2010, March Improved initialization with homotopy method, functions as formal inputs to functions, Unicode support, access control to protect IP, improved support of object libraries
3.3 2012, May Added language elements to describe periodic and non-periodic synchronous controllers based on clocked equations, as well as synchronous state machines.

Scope of the Specification

The semantics of the Modelica language is specified by means of a set of rules for translating any class described in the Modelica language to a flat Modelica structure. A class must have additional properties in order that its flat Modelica structure can be further transformed into a set of differential, algebraic and discrete equations (= flat hybrid DAE). Such classes are called simulation models. The flat Modelica structure is also defined for other cases than simulation models; including functions (can be used to provide algorithmic contents), packages (used as a structuring mechanism), and partial models (used as base-models). This allows correctness to be verified before building the simulation model. Modelica was designed to facilitate symbolic transformations of models, especially by mapping basically every Modelica language construct to continuous or instantaneous equations in the flat Modelica structure. Many Modelica models, especially in the associated Modelica Standard Library, are higher index systems, and can only be reasonably simulated if symbolic index reduction is performed, i.e., equations are differentiated and appropriate variables are selected as states, so that the resulting system of equations can be transformed to state space form (at least locally numerically), i.e., a hybrid DAE of index zero. The Modelica specification does not define how to simulate a model. However, it defines a set of equations that the simulation result should satisfy as well as possible. The key issues of the translation (or flattening) are:

• Expansion of inherited base classes
• Parameterization of base classes, local classes and components
• Generation of connection equations from connect-equations

The flat hybrid DAE form consists of:

• Declarations of variables with the appropriate basic types, prefixes and attributes, such as "parameter

Real v=5".

• Equations from equation sections.
• Function invocations where an invocation is treated as a set of equations which involves all input and all

result variables (number of equations = number of basic result variables).

• Algorithm sections where every section is treated as a set of equations which involves the variables

occurring in the algorithm section (number of equations = number of different assigned variables).

• When-clauses where every when-clause is treated as a set of conditionally evaluated equations, also called

instantaneous equations, which are functions of the variables occurring in the clause (number of equations = number of different assigned variables). Therefore, a flat hybrid DAE is seen as a set of equations where some of the equations are only conditionally evaluated (e.g. instantaneous equations are only evaluated when the corresponding when-condition becomes true). Initial setup of the model is specified using start-values and instantaneous equations that hold at the initial time only. A Modelica class may also contain annotations, i.e. formal comments, which specify graphical representations of the class (icon and diagram), documentation text for the class, and version information.

Some Definitions

The semantic specification should be read together with the Modelica grammar. Non-normative text, i.e., examples and comments, are enclosed in [ ]; comments are set in italics.

Term Definition
Component An element defined by the production component_clause in the Modelica grammar

(basically a variable or an instance of a class)

Element Class definitions, extends-clauses and component-clauses declared in a class

(basically a class reference or a component in a declaration).

Flattening The translation of a model described in Modelica to the corresponding model described

as a hybrid DAE, involving expansion of inherited base classes, parameterization of base classes, local classes and components, and generation of connection equations from connect-equations (basically, mapping the hierarchical structure of a model into a set of differential, algebraic and discrete equations together with the corresponding variable declarations and function definitions from the model).

Implementations

Commercial front-ends for Modelica include AMESim from the French company Imagine SA (now part of LMS International), Dymola from the Swedish company Dynasim AB (now part of Dassault Systemes), CyModelica from the American company CyDesign Labs, Wolfram SystemModeler (formerly MathModelica) from the Swedish company Wolfram MathCore AB (now part of Wolfram Research), SimulationX from the German company ITI GmbH, MapleSim from the Canadian company Maplesoft, and CATIA Systems from Dassault Systemes (CATIA is one of the major CAD systems). JModelica.org is an extensible Modelica-based open source platform for optimization, simulation and analysis of complex dynamic systems. The main objective of the project is to create an industrially viable open source platform for simulation optimization of Modelica models, while offering a flexible platform serving as a virtual lab for algorithm development and research. OpenModelica is an open-source Modelica-based modeling and simulation environment intended for industrial and academic usage. Its long-term development is supported by a non-profit organization – the Open Source Modelica Consortium (OSMC). The goal with the OpenModelica effort is to create a comprehensive Open Source Modelica modeling, compilation and simulation environment based on free software distributed in binary and source code form for research, teaching, and industrial usage. The free simulation environment Scicos uses a subset of Modelica for component modeling. Support for a larger part of the Modelica language is currently under development. Nevertheless, there is still some incompatibility and diverging interpretation between all the different tools concerning the Modelica language.

Examples

The following code fragment shows a very simple example of a first order system (${\displaystyle {\dot {x}}=-c\cdot x}$):

model FirstOrder
parameter Real c=1 "Time constant";
Real x "An unknown";
equation
der(x) = -c*x "A first order differential equation";
end FirstOrder;

Interesting things to note about this example are the 'parameter' qualifier, which indicates that a given variable is time-invariant and the 'der' operator, which represents (symbolically) the time derivative of a variable. Also worth noting are the documentation strings that can be associated with declarations and equations.

The main application area of Modelica is the modeling of physical systems. The most basic structuring concepts are shown at hand of simple examples from the electrical domain:

Built-in and user derived types

Modelica has the four built-in types Real, Integer, Boolean, String. Typically, user-defined types are derived, to associate physical quantity, unit, nominal values, and other attributes:

type Voltage = Real(quantity="ElectricalPotential", unit="V");
type Current = Real(quantity="ElectricalCurrent", unit="A");
...

Connectors describing physical interaction

The interaction of a component to other components is defined by physical ports, called connectors, e.g., an electrical pin is defined as:

connector Pin "Electrical pin"
Voltage      v "Potential at the pin";
flow Current i "Current flowing into the component";
end Pin;

When drawing connection lines between ports, the meaning is that corresponding connector variables without the "flow" prefix are identical (here: "v") and that corresponding connector variables with the "flow" prefix (here: "i") are defined by a zero-sum equation (the sum of all corresponding "flow" variables is zero). The motivation is to automatically fulfill the relevant balance equations at the infinitesimally small connection point.

Basic model components

A basic model component is defined by a model and contains equations that describe the relationship between the connector variables in a declarative form (i.e., without specifying the calculation order):

model Capacitor
parameter Capacitance C;
Voltage u "Voltage drop between pin_p and pin_n";
Pin pin_p, pin_n;
equation
0 = pin_p.i + pin_n.i;
u = pin_p.v - pin_n.v;
C * der(u) = pin_p.i;
end Capacitor;

The goal is that a connected set of model components leads to a set of differential, algebraic and discrete equations where the number of unknowns and the number of equations is identical. In Modelica, this is achieved by requiring so called balanced models.

However, for most cases, a simple rule can issued, that counts variables and equations the same way as most simulation tools do:

A model is balanced when the number of its equations
equals the number of its variables.


given that variables and equations must be counted according to the following rule:

->Number of model equations                            =
Number of equations defined in the model             +
number of flow variables in the outside connectors->Number of model variables = Number of variables defined in the model
(including the variables in the physical connectors)


Note that standard input connectors (such as RealInput or IntegerInput) do not contribute to the count of variables since no new variables are defined inside them. The reason for this rule can be understood thinking of the capacitor defined above. Its pins contain a flow variable, i.e. a current, each. When we check it, it is connected to nothing. This corresponds to set an equation pin.i=0 for each pin. That's why me must add an equation for each flow variable.

Obviously the example can be extended to other cases, in which other kinds of flow variables are involved (e.g. forces, torques, etc.).

When our capacitor is connected to another (balanced) model through one of its pins, a connection equation will be generated that will substitute the two i=0 equations of the pins being connected. Since the connection equation corresponds to two scalar equations, the connection operation will leave the balanced larger model (constituted by our Capacitor and the model it is connected to).

The Capacitor model above is balanced, since

number of equations =   3+2=5   (flow variables: pin_p.i, pin_n.i, u)
number of variables =       5   (u, pin_p.u, pin_p.i, pin_n.u, pi_n.i)

Verification using OpenModelica of this model gives, in fact:

Class Capacitor has 5 equation(s) and 5 variable(s).
3 of these are trivial equation(s).


Another example, containing both input connectors and physical connectors is the following component from Modelica Standard Library:

model SignalVoltage
"Generic voltage source using the input signal as source voltage"
Interfaces.PositivePin p;
Interfaces.NegativePin n;
Modelica.Blocks.Interfaces.RealInput v(unit="V")
"Voltage between pin p and n (= p.v - n.v) as input signal";
SI.Current i "Current flowing from pin p to pin n";
equation
v = p.v - n.v;
0 = p.i + n.i;
i = p.i;
end SignalVoltage;

The component SignalVoltage is balanced since:

number of equations =   3+2=5  (flow variables: pin_p.i, pin_n.i, u)
number of variables =       5  (i, pin_p.u, pin_p.i, pin_n.u, pi_n.i)

Again, checking with OpenModelica gives:

Class Modelica.Electrical.Analog.Sources.SignalVoltage has 5 equation(s) and 5 variable(s).
4 of these are trivial equation(s).


Hierarchical models

A hierarchical model is built-up from basic models, by instantiating basic models, providing suitable values for the model parameters, and by connecting model connectors. A typical example is the following electrical circuit:

model Circuit
Capacitor C1(C=1e-4) "A Capacitor instance from the model above";
Capacitor C2(C=1e-5) "A Capacitor instance from the model above";
...
equation
connect(C1.pin_p, C2.pin_n);
...
end Circuit;

Via the language element annotation(...), definitions can be added to a model that do not have an influence on a simulation. Annotations are used to define graphical layout, documentation and version information. A basic set of graphical annotations is standardized to ensure that the graphical appearance and layout of models in different Modelica tools is the same.

Applications

Modelica is designed to be domain neutral and, as a result, is used in a wide variety of applications, such as fluid systems (for example, steam power generation, hydraulics, etc.), automotive applications (especially powertrain) and mechanical systems (for example, multi-body systems, mechatronics, etc.).

In the automotive sector, many of the major automotive OEMs are using Modelica. These include Ford, General Motors, Toyota, BMW and Daimler. Modelica is also been increasingly used for the simulation of thermo-fluid and energy systems.

The characteristics of Modelica (acausal, object-oriented, domain neutral) make it well suited to system-level simulation, a domain where Modelica is now well established.

Literature

• Benveniste A., Caspi P., Edwards S.A., Halbwachs N., Le Guernic P., and Simone R. (2003): The Synchronous

Languages Twelve Years Later. Proc. of the IEEE, Vol., 91, No. 1.

• Colaco J.-L., and Pouzet M. (2003): Clocks as First Class Abstract Types. In Third International Conference on

Embedded Software (EMSOFT'03), Philadelphia, Pennsylvania, USA, October 2003.

• Elmqvist H., Otter M. and Cellier F.E. (1995): Inline Integration: A New Mixed Symbolic/Numeric Approach

for Solving Differential-Algebraic Equation Systems. Keynote Address, Proceedings ESM'95, European Simulation Multiconference, Prague, Czech Republic, June 5-8, 1995, pp. xxiii-xxxiv.

• Forget J., F. Boniol, D. Lesens, C. Pagetti (2008): A Multi-Periodic Synchronous Data-Flow Language. In 11th

IEEE High Assurance Systems Engineering Symposium (HASE'08), Dec. 3-5 2008, Nanjing, China, pp. 251-260.

• Harel, D. (1987): Statecharts: A Visual Formalism for Complex Systems. Science of Computer Programming

8, 231-274. Department of Applied Mathematics, The Weizmann Institute of Science, Rehovot, Israel.

• Looye G., Thümmel M., Kurze M., Otter M., and Bals J. (2005): Nonlinear Inverse Models for Control.

Proceedings of 4th International Modelica Conference, ed. G. Schmitz, Hamburg, March 7-8.

• Pouzet M. (2006): Lucid Synchrone, Version 3.0, Tutorial and Reference Manual.