LUND UNIVERSITY

PO Box 117221 00 Lund+46 46-222 00 00

An XML Representation of DAE Systems Obtained from Modelica Models

Casella, Fracesco; Donida, Filippo; Åkesson, Johan

2009

Link to publication

Citation for published version (APA):Casella, F., Donida, F., & Åkesson, J. (2009). An XML Representation of DAE Systems Obtained from ModelicaModels. Paper presented at 7th International Modelica Conference, 2009, Como, Italy.

Total number of authors:3

General rightsUnless other specific re-use rights are stated the following general rights apply:Copyright and moral rights for the publications made accessible in the public portal are retained by the authorsand/or other copyright owners and it is a condition of accessing publications that users recognise and abide by thelegal requirements associated with these rights. • Users may download and print one copy of any publication from the public portal for the purpose of private studyor research. • You may not further distribute the material or use it for any profit-making activity or commercial gain • You may freely distribute the URL identifying the publication in the public portal

Read more about Creative commons licenses: https://creativecommons.org/licenses/Take down policyIf you believe that this document breaches copyright please contact us providing details, and we will removeaccess to the work immediately and investigate your claim.

An XML Representation of DAE SystemsObtained from Modelica Models

Francesco Casellaa Filippo Donidaa Johan Åkessonb,c

aDipartimento di Elettronica e Informazione, Politecnico di MilanoVia Ponzio 35/5, 20133 Milano, Italy

bDepartment of Automatic Control, Lund University, Lund, SwedencModelon AB, Sweden

Abstract

This contribution outlines an XML format for repre-sentation of flat Modelica models. The purpose is tooffer a standardized model exchange format which isbased on the DAE formalism and which is neutral withrespect to model usage. Many usages of models gobeyond what can be obtained from an execution inter-face offering evaluation of the model equations. Sev-eral such usages arise in the area of control engineer-ing, where Linear Fractional Transformations (LFTs),derivation of robotic controllers, optimization, and realtime code generation are some examples. The choiceof XML is motivated by its defacto standard statusand the availability of free and efficient tools. Also,the XSLT language enables specification of transfor-mation of the XML model representation into otherformats.

Keywords: DAE representation; XML standard;modeling

1 Introduction

The Modelica language allows to build complex mod-els of physical systems, described by differential-algebraic equations (DAE). These models can be usedfor different purposes: simulation, analysis, optimiza-tion, model transformation, control system synthesis,real-time applications and so forth. Each one of theseactivities involves a specific handling of the corre-sponding differential algebraic equations, by both nu-merical and symbolic algorithms. Moreover, special-ized software tools which implement these algorithmmay already exist, and only require the equations ofthe model to be input in a suitable way.

The goal of this paper is to define an XML-based representation of the DAEs of Modelica mod-els, which can then be easily transformed into the in-

put of such tools, e.g. by means of XSLT transfor-mations. On one hand, this representation must be asclose as possible to the mathematical equations, there-fore without any aggregation, inheritance, and com-plex data structures left. On the other hand, it mustbe as general as possible with respect to the possibleusage of the equations, which should not be limited tosimulation.

This representation could then be used as a standardinterface between the front-end of any Modelica com-piler, and any possible back-end for simulation, opti-mization, analysis, etc.

In addition, the XML representation could also bevery useful for treating other information concerningthe model, for example using an XML schema (DTDor XSD) for representing the simulation results, orthe parameter settings. In those cases, using a well-accepted standard will result in great benefits in termsof interoperability for a very wide spectrum of appli-cations.

The paper is structured as follows: in Section 2, theabstract structure of the DAE representation is infor-mally described, motivating the structure of the formalXML schema definition. Section 3 discusses some ofthe possible usages of such a representation. Section4 briefly describes test implementations in the Open-Modelica and JModelica.org compilers, while Section5 ends the paper with concluding remarks and futureperspectives.

2 Abstract representation of the DAEsystem

To the best of the authors’ knowledge, the optimumrepresentation for defining a DAE system should be asclose as possible to the mathematical definition. Pro-vided that a DAE system consists of a system of dif-

ferential algebraic equations, it can be expressed as:

f (x,x,y,u,v, t, p) = 0 (1)

