modelica and smile – a case study applying object ... - CiteSeerX

MODELICA AND SMILE – A CASE STUDY APPLYING OBJECT-ORIENTED CONCEPTS TO MULTI-FACET MODELING Hubertus Tummescheit, Matthias Klose, Thilo Ernst DLR K¨oln Hauptabteilung Energietechnik Linder H¨ohe D-51140 K¨oln, Germany

Technical University of Berlin Software Engineering Research Group Franklinstr. 28/29 D-10587 Berlin, Germany

GMD FIRST Research Inst. for Computer Architecture and Software Technology Rudower Chaussee 5 D-12489 Berlin, Germany

[email protected], [email protected], [email protected]

ABSTRACT A new language called Modelica for hierarchical physical modeling is developed in an international effort. The main objectives are to make it easy to exchange models and model libraries between tools and to use object-oriented constructs to facilitate the reuse of modeling knowledge. The design approach joins the concepts of non-causal modeling with ordinary differential and algebraic equations with object-oriented model structuring facilities. Modelica’s language features are compared to the features of Smile, one of the existing object-oriented modeling languages available from the TU of Berlin and GMD FIRST. The Smile environment is used at DLR Cologne for the modeling of solar thermal power plants, but the Smile development team plans to extend the environment with the Modelica language (Ernst, T.,S. J¨ahnichen, M. Klose 1997). The example of a simple stove with electrical plates is used to point out the new model structuring possibilities. A tank system with a centrifugal pump is used to demonstrate new possibilities of modeling using genericity and inheritance.

INTRODUCTION Within the last two decades several object-oriented languages for physical systems modeling has been developed, some of which are also non-causal. These are ASCEND(Piela, Epperly, Westerberg, and Westerberg 1991), Dymola(Elmqvist 1978), ObjectMath(Fritzson, Engelson, and Viklund 1993), Omola(Mattsson and Andersson 1992), SIDOPS+(Breunese and Broenink 1997), Smile(Jochum and Kloas 1994), ULM(Jeandel, Ravier, and Buhsing 1995) and NMF(Sahlin, Bring, and Sowell 1994). The Modelica design group, a technical committee within EUROSIM, has attempted to unify the different concepts and introduce a common syntax and semantic for the Modelica language. Modelica is intended to be a superset of the aforementioned languages and to become a neutral exchange format for model representation. Most of the current simulation systems are strong in one domain but not suitable in other domains. The increasing complexity and interdisciplinary nature of todays engineering projects calls for improved interaction between simulation environments and for simulation tools that handle multi-domain problems. The Modelica language is intended to be applicable to multiple modeling formalisms and engineering domains alike, thus enabling interoperability between models from different simulation systems.

THE MODELICA LANGUAGE In general-purpose programming languages and in some modeling languages, object-orientation has matured into a powerful concept that is widely accepted. It improves the developer’s productivity by supporting reuse and extensibility, and provides a high level of abstraction for the modeling of complex systems. Based on the excellent experience with the aforementioned object-oriented modeling languages it was decided to base the Modelica language1 on this principle. Among other notions found in the Modelica language – described in more detail in (Elmquist and Mattsson 1997) – Modelica offers the class concept, already present in most of its predecessor languages, as the central building block of modularization. There are powerful relationships between classes for the modeling of a complex systems and the system itself:

 

Inheritance allows the derivation of similar models from one or more base models. It makes it possible to extend existing models. Composition of a model from several component models makes it possible to decompose a model into smaller subcomponents and to describe the structure of large components in a way that perfectly reflects the structure of the real system.

Type parameterization will be one of the features of Modelica that is new within the field of object-oriented, equation based modeling languages. In combination with inheritance it has the potential to enhance the flexibility and reusability of models to a great extent. The expressive power of type parameters will have the largest impact for complex models that are beyond the scope of this paper, but the concepts and benefits will be demonstrated with simple case studies. Some of the basic building blocks of the models used in the following section will serve to give a brief introduction to Modelica’s syntax and semantics. The basic types that are used in the model are all predefined in the Modelica base library. An example for a type definition is the definition for density: type Density = Real( final Quantity="Density", final Unit ="kg/m3", Min=0.0);

Real is one of the predefined Modelica types. All instances of Density will have the unit kg=m3 , the final modifier 1 The Modelica language and models presented in this paper reflect the design state as of August 1997. Some features of the Modelica language are still not finally defined and further interesting features, such as support for partial differential equations, will be considered in the ongoing design effort.

