AN INTRODUCTION TOMULTI-PARADIGM MODELLING AND SIMULATION

Hans Vangheluwe

School of Computer ScienceMcGill University, Montreal

Quebec, Canadahv@cs.mcgill.ca

Juan de Lara

E.T.S. de InformaticaUniversidad Autonoma de Madrid

Madrid, SpainJuan.Lara@ii.uam.es

Pieter J. Mosterman

Simulation and Real-Time TechnologiesThe MathWorks, Inc.

Natick, MA, USApieter j mosterman@mathworks.com

ABSTRACT

Modelling and simulation are becoming increasingly im-portant enablers in the analysis and design of complex sys-tems. To tackle problems of ever increasing complexity,modelling and simulation research is shifting from simula-tion techniques to modelling methodology and technology.In this article, the emerging field of Computer AutomatedMulti-Paradigm Modelling is presented. Multi-paradigmmodelling adresses and integrates three orthogonal direc-tions of research:

1. multi-formalism modelling, concerned with the cou-pling of and transformation between models describedin different formalisms,

2. model abstraction, concerned with the relationship be-tween models at different levels of abstraction, and

3. meta-modelling, concerned with the description (mod-els of models) of classes of models, which allows for-malism specification.

The article first introduces the general concepts of Mod-elling and Simulation theory, and explains how rigourousapplication thereof provides a sound basis for the mean-ingful exchange and re-use of knowledge about the be-haviour of complex systems. The representation of mod-els in diverse formalisms, at different levels of abstraction,and the (behaviour-conserving) transformation between theformalisms is demonstrated.

1 MODELLING AND SIMULATION

At a first glance, it is not easy to characterize modellingand simulation. Certainly, a variety of application domainssuch as fluid dynamics, energy systems, and logistics man-agement make use of it in one form or another. Dependingon the context, modelling and simulation is often seen asa sub-set of Systems Theory, Control Theory, NumericalAnalysis, Computer Science, Artificial Intelligence, or Op-erations Research. Increasingly, modelling and simulationintegrates all of the above disciplines. As a paradigm, it isa way of representing problems and thinking about them as

Real-Worldentity

BaseModel

System S

only study behaviour inexperimental context

experimentwithin context

Model M

Simulation ResultsExperiment Observed Data

within context

simulate= virtual experiment

Model Basea-priori knowledge

validation

REALITY MODEL

GOALS

Modelling and Simulation Process

Figure 1: Modelling and Simulation concepts.

much as a solution method. The problems cover the analy-sis and design of complex dynamical systems. In analysis,abstract models are built inductively from observations of areal system. In design, models deductively derived from apriori knowledge are used to build a system, satisfying cer-tain design goals. Often, an iterative combination of analy-sis and design is needed to solve real problems. Though thefocus of modelling and simulation is on the time-varyingbehaviour of dynamical systems, static systems (such asEntity-Relationship (ER) models, described in the UnifiedModeling Language (UML) (Rumbaugh et al., 1999)) area limit-case. Both physical (obeying conservation and con-straint laws) and non-physical (informational, such as soft-ware) systems and their interactions are studied.

1.1 Concepts

Figure 1 presents modelling and simulation concepts as in-troduced by Zeigler (Zeigler, 1984b; Zeigler et al., 2000).

Real World Entity or object can exhibit widely varyingbehaviour depending on the context in which it is stud-ied as well as the aspects of its behaviour which areunder study.

Base Model is a hypothetical, abstract representation ofthe object’s properties, in particular, its behaviour,which is valid in all possible contexts, and describesall the object’s facets.

System is a well defined object in the Real World underspecific conditions, only considering specific aspectsof its behaviour.

Experimental Frame (EF) describes a limited set of cir-cumstances under which a system (real or model) is tobe observed or subjected to experimentation. As such,the Experimental Frame reflects the objectives of theexperimenter who performs experiments on a real sys-tem or, through simulation, on a model.

(Lumped) Model (not to be confused with a lumped pa-rameter model (Cellier, 1991)) is an abstract represen-tation of a system within the context of a given Exper-imental Frame. Usually, certain properties of the sys-tem’s structure and/or behaviour are reflected by themodel (within a certain range of accuracy).

Experimentation is the act of carrying out an experiment.An experiment may interfere with system operation(influence its input and parameters) or it may not. Assuch, the experimentation environment may be seen asa system in its own right (which may itself be modelledin a lumped model). Also, experimentation involvesobservation. Observation yields measurements.

Simulation of a lumped model in a certain formalism(such as Petri Net, Differential Algebraic Equations(DAE) or Bond Graph) computes the dynamic in-put/output behaviour. Simulation may use symbolicas well as numerical techniques. Simulation, whichmimics the real-world experiment, can be seen as vir-tual experimentation. Whereas the goal of modellingis to meaningfully describe a system, presenting infor-mation in an understandable, re-usable way, the aim ofsimulation is to be fast and accurate. Symbolic tech-niques are often favoured over numerical ones as theyallow the generation of classes of solutions rather thanjust a single one (e.g., sin

x as a solution to the har-

monic equation as opposed to one single approximatetrajectory solution). Furthermore, symbolic optimiza-tions have a much larger impact than numerical onesthanks to their global nature. Crucial to the System–Experiment/Model–Virtual Experiment scheme is thatthere is a homomorphic relation between model andsystem: building a model of a real system and subse-quently simulating its behaviour should yield the sameresults as performing a real experiment followed byobservation and codifying the experimental results.

Verification is the process of checking the consistency of asimulation program with respect to the lumped modelit is derived from.

Experimental Frame Definition

Structure Characterisation

Parameter Estimation

Simulation

Validation

class of parametric model candidates

parametric model

model with meaningful parameter values

simulated measurements

validated model

a priori

knowledge