where x is the derivative of state, x is the states, y arethe outputs, u are the inputs, v are the algebraic vari-ables, t is the time and p is the set of the parameters.

For the rest of this paper, we assume that the DAEs(1) describing the model have index 1. This restric-tion is necessary to give to the x variables the meaningof states, i.e., variables whose initial values can be ar-bitrarily selected. Most applications for DAE models(and all the applications discussed in this paper) re-quire an index-1 DAE as input, so it is reasonable todiscuss a representation limited to this class of equa-tions. In case the equations of the original Modelicamodel have higher index, such DAEs can be obtainedby symbolic index reduction, which is an available fea-ture in most Modelica tools, so this is not a drastic lim-itation to the range of applicable models. In this case,however, we must assume that the index reduction pro-cedure gives a fixed selection of states.

Even though the representation provided in equation1 is very general, and is very appreciable for viewingthe problem as one could see it written on paper, itcannot be directly used for inter-tools exchange in anefficient way.

The main idea is then to provide a standardizedmathematical representation of the DAE system thatrelies on standard technology and is application-oriented. This justifies the adoption of the XML stan-dard as the base framework. It can be noted that whileXML is generally not suited for manual inspection, anXSLT transformation translating an XML descriptioninto, e.g., a flat Modelica representation is easily de-fined.

As an additional requirement, we must consider thatthe DAE systems we are dealing with are derived fromthe Modelica models. Even if this can be seen as arestriction, this is not, since the Modelica languagespecification interprets a superset of the problems thatare object of this paper, providing a textual definitionto describe the physical systems, concerning also thevariables types and the expressions operators defini-tions.

Previous efforts have been registered to define stan-dard XML-based representations of Modelica mod-els, including [14, 15]. A standard representation ofprocess engineering models is described in [2] and astandard for Modelica-derived simulation models ispresented in [11]. In addition, a standard represen-tation for API implementation for Modelica is given

in [16], and standard representation for simulation li-braries [9]. A recent initiative is the Functional ModelInterface (FMI)1, [6], which is aimed at creating astandard for a Modelica execution API.

The aim of this work is to take advantage from allthis studies and try to define a simple and general rep-resentation which is not tailored for a particular us-age, but rather aims at covering the largest possibleproblems that can be formulated starting from a Mod-elica model. Particular care has been exercised in or-der to define concepts and structures which are generalenough to be usable in different contexts.

In the remainder of this section, the different partsof the proposed XML representation will be described.

2.1 Variables

The Variables entity corresponds to the set ofscalar variables (real, integer, boolean) that are presentin the equations of the DAE. In particular, taking intoaccount the continuous-time representation (1), fivetypes of variables are needed:

∙ Time-invariant, i.e., the constants and the param-eters.

∙ Input variables, conceptually given from the out-side.

∙ Algebraic variables corresponding to algebraicequations in the matching algorithm. This cat-egory also includes dummy derivatives obtainedafter index reduction. This set of variables couldalso be identified as the set of the time-variantvariables not contained in the set of states or in-puts.

∙ State variables.

∙ Derivatives of state variables.

As one could easily imagine, some constraints arepresent on the variables set. Firstly, a one-to-one re-lationship is defined between the set of the state vari-ables and the set of derivatives. Secondly, the outputsare a subset of the state and algebraic variables, in thesense that the state and algebraic variables might alsobe marked as output variables, i.e., have an output at-tribute.

Associated with a variable is also a set of attributes,corresponding to the attributes specified by the Model-ica language. These include the start attribute, min and

1The work on FMI is done within the ITEA2 project MOD-ELISAR.

max, unit, nominal etc. These attributes are essentialto include in a model specification format since theyprovide information about, for example, start values ofvariables, model validity regions and unit information.

Note that string parameters could also be consid-ered, with constant binding to constant literal strings.The string binding equations will not be considered inthe equation sets, because are irrelevant from a mathe-matical point of view.

2.2 Expressions

Expressions represent all the mathematical ex-pression of the system and can be formed by aggre-gating identifiers and literals through:

∙ Unary operators. This class contains all the math-ematical functions that require only one argumentas input. Possible examples are the trigonomet-ric functions (sin, cos, tan, asin, acos,atan), the hyperbolic functions (sinh, cosh,tanh), the exponential functions (exp), the log-arithmic functions (log, log10), and the squareroot function (sqrt).

