A Multi-Paradigm Modelling and Simulation Methodology:

Formalisms and Languages

Hans L. Vangheluwe and Ghislain C. Vansteenkiste
Applied Mathematics, Biometrics and Process Control
University of Gent
Coupure 653, B-9000 Gent
Belgium
e-mail: Hans.Vangheluwe@rug.ac.be

1 Abstract
Recently, the interest in Computer Aided Engineering
of complex systems has increased 1]. This increase is
mainly due to the growing complexity of systems under
study. This article focuses on systems characterised,
not so much by a large number of components, but
rather by the diversity of the components. A simplied example of an environmental system is presented.
For the analysis and design of such complex systems, it
is no longer su cient to study the diverse components
separately, using the speci c formalisms these components were modelled in. Rather, it becomes necessary
to answer questions about properties (most notably
behaviour) of the whole system.
This article discusses in an informal manner, the concept of \formalism" which is the key to expressing semantics of models. Those models can be represented
using di erent modelling languages. It is shown how
di erent modelling languages are related to one another, enabling meaningful model exchange and re-use.
Some particular model representations are suited for
use by a \solver", allowing the model to be simulated.
The general architecture of simulators is presented.
In certain cases, it is possible to describe a mathematical relationship between di erent formalisms. This
mapping may be implemented as a translator between
modelling languages. Transformation between formalism has di erent uses. Firstly, certain questions about
a system can only be answered in certain formalisms,
necessitating model transformation to the appropriate
formalism. Secondly, to elicit the meaning of a coupled
model consisting of sub-models in di erent formalisms,
transformation of these sub-models to a common formalism is appropriate. This transformation process
will be demonstrated.
Research Fellow at CERC, the Concurrent Engineering Research Center, WVU, Morgantown, USA

2 Introduction
The analysis, design and control of complex systems
(hardware, software and hybrid) involves the manipulation of di erent abstract representations or \models" of these systems. Typical abstractions or formalisms used in physical systems modelling are bond
graphs, Petri-nets, di erential equations and queueing
networks. In software systems, abstractions include nite state automata and entity relationship diagrams.
The representation and manipulation of system models using di erent formalisms has been a task allotted
to the experienced modeller, who traverses the modelling life-cycle, from goals, through multiple abstract
models, into a concrete implementation. This process
has hitherto remained internalised (i.e., the modeller's
experience), limiting the chances of its successful automation.
Due to the continuing integration of hardware and software, there is a growing need for integrated modelling
support. It is suggested that a rigorous multi-paradigm
modelling methodology will provide a backbone for
complex decision-making.
One of the main advantages of explicit model representation are the resulting simulations. At di erent
levels of abstraction, experiments can be performed on
the model through simulation. This provides quantitative insight into the (analysed, designed, controlled)
system. Through simulations, chances of propagating
errors throughout the design are greatly reduced and
insight into the dynamics of the system is enhanced.
In the sequel, the term \formalism" will be used
rather than the more vaguely de ned \paradigm". A
paradigm is a way to view things (e.g., functional,
object-oriented, . . . ). A formalism is a rigorous, mathematical framework. We will loosely de ne a paradigm
as a set of similar formalisms.

To focus the attention, Figure 1 gives an example of a

Paper Mill
trees

WWTP

Fish Farm

is the \state transition function" which maps a state

into the \next" state.
Given a start state s0 2 S , the state trajectory T =
fs ji 2 N g is given by the iterative speci cation
i

s +1 = (s )

DAE
polluted
effluent

purified
effluent

algae

Figures 2,3 and 4 demonstrate how the FSA model of

System Dynamics

Discrete Event

paper

fish

landfill

Figure 1: Complex System Example

complex system. The complexity lies in the diversity
of the di erent components:
A paper mill produces paper from trees with polluted water as a side-e ect. This system is modelled as a discrete-event scheduling system.
A Waste Water Treatment Plant (WWTP) takes
the polluted e uent from the mill and puri es it.
Some solid waste is taken to a land ll whereas the
partially puri ed water ows into a lake. This system is modelled using Di erential Algebraic Equations (DAEs) describing the biochemical reactions
in the WWTP.
A Fish Farm grows sh in the lake which feed on
algae which are highly sensitive to polluted water.
The water is also used for a tree plantation which
supplies the paper mill. This system is modelled
using the System Dynamics formalism (see Section 4).
It is obvious that decision-making for this system will
require understanding of the behaviour of the overall
system. Studying the individual components will not
su ce.

