Integrated Model-driven Development Environments for Equation-based Object-oriented Languages




НазваниеIntegrated Model-driven Development Environments for Equation-based Object-oriented Languages
страница5/55
Дата04.10.2012
Размер0.98 Mb.
ТипДокументы
1   2   3   4   5   6   7   8   9   ...   55

2.2The Modelica Language


Starting 1989, our group developed an equation-based specification language for mathematical modeling called ObjectMath (Fritzson et al. 1995 [53], Viklund et al. 1992 [173]), using Mathematica as a basis and a frontend, but adding object orientation and efficient code generation. Following this path, in 1996 our group joined efforts with several other groups in object-oriented mathematical modeling to start a design-group for developing an internationally viable declarative mathematical modeling language. This language, called Modelica, has been designed by the Modelica Design Group, initially consisting mostly of the developers of a number of different equation-based object-oriented modeling languages like Allan, Dymola, NMF, ObjectMath, Omola, SIDOPS+, Smile, as well as other modeling and simulation experts. In February 2000, a non-profit organization named “Modelica Association” was founded in Linköping, Sweden, for further development and promotion of Modelica. Modelica (Elmqvist et al. 1999 [35], Fritzson 2004 [44], Fritzson and Engelson 1998 [50], Modelica.Association 1996-2008 [99], Tiller 2001 [152]) is an object-oriented modeling language for declarative equation-based mathematical modeling of large and heterogeneous physical systems. For modeling with Modelica, commercial software products such as MathModelica (MathCore [91]) or Dymola (Dynasim 2005 [27]) have been developed. Also open-source implementations like the OpenModelica system (Fritzson et al. 2002 [46], PELAB 2002-2008 [118]) are available.

The Modelica language has been designed to allow tools to automatically generate efficient simulation code with the main objective of facilitating exchange of models, model libraries, and simulation specifications. The definition of simulation models is expressed in a declarative manner, modularly and hierarchically. Various formalisms can be expressed in the more general Modelica formalism. In this respect Modelica has a multi-domain modeling capability which gives the user the possibility to combine electrical, mechanical, hydraulic, thermodynamic, etc., model components within the same application model. Compared to most other modeling languages available today, Modelica offers several important advantages from the simulation practitioner’s point of view:

  • Object-oriented mathematical modeling. This technique makes it possible to create model components, which are employed to support hierarchical structuring, reuse, and evolution of large and complex models covering multiple technology domains. A general type system that unifies object-orientation, multiple inheritance, and generics templates within a single class construct. This facilitates reuse of components and evolution of models.

  • Acausal modeling based on ordinary differential equations (ODE) and differential algebraic equations (DAE) together with discrete equations forming a hybrid DAE.. There is also ongoing research to include partial differential equations (PDE) in the language syntax and semantics (Saldamli et al. 2002 [142]), (Saldamli 2002 [140], Saldamli et al. 2005 [141]).

  • Multi-domain modeling capability, which gives the user the possibility to combine electrical, mechanical, thermodynamic, hydraulic etc., model components within the same application model.

  • A strong software component model, with constructs for creating and connecting components. Thus the language is ideally suited as an architectural description language for complex physical systems, and to some extent for software systems.

  • Visual drag & drop and connect composition of models from components present in different libraries targeted to different domains (electrical, mechanical, etc).

The language is strongly typed and declarative. See (Modelica.Association 1996-2008 [99]), (Modelica-Association 2005 [101]), (Tiller 2001 [153]), and (Fritzson 2004 [44]) for a complete description of the language and its functionality from the perspective of the motivations and design goals of the researchers who developed it. Shorter overviews of the language are available in (Elmqvist et al. 1999 [35]), (Fritzson and Engelson 1998 [50]), and (Fritzson and Bunus 2002 [49]).

The Modelica component model includes the following three items: a) components, b) a connection mechanism, and c) a component framework. Components are connected via the connection mechanism realized by the Modelica system, which can be visualized in connection diagrams. The component framework realizes components and connections, and ensures that communication works over via the connections.

For systems composed of acausal components with behavior specified by equations, the direction of data flow, i.e., the causality is initially unspecified for connections between those components. Instead the causality is automatically deduced by the compiler when needed. Components have well-defined interfaces consisting of ports, also known as connectors, to the external world. A component may internally consist of other connected components, i.e., hierarchical modeling is possible. Figure 2 -4 shows a hierarchical component-based modeling of an industry robot.



