MODELITH: A FRAMEWORK ENABLING
TOOL-INDEPENDENT MODELLING AND SIMULATION
Jonas Larsson
Björn Johansson
Petter Krus
Magnus Sethson
Mechanical Engineering Systems
Department of Mechanical Engineering
Linköping University, Sweden
E-mail: jonla@ikp.liu.se
KEYWORDS
Differential-algebraic equations, Modelica, numerical
solvers, code generators, object-oriented modelling
ABSTRACT
Several approaches exist for modelling of physical systems,
often implemented in a modelling language. Due to
differences in modelling approaches, it is a complicated
procedure to interchange information between different
modelling languages, documents or applications. This puts
a constraint on what the users can do in terms of custom
simulators and on what simulation tools they can combine.
In order to overcome this situation, a framework named
Modelith is presented in this paper that defines the
translation procedure from modelling language to
executable model in a number of steps. This enables the
user to move from a tool-centric to a model-centric view
where the models are independent of the simulation tools.
An implementation of the framework is presented using
XML-based technologies for information management. As
an example, it is shown how this implementation can be
used to translate a subset of the modelling language
Modelica into components for the simulation tool Hopsan.
INTRODUCTION
Today, mature languages exist for declaring simulation
models of physical systems within the technical, biological
and chemical domains. Some of these languages are
Modelica (Elmqvist et al. 1999), Ascend (Piela et al. 1991)
and VHDL-AMS (IEEE 1999). Support for them is given
by a number of tools for model creation, editing and
numerical simulation.
The languages have become increasingly powerful with
support for non-causal models, object-oriented concepts
like inheritance and with possibilities to describe both
continuous and discrete phenomena. The increasing flora of
languages and desires to interchange information between
them might lead to drawbacks in the future engineering
process. Also the developers of the engineering tools can
not possibly oversee and maintain language translators for
every possible combination needed. As a result, since most
users do not have the knowledge nor resources for creating
necessary translators, the tool providers dictate what can be
done with models written in a certain language.
Proceedings 14th European Simulation Symposium
A. Verbraeck, W. Krug, eds. (c) SCS Europe BVBA, 2002
If it was easier to transform models into and out from a
certain language, the following advantages would be
reached.
• The possibility to edit models using different levels of
abstraction using custom editors.
• To present models in several ways. Some are suitable
for experts and others for novice users.
• Models can be translated into programming languages
such as C and Java. This gives the possibility e.g. to
create code suitable for embedded systems and to
create stand-alone simulators.
• Since models can be translated into virtually any
desired implementation language, they become
portable. The portability is necessary, since engineering
work is becoming more of a co-operative task. They
need to be easy to adopt to new engineering tools.
• Models will get easier to maintain for future use, even
if a certain tool disappears from the market. The
models thereby become future proof.
With a proposed intermediate format the authors trie to
solve some of these problems, both in terms of flexibility
for future use, easy translator generation and fulfilment of
the modelling and simulation requirements. The XMLstandard has many of these properties and is also the focus
of this paper.
The ideas are presented as a framework together with an
implementation.
RELATED WORK
A similar approach exists, called DS-Block (Otter and
Elmqvist 1995), which is a low-level description of models
that can contain both implicit and explicit models. The
difference between DS-Block and the proposed framework
is that the DS-block model description is intended mainly as
a general format to be accessed by numerical solvers, and
not for generation of other model representations.
Modelling and simulation of the human body using XML as
model carrier is done in (Ward et al. 2001) and in the
CellML language specified by the Bioengineering Institute
at the University of Auckland. Also concepts for modelling
of chemical processes using XML are under progress; see
(Murray-Rust et al. 2001).
•
THE FRAMEWORK
Two steps with clearly defined interfaces can describe the
transformation from a declarative modelling language into
an executable model:
1. Flattening of model into equations, variables etc. and
removing the hierarchy in the modelling description
2. Implementation of the equations into a computer
language.
An intermediate model language is defined, as shown in
Figure 1. Four types of transformers can be made; the two
mentioned
above
for
flattening
and
conversion/implementation of equations and two for
translating languages into and from the intermediate
language. This makes it possible to combine “transformers”
from different vendors into a chain of language
transformers that builds up a language transformation.
...
Modelica
Intermediate lang.
Transformer
...
VHDL-AMS
Transformer
Object-oriented implicit
Transformer
Flattened implicit
Flattened explicit
Transformer
Transformers
Standalone
application
..
Java
. . Matlab/Simulink
S-function
Figure 1. The Framework Consisting of an Intermediate
Language and a Number of Transformers
The later operations are easier to implement than the earlier
ones in the chain. To parse a language is not an easy task,
even if there are tools providing support for that. Often this
part requires symbolic math operations. To generate target
language implementation is an easier task, especially when
using XML as intermediate format. This is also the most
interesting operation for the end user of the implemented
framework.
GENERAL CONSIDERATIONS FOR THE
INTERMEDIATE LANGUAGE
A number of requirements can be put on the intermediate
language. These have all been considered in the paper.
• It should be straightforward to transform from and
into it.
• The most important features of modern modelling
languages should be supported, such as Modelica,
but not to such extent that the translation process
becomes overly complex.
• It must be easy to validate syntax and relations.
• It should be expressive enough for the purpose of
using it as a model repository.
The language should be be extendible so that the
implementation suggested e.g. in this paper can be
altered without too much work and with backward
compatibility.
TECHNOLOGIES USED FOR THE
IMPLEMENTATION
The authors chose XML, a standard recommended by the
World Wide Web Consortium (W3C), as a base for the
intermediate language. XML is a standard for representing
relational data, and brings text documents to a higher level
by introducing a hierarchy where each level contains an
identifier, tag, and some text data. XML is originally
designed for exchange of data over the Internet, why many
possibilities to transform XML data are available. It is a
mark-up language very much like HTML. It is lightweight
in comparison with e.g. STEP (ISO 10303) and it supports
the definition of schemas (expresses the data model) for
validation of the produced documents. There exist a large
variety of open-source and license-free tools for performing
various operations on XML documents and the support for
XML will be long lasting due to its fundamental nature.
This language supports, by itself, most of the demands
mentioned above for the intermediate language. To
illustrate the most fundamental concept to “mark up” data
using XML, the example below shows some XML data.
Two elements are there, “Modelith” and “model”, where
model is contained in Modelith. The model element has an
attribute with the name “name” and value “Spring”. This
vocabulary is used later in the paper.
<Modelith>
<model name=”Spring”/>
</Modelith>
Figure 2. XML Document Sample
XSLT, a standard recommended by W3C, is a technology
for transforming XML documents into any text format. It
does not demand much knowledge in programming but
focuses on the transformation operation itself. The authors
have made use of XSLT to a large extent in the transformers
described earlier. In the flattening and export transformers,
XSLT is the only tool needed. These transformers are
therefore especially easy to adopt and create for new
purposes.
The operation of converting the equations into calculations
is performed using a programming language; in this case
Java for portability and for the close relation between Java
and XML. A symbolic math package is also needed to
extend the capabilities of Java. We have used one of the
freely available ones, made by Thorsten Pawletta at the
University of Wismar, Germany. The Java program was
implemented with functions for accessing XML documents
through the Document Object Model, DOM, a standard
recommended by W3C. DOM is an application
programming interface that is used to access XML
documents from a programming language and navigate
through the document in order to perform operations on the
structure or content of the data. Further was Xpath used, a
standard also recommended by W3C, a query language for
XML. Xpath was used to specify where to fetch data from
the XML document and where to place new information.
The DOM API Xalan from The Apache Software
Foundation, http://www.apache.org, was used.
optional “changes_value” element part of the “uses”
element can e.g. be used to change the unit of a variable
part of the base class.
AN IMPLEMENTATION OF THE INTERMEDIATE
LANGUAGE
In XML, XML-Schema, a standard recommended by W3C,
can be used to define what information should go in an
XML document and how it should be structured to be
correct. We use it here to describe the different parts of the
intermediate language implemented. An XML document of
the implemented intermediate language has a data structure
as shown in Figure 3. It has a root element called Modelith.
Then, it has three classes, as they are called in Modelica;
implemented by the elements “type”, “model” and
“connector” directly under the root. The names of the
elements come from the Modelica language, which is the
case for most of the Modelith language. As in objectoriented languages, instances of these classes can be
created. The class is used as a kind of template.
Figure 5. One of the top elements, in this Case “type”
Instances of the “connector” class are used as connection
points for model instances. It could e.g. be a resistor port or
motor shaft. A “connector” element contains a number of
variables implemented by “type_instance” elements. Each
such element here has an extra attribute named “prefix” that
tells whether the variable should be summed to zero or be
set equal with respect to corresponding variables in all other
connectors connected to. If a resistor port was defined, the
“prefix” attribute for the current variables would be set to
“flow” and the variables be summed to zero in each
crossing. If the “prefix” attribute is missing all variables are
assumed to be equal, having the same effort.
The “model” class, shown in Figure 6, is the central class
in the language. It can as the other classes make use of
inheritance. It is here that the three levels mentioned earlier;
the implicit, flattened implicit and flattened explicit are
defined.
Figure 3. The Top Element of the Intermediate Language
Schema
In Figure 3, squares indicate XML elements, rounded
squares choices, sequences or groups and dashed lines
indicate that the element is optional. Plus signs indicate that
some information in the figure is hidden. The schema and
the pictures have been created in XML Spy (Kirn 2002),
which is a powerful editor for XML (www.xmlspy.com).
The schema used by the authors is found at their URL,
http://hydra.ikp.liu.se. An XML document that is valid
when compared to the schema above (ignoring hidden
information in the schema) could be the following:
<Modelith>
<model/>
<connector/>
<type/>
<model/>
</Modelith>
Figure 4. Modelith Document Sample
The “type” class, implemented as in Figure 5, is the most
fundamental one. Type instances, implemented as
“type_instance” elements, are used as variables, parameters
and constants. By itself the class specifies e.g. what unit the
instances should use. The “type” element has one optional
element, as also the “model” and “connector” elements
have. The “uses” element there tells what class the current
class, in this case “type”, uses as base for adding further
information. It is this element that makes it possible to
inherit variables, connectors etc from other classes. The
Figure 6. The Central Class, “model” in which e.g. all
Equations are Placed
Object-oriented implicit model
The implicit part of a model, shown in Figure 6, contains a
number of internal variables, parameters and constants as
realised by “type_instance” elements with a “prefix”
attribute telling which of the mentioned kinds is to be used.
The “connector_instance” elements define the connectors
on the model that other models can connect to. The model
can contain instances of other models that can be connected
together using “connection” elements. Each of these makes
a connection between two model instances by specifying
which connector instances on them to connect. Finally, the
model can contain a number of equations.
The authors have chosen to use a subset of MathML, a
standard recommended by W3C, for the equations, see
Figure 7. The equations are then unfortunately not easy to
read as pure strings, but are much easier to transform, and it
can be used to produce typeset equations for documentation
for MathML enabled browsers. XSLT is not well suited for
string manipulation, therefore it is better to have an XML
representation of the equation. This also gives the
possibility to validate equations against the schema. Usermade functions can be referred to here with any number of
arguments. A future extension of the schema would be to
include algorithms so that these functions can be specified
directly and thus not be external. The MathML functions
supported in this schema are “plus”, “minus”, “times”,
“divide” and “diff” where “diff” is differentiation with
respect to some variable specified in the “bvar” element,
normally set to “time”. To reference variables part of
connector instances, the subscript notation of MathML is
used, as can be seen in Appendix B and D.
connections have been transformed into equations using the
causal information found in the connector classes. At the
end of the flattened part, the explicit part with its extra
information can be added.
Figure 8. The Flattened Part of a Model. The Elements have
the Same Contents as in the Object-Oriented Part
Explicit part of the flattened implicit model
This part, shown in Figure 9, holds information that helps in
simulating the flattened model. All type instances of
parameter and constant type are left in the implicit flattened
part as well as all connector instances. The rest of the type
instances are here together with all found from expanding
the connector instances. The “prefix” attribute is set to
“input”, “output” or nothing for all “type_instance”
elements so that the output transformer knows how to
define the interface to the model. A “prefix” attribute set to
nothing would mean that the variable is an internal one. In
this case, if the “prefix” attribute in a “type_instance” in a
“connector” element referred to by an expanded
“connector_instance” element has the value “flow”, the
“prefix” attribute in the corresponding “type_instance”
element in the explicit part is set to “output” and vice versa.
An extra attribute named “connector_instance” tells
whether the type instance comes from an expanded
connector instance and if so, from which one.
Figure 7. The Content of Equations and Jacobian Elements,
i.e. MathML Expressions
Flattened implicit model
This part, shown in Figure 8, contains a number of type
instances, optionally connector instances and finally
equations. The elements are equal to the ones found in the
object-oriented part of the model. The difference is that all
elements from inherited models have been added and that
Figure 9. The Explicit Part of a Model
In simulation, the variables need to be calculated. The
equation system formed by the equations then needs to be
solvable. Therefore, the MathML “diff” function is here
replaced with a time discrete expression. In this
implementation, the authors have chosen to insert new type
instances with names that are formed from the arguments to
the “diff” functions. Each new type instance generates an
equation where a time discrete expression is stated. In
Equation (1) below, the variable “x” is calculated using the
trapezoidal rule. There, “h” is most recent simulation time
step, “delay” is a function that delays the second argument
the time specified by the first and “der_x” is the new
variable that is the time derivative of “x”.
x = delay(h, x ) + h
(der _ x + delay(h, der _ x ))
2
(1)
The other way would be to use the bilinear transform, as is
done in (Krus 1996). This however demands the usage of
more powerful symbolic math operations that can be
performed for example by using the symbolic math package
Mathematica (Wolfram 1999).
Since, in the general case, the equation system could be
non-linear, a Jacobian is also formed so that the NewtonRaphson solve method can be used. The Jacobian is defined
for the left-hand side of the equations and therefore all
equations from the flattened implicit part are copied to the
explicit part and transformed so that the right hand side is
zero.
The Jacobian has a number of rows and each row has an
“element” element. Each “element” contains a MathML
expression that is the derivative of the equation referred to
by the row number and with respect to a certain variable.
The variable in question is from the list of “type_instance”
element in the explicit part with the “prefix” attribute set to
“output” or nothing, at the position determined by the
position of the “element” in the current row of the Jacobian.
IMPLEMENTATION OF THE TRANSFORMERS
Input transformer
As an example modelling language to translate, the authors
chose Modelica since it is widespread and is one of the
most complete languages available. A Modelica parser was
created as well as a tree builder that outputs an XML file.
The free parser generator JavaCC (Microsystems 1998) was
used. A parser, explained in (Levine et al. 1992), finds
certain units of information in its input. These units are
specified in a grammar. The unit “left_bracket_key” e.g.,
found there, is the character “(“. As an example, the
Modelica input shown below is transformed into the
following XML information.
model a
end a;
<Modelica>
<model_definition>
<class_definition>
<model_key/>
<IDENT>a</IDENT>
<class_specifier>
<end_key/>
<IDENT>a</IDENT>
</class_specifier>
</class_definition>
<semi_colon_key/>
</model_definition>
</Modelica>
Figure 10. The XML-Transformed Modelica Document
The shown XML file can then be transformed into the
Modelith language using e.g. XSLT.
Flattening
This operation is performed in several steps, each with an
XSLT file as input specifying how the incremental
transformation is to be performed. The user specifies a
model to flatten. The inheritance in all classes is substituted
so that the classes are complete by themselves and do not
reference anything outside the class. The flattened part also
contains all equations that have been collected from
inherited models as well as the current model. If a model
that is inherited contains connections, these are transformed
into equations in a way that is determined by the type of
variables part of the connectors, as explained earlier. The
name of a variable in an equation is determined from where
in the hierarchy a model resides with respect to the toplevel model in order to avoid name conflicts. Compare this
to the variable naming conventions found in C++ or Java.
From equations to calculations
The connector instances in the flattened model are
expanded so that a number of variables can be extracted.
The generated “type_instance” elements contain an extra
attribute called “connector_instance” that tells which
connector instance in the model they belong to.
The equations of the flattened model are first brought to the
input format of the symbolic math package using XSLT.
Then, all terms on the right hand side of each equation are
moved to the left side and the right hand side is set to zero
to be able to differentiate and establish the Jacobian. All
differentiation functions are replaced by new type instances
and each new type instance generates a new equation with a
time discrete expression that calculates an approximation of
the derivative. The equations as well as new type instances
are added to the explicit part of the document.
Now, each element in the Jacobian is calculated. The
expression to be differentiated is sent to the symbolic math
package together with the name on the variable to
differentiate with respect to. An equation is returned with
the differentiated expression, which is transformed to
MathML and added to the explicit part.
Output transformer
Here, we focus on the creation of simulation models rather
than creation of stand-alone simulators, applications or
graphical and textual presentations.
A simulation model that makes use of the solver in the tool
exported to is here called continuous. The other type of
model that could be output is the one that includes its own
solver, here called a discrete model. Both can be created
from the information part of the explicit model, at least if
AN EXAMPLE
The mass and spring system shown in Figure 11 is used as
an example in the following text. The Modelica code is
found in Appendix A. The example is a mass and a spring.
The connector instances of the Modelica component are n1
and n2, k is the spring stiffness and endpos the position of
the mass where the spring starts to act.
derivatives of the variable “x” of connector instance “n2”
and variable “sx” of connector instance “n2” respectively.
They are part of two new equations that have been added as
well. As can be seen, the equations are now in a form where
the right hand side is equal to zero. A Jacobian can now
easily be established.
From the information found in the complete Modelith file,
any type of output can now be created in the general case. It
can be a Modelica file, a Matlab/Simulink
continuous/discrete S-function, HOPSAN or something
else. In this example, the output is a kind of discrete
component since the numerical integration is taken care of
by the component itself. The output transformer is in the
form of one XSLT file of about 350 lines of code. Half of
this file deals with transforming the MathML equations into
appropriate FORTRAN code and the other half is the
supporting parts of the FORTRAN subroutine.
n1
n2
k
Figure 11. The Example Model
The connector instances define the interface to the outer
world. Normally, forces and velocities would be the
variables to solve for numerically. In this example however,
the component is to be used in the simulation tool Hopsan.
Hopsan makes use of bilateral delay lines, described by
(Auslander 1968) and (Johns and O’Brien 1980) where it is
referred to as Transmission Line Modelling (TLM). This is
used to numerically integrate a system of ordinary
differential equations. The connector “MechanicQNode”
therefore contains two extra variables that have the prefixes
set to “wave” and “impedance”, a small extension to the
Modelica language. The model “TwoFlange” also contains
one equation for each connector instance that calculates the
force acting on the mass using the wave and the impedance
given from external components in Hopsan. The model
“TransMass” inherits “TwoFlange” and adds an equation
for the mass inertia and the force from the spring.
After running the Modelica code through the input
transformer, the code in Appendix B is produced. This file
is considerably longer, but also “tagged” with its
information type. Maybe most notably, the equations are
now in MathML form.
After having flattened the model “TransMass”, the code
found in Appendix C is added to “TransMass” model in
Appendix B. This part of the model now contains all
elements found in “TwoFlange” and “TransMass”, e.g.
connector- and type instances as well as equations.
The file in Appendix C can now be used to extract extra
information that is added as a new element with name
“explicit” in the flattened part, shown in Appendix D. This
contains all type instances that are variables from the
flattened part as well as two new ones with name
“der_n2_x” and “der_n2_sx”. These are approximate
Position (n2.x) [m]
endpos
1.20
1.50
1.00
1.00
0.80
0.50
0.60
0.00
0.40
-0.50
0.20
-1.00
0.00
0.00
0.50
1.00
1.50
Time [s]
2.00
2.50
Velocity (n2.sx) [m/s] (dashed line)
the derivatives are expressed explicitly, otherwise only the
discrete model can be created.
Output transformers have been implemented and tried for
Mathwork’s tool Matlab/Simulink (both continuous and
discrete S-functions) in (Johansson et al. 2002) and for the
free simulation package Hopsan (Larsson et al. 1998) as
shown in the next chapter. Hopsan is developed at the
division of Mechanical Engineering Systems and is mainly
intended for mechatronic systems.
-1.50
3.00
Figure 12. Simulation Results from Hopsan
When running the generated component in a Hopsan
simulation where a force is given as a step from the left, the
position and velocity varies repeatedly as shown in the
figure above. The mass bounces repeatedly against the
spring.
FUTURE WORK
The Modelith XML schema presented in this paper should
represent a good start for anyone interested in transforming
simulation models. To increase simulation performance, a
number of things can be done. The most import one is
transforming the Jacobian into Block-lower-triangular form
so that the evaluation of the equation system can be split
into several parts.
Another research area is to include Modelith in a
framework for the whole product model including
information such as requirement specifications and
geometric data.
CONCLUSIONS
It is shown in the paper that the work needed for a user to
translate equations into implemented calculations can be
dramatically reduced by introducing an intermediate
language together with some well-defined transformers that
act incrementally on this language. The only work needed
by the user is to make use of a ready-made intemediate
language and transformers and create one or more
transformers that import or export models from the
intermediate language. One or more of the latter could have
been created earlier by another user.
DISCUSSION
Since the transformers can be developed individually and
since only freely-available programming languages and
tools are needed, the framework can act as a catalyst,
encouraging cooperation, in the area of modelling and
simulation.
Hopefully, this will lead to the creation of special-purpose
modelling languages, new modelling- as well as simulation
tools and also translators for physical systems model
languages. This in turn would give a larger degree of
freedom for users of simulation when it comes to defining
models, choosing simulation tools and creating custom
applications from the models.
The implementation of the framework shows that most of
the work regarding creation of the internal transformers for
the intermediate language. This work that is however only
done once. The import and export transformers are easy and
quickly implemented using all facilities of the XML
domain, this part is hopefully where most of the users will
find themselves.
New user groups such as teachers and engineers can be
reached due to the new simple way of translation. They will
be able to develop simulation solutions for education and
special-purpose simulators.
REFERENCES
Auslander D.M., 1968. “Distributed System Simulation with
Bilateral Delay-Line Models.” Journal of Basic Engineering,
No.90 (June), 195-200.
Elmqvist, H.; Mattsson, S.E.; and Otter, M. 1999. ”Modelica - A
Language for Physical System Modeling, Visualization and
Interaction”. Plenary paper. 1999 IEEE Symposium on
Computer-Aided Control System Design. (Hawaii, August
22-27), IEEE, 630-639
Harold, E. R. and Means, E. S. 2001. XML in a Nutshell. O'Reilly
& Associates
IEEE. 1999. 1076.1 Working Group: Analog and Mixed-Signal
Extensions for VHDL
Johansson, B.; Larsson, J.; Krus, P.; and Sethson, M. 2002. “An
XML-based model representation for model management,
transformation and exchange“. To be presented at the ASME
Symposium
on
Automated
Modelling.
(New
Orleans,Louisiana, Nov.17-22) . ASME
Johns, P. B. and O'Brien, M. 1980. "Use of transmission line
modelling (t.l.m) method to solve nonlinear lumped
networks." The Radio Electron and Engineer. No.50
(Jan/Feb), 59-70
Kirn, L. 2002. “XML Integrated Development Environments –
Accelerating XML Application Development In the
Interprise.” Whitepaper, Altova Inc, Beverly, USA
Krus, P. 1996. “An Automated Approach for Creating
Components and Subsystems for Simulation of Distributed
Systems.” In 9th Bath International Fluid Power Workshop.
Burrows, C.R. and Edge, K.A. (Eds.). Research Studies Press
Larsson, J.; Jansson, A.; and Krus, P. 2002. “User’s guide to
Hopsan - An integrated simulation environment.” Technical
Report LiTH-IKP-R1258, Mechanical Engineering Systems,
Linköping University, Linköping, Sweden
Levine, J. R.; Mason, T.; and Brown, D. 1992. Lex & Yacc.
O’Reilly & Associates, Inc., Second Edition
Microsystems, S. 1998. “Java Compiler Compiler” Technical
Report, Sun Microsystems
Modelica Association. 1999. “Modelica A Unified ObjectOriented Language for Physical Systems Modelling,
Language Specification”
Murray-Rust, P.; Rzepa, H.S.; and Wright, M. 2001.
“Development of Chemical Markup Language (CML) as a
System for Handling Complex Chemical Content”. New
Journal of Chemistry, No.25:4 (March), 618-634
Otter, M. and Elmqvist, H. 1995. “The DSblock model interface
for exchanging model components”, In proceedings of the
1995 EUROSIM Conference. (Vienna, Austria, Sept.11-15).
Elsevier Science Publishers, 505-510
Piela, P.; Epperly, T.; Westerberg, K.M.; and Westerberg, W. 1991.
“ASCEND: An object-oriented computer environment for
modelling and analysis: the modelling language.” Computers
and Chemical Engineering, No.15:1, 53-72.
Ward, R.C.; Kruse, K.L.; Allgood, G.O.; Hively, L.M.; Munro,
N.B.; and Easterly, C.E. 2001. "Virtual Human Project," in
Proceedings of AeroSense 2001 Meeting. (Orlando, FL USA,
April 16-20)
Wolfram, S. 1999. The Mathematica Book, 4th revised edition,
Cambridge University Press
APPENDIX A. MODELICA SUBSET DOCUMENT
type Position = Real(unit="m")
type Velocity = Real(unit="m/s")
type Force = Real(unit="N")
type MechImpedance = Real(unit="N.s^2/m")
"Mechanical impedance";
type Mass = Real(unit="kg")
"Mass";
type TransStiffness = Real(unit="N/m")
"Translational stiffness";
connector MechanicQNode
"Node for usage with the TLM technique"
Force F;
wave Force cx
"Characteristic wave";
impedance MechImpedance Zx
"Characteristic impedance";
flow Position x;
flow Velocity sx;
end MechanicQNode;
model TwoFlange
MechanicQNode n1
"Left mechanical node";
MechanicQNode n2
"Right mechanical node";
equation
n1.x = -n2.x;
n1.sx = -n2.sx;
n2.sx = der(n2.x);
n1.F = n1.cx + n1.sx*n1.Zx
"TLM eq for node n1";
n2.F = n2.cx + n2.sx*n2.Zx
"TLM eq for node n2";
end TwoFlange;
model TransMass extends TwoFlange;
parameter Mass m=10.0
"The mass";
parameter TransStiffness k=1e+5
"Spring constant for right end pos";
parameter Position endpos=1.0
"End position";
equation
n1.F-n2.F-OnPositive(n2.x-endpos)*
(n2.x-endpos)*k = m*der(n2.sx)
"Newtons 2:nd with an end spring";
end TransMass;
APPENDIX B. OBJECT-ORIENTED IMPLICIT
MODELITH DOCUMENT
APPENDIX C. FLATTENED IMPLICIT PART OF
MODEL
<Modelith>
<type name="Position">
<uses class="Real">
<changes_value type_instance="unit"
value="m"/>
</uses>
</type>
.
.
<connector name="MechanicQNode" comment="A
node for usage with the TLM technique">
.
.
<type_instance name="sx" prefix="flow">
<uses class="Velocity"/>
</type_instance>
</connector>
<model name="TwoFlange">
<connector_instance name="n1" comment="Left
mechanical node">
<uses class="MechanicQNode"/>
</connector_instance>
<connector_instance name="n2" comment="Right
mechanical node">
<uses class="MechanicQNode"/>
</connector_instance>
<equation>
<MathML>
<apply>
<eq/>
<ci>
<msub>
<mi>x</mi>
<mi>n1</mi>
</msub>
</ci>
<apply>
<minus/>
<ci>
<msub>
<mi>x</mi>
<mi>n2</mi>
</msub>
</ci>
</apply>
</apply>
</MathML>
</equation>
.
.
</model>
<model name="TransMass">
<uses class="TwoFlange"/>
<type_instance name="m" prefix="parameter"
value="10.0" comment="The mass">
<uses class="Mass"/>
</type_instance>
.
.
<equation>
.
.
</equation>
</model>
</Modelith>
<flattened>
<connector_instance name="n1" comment="Left
mechanical node">
<uses class="MechanicQNode"/>
</connector_instance>
.
.
<type_instance name="m" prefix="parameter"
value="10.0" comment="The mass">
<uses class="Mass"/>
</type_instance>
.
.
<equation>
.
.
</equation>
.
.
</flattened>
APPENDIX D. EXPLICIT PART OF FLATTENED
IMPLICIT MODEL
<explicit>
<type_instance name="F" prefix="output"
connector_instance="n1"/>
<type_instance name="cx" prefix="input"
connector_instance="n1"/>
<type_instance name="Zx" prefix="input"
connector_instance="n1"/>
.
.
<type_instance name="x" prefix="output"
connector_instance="n2"/>
<type_instance name="sx" prefix="output"
connector_instance="n2"/>
<type_instance name="der_n2_sx"
prefix="derivative" state="sx"
connector_instance="n2"/>
<type_instance name="der_n2_x"
prefix="derivative" state="x"
connector_instance="n2"/>
<equation>
<MathML>
<apply>
<eq/>
<apply>
<plus/>
<ci>
<msub>
<mi>x</mi>
<mi>n1</mi>
</msub>
</ci>
<ci>
<msub>
<mi>x</mi>
<mi>n2</mi>
</msub>
</ci>
</apply>
<cn>0</cn>
</apply>
</MathML>
</equation>
.
<jacobian>
<row>
<element>
<MathML>
<cn>1</cn>
</MathML>
</element>
.
</row>
.
</jacobian>
</explicit>