∙ Binary operators. This set contains all the alge-braic operators like +, *, -, /, the factor functionˆ, and the atan2 function.

∙ Function calls referring to user-defined functions.

XML encoding of expressions is straightforwardby introducing elements corresponding to an abstractgrammar specification used in a compiler. This ap-proach renders the DAE XML representation format toprovide abstract syntax trees (ASTs) for expressions,which simplifies the development of XSLT transfor-mations. Also, translating this representation intoother formats for representing mathematical expres-sions, e.g., MathML, [5], would be trivial.

2.3 Functions

A Function is conceptually equivalent to an algo-rithm, i.e. a part of a procedural code and, in this sensehas:

∙ Input variables (possibly with default values)

∙ Output variables

∙ Protected variables (i.e. variables visible onlywithin the function)

∙ An algorithm to compute outputs from inputs,possibly using protected variables.

The DAE representation contains only scalar vari-ables. If any vector or array variable is presentwithin the original object oriented model, it is flat-tened to their fundamental scalar elements by the com-piler before producing the XML. This is also the casefor the other data structures (e.g. records) and forthe functions. In particular, functions returning vec-tors or records are split into separate scalar func-tions, each one corresponding to the computation ofa single scalar element of the outputs. For example,(x,y)=f(u,v) is converted to the scalar equations:

1 x1 = f1(u1,u2,v1,v2)

2 x2 = f2(u1,u2,v1,v2)

3 y1 = f3(u1,u2,v1,v2)

4 y2 = f4(u1,u2,v1,v2)

where each function fj() is defined in Modelica asthe original function f(), save that all outputs exceptthe j-th are declared as protected variables instead ofoutputs. The fj() functions should retain a refer-ence to the original function f(), allowing an effi-cient computation scheme, where required. As an ex-ample, a simulation applications might cache the re-sults of calling f(u,v) when encountering the firstcall to any fj(u,v), and then use this to get the re-sults of the other scalar functions calls with the samearguments, without re-executing the algorithm.

If the compiler performs function in-lining beforegenerating the XML representation, the correspondingfunction calls disappear from the model; on the otherhand, sophisticated in-lining of non-trivial functionscould be performed by a post-processing tool, whoseinput is the XML code. The subject of in-lining is thuscompletely transparent and orthogonal to the DAE rep-resentation discussed here.

The algorithm in a function is formulated by an im-perative language equivalent to Modelica algorithms,expressed as an XML translation of the correspondingabstract syntax tree.

The abstract syntax tree representation for func-tions is conceptually a superset of the Expressionentity defined in subsection 2.2. More pre-cisely, it is necessary to add three main classesof entities. Firstly, the program flow constructs(such as the if-then-else, the for-loop, thewhile-loop and others) are necessary. Secondly,there are some Modelica-specific constructs, e.g.,

sample() and initial(). Finally, the basic op-erators provided by a majority of programming lan-guages, i.e., the boolean relation operators including<, <=, ==, <>, > and >=, and finally type conversionprimitives such as floor and edge.

Again, XML elements are conveniently introducedto represent functions and related quantities. The ad-vantages of having such kind of abstract representa-tion are evident, for example, it can be easily convertedto any imperative programming language (C, Matlab,Mathematica, Maxima, Maple, Scilab, Python, Java,etc) by means of XSLT transformations.

2.4 Equations

In many cases, a Modelica model includes parametersdepending on other parameters. For simulation, it isnecessary to solve the corresponding equations numer-ically at initialization. The numerical values can thenbe used for dynamic simulation. For other purposes,it may be necessary to keep some of these relation-ships in the model. For instance, in optimization prob-lems there may be a free parameter p1 and anotherparameter p2 = f(p1). In this case, the parameterp2 cannot be computed before the optimization pro-cedure starts, but rather, the relationship needs to beincluded amongst the constraints in the optimization.When building LFT representations, p1 might be anuncertain parameter, while f() might be well known;in this case, one wants to keep the dependency of p2from p1 in the dynamic model.