declares this attribute for unalterable. Other predefined attributes of the basic type Real are Min and Max for the physically meaningful limits of a type, start to provide initial values, Magnitude to give a hint about adequate error tolerances to the solver and some more. This strong typing offers the possibility that tools can implement consistency checks for equations. Connectors In Modelica the interaction between submodels is described by connecting special classes, called connectors. The easiest way to promote compatibility between submodels is to define a standard set of connectors for an application domain which is used throughout all components. The basic connector types for the following examples are: connector FlowCut flow MassFlow m_dot; Density rho; Pressure p; end FlowCut;

model WaterTank=AbstractTank( redeclare Content = Water ); model Tanksys AbstractTank oilTank(redeclare Content = Oil); end Tanksys

The line beginning with virtual defines a type parameter with name Content whose value is constrained to the type BasicLiquid. In subclasses the type parameter can be redeclared to be any type that is compatible with the constraining type. In addition to constraining the type value, the value also serves as a default value for the type parameter, therefore eliminating the need to specify the type parameter when using the type. Used in conjunction with parameter propagation through the hierarchical levels of a complex system, this forms a useful and consistent mechanism to exchange submodels without changing existing validated models and without exploding the number of models in the model library (with classes only differing in the type parameter).

Descendants of FlowCut have to add one more variable for the energy content of a fluid, e. g. temperature or enthalpy Local Classes depending on the model assumptions. In the following examples all types which are not defined in this paper are type- Inner or local classes are an feature of Modelica which also set in slanted type. opens new possibilities of genericity in physical modeling. The usage of inner classes in modeling exploits the fact that connector MixtureFlowCut components and connectors of the surrounding class are visextends FlowCut; ible to the inner class. Therefore inner classes are suitable parameter Integer N; MolarParts conc[N] "concentration vector"; to either implement additional phenomena in a compound end MixtureFlowCut; model – e. g. model heat dissipation of a printed circuit board – or to model variations of model behaviour that can connector HeatCut be controlled through type parameters in higher levels of Temperature T1, T2; the model composition hierarchy. For an example of inner flow HeatFlux dQ; classes see the section “Submodel and Connector Parameend HeatCut; terization”. The connector for fluid flows with concentration information is an extension of the basic connector for flows. MolarParts is a type that implements avector of concentrations. THE SMILE LANGUAGE The extends keyword is the Modelica notion for inheri- The simulation language Smile is an extension of Objective tance. Semantically a connection between two connectors C, which itself is an object-oriented general-purpose promeans that members of a connection i. e. those having the gramming language based on C and Smalltalk. By adding corresponding name are connected to each other. Across means to express different types of equations, to define variables as voltages or pressure are connected to be equal connection interfaces, and to specify connections, Smile on both sides of a connection, but for quantities expressing becomes an equation-based object-oriented simulation lana flow like mass flow or current it is more in tune with en- guage. A further characteristic of the Smile language is the gineering practice to require them to be summed to zero at strict separation of model and experiment. Two of the difa connection point. The flow keyword in the connector en- ferences between Smile and Modelica have a large influence forces this rule. In Modelica the convention is that a flow on the model structuring process: into a component is counted as positive. 1. overwriting of equations in descendant classes is allowed in Smile, Type Parameters Type parameters are well known in general purpose programming languages like Ada83 or, in combination with inheritance, like C++ or Eiffel, but they are new to modeling languages. Type parameters are placeholders also defining restrictions for the actual type of a component which can be determined later. They offer considerable advantages in terms of model genericity. One particularly powerful application of type parameters is medium parameterization in process engineering. partial model AbstractTank virtual model Content = BasicLiquid; end AbstractTank;

2. Smile does not offer type parameters. More information on the Smile language can be found at the URL http://www.cs.tu-berlin.de/˜smile/ess97

THE STOVE MODEL IN MODELICA AND SMILE The evolution of Modelica was guided by the experience from various object oriented Modeling languages. We use the Smile language to demonstrate the structural changes in

models between Modelica and other object-oriented mod- partial model LiquidEmbeddedHeatStore extends EmbeddedHeatStore; eling languages. Modelica is more concise than Smile, so MassFlow dm = 0.0; we will present the model as Modelica code and explain the virtual model SomeLiquid = BasicLiquid; differences where appropriate. The basic physical phenomSomeLiquid liquid; ena are heat storage and heat transfer, which are modeled Boolean boiling = false; in the classes HeatStore, EmbeddedHeatStore and further equation descendants: model HeatStore Mass m; HeatCapacity cp; HeatFlux dQ = 0.0,source = 0.0; Temperature T=300.0; end HeatStore;

