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 sucient to study the diverse components
separately, using the specic 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 dierent modelling languages. It is shown how
dierent 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 dierent formalisms. This
mapping may be implemented as a translator between
modelling languages. Transformation between formalism has dierent 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 dierent 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 dierent abstract representations or \models" of these systems. Typical abstractions or formalisms used in physical systems modelling are bond
graphs, Petri-nets, dierential equations and queueing
networks. In software systems, abstractions include nite state automata and entity relationship diagrams.
The representation and manipulation of system models using dierent 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 dierent
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 dened \paradigm". A
paradigm is a way to view things (e.g., functional,
object-oriented, . . . ). A formalism is a rigorous, mathematical framework. We will loosely dene 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 specication
i
s +1 = (s )
DAE
polluted
effluent
purified
effluent
algae
landfill
Figure 1: Complex System Example
complex system. The complexity lies in the diversity
of the dierent components:
i
Figures 2,3 and 4 demonstrate how the FSA model of
System Dynamics
Discrete Event
paper
i
fish
A paper mill produces paper from trees with polluted water as a side-eect. This system is modelled as a discrete-event scheduling system.
A Waste Water Treatment Plant (WWTP) takes
the polluted euent from the mill and puries it.
Some solid waste is taken to a landll whereas the
partially puried water ows into a lake. This system is modelled using Dierential 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
suce.
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
trac light dynamics can be represented in dierent
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)
"solver-level"
(DSblock) language
DR and level always occur together. Levels may inuence each other by inuencing each other's BR and DR.
Figure 7 depicts the structure of a System Dynamics
model component.
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) specication of the state trajectory in the formalism serves as
a formal specication of a \solver" or simulation kernel. It is possible to design a modelling language for
a formalism with a well-dened Application Programmer's Interface (API) which is suited for linkage with
the solver. Dierent language belonging to the \formalism" category may exist. MSL-intern stands for a
machine-oriented dump of the internal representation.
MSL stands for Model Specication 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 (Dierential
Algebraic Equations), Bond Graphs, DEVS (Discrete
Event System Specication) 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
dierent 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 Specic Questions
The mathematical mapping between formalisms can
be used as a specication 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 dierent 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
x
M
m1
y
m2
x
M
x
y
y
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
dierent 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 dierent 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 Dierent 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 conuence 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 Jerey 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. Kerckhos, 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.