modeller’s andexperimenter’s

goals

experiment observation(measurement)

data

Information Sources Activities

Figure 2: Model-based systems analysis.

Validation is the process of comparing experiment mea-surements with simulation results within the contextof a certain Experimental Frame (Balci, 1997). Whencomparison shows differences, the formal model builtmay not correspond to the real system. A large num-ber of matching measurements and simulation results,though increasing confidence, does not prove valid-ity of the model however. For this reason, Popperhas introduced the concept of falsification (Magee,1985), the enterprise of trying to falsify or disprovea model. It is to be noted that the correspondence ingenerated behaviour between a system and a modelwill only hold within the limited context of the Ex-perimental Frame. Consequently, when using mod-els to exchange information between human or com-puter agents, a model must always be matched with anExperimental Frame before use. Conversely, a modelshould never be developed without simultaneously de-veloping its Experimental Frame. This requirementhas its repercussions on the design of model represen-tation languages.

1.2 The Modelling and Simulation Process

The use of simulation has proven to be invaluable in thestudy of complex systems. The simulation activity is partof the larger model-based systems analysis enterprise. Aframework for these activities is depicted in Figure 2. TheFramework starts by identifying an Experimental Frame.As mentioned above, the frame represents the experimen-tal conditions under which the modeller wants to investi-gate the system. As such, it reflects the modeller’s goalsand questions. Based on a frame, a class of matching mod-els can be identified. Through structure characterization,the appropriate model structure is selected based on a prioriknowledge and measurement data. Subsequently, duringmodel calibration, parameter identification (or estimation)

is_full

is_emptyheat

off

cool

is_coldis_hot

fill emptyclosed

Figure 3: T l controlled liquid in a vessel.

yields optimal parameter values for reproducing a set ofmeasurement data. Using the identified model and param-eters, simulation allows one to mimic the system behav-ior (virtual experimentation). The question remains how-ever whether the model has predictive validity: is it capa-ble not only of reproducing data which was used to choosethe model and to identify parameters, but also of predictingnew behavior ? In Figure 2, one notices how each step inthe modelling process may introduce errors. As indicatedby the feedback arrows, a model has to be corrected oncefalsified.

2 ABSTRACTION AND FORMALISM

Abstract models of system behaviour can be described atdifferent levels of abstraction or detail as well as by meansof different formalisms. The particular formalism and levelof abstraction depends on the background and goals of themodeller as much as on the system modelled. As an exam-ple, a temperature and level controlled liquid in a vessel isconsidered. This is a simplified version of the system de-scribed in (Barros et al., 1998), where structural change isthe main issue. On the one hand, the liquid can be heated orcooled. On the other hand, liquid can be added or removed.In this simple example phase changes are not considered.The system behaviour is completely described by the fol-lowing Ordinary Differential Equation (ODE) model:

dTdt 1

l WcρA φT

dldt φ if 0 l H else 0

is low l llow

is high l lhigh

is cold T Tcold

is hot T Thot

The inputs are the filling (or emptying if negative) flow rateφ, and the rate W at which heat is added (or removed ifnegative). This system is parametrized by A, the cross-section surface of the vessel, H, its height, c, the spe-

level

temperaturecold T_in_between hot

onoff

offoff

ofon

is_cold sensoris_hot sensor

full

l_in_between

empty

on off

off off

off on

is_full sensor

is_empty sensor

Continuous State TrajectoryDiscrete State Trajectory

fill

fill

heat

heat

Figure 4: Trajectories.

level

temperaturecold T_in_between hot

full

l_in_between

empty (cold,empty)

emptyfill

emptyfill

cool

heat

cool

heat (hot,full)

(hot,empty)

(cold,full)

(cold,l_ib) (T_ib,l_ib) (hot,l_ib)

(T_ib,full)

(T_ib,empty)

Figure 5: FSA formalism.

cific heat of the liquid c, and ρ, the density of the liq-uid. The state of the system is characterized by vari-ables T , the temperature and l, the level of the liquid.The system is observed through threshold output sensorsis low is high is cold is hot. Given input signals, param-eters, and a physically meaningful initial condition

T0 l0 ,

simulation of the behaviour yields a continuous state trajec-tory as depicted in Figure 4. By means of the binary (on/off)level and temperature sensors introduced in the differentialequation model, the state-space may be discretized. Theinputs can be abstracted to heater heat/cool/off and pumpfill/empty/closed. At this level of abstraction, a Finite StateAutomaton representation (with 9 possible states) of the dy-namics of the system as depicted in Figure 5 is most appro-priate. Though at a much higher level of abstraction, thismodel is still able to capture the essence of the system’sbehaviour. In particular, there is a behaviour morphismbetween both models: model discretization (from ODE toFSA) followed by simulation yields the same result as sim-ulation of the ODE followed by discretization.

2.1 Systems Theory

In general systems theory (Wymore, 1967), a causal (outputis the consequence of given inputs), deterministic (a knowninput will lead to a unique output) system model SYS isdefined. It is a template for a plethora of different formal-ims such as Ordinary Differential Equations, Finite StateAutomata, Difference Equations, Petri Nets, etc. Its generalform is

SYS T X Ω Q δ Y λ T time baseX input setω : T X input segmentQ state setδ : Ω Q Q transition functionY output setλ : Q Y output function

tx ti t f δω ti t f qi δ

ω tx t f δ ω ti tx qi