liquid.cp = cp; liquiq.T = T; boiling = (T > liquid.bp); der(m) = if boiling then - dQ/liquid.r else 0.0; der(T) = if boiling then 0.0 else dQ / (m*cp); end LiquidEmbeddedHeatStore;

A difference in the Smile-version of the stove is, that the equation for heat storage: dQ=mcp is already defined in the class HeatStore, because it can be overwritten in the descendant class LiquidEmbeddedHeatStore. This also means The medium dependent components of the liquid heat store that in Smile the class SolidEmbeddedHeatStore is not nec- are encapsulated in the medium submodel BasicLiquid. As BasicLiquid is an incomplete model that serves as a paressary. ent class for different liquids, it is called partial model. model EmbeddedHeatStore Two descendants of BasicLiquid with proper values for the extends HeatStore; parameters and a functional relation between heat capacity HeatCut top(T1=293.0), bottom(T1=293.0); and temperature cp cp T are Water and OliveOil. In parameter Area atop, abottom; general purpose programming languages classes which can parameter HTCoefficient htc_top, htc_bot; not be instantiated are called abstract classes. LiquidEmHeatConduction hc_top, hc_bottom; beddedHeatStore is such an abstract class, but after substiequation tution of a complete liquid model for the type parameter 0 = -dQ + source - top.dQ - bottom.dQ; BasicLiquid it turns into an instantiable class.

= ( )

hc_bottom = abottom * htc_bot; hc_top = atop * htc_top; top.dQ = hc_top *(top.T2 - top.T1); bottom.T1 = T; top.T1 = T; end EmbeddedHeatStore;

model SolidEmbeddedHeatStore extends EmbeddedHeatStore( redeclare parameter HeatCapacity cp, redeclare parameter Mass m); equation der(T) = dQ / (m*cp); end SolidEmbeddedHeatStore;

partial model Pan extends SolidEmbeddedHeatStore( redeclare parameter HeatFlux source=0.0, m = 0.7, cp = 450.0); HeatCut environment(T2 = 300.0) virtual model SomeLiquid = BasicLiquid; LiquidEmbeddedHeatStore content( redeclare model SomeLiquid = SomeLiquid); equation connect(content.bottom,top); connect(content.top,environment); end Pan;

The pan model illustrates, how type parameters offer more powerful concepts of genericity for modeling than inheritance alone. Within the model of the pan it is possible to leave the type of liquid in the pan undetermined. This can be achieved later, on instantiation of the pan model. Because BasicLiquid is an abstract class, there will be an error if no complete model is substituted in its place. The different specializations of the pans in Smile have to be modeled as subclasses of the generic pan through inheritance(see 2), Medium Parameterization whereas in Modelica they can be generated “on the fly” by The separation of medium specific model parts from equip- supplying the actual types water or oil to the type parameter ment dependent equations is a well known concept in Content(see 1). Type parameters are redeclared in a comobject-oriented modeling. It has been investigated thor- ponent modification. This means that it is not necessary to oughly by Nilsson in (Nilsson 1993). Type parameteri- derive a new class in order to substitute different behaviour zation adds a new dimension to this principle: with one as it is necessary in languages that only offer inheritance. type parameter describing a specific medium and propagation of this type parameter from the top level model down model Stove Pan pan1( through multiple hierarchical levels, all medium submodels redeclare model SomeLiquid = Water , in a complex system can be exchanged with a single statecontent(m = 2.0)); ment. For a solid body model, mass and – in this simple case – heat capacity, are not allowed to vary any more and are thus redeclared to be parameters. Smile does not distinguish between parameters and other variables in this way, the second reason why the class SolidEmbeddedHeatMedium is not needed in Smile.

partial model BasicLiquid parameter Temperature boilingpoint; parameter Density rho; HeatCapacity cp; parameter EvaporationEnthalpy r; end BasicLiquid;

Pan pan2( redeclare model SomeLiquid = OliveOil, content(m = 0.2)); Plates[2] myplates; equation connect(myplates[1].top,pan1.bottom); connect(myplates[2].top,pan2.bottom); end Stove;

SolidEmbeddedHeatStore