Figure 2 4. Hierarchical model of an industrial robot, including components such as motors, bearings, control software, etc. At the lowest (class) level, equations are typically found.

2.2.1An Example Modelica Model


The following is an example Lotka Volterra Modelica model containing two differential equations relating the sizes of rabbit and fox populations which are represented by the variables rabbits and foxes: The model was independently developed by Alfred J Lotka (1925) and Vito Volterra (1926): The rabbits multiply (by breeding); the foxes eat rabbits. Eventually there are enough foxes eating rabbits causing a decrease in the rabbit population, etc., causing cyclic population sizes. The model is simulated and the sizes of the rabbit and fox populations are plotted in Figure 2 -5 as a function of time.



Figure 2 5. Number of rabbits – prey animals, and foxes – predators, as a function of time simulated from the predator-prey LotkaVolterra model.

The notation der(rabbits) means time derivative of the rabbits (population) variable.

model LotkaVolterra

parameter Real g_r =0.04 "Natural growth rate for rabbits";

parameter Real d_rf=5e-5 "Death rate of rabbits due to

foxes";

parameter Real d_f =0.09 "Natural death rate for foxes";

parameter Real g_fr=0.1 "Efficiency in growing foxes from

rabbits";

Real rabbits(start=700) "Rabbits with start population 700";

Real foxes(start=10) "Foxes, with start population 10";

equation

der(rabbits) = g_r*rabbits - d_rf*rabbits*foxes;

der(foxes) = g_fr*d_rf*rabbits*foxes - d_f*foxes;

end LotkaVolterra;

2.2.2Modelica as a Component Language


Modelica offers quite a powerful software component model that is on par with hardware component systems in flexibility and potential for reuse. The key to this increased flexibility is the fact that Modelica classes are based on equations, i.e., acausal connections for which the direction of data flow across the connection is not fixed. Components are connected via the connection mechanism, which can be visualized in connection diagrams. The component framework realizes components and connections, and ensures that communication works and constraints are maintained over the connections. For systems composed of acausal components the direction of data flow, i.e., the causality is automatically deduced by the compiler at composition time.

Two types of coupling can be established by connections depending on whether the variables in the connected connectors are non-flow (default), or declared using the flow prefix:

  1. Equality coupling, for non-flow variables, according to Kirchhoff’s first law.

  2. Sum-to-zero coupling, for flow variables, according to Kirchhoff’s current law.

For example, the keyword flow for the variable i of type Current in the Pin connector class indicates that all currents in connected pins are summed to zero, according to Kirchhoff’s current law.



Figure 2 6. Connecting two components that have electrical pins.

Connection equations are used to connect instances of connection classes. A connection equation connect(pin1,pin2), with pin1 and pin2 of connector class Pin, connects the two pins (Figure 2 -6) so that they form one node. This produces two equations, namely:

pin1.v = pin2.v

pin1.i + pin2.i = 0

The first equation says that the voltages of the connected wire ends are the same. The second equation corresponds to Kirchhoff's second law, saying that the currents sum to zero at a node (assuming positive value while flowing into the component). The sum-to-zero equations are generated when the prefix flow is used. Similar laws apply to flows in piping networks and to forces and torques in mechanical systems.
1   2   3   4   5   6   7   8   9   ...   55

Похожие:

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconThe Domain Analysis Integrated in an Object Oriented Development Methodology

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconHypergraph-based Object-oriented Model for gis application

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconObject-Oriented Object-Oriented Languages

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconApplying uml and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition)

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconModel Development of a Total Integrated Maintenance System

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconAn integrated framework for model-based flow assurance in deep-water oil and gas production

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconThis paper introduces the basic concepts of Agile Database Techniques, and effective ways to go about the Data-Oriented aspects of Object Oriented software

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconObject-Oriented Metrics: an Annotated Bibliography

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconAn Introduction and Brief Examination of Object-Oriented Data Modeling

Integrated Model-driven Development Environments for Equation-based Object-oriented Languages iconAn Object-Oriented Support Tool for the Design of Casting Procedures

Разместите кнопку на своём сайте:
Библиотека


База данных защищена авторским правом ©lib.znate.ru 2014
обратиться к администрации
Библиотека
Главная страница