When dealing with simulation problems, equationsfor parameters are conceptually part of the initializa-tion section. However, they may play a special role innon-simulation problems, in particular when they allhave fixed = true. In the case of LFT transformationsthere are no initial equations, but it is still necessary toconsider the relationships between uncertain parame-ters and all other parameters when formulating the un-certain dynamic equations.

In fact, there is a whole class of problems for whichthe initial equations are irrelevant. As a first example,consider the LFT representation of an uncertain dy-namical system. This system only involve the dynamicequations, and the initial values of the states are notrequired for the transformation. Also, when dealingwith the derivation of inverse kinematics, computedtorque and inverse dynamics in robot models, the re-sulting problems are purely algebraic: there are no ini-tial equations involved once the appropriate BLT hasbeen performed and the irrelevant parts of the modelhave been discarded.

However, there are still many problems where thevalues of initial states are an essential part of the prob-lem. The initial variable values are generally notknown, but need to be solved from the initial equa-tions. There are also problems where additional initialequations are required to determine the values of someparameters (set with fixed=false). An additional exam-ple is given by the so-called trimming problems, wherethe values of the inputs are determined by prescribingcertain steady values for the outputs.

Therefore, three separate sets of equations need bedefined:

1. Dynamic equations. This set is composed ofequations specified in equation sections and bind-ing equations for variables. These equations arematched to algebraic variables (algebraic equa-tions) and to state derivatives (differential equa-tions). Each equation is given in residual form<expression> = 0.

2. Binding equations for parameters withfixed=true. These equations are matched tofixed=true parameters. The equations are in theform <parameter> = <expression>, and can besolved through assignments. The latter statementfollows since it is illegal to define models withcyclic dependencies between parameters inModelica.

3. Initial equations. This set is composed of equa-tion given in initial equation sections and bindingexpressions for variables with fixed=true. Theseequations are matched to state variables, param-eters with fixed=false, and possibly to inputs, ifthere are any (see example below). The initialequations should be in the form expression = 0.

model Minput Real u;output Real y;Real x;

equationder(x) = -x + u;y = 4*x;

initial equationder(x) = 0; // Implies x(0) = u(0)y = 4; // This equation determines

// x(0) = 1, and therefore// u(0) = 1;

end M;

Depending on the application, these three sets canbe used in different ways, as will be discussed in Sec-tion 3.

2.5 Additional information

As introduced above, the range of applications thatcould directly use as input an XML DAE represen-tation or any ad hoc description (derived from themore general one through XSLT transformation) is ex-tremely variegated [3]. The common aspect is thatthe majority of tools for these usages require an in-dex 1 DAE, as described in this section. Other in-formation could be available from the Modelica tool,which could be relevant for some applications. Forinstance, information about the BLT structure of thedynamic simulation problem (compute the derivativesand algebraic variables, given the inputs, states, pa-rameters, and time) could also be included, as well asinformation about the index reduction process in casethe DAEs are the result of some index reduction algo-rithm such as [12]. This is however beyond the scopeof the present paper.

3 Application examples

3.1 Simulation

The simulation tools are generally following the sameapproach. Firstly, the parameters and constants withineach equation are numerically evaluated, by solvingall the three equation sections together to determinethe initial values of everything. After that, the numer-ical values of parameters are fixed, and the dynamicequations are used to compute derivatives and alge-braic variables at each time step in an integration algo-rithm. This is also the case when considering the par-allel simulation problem. Functions are the “linked”as external functions if any function calls is presentfor the state derivative computation.

3.2 LFT Transformation

LFT is a widely used model description formalismin modern control and system identification theory,in which uncertain parameters and non-linearities are“pulled out” from the system, resulting in the feedbackconnection between a linear, time-invariant modeland blocks representing the uncertain and/or nonlin-ear parts. The procedure for obtaining an LFT repre-sentation from Modelica models is fully described in[4] and is only briefly summarized here. Assuming anODE system, the values of the parameters are givenby the binding equations, which specify the value ofeach parameter either by a numerical value, or as afunction of other parameters. At each time instant,