3 Semantics of Models
As in denotational semantics 2] of programming languages, we will formalise the meaning of a system
model by describing its relationship to a mathematical
framework: a \formalism". As an extremely simplied example, we present the Finite State Automaton
(FSA) formalism:
FSA =< S; >
where S is a nite set of sequential states and
:S!S

model trafficlights
{
red -> green;
green -> yellow;
yellow -> red;
}

Figure 2: FSA Language 1

model trafficlights:
states = {red, green, yellow};
transitions = {(red, green),
(green, yellow),
(yellow, red)};

Figure 3: FSA Language 2

green
red

yellow

Figure 4: FSA Graphical

tra c light dynamics can be represented in di erent
ways. All of these \languages" can however easily be
mapped onto the FSA formalism: they all have a nite
set of states and have a description of the transition
function. Thus, the semantics (and validity) of each of
these representations become apparent through their
denotation: their mapping onto the FSA formalism.
More generally, the relationship between a formalism,
its internal (to a computer) and its external (modelling
language) representation are seen in Figure 5. This gure shows how the structure of a formalism determines
the internal representation used, as well as semantic
checking rules 3] which check whether a lex-ed and
parsed model adheres to the structure and constraints

mathematics

formalism

computer science

end-user

internal
representation

languages

- semantic checks
- "writing" out
- closure
- optimisation

MSL-intern
MSL-extern
existing languages ...

solver
(simulation kernel)

DR and level always occur together. Levels may in uence each other by in uencing each other's BR and DR.
Figure 7 depicts the structure of a System Dynamics
model component.

"solver-level"
(DSblock) language

source

sink

level/stock

flow

birth
rate

death
rate

API

Figure 5: Formalism versus Language

Figure 7: System Dynamics Formalism

imposed by the formalism. Also, the (iterative) speci cation of the state trajectory in the formalism serves as
a formal speci cation of a \solver" or simulation kernel. It is possible to design a modelling language for
a formalism with a well-de ned Application Programmer's Interface (API) which is suited for linkage with
the solver. Di erent language belonging to the \formalism" category may exist. MSL-intern stands for a
machine-oriented dump of the internal representation.
MSL stands for Model Speci cation Language.

Figure 8 presents part of the \formalism space". The

dotted lines denote the existence of a solver capable
of simulating the model, thus generating a trajectory
(which is a model of the system in the DATA formalism). The vertical dashed line indicates the historical
distinction between \continuous" and \discrete" formalisms.

Obviously, translation between models belonging to

the same formalism is straightforward (see Figure 6).
Such translation allows for meaningful exchange and
re-use of models between users and tools.
mathematics

formalism

computer science

internal
representation
- semantic checks
- "writing" out

end-user

languages
lex/parse
language 1

language 2
solver
(simulation kernel)

Figure 6: Language Transformation

4 Commonly Used Formalisms

Some commonly used formalisms are DATA (timelabelled and ordered state values), DAE (Di erential
Algebraic Equations), Bond Graphs, DEVS (Discrete
Event System Speci cation) and System Dynamics.
System Dynamics describes the increase and decrease
of variables (called levels) through birth rates (BR) and
death rates (DR). The formalism prescribes that BR,

Bond Graph a-causal

System Dynamics

Bond Graph causal

DAE a-causal set

Process Interaction
Discrete Event
Finite State Automata

DAE causal set

DAE causal sequence (sorted)

DEVS
data

Figure 8: Formalisms
Figure 9 gives an example of a very particular formalism: the \network" or \coupled model" formalism.
When we observe a structured model such as the one
presented in the introduction, we can only make meaningful assertions about its structure, NOT about its
behaviour. In particular, the only knowledge we have
about the model is the set of sub-models it is composed of and a graph describing the coupling between
the sub-models.

5 Formalism Transformation
Often, a (mathematical) relationship exists between
di erent formalisms. Based on this mapping, translation of a model in one formalism to the same model
described in another formalism becomes possible. An

CoupledModel = < {Msub_i}, CouplingGraph >

mathematics

computer science

internal
representation I1

formalism F1

CouplingGraph

mathematical
mapping

Msub_1

syntax
directed
translation

Msub_2

internal
representation I2

formalism F2

CoupledModel

Figure 9: Network Formalism

end-user

languages
F1 - L1
F1 - L2
...
languages
F2 - L1
F2 - L2
...

Figure 12: Formalism and Language Transformation

example of a transformation between a System Dynamics model and its DAE representation is given in
Figure 10. Often, translation involves a loss of infor-

6 Coupled Model Transformation

Formalism: System Dynamics

source

sink

level/stock

flow

birth
rate

death
rate

Formalism: DAE
dL
-- = Birth_rate - death_rate
dt

Figure 10: System Dynamics to DAE Transformation