The time base T is the formalisation of the independentvariable time, also known as the indexing variable (Nance,1981). The input set describes all possible allowed inputs(possibly a product set). An input represents input dur-ing a time-interval. The history of system behaviour iscondensed into a state. The dynamics is described in atransition function which takes a current state, and appliesan input segment ω Ω to it to obtain a new state. Thesystem may generate output. The output is obtained as afunction λ of the state. State and transition function mustobey the composition or transitivity property. This prop-erty, whereby a transition over a time interval ti t f can al-ways be split into a composition of transitions over arbitrarysub-intervals, is the basis of all model simulators. As theoutput function is described separately, efficient simulatorswill only invoke it when the user desires to observe output.As SYS is a template for different formalisms, it is possibleto describe both models of the vessel example. In the ODEcase, the time base is continuous ( ). The transition func-tion is written in integral form. Different numerical approx-imations of the integral can be used in the implementationof an abstract simulator.

SYSODEVESSEL T X Ω Q δ Y λ

T X W φ ω : T XQ ! "#$ T l %δ : Ω Q Qδω ti t f T ti l ti &

Tti ('*) t f

ti

1lα W

α cρA φ

α T α + dα l

ti ('*) t f

tiφα dα

Y -, , , ,. is low is high is cold is hot λ : Q Y

Q T : Continuous T : Discrete T : / NOW 0Continuous DAE Difference Eqns. Algebraic Eqns.

Discrete Discrete-event FSA Integer Eqns.Naive Physics Petri Nets

Table 1: Formalism classification.

λT l l llow 1 l lhigh T Tcold T Thot

At a higher level of abstraction, we have represented timeas a discrete integer index. The transition function lists allpossible state transformations.

SYSFSAVESSEL T X Ω Q δ Y λ

T 32X 4 heat cool o f f 5 f ill empty closed ω : T XQ 4 cold Tbetween hot 6 empty lbetween f ull δ : Ω Q Qδ

o f f f ill 1 cold empty & cold lbetween δ

o f f f ill 1 cold lbetween & cold f ull δ

o f f f ill 1 cold f ull & cold f ull &...

δ

heat f ill hot f ull & hot f ull Y ., , , ,λ : Q YλT l l low 1 l high T cold T hot

Apart from the two causal, deterministic formalisms pre-sented above, a host of other formalisms are in use. Inparticular, through time-scale or parameter abstraction, re-ality is often represented by means of discrete-event mod-els. In these models, time evolves continuously (T ),but the state of the system only changes at a finite num-ber of points in time in a bounded time-interval. Thesetimes are called event-times. A number of discrete-eventformalisms, called world views were constructed. Worldviews range from Event Scheduling which expresses eventsand their consequences explicitly, focussing on the sim-ulation efficiency, over Activity Scanning and the ThreePhase Approach which emphasize changing conditions inthe system, to Process Interaction which represents the sys-tem in terms of interacting processes (Balci, 1988). Zeigler(Zeigler, 1984a) developed the DEVS discrete-event sys-tem specification. It allows other discrete-event formalismsto be expressed in terms of DEVS.

2.2 Formalism Classification

Formalism classification based on the general system modelstructure in Table 1 shows how different instantiations ofthat structure lead to different formalisms. For continuousmodels, classification according to physical domains such

M,S

M,S

M,S M,S

Q

M,S

Q

M,S

M,S M,S M,S

PaperPulp mill Waste Water Treatment Plant

Fish Farm

Effluent

Recycle (return) flow

Clarifier(DESS)

Activated sludge unit(DESS)

MixingAeration Sedimentation

Influent

Stormwater tank 1

Stormwater tank 2overflow

Switch

WWTP (DESS)

System of WWTP and Stormwater tanks (DEVS)

Input/Output function

Inputfunction

Outputfunction

algae

fish

GE

RRA

X

CFA

+

CFF

EDRF +

GFX

X

Figure 6: Complex system example.

as mechanical, electrical, and hydraulical, is meaningful.The variety of classifications leads to the insight that ulti-mately, one should picture a vast formalism-space and clas-sify that space according to various criteria. Different crite-ria will lead to different equivalence classes. The SYS timebase and state set allow for a high-level classification of for-malisms. Whithin the discrete-event realm, the world viewsprovide a further means of classification. Note how manylanguages and tools correspond to each single formalism.Though quite generic, the formalisms presented do not de-scribe non-causal models. When describing physical sys-tems, non-causal models describe conservation laws andconstraints without imposing a computational causality.Non-causal modelling formalisms and how they enablemeaningful model re-use are described in (Cellier, 1991).

3 MULTI-FORMALISM MODELLING

Complex systems are characterized, not only by a largenumber of components, but also by the diversity of the com-ponents. One of the observations of the European Com-mission’s ESPRIT Basic Research Working Group 8467(Vangheluwe and Vansteenkiste, 1996) “Simulation for theFuture: New Concepts, Tools and Applications” was thatfor the analysis and design of such complex systems, it isno longer sufficient to study the diverse components sepa-rately, using the specific formalisms these components weremodelled in. Rather, it is necessary to answer questionsabout properties –most notably behaviour– of the wholesystem. Also, to communicate knowledge about these sys-tems, one must deal with the diversity of the information.

3.1 A Complex System Example

To focus the attention, Figure 6 presents a complex system.

The complexity lies in the diversity of the different compo-nents, both in abstraction level and in formalism used:7 A paper and pulp mill produces paper from trees with

polluted water as a side-effect. This system is mod-elled as a process interaction discrete-event schedulingsystem (in particular, in GPSS (Gordon, 1996)).7 A Waste Water Treatment Plant (WWTP) purifies thepolluted effluent from the mill. Some solid waste istaken to a landfill. The partially purified water flowsinto a lake. This system is modelled using DifferentialAlgebraic Equations (DAEs) describing the biochem-ical reactions in the WWTP.7 A Fish Farm grows fish in the lake. The fish feed onalgae which are highly sensitive to polluted water. Thewater is also used for a tree plantation which suppliesthe paper mill. This eco-system is modelled using theForrester System Dynamics formalism. The dottedfeedback arrow from the fish farm to the paper mill in-dicates the possible disastrous impact of poisoned fishon the productivity of workers in the mill.

It is obvious that decision-making for this system will re-quire understanding of the behaviour of the overall system.Studying the individual components will not suffice. Thecomplexity of this system and its model is due to7 the number of interacting, coupled, concurrent com-

ponents. Complex behaviour is often a consequenceof a large number of feedback loops;7 the variety of component formalisms. Often, a mix ofsoftware and hardware, continuous and discrete com-ponents occurs;7 the variety of views, at different levels of abstraction.

A model of a system such as the one described abovemay be valid (within a particular experimental context) ata certain level of abstraction. This level of abstraction,which may be different for each of the components, is de-termined by the available knowledge, the questions to beanswered about the system’s behaviour, the required accu-racy of answers, etc. Orthogonal to the choice of modelabstraction level is the selection of suitable formalisms inwhich the models are described. The choice of formalismis related to the abstraction level, the amount of data thatcan be obtained to calibrate the model, the availability ofsolvers/simulators for that formalism, as well as to the kindof questions which need to be answered.

3.2 Forrester System Dynamics

To fully explain the model, we now present the semanticsof the Forrester System Dynamics (FSD) formalism. TheFSD formalism (Cellier, 1991) describes the variation ofmaterial-like quantities or levels. The variation is deter-mined by birth rates (BR) and death rates (DR). BR and DRare graphically represented as valves to the left and rightrespectively of boxes denoting the levels. Levels may in-fluence each other by influencing each other’s BR and DR.

Predator Prey

Grazing_efficiency

uptake_predatorloss_prey

predator_surplus_DR

prey_surplus_BR

2−species predator−prey system

Figure 7: Predator-prey, FSD formalims.

state trajectory data (observation frame)

DAE a-causal set

DAE causal set

DAE causal sequence (sorted)

Difference Equations

System Dynamics

Transfer Function

Figure 8: Formalism transformation.

The influences are given by algebraic functions. Figure 7shows a typical interaction between a predator and a prey.The (product) interaction between predator and prey pop-ulations influences the predator’s birth rate and the prey’sdeath rate. The System Dynamics semantics is given bymapping each of the level/BR/DR combinations onto an Or-dinary Differential Equation

d leveldt BR DR 8

The operations such as product and sum are mappedonto the appropriate algebraic equations and couplings aremapped onto algebraic equalities.Based on this relationship between the System Dynamicsand the ODE formalisms, translation of any model in thefirst formalism to the same model described in the secondformalism is possible. In practice, this implies that a com-piler can translate any model in the first formalism onto a(behaviourally equivalent) model in the second formalism.In Figure 8, a small part of “formalism space” is depicted inthe form of a Formalism Transformation Graph (FTG). Thedifferent formalisms described before are shown as nodesin the graph. The vertical striped line denotes the distinc-tion between continuous models (on the left) and discrete

models (on the right). The well known Difference Equa-tions formalism is often implicitly used in numerical sim-ulators: ODEs are discretised by means of a suitable nu-merical scheme and the resulting difference equations areiteratively solved. Suitable refers to the nature of the equa-tions as well as to the accuracy requirements. The arrowsdenote a homomorphic relationship “can be mapped onto”,implemented as a transformation between formalisms. Thevertical, dotted lines denote the existence of a solver or sim-ulation kernel which is capable of simulating a model, thusgenerating a trajectory. A trajectory is really a model ofthe system in the data formalism (time/value tuples). Ob-viously, the experimental frame of a trajectory is very lim-ited. In a denotational sense, traversing the graph makessemantics of models in formalisms explicit: the meaning ofa model/formalism is given by mapping it onto some knownformalism (whose meaning may in turn be given by map-ping it onto an even more basic formalism, etc. ). Though amulti-step mapping may seem cumbersome, it can be per-fectly and correctly performed by tools. The advantage ofthis approach is that the introduction of a new formalismonly requires the description of the mapping onto the near-est formalism as well as the implementation of this mappingin the form of a model translator. It is often meaningful tointroduce a new formalism for a specific application, encod-ing particular properties and constraints of the application.Often, translation involves some loss of information. Thisloss may be a blessing in disguise as it entails a reductionin complexity, hopefully leading to an increase in (simula-tion) performance. Usually, the aim of multi-step mappingis to eventually reach the trajectory level. Another majoruse for formalism transformation is the answering of partic-ular questions about the system. Some questions can onlybe answered in the context of a particular formalism. Incase of a FSD model for example, the visual inspection ofthe model can provide insight into influences. If the modelis mapped onto a set of Algebraic and Ordinary Differen-tial Equations, a dependency analysis may reveal algebraiccycles not apparent at the System Dynamics level. At thissame level, one may check whether parts of the model arelinear. If so, these parts may be solved symbolically bymeans of computer algebra. Also, transformation to theLaplace domain (i.e., to a Transfer Function form) leads toa plethora of techniques for stability analysis. Finally, thetransformation, through numerical simulation, to the datalevel, allows for quantitative analysis of problems posed ininitial value form.Note how the larger the number of intermediate formalismsbecomes, the higher the possibility for optimization alongthe way will be.Above all, the traversal described above is the basis for themeaningful coupling of models described in different for-malisms. This will be discussed next.

Msub_1 Msub_2

CoupledModel

CouplingGraph

Msub_3

Figure 9: Multi-formalism coupled model.

3.3 Coupled Model Transformation

Figure 9 shows a multi-formalism coupled model (the dif-ferent shades denote different formalisms). Models of thistype are said to belong to the network or coupled formal-ism. When we observe a structured model at this level, wecan only make meaningful assertions about its structure, itsoutside connections (its interface) and its components, notabout its overall meaning or behaviour ! Formally, a cou-pled model has the form

CM 9 id inter f ace S C The model is identified by a unique identifier id (for exam-ple, a name or reference). The inter f ace is a set of connec-tors or ports to the outside. Associated with the ports areallowed values as well as causality. Meaningful causalitiesare in out inout . The set S contains the sub-models (or atleast their unique identifiers). The coupling information iscontained in a graph structure C. For non-causal, continu-ous models, the graph is undirected. For causal models, thegraph is directed. Obviously, a coupled model is only validif types and causalities of connected ports are compatible.In certain cases, the graph may be annotated with extra in-formation. In case of discrete-event models, a tie-breakingfunction is usually required to select between simultaneousevents (Zeigler, 1984a).If all the sub-models are described in the same formalismF , it may be possible to (recursively, bottom-up, if the sub-models are coupled models in their own right) replace thecoupled model (at least conceptually) by one atomic modelof type F. In this case, F is called closed under cou-pling (or under composition). The closure property hasto be proven for each F . The property often holds byconstruction. In case of Differential Algebraic Equations(DAEs), connections connect

porti port j are replaced

by porti port j coupling equations. Together with thesub-models’ equations, these form a DAE. In formalismssuch as Bond Graphs, information about the physical na-ture of variables allows one to generate either the abovetype of equations in case of coupling of across variables(this corresponds to Kirchoff’s voltage law in electricity)and an equation summing all connected values to zero forthrough variables (this corresponds to Kirchoff’s current

law in electricity). In discrete-event models, implement-ing closure involves the correct time-ordered scheduling ofsub-model events. The most imminent event will always beprocessed first. The tie-breaking function is used to resolveconflicts due to simultaneous events (an artifact of the highlevel of abstraction).If a coupled model consists of sub-models expressed in dif-ferent formalisms, different approaches are possible:7 A super-formalism can be used which subsumes the

different formalisms of the sub-models. The differ-ent sub-models are thus described in the same for-malism. The Hybrid DAE (Vangheluwe, 2000) andDEVS&DESS (Zeigler et al., 2000) formalisms in-tegrate continous and discrete modelling constructs.Meaningful super-formalisms which truly add expres-siveness and reduce complexity are rare. Bond Graphs(Cellier, 1991) are a good example of the integrationof different domains (mechanical, electrical, hydrauli-cal).7 Another approach is to transform the different sub-models to one common formalism. Which formalismto transform to depends on the questions asked. Theclosest common formalism for the WWTP (DAE) andfish farm (System Dynamics) example is the DAE for-malism. By transforming the fish farm model to a setof DAEs, and using the closure property of the DAEformalism, it becomes possible to answer questionsabout the overall model. Often, the target formalismis the trajectory level.7 In the co-simulation approach, each of the sub-modelsis simulated with a formalism-specific simulator. In-teraction due to coupling is resolved at the trajectorylevel. Compared to transformation to a common for-malim before simulation, this approach, though ap-pealing from a software engineering point of view, dis-cards a variety of useful information. Questions canonly be answered at the trajectory level. Furthermore,there are obvious speed and numerical accuracy prob-lems for continuous formalisms (Foster and Yelmgren,1997). The approach is meaningful only for discrete-event formalisms. In this realm, it is the basis of theDoD High Level Architecture (HLA) for simulator in-teroperability.

The transformation to a common formalism mentionedabove proceeds as follows:

1. Start from a coupled multi-formalism model. Checkconsistency of this model (e.g., whether causalites andtypes of connected ports match).

2. Cluster all models described in the same formalism.

3. For each cluster, implement closure under coupling.

4. Look for the “best” common formalism in the Formal-ism Transformation Graph all the remaining different

formalisms can be transformed to. In the worst case,this will be the trajectory level in which case the ap-proach falls back to co-simulation. Which commonformalism is best depends on a quality metric whichcan take into account transformation speed, potentialfor optimization, etc. .

5. Transform all the sub-models to the common formal-ism.

6. Implement closure under coupling of the common for-malism.

Certain questions about a system can only be answered incertain formalisms, necessitating model transformation tothe appropriate formalism. A side-effect of mapping ontoa common formalism is the great potential for optimizationof the flattened model, as well as the reduced number of(optimized) simulation kernels needed. When models areused to communicate knowledge between humans or tools,the formalism used must be clearly and uniquely speci-fied. As described further on, meta-modelling allows forexplicit reasoning about often subtle differences betweenformalisms. This is achieved by explicitly modelling bothsyntax and semantics of formalisms.

3.4 The Formalism Transformation Graph

To describe which formalism transformation are possi-ble, the Formalism Transformation Graph (FTG) is used(Vangheluwe, 2000). As an example, the transformationscurrently known to the authors are shown in Figure 10. Theline at the bottom denotes the state trajectory formalism.In principle, this should be a single node, but a line wasused for aesthetic purposes. The vertical dashed line de-notes the crude division between continuous and discrete(-event) models. Vertical dashed arrows denote the existenceof a simulator which maps an abstract model onto a statetrajectory (given initial conditions, parameters, etc. ). It isnoted that iterative simulation can be seen as a special caseof model transformation.

4 META-MODELLING

A proven method to achieve flexibility for a modelling lan-guage to support many formalisms is to model the languageitself. This approach is demonstrated in, among others,the domain modelling environment (DOME) (Honeywell,1999; Engstrom and Kruger, 2000) and the multigraph ar-chitecture (MGA) (Karsai et al., 2000). To illustrate thisnotion, consider the state transition diagram in Figure 11 (inthe Deterministic Finite State Automata formalism). Whenin the ON state, a transition to the OFF state occurs whenthe condition t 2 becomes true and this generates an alarmaction. The state, transition, condition, and action elementsare part of any state transition diagram and their dependen-cies can be modelled as shown in Figure 12 (in the Entity-Relationship formalism). This model specifies a family ofstate transition diagrams where each instantiation has states

OFFONt > 2/alarm

Figure 11: A state transition diagram model.

Transition

1:1

1:1 1:11:N

1:1

1:N

Condition Action

State

a0:11:1

a

Figure 12: A model of state transition diagram models.

that are connected by transitions. Each state can have anynumber of outgoing transitions, indicated by the 1 : 1 and1 : N cardinality on the downward arrow in the figure, i.e.,each state can have between 1 and N transitions and eachtransition has to exit between 1 and 1 states (i.e., it has tobe connected to one and only one state), where N repre-sents any number. Each transition can enter only one stateand each state may have any number of entering transitionsindicated by the cardinality on the upward arrow. The tran-sitions between states have two attributes, one conditionthat allows the state transition to be taken and one optional(indicated by the 0 : 1 cardinality) action. The model inFigure 12 can be used to specify different state transitiondiagram formalisms, e.g., the action attribute can be mademandatory for each transition by changing the cardinalityfrom 0 : 1 to 1 : 1. Furthermore, actions can be associatedwith states as well.Such a model of the modelling language is called a meta-model. It prescribes the possible mathematical structures(formalisms) that can be expressed in the modelling lan-guage and can be tailored to specific needs of particulardomains. From the meta-model specification, the mod-elling language, graphical or textual, can then be instan-tiated automatically. This requires the meta-model mod-elling formalism to be sufficiently rich and support the con-structs needed to define a modelling language. To allow foreasy extension, the meta-model modelling formalism canbe modelled by a meta-meta-model. This meta-meta-modelspecification captures the basic elements that can be usedto design a meta-model modelling formalism. In case newconcepts and structures are required, these can be conve-niently modelled at a meta-meta-level.For example, the meta-model in Figure 12 is limited to thefamily of state transition diagrams. This restriction can beremoved by modelling the model of state transition dia-grams in Figure 12 by the meta-meta-model in Figure 13. Itcontains an abstract representation of the mechanisms thatare part of the state transition diagrams meta-model, i.e.,entities (states, transitions), attributes (actions and condi-tions), and relations between them. This meta-meta-modelgroups entities and relations by an object model componentand each of them optionally has any number of attributes.It also shows that each relation connects to one entity as

DEVS

Process Interaction Discrete Event

state trajectory data (observation frame)

Petri NetsStatecharts

scheduling-hybrid-DAE

Bond Graph a-causal

Bond Graph causal

DAE non-causal set

DAE causal set

PDE

Transfer Function

Difference Equations

System Dynamics

KTG Cellular Automata

Event Scheduling Discrete Event

3 Phase Approach Discrete Event

DAE causal sequence (sorted)

DEVS&DESS

Activity Scanning Discrete Event

Timed Automata

Figure 10: Formalism Transformation Graph.

1:1 0:N

0:N

src

dst

atr

1:1

0:N1:1

Relation

Object Attribute

Entity

Figure 13: A state transition diagram meta-meta-model.

its source (marked src) and one entity as its destination(marked dst), and, therefore, directed links can be used.The meta-meta-model specification language has to con-sist of entities, attributes to specify the cardinality and rela-tions to specify the three types, (i) source relations (src), (ii)destination relations (dst), and (iii) attribute relations (atr).Given the meta-meta-model in Figure 13, a broader fam-ily of meta-models can be described. For example, a Petrinet as illustrated in Figure 14 consists of places (shown astransparent circles) and transitions (shown as solid rectan-gles). Each place has connections to transitions and eachtransition to places. A transition may have a condition andwhen this condition is true and all its input places, i.e.,places that are the source to the transition, contain a token(shown as a black dot inside a place), it may fire (the corre-sponding transition may be executed). The Petri nets meta-model shown in Figure 15 specifies places and transitionsthat can connect to one another. Furthermore, the tokensare specified as optional attributes of a place and conditionsas an optional attribute of a transition. The family of Petrinets that can be instantiated from this meta-model allowsplaces with multiple tokens. However, in some modellingparadigms, only one token per place is allowed, which canbe conveniently changed in the meta-model by specifying

ON OFFt > 2

Figure 14: A Petri net model.

1:1

1:1 1:11:10:1

0:N

0:N

1:1

1:1 0:N

1:1

1:1

Transition

Connection

Condition

Token Placea

a

Figure 15: A model of Petri net models.

0 : 1 cardinality, and, consequently, constraining the fam-ily of Petri nets. Note that this represents both a static anddynamic constraint. When the Petri net is initialized, it canbe ensured by the model editor that each place has beenassigned at most one token. However, it is still necessaryto dynamically check whether this constraint is violatedduring execution. To be able to fully specify modellingformalisms, a meta-level formalism is often extended witha textual constraint language complementary to the oftengraphical base. This language can be used to rule out se-mantically incorrect models and greatly reduce the family

meta-metamodel

meta-modelprocessor

meta-modeluserinput

a model of a class of models (the formalism MF)semantics within formalism MMFdescribes: structure and constraints

a model in formalism MF

-create-delete-verify (local, global)

meta-modelprocessor model

userinput

a model of a class of models (the formalism F)semantics within formalism MFdescribes: structure and constraints

a model in formalism F

-create-delete-verify (local, global)

MMF

MF

F

(ER)

(ER)

(FSA)

Figure 16: Meta- ::&: models.

of models that can be modelled (Nordstrom, 1999). For ex-ample, a model of a family of Petri nets could include theconstraint that there should never be more than ten tokensin the net (to model a resources limit) by an additional spec-ification Token.allInstances->size < 10.The outlined meta-modelling approach leads to the layeredstructure in Table 2. The model row represents a particu-lar model such as the state transition diagram in Figure 11.At a meta-level, the meta-model row represents a class ofmodels (or formalism), e.g., the model of the family ofstate transition diagrams in Figure 12. This meta-model hasmeaning within a formalism which is specified by a meta-meta-model. This could be the model in Figure 13.The apparent advantage of this approach is the tremendousflexibility that can be achieved.This is manifested in the ease with which new formalismscan be designed. By adapting the model of a modellingformalism, and automatically generating a prototype of themodelling environment, design choices can be rapidly eval-uated.Figure 16 depicts how meta-models are models too. AnFSA model is constructed within the FSA formalism. In themeta-modelling approach, the FSA formalism is explicitlymodelled. The FSA formalism’s meta-model has meaningwithin the Entity-relationship formalism.

4.1 Meta-modelling Model Transformation

Upto now, only model syntax has been considered in meta-modelling. It is however above all necessary to describemodel semantics. At the core of this is the specification ofmodel transformation.Some of the manipulations we are interested in are:7 Formalism transformation: Given a model in a cer-

tain formalism, these transformations convert it intoa model, but expressed in another formalism. ForModelling and Simulation, possible transformationsare found in the Formalism Transformation Graph.

meta-model a model in formalism ER

meta-modelprocessor

model

userinput

a model of a class of models (the formalism NFA)semantics within formalism ER

a model in formalism NFA

-create-delete-verify (local, global)

MF

F

(ER)

(NFA)

meta-model a model in formalism MF

meta-modelprocessor

model

userinput

a model of a class of models (the formalism F)semantics within formalism MFdescribes: structure and constraints

a model in formalism FSA

-create-delete-verify (local, global)

MF

F

(ER)

(FSA)(multi-formalism)

model transformer=

meta-modelprocessor

transformationmeta-model

MF (GGR)

Figure 17: Model transformation meta-specification.

7 Model optimization: These transformations do notchange the formalism in which the model is expressed.Their application results in a reduction of model com-plexity.7 Code Generation: These transformations produce atextual representation of the model (subject to syntac-tic constraints) suitable for interpretation by a simula-tor.7 Simulator specification: These specifications give theoperational semantics of the model.

All these tasks depend on the formalisms of interest. How-ever, since models determined by some meta-model canalways be described as graphs (subject to the constraintsgiven by the meta-model), these tasks can be performedby a generic graph-transformation algorithm. Thereforeit makes sense to combine meta-modelling and graph-grammars (Dorr, 1995) in a unifying framework. Meta-models determine the classes of graphs that are allowed onthe LHS and RHS of a graph-grammar rule. Furthermore,the rules themselves, and the grammars, can be viewed asmodels in the graph-grammar (GGR) formalism, which it-self is described in a meta-model. This is depicted in Fig-ure 17. Graph Grammars are composed of rules, each map-ping a graph on the left-hand side (LHS) to a graph on theright-hand side (RHS). A graph-grammar is applied to aninput graph (called host graph) in order to perform a trans-formation. When a match is found between the LHS of arule and a part of the host graph, this subgraph is replacedby the RHS of the rule. Rules may also have a condition thatmust be satisfied for the rule to be applied, as well as actionsto be performed when the rule is executed. A rewriting sys-tem iteratively applies matching rules in the grammar to thegraph, until no more rules are applicable.On the one hand, the use of a model (in the form of a graphgrammar) of graph transformations has some advantagesover an implicit representation (embedding the transforma-tion computation in a program) (Blonstein et al., 1996):7 it is an abstract, declarative, high level representation,

and7 the theoretical foundations of graph rewriting systemsmay assist in proving correctness and convergenceproperties of the transformation tool.

Level Description Example

meta-meta-model Model used to specify Relation hasDestination Entitymodelling languages

meta-model Model used to specify models, State connectsTo Transitionan instantiation of a meta-meta-model

model The description of an object when t > 2 transition from ON to OFFin a specific formalism

Table 2: Three layer meta-modelling structure.

Q

R

::=

Q

R

P R

Copy output edges from nodes Q and R into node QRSet type of node QR to terminal if nodes Q or R are terminal

c/a

c/b

c/a b

Rule 1.

P Q ::= P PQ

Copy output edges from nodes P and Q into node PQ

c/a

c/bc/a b

Q

Rule 2.

P::=

If P has no input edges

c/aRule 3.

Set type of node PQ to terminal if nodes P or Q are terminal

P Q

Figure 18: NFA to DFA Graph Grammar.

On the other hand, the use of graph grammars is constrainedby efficiency. In the most general case, subgraph isomor-phism testing is NP-complete. However, the use of smallsubgraphs on the left hand side of graph grammar rules, aswell as using node labels and edge labels can greatly reducethe search space.As an example, Figure 18 gives the rules for transforminga non-deterministic finite state automaton (NFA) into anequivalent deterministic finite state automaton (DFA). Fig-ure 19 shows the application of this graph grammar to asimple NFA.It should be noted that the operational semantics of a for-malism may be expressed in the form of a graph grammarmodel. This, by encoding the formalism’s transition func-tion. As such, graph grammar application corresponds tosimulation. We can thus regard the graph grammar as anexecutable specification. This approach is desirable for itsgenerality, since it can be applied to a wide class of for-malisms. There is, however, a tradeoff made between gen-erality and efficiency. As a general rule, customized, hand-coded, formalism-specific simulation algorithms are moreefficient. The approach of relying on graph grammars is ex-pensive due to the nature of the graph matching algorithm.

A

B

C

D

c/a

c/b

A

B

D

C

c/a bd/e

d/f

g/h

d/e

g/h

d/ed/f

A

g/h

B

c/a bd/e

g/h

D

d/e

d/fBC

BC d/f

d/f

DBCA

d/f

c/a b

d/e

g/h

A BC AD

c/a b

g/h

d/e f

D

BC ADA

g/h

c/a b d/e f

1.

3.4.

5. 6.

rule 3

rule 1

rule 3

rule 1 rule 3

2.

Figure 19: NFA to FSA Transformation.

However, there are other motivations, both theoretical andpractical:7 Explicitly defining the operational semantics of any

formalism should be part of the design of a simulator.The specification is then the basis for any implemen-tation.7 The specification and its interpretation provide aframework (a reference implementation) for verifyingand testing different (hand-crafted, efficient) imple-mentations.7 It provides a portable simulator, since it is more ab-stract than a hand-coded implementation.7 It allows for reasoning about the described systems.For example, it allows for the definition of general al-gorithms for bisimulation.

5 CONCLUSIONS

We have presented a comprehensive overview of multi-paradigm Modelling and Simulation. The focus wason the concept of multi-formalism modelling of com-plex systems, and its relation to the semantics of mod-els. Furthermore, meta-modelling was presented as ameans of dealing with multiple formalisms. Currently,

the first two authors are developing AToM3, a meta-modelling environment. AToM3 uses graph grammars tospecify (at a meta-level), the transformations in the For-malism Transformation Graph. AToM3 can be found athttp://moncs.cs.mcgill.ca/MSDL/research/projects/AToM3.

ACKNOWLEDGEMENT

Prof. Vangheluwe gratefully acknowledges partial supportfor this work by a National Sciences and Engineering Re-search Council of Canada (NSERC) Individual ResearchGrant.

REFERENCESBalci, O. (1988). The implementation of four conceptual frame-

works for simulation modeling in high-level languages. InAbrams, M., Haigh, P., and Comfort, J., editors, Proceedingsof the 1988 Winter Simulation Conference, pages 287–295.Society for Computer Simulation International (SCS).

Balci, O. (1997). Principles of simulation model validation, verifi-cation, and testing. Transactions of the Society for ComputerSimulation International, 14(1):3–12. Special Issue: Princi-ples of Simulation.

Barros, F. J., Zeigler, B. P., and Fishwick, P. A. (1998). Mul-timodels and dynamic structure models: an integration ofDSDE/DEVS and OOPM. In Medeiros, D., Watson, E., andM.S., M., editors, Proceedings of the 1998 Winter Simula-tion Conference, pages 413–419. Society for Computer Sim-ulation International (SCS).

Blonstein, D., Fahmy, H., and Grbavec, A. (1996). Issues in thepractical use of graph rewriting.

Cellier, F. E. (1991). Continuous System Modeling. Springer-Verlag, New York.

Dorr, H. (1995). Efficient graph rewriting and its implementation.

Engstrom, E. and Kruger, J. (2000). A meta-modeler’s job isnever done: Building and evolving domain-specific toolswith DOME. In Varga, A., editor, IEEE International Sym-posium on Computer-Aided Control System Design, pages83–88. IEEE Computer Society Press. Anchorage, Alaska.

Foster, L. and Yelmgren, K. (1997). Accuracy in DoD HighLevel Architecture Federations. In Obaidat, M. S. and Ill-gen, J., editors, Summer Computer Simulation Conference(SCSC’97), pages 451–460. Society for Computer Simula-tion International (SCS). Arlington, Virginia.

Gordon, G. (1996). System Simulation. Prentice Hall of India,second edition.

Honeywell (1999). DOME guide.http://www.htc.honeywell.com/dome/, Honeywell Technol-ogy Center, Honeywell. version 5.2.1.

Karsai, G., Nordstrom, G., Ledeczi, A., and Sztipanovits, J.(2000). Specifying graphical modeling systems usingconstraint-based metamodels. In Varga, A., editor, IEEE In-ternational Symposium on Computer-Aided Control SystemDesign, pages 89–94. IEEE Computer Society Press. An-chorage, Alaska.

Magee, B. (1985). Popper. Fontana Press (An Imprint of Harper-Collins Publishers), London.

Nance, R. E. (1981). The time and state relationships in simulationmodeling. Communications of the ACM, 24(4):173–179.

Nordstrom, G. G. (1999). Metamodeling – Rapid Design andEvoluion of Domain-Specific Modeling Environments. PhDdissertation, Vanderbilt University, Electrical Engineering.

Rumbaugh, J., Jacobson, I., and Booch, G. (1999). The UnifiedModeling Language Reference Manual. Object TechnologySeries. Addison-Wesley.

Vangheluwe, H. L. (2000). DEVS as a common denominator formulti-formalism hybrid systems modelling. In Varga, A.,editor, IEEE International Symposium on Computer-AidedControl System Design, pages 129–134. IEEE Computer So-ciety Press. Anchorage, Alaska.

Vangheluwe, H. L., Kerckhoffs, E. J., and Vansteenkiste, G. C.(2001). Computer automated modelling of complex systems.In Kerckhoffs, E. J. and Snorek, M., editors, 15th EuropeanSimulation Multi-conference (ESM), pages 7–18. Society forComputer Simulation International (SCS). Prague, CzechRepublic.

Vangheluwe, H. L. and Vansteenkiste, G. C. (1996). SiE: Simula-tion for the Future. Simulation, 66(5):331 – 335.

Wymore, A. W. (1967). A Mathematical Theory of Systems Engi-neering – the Elements. Wiley Series on Systems Engineer-ing and Analysis. Wiley.

Zeigler, B. P. (1984a). Multifacetted Modelling and Discrete EventSimulation. Academic Press, London.

Zeigler, B. P. (1984b). Theory of Modelling and Simulation.Robert E. Krieger, Malabar, Florida.

Zeigler, B. P., Praehofer, H., and Kim, T. G. (2000). Theory ofModelling and Simulation: Integrating Discrete Event andContinuous Complex Dynamic Systems. Academic Press,second edition.