Paradigm | Declarative language |
---|---|
Developer | Modelica Association Project (MAP) |
First appeared | 1997 |
Stable release | 3.5 / February 18, 2021 [1] |
OS | Cross-platform |
License | CC-BY-SA |
Filename extensions | .mo |
Website | www.modelica.org |
Major implementations | |
AMESim, CATIA Systems, Dymola, JModelica.org, MapleSim, Wolfram SystemModeler, OpenModelica, Scicos, SimulationX, Xcos |
Modelica is an object-oriented, declarative, multi-domain modeling language for component-oriented modeling of complex systems, e.g., systems containing mechanical, electrical, electronic, hydraulic, thermal, control, electric power or process-oriented subcomponents. The free Modelica language [1] is developed by the non-profit Modelica Association. [2] The Modelica Association also develops the free Modelica Standard Library [3] that contains about 1400 generic model components and 1200 functions in various domains, as of version 4.0.0.
While Modelica resembles object-oriented programming languages, such as C++ or Java, it differs in two important respects. First, Modelica is a modeling language rather than a conventional programming language. Modelica classes are not compiled in the usual sense, but they are translated into objects which are then exercised by a simulation engine. The simulation engine is not specified by the language, although certain required capabilities are outlined.
Second, although classes may contain algorithmic components similar to statements or blocks in programming languages, their primary content is a set of equations . In contrast to a typical assignment statement, such as
x:=2+y;
where the left-hand side of the statement is assigned a value calculated from the expression on the right-hand side, an equation may have expressions on both its right- and left-hand sides, for example,
x+y=3*z;
Equations do not describe assignment but equality. In Modelica terms, equations have no pre-defined causality . The simulation engine may (and usually must) manipulate the equations symbolically to determine their order of execution and which components in the equation are inputs and which are outputs.
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 [4] of Hilding Elmqvist and on the experience with the modeling languages Allan, [5] Dymola, NMF [6] ObjectMath, [7] Omola, [8] SIDOPS+, [9] and Smile. [10] Hilding Elmqvist is the key architect of Modelica, but many other people have contributed as well (see appendix E in the Modelica specification [1] ). 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: [11]
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. |
3.4 | 2017, April | Automatic conversion of models. Many minor improvements |
3.5 | 2021, February | Annotations for predefined plots. Change of specification format, with many editorial changes. Clarifications to synchronous language elements and state machines. Many minor clarifications to functions, model conversions, and several other parts of the specification. |
Commercial front-ends for Modelica include AMESim from the French company Imagine SA (now part of Siemens Digital Industries Software), Dymola from the Swedish company Dynasim AB (now part of Dassault Systemes), Wolfram SystemModeler (formerly MathModelica) from the Swedish company Wolfram MathCore AB (now part of Wolfram Research), SimulationX from the German company ESI ITI GmbH, MapleSim from the Canadian company Maplesoft, [12] JModelica.org (open source, discontinued) and Modelon Impact, [13] from the Swedish company Modelon AB, and CATIA Systems [14] [15] from Dassault Systemes (CATIA is one of the major CAD systems).
Openmodelica [16] 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, [17] compilation and simulation environment based on free software distributed in binary and source code form for research, [18] [19] teaching, [20] 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. [21]
The following code fragment shows a very simple example of a first order system ():
modelFirstOrderparameterRealc=1"Time constant";Realx(start=10)"An unknown";equationder(x)=-c*x"A first order differential equation";endFirstOrder;
The following code fragment shows an example to calculate the second derivative [22] of a trigonometric function, using OMShell, as a means to develop the program written below.
modelsecond_derivativeReall;Realz=sin(w*time);Realm;parameterRealw=1;equationl=der(z);m=der(l);endsecond_derivative;
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:
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:
typeVoltage=Real(quantity="ElectricalPotential",unit="V");typeCurrent=Real(quantity="ElectricalCurrent",unit="A");...
The interaction of a component to other components is defined by physical ports, called connectors, e.g., an electrical pin is defined as
connectorPin"Electrical pin"Voltagev"Potential at the pin";flowCurrenti"Current flowing into the component";endPin;
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.
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):
modelCapacitorparameterCapacitanceC;Voltageu"Voltage drop between pin_p and pin_n";Pinpin_p,pin_n;equation0=pin_p.i+pin_n.i;u=pin_p.v-pin_n.v;C*der(u)=pin_p.i;endCapacitor;
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.
The full rules for defining balanced models are rather complex, and can be read from [1] in section 4.7.
However, for most cases, a simple rule can be 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 we 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 [16] 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:
modelSignalVoltage"Generic voltage source using the input signal as source voltage"Interfaces.PositivePinp;Interfaces.NegativePinn;Modelica.Blocks.Interfaces.RealInputv(unit="V")"Voltage between pin p and n (= p.v - n.v) as input signal";SI.Currenti"Current flowing from pin p to pin n";equationv=p.v-n.v;0=p.i+n.i;i=p.i;endSignalVoltage;
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 [16] gives
Class Modelica.Electrical.Analog.Sources.SignalVoltage has 5 equation(s) and 5 variable(s). 4 of these are trivial equation(s).
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:
modelCircuitCapacitorC1(C=1e-4)"A Capacitor instance from the model above";CapacitorC2(C=1e-5)"A Capacitor instance from the model above";...equationconnect(C1.pin_p,C2.pin_n);...endCircuit;
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.
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) [23] 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, [24] [25] [26] General Motors, [27] Toyota, [28] BMW, [29] and Daimler. [30]
Modelica is also being increasingly used for the simulation of thermo-fluid and energy systems. [31]
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. [32]
{{cite journal}}
: Cite journal requires |journal=
(help)Modelica language is well-established for system-level modelling tasks in many domains of engineering, such as automotive, robotics, mechatronics, energy, aerospace, in particular when multi-domain modelling is required.
{{cite book}}
: Missing or empty |title=
(help)An analog computer or analogue computer is a type of computer that uses the continuous variation aspect of physical phenomena such as electrical, mechanical, or hydraulic quantities to model the problem being solved. In contrast, digital computers represent varying quantities symbolically and by discrete values of both time and amplitude.
In electrical engineering, electrical elements are conceptual abstractions representing idealized electrical components, such as resistors, capacitors, and inductors, used in the analysis of electrical networks. All electrical networks can be analyzed as multiple electrical elements interconnected by wires. Where the elements roughly correspond to real components, the representation can be in the form of a schematic diagram or circuit diagram. This is called a lumped-element circuit model. In other cases, infinitesimal elements are used to model the network, in a distributed-element model.
The lumped-element model simplifies the description of the behaviour of spatially distributed physical systems, such as electrical circuits, into a topology consisting of discrete entities that approximate the behaviour of the distributed system under certain assumptions. It is useful in electrical systems, mechanical multibody systems, heat transfer, acoustics, etc. This may be contrasted to distributed parameter systems or models in which the behaviour is distributed spatially and cannot be considered as localized into discrete entities.
In electrical engineering and electronics, a network is a collection of interconnected components. Network analysis is the process of finding the voltages across, and the currents through, all network components. There are many techniques for calculating these values; however, for the most part, the techniques assume linear components. Except where stated, the methods described in this article are applicable only to linear network analysis.
The electronic–hydraulic analogy is the most widely used analogy for "electron fluid" in a metal conductor. Since electric current is invisible and the processes in play in electronics are often difficult to demonstrate, the various electronic components are represented by hydraulic equivalents. Electricity was originally understood to be a kind of fluid, and the names of certain electric quantities are derived from hydraulic equivalents. As with all analogies, it demands an intuitive and competent understanding of the baseline paradigms, and in the case of the hydraulic analogy for electronics, students often have an inadequate knowledge of hydraulics.
In the systems sciences system equivalence is the behavior of a parameter or component of a system in a way similar to a parameter or component of a different system. Similarity means that mathematically the parameters and components will be indistinguishable from each other. Equivalence can be very useful in understanding how complex systems work.
A state variable is one of the set of variables that are used to describe the mathematical "state" of a dynamical system. Intuitively, the state of a system describes enough about the system to determine its future behaviour in the absence of any external forces affecting the system. Models that consist of coupled first-order differential equations are said to be in state-variable form.
A bond graph is a graphical representation of a physical dynamic system. It allows the conversion of the system into a state-space representation. It is similar to a block diagram or signal-flow graph, with the major difference that the arcs in bond graphs represent bi-directional exchange of physical energy, while those in block diagrams and signal-flow graphs represent uni-directional flow of information. Bond graphs are multi-energy domain and domain neutral. This means a bond graph can incorporate multiple domains seamlessly.
EcosimPro is a simulation tool developed by Empresarios Agrupados A.I.E for modelling simple and complex physical processes that can be expressed in terms of Differential algebraic equations or Ordinary differential equations and Discrete event simulation.
A signal-flow graph or signal-flowgraph (SFG), invented by Claude Shannon, but often called a Mason graph after Samuel Jefferson Mason who coined the term, is a specialized flow graph, a directed graph in which nodes represent system variables, and branches represent functional connections between pairs of nodes. Thus, signal-flow graph theory builds on that of directed graphs, which includes as well that of oriented graphs. This mathematical theory of digraphs exists, of course, quite apart from its applications.
Dymola is a commercial modeling and simulation environment based on the open Modelica modeling language.
Pantelides algorithm in mathematics is a systematic method for reducing high-index systems of differential-algebraic equations to lower index. This is accomplished by selectively adding differentiated forms of the equations already present in the system. It is possible for the algorithm to fail in some instances.
JModelica.org is a commercial software platform based on the Modelica modeling language for modeling, simulating, optimizing and analyzing complex dynamic systems. The platform is maintained and developed by Modelon AB in collaboration with academic and industrial institutions, notably Lund University and the Lund Center for Control of Complex Systems (LCCC). The platform has been used in industrial projects with applications in robotics, vehicle systems, energy systems, CO2 separation and polyethylene production.
Wolfram System Modeler, developed by Wolfram MathCore, is a platform for engineering as well as life-science modeling and simulation based on the Modelica language. It provides an interactive graphical modeling and simulation environment and a customizable set of component libraries.
Simcenter Amesim is a commercial simulation software for the modeling and analysis of multi-domain systems. It is part of systems engineering domain and falls into the mechatronic engineering field.
In control system theory, and various branches of engineering, a transfer function matrix, or just transfer matrix is a generalisation of the transfer functions of single-input single-output (SISO) systems to multiple-input and multiple-output (MIMO) systems. The matrix relates the outputs of the system to its inputs. It is a particularly useful construction for linear time-invariant (LTI) systems because it can be expressed in terms of the s-plane.
System-level simulation (SLS) is a collection of practical methods used in the field of systems engineering, in order to simulate, with a computer, the global behavior of large cyber-physical systems.
OpenModelica is a free and open source environment based on the Modelica modeling language for modeling, simulating, optimizing and analyzing complex dynamic systems. This software is actively developed by Open Source Modelica Consortium, a non-profit, non-governmental organization. The Open Source Modelica Consortium is run as a project of RISE SICS East AB in collaboration with Linköping University.
AltaRica is an object-oriented modeling language dedicated to probabilistic risk and safety analyses. It is a representative of the so-called model-based approach in reliability engineering. Since its version 3.0, it is developed by the non-profit AltaRica Association, which develops jointly the associated modeling environment AltaRica Wizard.