the values of states and inputs are known; the numeri-cal values of the parameters are not known explicitly,but they can be considered as known, given the bind-ing equations. The goal is now to compute the statederivatives x and the algebraic variables v. To thisend, the equations and the variables of the problem canbe re-ordered so that the incidence matrix (equationson the rows, unknowns on the columns) is brought inBlock-Lower-Triangular (BLT) form. This task is ac-complished by using the well-known Tarjan algorithm[7], applied to the equations-variables bipartite graph,which is equivalent to the incidence matrix of the sys-tem. The strongly connected components of the graphcorrespond to the blocks on the diagonal, and a par-tial ordering among equations can be deduced fromthe graph after the algorithm has terminated. After re-ordering, the system can be formulated as

Φ(x,u,Ξ, p0) = 0, (2)

where Φ(⋅) is the set of re-ordered equation residualsand Ξ is the re-ordered set of the system unknowns(i.e., all the elements of vectors x and v). By definingΦ j(⋅) as the j-th sub-set of equations corresponding toone block of the BLT form, Ξ j as the correspondingsub-set of unknown variables, and q as the number ofblocks on the diagonal of the BLT incidence matrix,the re-ordered system equations (2) can be formulatedas

Φ1(x,u,Ξ1, p0) = 0 (3)

Φ2(x,u,Ξ1,Ξ2, p0) = 0 (4)

... (5)

Φq(x,u,Ξ1, ...,Ξq−1,Ξq, p0) = 0. (6)

The system expressed in the form (3)-(6) can be exe-cuted within a suitable environment, which supportsthe symbolic manipulation of LFTs. Summing up,in the case of LFTs, the binding equations for pa-rameters are solved by keeping the uncertain parame-ters as symbolic objects, and the resulting expressionsare symbolically substituted in the dynamic equations;then, the relationship between the states and the inputson one hand and the derivatives and the outputs on theother hand, is transformed into an LFT.

3.3 Derivation of robotic controllers

The design of controllers for robotic systems with Ndegrees of freedom usually starts with the equations of

motion obtained from the Euler-Lagrange equations:

B(q)q+H(q, q)q+E(q) = τ (7)

yp = K(q) (8)

yv =∂K∂q

q, (9)

where q is the N-element vector of Lagrangian coordi-nates, which usually correspond to the rotation anglesof the actuator motors, q is the vector of the corre-sponding generalized velocities, yp is the vector of theCartesian positions of selected points of the robot, τ

is the vector of generalized applied forces correspond-ing to each degree of freedom (the torques applied bythe actuators), B(q) is the inertia matrix, H(q, q) is thematrix corresponding to the centripetal, Coriolis, andviscous friction forces, E(q) accounts for the effectsof the gravitational field.

The classical approach to write (7) requires to com-pute the so-called direct kinematics, i.e. how the val-ues of q and q translate into the position and motion ofthe robot’s links, then to compute the Lagrange func-tion, i.e. the difference between kinetic and potentialenergy, and apply the Euler-Lagrange equations. Thiscan be done manually, or using one of the specializedtools available for this task.

With an object-oriented approach the original modelis usually an index-3 DAE. This model is then broughtinto index-1 form

F(x, x,y,u) = 0 (10)

where

x =[

xp

xv

]=

[qq

], y =

[yp

yv

], u = τ, (11)

by means of connection tree analysis, change of statevariables, and index reduction algorithms; this modelis mathematically equivalent to the Lagrange model(7)-(9). Currently available Modelica tools solve thesimulation problem by producing an efficient proce-dure to solve it for x and y given x and u. This pro-cedure effectively brings the system into state-spaceform, which can then be linked to any ODE/DAEsolver. In fact, there are other things that can be donewith the model (10), which are very useful for the de-sign of control system.

Robot trajectories are originally defined in Carte-sian space as functions of time y0

p(t). Obtaining thecorresponding reference trajectories in Lagrangian co-ordinates for the low-level robot joint controllers re-quires solving the problem to obtain the the so-called

inverse kinematics:

q0(t) = K−1(yp) (12)

q0(t) =(

∂K∂q

)−1

yv; (13)

the Jacobian of K(q) is also needed to numerically in-vert (8). Furthermore, two interesting approaches tomodel-based robot control are based on the direct useof (7): the pre-computed torque approach and the in-verse dynamics approach.

The pre-computed torque approach is a feed-forward compensation scheme, which requires tosolve (7) backwards, i.e. compute the (theoretical)torque required to follow the reference trajectory:

τ = B(q0)q0 +H(q0, q0)q0 +E(q0), (14)

and then feed it directly to the actuators; some decen-tralized feedback action is also included to deal withuncertainties and disturbance.

The inverse dynamics approach is a feedback com-pensation scheme, that uses the model in order totransform the non-linear control problem into a linearproblem with constant coefficients. Using this method,a virtual input variable v is defined which satisfies

τ = B(q0)v+H(q, q)q+E(q). (15)

Since the inertia matrix B is assumed to be structurallynon-singular, it is always possible to solve (15) forv(t), given the generalized velocities q(t) and q(t), thatare sensor outputs. Using this virtual input, the robotdynamics (7) can then be formulated as a set of doubleintegrators:

q = v (16)

For the robotic applications, the parameter bindingequations are solved numerically; their numerical val-ues are then substituted into the dynamic equations.Depending on the specific robotic problem: directkinematic, inverse kinematic, pre-computed torques orinverse dynamics approach, these equations (or a partof these) are then solved.

3.4 Optimization

The needs for solving optimization problems based onModelica models usually goes beyond what is typi-cally offered by a simulation oriented execution API,see [1]. In some cases, the initial conditions are freevariables in the optimization, which implies that theinitial equations must be explicitly available. Thesame situation holds for dependent parameters since

such a parameter may be dependent on another pa-rameter which is free in the optimization. In addition,quantities derived from the model equations such asfirst and second order derivatives and sparsity patternsmay be required by numerical algorithms.

The availability of a standardized XML-basedmodel exchange format is useful in an optimizationcontext since it enables transformation of a model intovarious formats suitable for different algorithms. Also,having access to expression syntax trees is useful forderiving derivatives, e.g., by means of automatic dif-ferentiation. It is worth noticing, however, that in orderto completely specify an optimization problem, quan-tities such as cost function and constraints must also betaken into account. This is not part of the specificationproposed in this paper. For a discussion on representa-tion of optimization problems derived from Modelicamodels and Optimica specifications, see [10].

3.5 Real time code generation

Real time code could be directly generated by in-liningthe discretization method within the equations of theXML file (e.g., forward or backward Euler), thus ob-taining the core of the real time code. This could alsobe directly obtained from the XML formulation of theDAEs through the usage of an XSLT transformationif no symbolic manipulation is required. The simu-lation problem is then formulated by solving the dy-namic equations for the next states and for the alge-braic variables and then bringing it into BLT form.

If all the equations in the BLT form are linear, orcan at least be solved explicitly in symbolic form, thenit is straightforward to generate simulation code withfixed execution time. Otherwise, if there are implicitnonlinear equations, iterative solvers will be neededand there might be convergence problem that requireproper handling.

4 Test implementations

There are two prototype implementations available.The implementation of the XML module within theOpenModelica compiler started the past year and isnow included in the latest release of the compiler. Thisfunctionality allows dumping of a flattened Modelicamodel after performing the index reduction (if neces-sary), the BLT transformation and the matching algo-rithm. The API method provided by the OpenMod-elica compiler offers the possibility to specify severalinputs parameters, such as if to add or not the informa-

tion for solving the system, and if to dump the equa-tions as residuals or add MathML representation for allthe equations. This XML schema is available at [8].

The JModelica.org platform currently supports gen-eration of variable meta data, as described in Sec-tion 2.1, in XML format, see [13, 10]. It is intendedthat this functionality is extended to include also equa-tions an functions as well as cost functions and con-straints for optimization.

As for the actual specification of a DAE XMLschema, the objective is to build on what is done inthe FMI initiative concerning model meta data and tomerge this with the existing schema [8].

5 Conclusions and future perspec-tives

In this paper, we have outlined an XML represen-tation of DAEs. This will allow easy coupling ofModelica compiler front-ends with diverse applica-tion back-ends that require the system equations asinputs. This format is not limited to Modelica mod-els, but could be used as a lingua franca to repre-sent continuous-time dynamical systems originally de-scribed with other modelling languages, such as, e.g.,gPROMS or VHDL-AMS. This would allow devel-opers of application back-ends (e.g. for optimal con-troller generation) to support multiple modelling plat-form easily.