EmbeddedHeatStore

Pan

SUBMODEL AND CONNECTOR PARAMETERIZATION

Plate

Type parameterization can also be used to replace components or groups of components within a compound system. In the following the possibilities and limits of this use of type parameters are investigated for a small system consisting of a pump and two tanks. The goal is to have a reusable model that is valid for a simple one-component liquid and, after type substitution, for a mixture of N components. The simplest form of code reuse deals with a single component: The connector for flows in the base model for all machinery handling one-component flows is replaced by the extension of the original connector additionally containing the concentration vector. A pump is one of the many components within the models of a chemical plant, where concentrations are not changed and just propagated: inlet.conc[N] = outlet.conc[N]. This equation has to be added to the pump model, but it would be convenient to handle this via a type parameter globally for all models that have no influence on the concentration, like valves and branches. This goal can be achieved with Local Classes.

LiquidEmbeddedHeatStore HeatStore

Water Stove

BasicLiquid OliveOil Pan1(Content = Water) Pan2(Content = OliveOil)

is a relation

Plate[2] part of relation

Figure 1: Partial Inheritance Tree of the Modelica Model

For model structuring Smile offers comparable language partial model FlowDevice virtual connector AnyFlowCut=FlowCut; support as Modelica(see 2). The inheritance hierarchy and AnyFlowCut inlet, outlet; component composition is similar to a Modelica model, unmodel InertVars less when type parameterization is used. The effects of end InertVars; type substitution are analogous to overwriting component virtual model NoEffect=InertVars; classes in Smile, with the difference that subclassing cannot NoEffect join; be used to modify a component at the point of its declara- end FlowDevice; tion. The second difference is that inheritance by itself does not allow to hand down the type of a class into the composi- partial model MixFlowDevice extends FlowDevice; tion hierarchy. In a class it is always only possible to rederedeclare connector AnyFlowCut=MixFlowCut; clare the type of the components of the parent class, but it model InertMix is impossible to alter a component within its components. extends InertVars; Type parameterization offers more freedom and leads to equation connect(inlet.conc[N],outlet.conc[N]); less code bulk (no explicit subclasses are needed). Medium SmileObject

HeatStore

BasicLiquid

EmbeddedHeatStore

Pan

WaterPan

Plate

( common root model)

OliveOil

Water

LiquidEmbeddedHeatStore

OliveOilPan OilHeatStore WaterHeatStore

end InertMix; end MixFlowDevice;

Descendants of MixFlowDevice now have two options: if a piece of equipment does have no influence on the concentration, the type parameter NoEffect is redeclared to the type InertMix, otherwise the corresponding equations for chemical reactions have to be implemented. There are other possibilities for variables that are not affected by a model: e. g. adiabatic devices have no influence on the enthalpy. Therefore the possibility of uneffected variables is already present in the base class FlowDevice. The main characteristic of centrifugal pumps is the relationship between the pressure difference across inlet and outlet and the volumetric flow rate. A common way to define this relation is:


=
is p

1

k nrel

+2

2

_

k nrel Vrel

3_

j_ j

k Vrel Vrel ;

_

where p the pressure difference, Vrel the relative flowrate and nrel the relative rotational speed of the pump. The parameters k1 ; k2 and k3 permit to adapt the relation Figure 2: Partial Inheritance Tree of the Smile Model very closely to that of any given centrifugal pump. This equation and the necessary parameters are implemented in the model PumpEquations. Now it is easy to model difsubmodel parameterization in chemical engineering models ferent pumps using the same base model PumpEquations is a typical case where a medium submodel is needed in al- that handles single- and multi- component flows alike: most all components. Declaration of the medium model in model CentrifugalPump one central place and then propagating it through the whole extends FlowDevice; model hierarchy is a big advantage compared to multiplying PumpEquations pump; the code for use with different media. equation is a relation

part of relation

connect(pump.inlet, inlet); connect(pump.outlet, outlet); end CentrifugalPump; model MixCentrifugalPump extends MixFlowDevice; PumpEquations pump; redeclare model NoEffect=InertMix; equation connect(pump.inlet, inlet); connect(pump.outlet, outlet); end MixCentrifugalPump;