mation. This may be a blessing in disguise as it entails
a reduction in complexity. One major use for formalism transformation is the answering of particular questions about the system. Some questions can only be
answered in the context of a particular formalism as
illustrated in Figure 11.
Q: feedback ?

Q: linear system ?

Q: trajectory ?

System Dynamics

System Dynamics

System Dynamics

DAE

DAE
data

Figure 11: Formalism Speci c Questions

The mathematical mapping between formalisms can
be used as a speci cation for semantic mapping functions to implement syntax directed translation between
the internal representations of both formalisms. This
in turn allows for the automatic translation between
languages belonging to di erent formalisms. Such an
approach leads to Figure 12.

As previously mentioned, a coupled model only provides information about its components and their interconnection (Figure 9). If all the sub-models are of
the same formalism F , it may be possible to transform
the coupled model into one atomic model of type F .
The ability to do this within a formalism F is called
the closure property 4] of F (which has to be proven
mathematically for each F ). This process is illustrated
in Figure 13.
x

m1
y

m2

x
y

NAME UNIFICATION
M = < {m1, m2},
m1: x -> m1.x; y -> m1.y
{M.x-m1.x, m1.y-m2.x, m2.y-M.y}>
m2: x -> m2.x; y -> m2.y
m1: y:=f(x)
CLOSURE of DAE formalism
m2: y:=g(x)
m1.x := M.x
m1.y := f(m1.x)
m2.x := m1.y
m2.y := g(m2.x)
M.y := m2.y

Figure 13: Closure in One Formalism

If a coupled model consists of sub-models expressed in
di erent formalisms, two classes of solutions exist:
1. To use a meta-formalism, which subsumes the different formalisms of the sub-models. Meaningful
meta-formalisms are very rare (Bond Graphs are
a good example). Though it is in theory possible to construct them, this is only meaningful if
complexity is reduced or more insight is gained.
2. To transform the di erent sub-models to a common formalism as illustrated in Figure 14. To de-

System Dynamics

?
DAE

Bond Graph

: closure of DAE formalism

Figure 14: Coupling of Di erent Formalisms

termine which formalism to transform a Formalism Transformation Lattice, describing all known
translations, is used. As an example, the transformations currently being implemented by the authors are shown in Figure 15.
Bond Graph a-causal
System Dynamics

Bond Graph causal

DAE a-causal set

Process Interaction
Discrete Event
Finite State Automata

DAE causal set

DAE causal sequence (sorted)

DEVS
data

Figure 15: Formalism Transformation Lattice

7 Conclusions
Discussions within the Simulation in Europe ESPRIT
Basic Research Working Group 5] have clearly shown a
need for multi-formalism modelling. This article gives
an informal description of an approach which is intuitively appealing, yet rigorously correct. Preliminary
implementations of the framework were successful and
will be pursued. It is believed the correctness and standardisation of modelling and simulation environments
will greatly improve if due attention is paid to the
meaning of models by means of rigorously described
formalisms.

8 Acknowledgements
The authors wish to express their gratitude to Dr.
Y.V. Reddy, director of the Concurrent Engineering

Research Center (CERC) for his continuing support

of this research. Dr. Reddy is also the originator
of the term \SimFormatics", the con uence of Modelling, Simulation and Informatics, to which this work
is a small contribution. The authors would also like
to thank Dr. Srinivas Kankanahalli of CERC for the
stimulating discussions on the information preserving
nature of the model-solver combination.

References
1] Hans Vangheluwe and Ghislain Vansteenkiste.
Computer-aided modelling of complex systems. In
Proceedings of the ADIUS Sixteenth Annual Conference (Seattle), 3800 Stone School Rd., Ann Arbor, Michigan 48108-2499 USA, June 1995. Applied
Dynamics International.
2] Hanne Riis Nielson and Nielson Flemming. Semantics with Applications: A Formal Introduction. Wiley Professional Computing. John Wiley & Sons,
Chichester, England, 1992.
3] Alfred Aho, Ravi Sethi, and Je rey Ullman. Compilers, Principles, Techniques, and Tools. AddisonWesley, 1986.
4] Bernard P. Zeigler. Theory of Modelling and Simulation. Robert E. Krieger, Malabar, Florida, 1984.
5] Eugene J.H. Kerckho s, Hans L. Vangheluwe,
Ghislain C. Vansteenkiste, and Philippe Geril.
Improving the modelling and simulation process.
Progress Report 1994:1, ESPRIT Basic Research
Working Group 8467, BIOMATH Department,
University of Gent, Coupure 653, B-9000 Gent,
Belgium, 1994.