The proposed format does not support all featuresof Modelica. Notably, description of hybrid constructsare lacking. However, there is a number of interestingapplications where this is not needed, as demonstratedby the examples outlined in this paper.

The XML description format outlined in this pa-per might be extended in several respects. First ofall, support for discontinuous expressions (e.g. if-expressions) could be added, possibly by including anexplicit representation of the root functions that manytools need in order to handle discontinuities properly.In order to support hybrid models, it would also benecessary to introduce the concepts of discrete vari-ables, discrete equations (those within when state-ments), time events and state events. Another exten-sion might be to support variables declared as vectorsand array equations, without reducing all equations totheir scalar form; this might be useful for sophisticatedsymbolic processing at the vector level. Support ofindex-1 models with dynamic sets of states (such asthose resulting from the dummy derivative algorithm[12] in some cases) might be added, as well as support

for the description of higher index models. Finally,it would be interesting to investigate how this kind offormalism could be employed to describe sub-modelsthat could then be aggregated at a higher level, by in-troducing some kind of connector concept; this mightallow some form of separate compilation strategy, atleast for a certain class of problems that do not lead tohigher index DAEs when connecting the submodels.

References

[1] Johan Åkesson. Optimica—an extension of mod-elica supporting dynamic optimization. In In 6thInternational Modelica Conference 2008. Mod-elica Association, March 2008.

[2] Christian H. Bischof, H. Martin Bücker, Wolf-gang Marquardt, Monika Petera, and Jutta Wyes.Transforming equation-based models in processengineering. In H. M. Bücker, G. Corliss, P. Hov-land, U. Naumann, and B. Norris, editors, Au-tomatic Differentiation: Applications, Theory,and Implementations, Lecture Notes in Compu-tational Science and Engineering, pages 189–198. Springer, 2005.

[3] F. Casella, F. Donida, and M. Lovera. Beyondsimulation: Computer aided control system de-sign using equation-based object oriented mod-elling for the next decade. In 2nd InternationalWorkshop on Equation-Based Object-OrientedLanguages and Tools, July, 8 2008.

[4] F. Casella, F. Donida, and M. Lovera. Automaticgeneration of lfts from object-oriented non-linearmodels with uncertain parameters. In 6th ViennaInternational Conference on Mathematical Mod-eling, February, 11-13 2009.

[5] D. Suliman D. Draheim, W. Neun. Searching andclassifing equations on the web, zib report 04-22. Technical report, Konrad-Zuse-Zentrum fürInformationstechnik, Berlin, 2004.

[6] DLR, Dynasim, ITI and QTronic. The functionalmodel interface. Draft.

[7] I. S. Duff and J. K. Reid. An implementation ofTarjan’s algorithm for the block triangularizationof a matrix. ACM Transactions on MathematicalSoftware, 4(2):137–147, 1978.

[8] Filippo Donida. DAE XSD schema, 2009.http://home.dei.polimi.it/

donida/Projects/AutoEdit/Images/DAE.xsd.

[9] P. A. Fishwick. Using xml for simulation model-ing. In Winter simulation conference, December,8-11 2002.

[10] J. Åkesson, T. Bergdahl, M. Gäfvert, andH. Tummescheit. The JModelica.org OpenSource Platform. In 7th International ModelicaConference 2009. Modelica Association, 2009.

[11] J. Larsson. A framework for simultion-independent simulation models. Simulation,82(9):563–379, 2006.

[12] S. E. Mattsson and G. Söderlind. Index reductionin differential-algebraic equations using dummyderivatives. SIAM Journal on Scientific Comput-ing, 14(3):677–692, 1993.

[13] Modelon AB. JModelica Home Page, 2009.http://www.jmodelica.org.

[14] A. Pop and P. Fritzson. Modelicaxml: A model-ica xml representation with applications. In 3rdModelica conference, November, 3-4 2003.

[15] U. Reisenbichler, H. Kapeller, A. Haumer,C. Kral, F. Pirker, and G. Pascoli. If we only hadused xml... In 5th Modelica conference, Septem-ber, 4-5 2006.

[16] M. Tiller. Implementation of a generic data re-trieval api for modelica. In 4th Modelica confer-ence, March, 7-8 2005.