Valves for flows with multiple components can be built in a similar way. The technique of propagation of type parameters to change the behaviour of submodels is even more useful, when several submodels of the same type need to be replaced at the same time. model TankSystem virtual model SystemTank = BasicTank; SystemTank tank1, tank2; virtual model Pump = CentrifugalPump; Pump aPump; equation connect(tank1.outlet, aPump.inlet); connect(aPump.outlet,tank2.inlet); end TankSystem; model MixTankSystem =TankSystem( redeclare model SystemTank=MixTank, redeclare model Pump=MixCentrifugalPump);

There is still the need for one type parameter per component type that needs to be adapted to handle flows with several components. An important feature of the Modelica language is, that type compatibility is not necessarily based on inheritance, but on type equivalence, i. e. the existence of the same basic components in the substituted type. Different concepts of the relation between type equivalence and inheritance are explained in (Abadi and Cardelli 1996). MixCentrifugalPump does not inherit from CentrifugalPump, but after expansion it contains all components of CentrifugalPump plus some new ones, therefore it is type equivalent. The proposed inheritance hierarchy is useful, because many more components apart from the pump share the feature of leaving the chemical composition unchanged.

CONCLUSION AND OUTLOOK Inheritance in combination with type parameterization, type parameter propagation and local classes are powerful concepts which are new for object-oriented modeling languages. The benefits of their use compared to traditional object oriented models has been investigated by means of simple examples. The drawback of type parameters is the increased difficulty to validate models, as a model with type parameters can be instantiated with many combinations of actual types, all of which need to be validated. Up to now there is no experience in using type parameters in a graphical user interface. Type parameters may well alter the behavior of a model in a radical way, type parameter propagation may alter the behavior of all models within a system. Visual feedback to the user about such changes is important, but difficult to realize. It remains an interesting task for the future to integrate type parameters and parameter propagation into graphical user interfaces for modeling in an intuitive way.

References Abadi, M. and L. Cardelli (1996). A Theory of Objects. New York, Berlin: Springer. Breunese, A. P. and J. F. Broenink (1997, January). Modeling mechatronic systems using the sidops+ language. In J. J. Granda and G. Dauphion-Tauguy (Eds.), Proceedings of the 1997 Western Multiconference, Volume 29 of Simulation Series, pp. 301–306. Elmquist, H. and S.-E. Mattsson (1997). An introduction to the physical modeling language modelica. in this volume. Elmqvist, H. (1978). A Structured Model Language for Large Continuous Systems. Ph. D. thesis, Department of Automatic Control, Lund Institute of Technology, Sweden. Tech. Report Number: CODEN:LUFTD2/(TFRT-1015). Ernst, T., S. J¨ahnichen, M. Klose (1997). The architecture of the smile/m simulation environment. In A. Sydow (Ed.), Proceedings of the 15th IMACS world congress on Scientific Computation, Modelling and Applied Mathematics, Volume 6, Berlin, Germany. Wissenschaft und Technik Verlag. Fritzson, P., V. Engelson, and L. Viklund (1993). Variant handling, inheritance and composition in the ObjectMath computer algebra environment. In A. Miola (Ed.), Design and Implementation of Symbolic Computation Systems (DISCO), Volume 722 of LNCS, Gmunden, Austria, pp. 145–160. Springer-Verlag. Jeandel, A., P. Ravier, and A. Buhsing (1995). U.l.m.: Reference guide. Technical report, Gaz de France. Jochum, P. and M. Kloas (1994). The dynamic simulation environment Smile. In G. Tsatsaronis (Ed.), Second Biennial European Conference on System Design & Analysis, pp. 53–56. The American Society of Mechanical Engineers. Mattsson, S. E. and M. Andersson (1992). Omola — an object-oriented modelling language. In M. Jamshidi and C. J. Herget (Eds.), Recent Advances in Computer-Aided Control Systems Engineering, Studies in Automation and Control, pp. 291–310. Amsterdam: Elsevier Science Publishers. Nilsson, B. (1993). Object-Oriented Modeling of Chemical Processes. Ph. D. thesis, Department of Automatic Control, Lund Institute of Technology, Lund, Sweden. Piela, P. C., T. G. Epperly, K. M. Westerberg, and A. W. Westerberg (1991). ASCEND: An object-oriented computer environment for modeling and analysis: The modeling language. Computers & Chemical Engineering 15, 53–72. Sahlin, P., A. Bring, and E. Sowell (1994). The neutral model format for building simulation, version 3.0. Technical Report ITM Report 1994:4, Dept. of Biolding Services Engineering, Royal Institute of Technology, Stockholm, Stockholm, Sweden.