A Simulation Environment for Multimodeling*
Paul A. Fishwick
University of Florida
Abstract
Large scale systems are typically quite difficult to model. Hierarchical decom
position has proven to be one successful method in managing model complexity, by
refining model components into models of the same type as the lumped model. Many
systems, however, cannot be modeled using this approach since each abstraction level
is best defined using a different modeling technique. We present a multimodel ap
proach which overcomes this limitation, and we illustrate the technique using a fairly
simple scenario: boiling water. State and phase trajectories are presented along with
an implementation using the SimPack simulation toolkit. Multimodeling has provided
us with a mechanism for building models that are capable of producing answers over a
wide range of fidelity. [Key Words: Multimodeling, Process Abstraction, Combined
Simulation, Phase Transitions, Simulation Environment]
1 Introduction
Modeling "in the large" has always been a central topic in computer simulation. Ap
proaches in past work have concentrated on using functional coupling and hierarchical
decomposition to alleviate the problems associated with complex, cumbersome models.
These techniques have been partially successful but they have lead to the manifestation
of simulation languages and methodologies that grow to fit the needs of new applica
tions and extensions. Our approach multimodeling advocates the use of existing,
well known model types (such as Petri networks, automata, Markov models and block
models) within the same model structure: a multimodel.
Multimodeling [9, 7] is the process of engineering a model by combining different
model types to form an abstraction network or hierarchy. If we begin to understand a
physical system by creating a model, we often find that the model is too limited; the model
will answer only a very limited set of questions about system behavior. It is necessary, then,
to create many models and link them together, thereby maintaining a multilevel view of a
system while permitting an analyst to observe system output at several abstraction levels.
Even apparently simple physical systems can exhibit remarkly complex behavior in terms
of all models necessary to completely define the system. Consider a pot of boiling water
*The author is grateful for partial funding of this research through a grant from the Florida High
Technology Council. Author's Address: Paul A. Fishwick, Dept. of Computer and Information Sciences,
University of Florida, Bldg. CSE, Room 301, Gainesville, FL 32611
CIS TR93003 TBP: J. Discrete Event Dynamic Systems 2
Foam
Water
o
O Copper Pot
Heating Element
Figure 1: A pot of boiling water.
(see fig. 1). To model this system, we must first determine what questions we are likely to
ask of the system. Only then, can we proceed with creating an a priori assumption as to
system structure. If we are concentrating only on the temperature history of the water then
we might consider a simple linear system structure; however, we will run into trouble as
soon as we want to ask questions relating to what happens to the system in an exception
condition (overflow, underflow) or at a higher level of abstraction (heating,cooling). A
significant problem with single level models is that, not only do they attempt to answer
a narrow set of questions, but the models are made to be used only by a select number
of people. It would be convenient if we could create models that can provide answers
to children in an educational setting, as well as to scientists. To enlarge our class of
answerable questions, we must combine models together in some seamless fashion.
Recent simulation methodology has developed concepts to model complex systems
over multiple levels of abstraction [3, 4, 5]. Oren [14] defined a concept of multimodel to
formalize models containing several submodels, only one of which is put into effect at any
given time. The idea of a multimodel has its roots within the work in combined simulation
modeling. Combined modeling has traditionally referred to a integration of discrete
event and continuous modeling within the same system description. Pritsker [19, 20] first
implemented combined modeling in the GASP modeling language. Cellier [1] developed
an approach to combined continuous/discrete event models implemented in a GASP
language extension. Praehofer [18] extended the Discrete Event System Specification
(DEVS) [25] to provide a formalism and a simulation environment for specifying combined
continuous/discrete event models.
The previous research in combined modeling has fueled the study of multimodels, but
our approach to modeling is significantly different in that we build models for largescale
systems by employing those modeling techniques that have been proven useful for a
specific abstraction level. Instead of using only Petri nets or only automata, and then
extending these types (i.e., colored Petri nets, augmented automata), we mix and match
types to form a multimodel. We do not subscribe to the idea that, in order to model
ever increasingly complicated systems, one must continue to extend a singular modeling
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
approach. Instead, a blending of approaches is warranted. The multimodel approach
uses SimPack [6] tools depending on the model types present in the abstraction hierarchy.
SimPack is a collection of C and C++ libraries and executable programs for computer sim
ulation. In this collection, several different simulation algorithms are supported including
discrete event simulation, continuous simulation and multimodel simulation. The pur
pose of the SimPack toolkit is to provide the user with a set of utilities that illustrate the
basics of building a working simulation from a model description. Most simulation pack
ages cover one of two areas: discrete event or continuous. Discrete event methods cater
to those performing modeling of queuing networks, flexible manufacturing systems and
inventory practices. Continuous methods are normally associated with block diagram
methods for control and system engineering. Some available software can perform both
types of simulation; however, bulk support is usually available in only one form. Clas
sic discrete event simulation languages such as GPSS [21], SLAM [20], SIMSCRIPT [12]
and SIMAN [16] have been used extensively over the past decade, while continuous lan
guages such as CSMP, DESIRE [11] and continuous system language derivatives provide
adequate support for modeling continuous systems [2] in the form of block models.
As systems become large and complex, the analyst will require simulation software that
can support a wide variety of model types. One solution to modeling complex systems in
simulation languages is to convert all models into that language. Our approach is quite
different we recognize that, for instance, resource contention is best modeled with Petri
nets; queuing problems are best modeled with queuing graphs and some continuous
systems are best modeled with engineering block diagrams. Therefore, our approach is to
provide a set of C and C++ tools that accommodates a direct translation from these unique
graphing approaches into callable routines; we do not force the user to think in terms of
a single overall language for all simulation applications. Instead, we believe that most
systems will contain model components whose types are different. The perceived need
to have an "all in one" simulation language does not match most real world problems
where a set of welltested model types has developed naturally. The SimPack emphasis on
"diversity" in modeling makes it a natural candidate in which to construct multimodels.
We begin by introducing an example of boiling water. Section 2 outlines the use of
three automata levels, one continuous block model level and a small Petri net, to model the
boiling water process. In section 3, we formalize the algorithm associated with executing
multimodels using DEVS. Examples drawn from computer experiments on the boiling
water multimodel are illustrated in section 4, and section 5 presents conclusions and a
future direction for this work.
2 Example System: Boiling Water
2.1 Overview
Consider a pot of boiling water on a stovetop electric heating element. Initially, the pot
is filled to some predetermined level with water. A small amount of detergent is added
to simulate the foaming activity that occurs naturally when boiling certain foods. This
system has one input or control the temperature knob. The knob is considered to be in
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
one of two states: on or off (on is 190C; off is a ambient temperature). We make the
following assumptions in connection with this physical system:
1. The input (knob turning) can change at any time. The input trajectories are piecewise
continuous with two possible values (ON,OFF).
2. The liquid level (height) does not increase until the liquid starts to boil.
3. When the liquid starts to boil, a layer of foam increases in height until it either
overflows the pot or the knob is turned off.
4. The liquid level decreases during the boiling and overflow phases only.
To create a mathematical model, we must start with data and expert knowledge about
the domain. If enough data can be gathered in a cost effective way then our model
engineering process will be simplified since we will not have to rely solely on heuris
tics to identify the model. By analyzing a pot of boiling water we may derive simple
causal models whose individual transitions may be knob_on = water_getting_hotter or
water_getting_hotter = water_boiling. An important facet of system modeling is that we
choose certain modeling methods that require a categorization of informally specified sys
tem components. Key components of any system model are input, output, state, event, time
and parameter. Different modeling methods include these components in different ways.
For instance, an FSA focuses on statetostate transitions with input being labeled on each
arc. A dataflow model, on the other hand, focuses on the transfer function between input
and output.
To create models, we must review the purpose and goals of the simulation. We choose
to concentrate on temporal phase information so that we can answer questions of the
sort "What can happen immediately after the pot boils?" or "How long does it take
for the water to cool to room temperature if the knob is turned off when T = 90C?"
In the following sections, we discuss a stepwise refinement process to create multiple
models of the boiling water system. Our refinement procedure is shown in figure 2. The
hierarchy is representational in nature. We define a hierarchical organization since future
questionanswering about the system will be facilitated by maintaining such a structure.
Often, a question may require only the information present on a specific layer regardless of
whether some states in that layer represent lower level states; a "lumped" state by itself
can carry information in addition to the default information it carries by representing a
submodel. If we want to construct a second level abstraction of the total system, we take
the topmost FSA and include the second level FSA to form FSA2. Each level represents
a more detailed representation of a given state in the layer above.
2.2 Two Homogeneous Refinements
Homogeneous refinement is the refinement of a model to more detailed models of the
same type. For instance, consider a printed circuit board. There are many levels each of
which can be modeled using the same block formalism. The model is defined as having
type "block" just as a model might have type "Petri net" or "compartmental model." The
chip level of the PC board model will contain function blocks that are decomposed into
CIS TR93003 TBP: J. Discrete Event Dynamic Systems 5
2 State Automaton
Level 1 (FSA1)
refine
5 State Automaton
Level 2 (FSA2)
refine
6 State Automaton
Level 3 (FSA3)
refine
6 State Automaton with Block
Graphs m each State
Level 4 (COMBINED)
Figure 2: Model refinement procedure.
block networks. In this way, the modeller can build a hierarchy of models without having
to represent one model at the lowest abstraction/aggregation level.
Figure 3 displays three levels of finite state automata for the boiling water process.
The topmost FSA in fig. 3 displays a simple two state automaton with input. We label this
FSA level 1, or "FSA1." The input is discretized so that the knob control is either ON or
OFF. Input can occur at any time, and will facilitate a change in state. A change in input
is denoted by I = il on an arc in fig. 3 defining where the state transition is accomplished
when the input becomes il. If the knob is turned on while in state cold then the system
moves to state not cold. When temperature reaches the ambient temperature (denoted by
T = a) then the system returns to cold. The second level includes a detailed representation
of state "not Cold." By combining this new FSA with FSA1, we create FSA2 (a complete
model of the boiling process). FSA3 is constructed similarly.
Note that a transition condition may sometimes refer to a more detailed state specifica
tion than is available at the current level of abstraction. For example, the transition from
Exception to Boiling refers to the phase Overflow. In model building, such conditions
are evidence that further state refinement is necessary; however, the hierarchy is useful
not only for model building but also for facilitating questionanswering using a variety of
abstractions. Alternatively, the modeller may decide to terminate the refinement process
leaving the transition nondeterministically specified. The decision whether to continue
refinement should be based on the modeling objectives, the accuracy required, and the
computational resources available [22, 23].
2.3 Heterogeneous Refinement
Heterogeneous refinement takes homogeneous refinement a step further by loosening the
restriction of equivalent model types. For instance, we might have a Petri net at the high
abstraction level and we may choose to decompose each transition into a block graph so
CIS TR93003 TBP: J. Discrete Event Dynamic Systems 6
I=ON
not
I=OFF Cold CCld I= ON orI=OFF
T=a
............. ........................ '' ......
I=ON ..........
from r not Cold
T=100 (I=OFF and =Overflow
Heating
I=ON Boiling Hf = Ht xceptio
SI=N I=FF
I=FF
I=ON ..
to  Cooling 1 ...... I=ON,
Cold (I=OFF and
= Underflow)
T= =OFF =FF
T = ^ . . . . . ._. .._ . . . . . . . . . . 2 .
from
Boiling
Underflow Overflow I
S I=N or lO=FF
Figure 3: Homogeneous FSA refinement.FF
Figure 3: Homogeneous FSA refinement.
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
from
from
Cold to
I=ON Boiling
I=0 T=100
T(O)=a
F k T
I=ON
I=OFF
to
Cooling
Figure 4: Decomposition of heating state.
that when a transition fires within the Petri net, one may "drop down" into the functional
block level. For the last FSA in fig. 3 we choose to represent each state as a continuous
model. Specifically, each state will define how three state variables, T (temperature), Hw
(height of water), and H1 (height of foam on the top of the water) are updated. Also, the
parameter H, is the height of the pot. In all cases, Hf > H, and H,, Hf < Ht. The end
result will eventually be a multimodel that will be coordinated by FSA3.
The lowlevel continuous models Mi,..., M5 are defined as follows:1
1. (MI) COLD: T = a, H = 0, H = 0.
2. (M2) HEATING: T = ki(100 T), H = 0, Hf = 0.
3. (. ) COOLING: T = k2(a T), H, = 0, Hf = k3.
4. (M4) BOILING: T = 100, H = k4, = ks.
5. (Ms) OVERFLOW: same as BOILING with constraint Hf = Ht.
6. (. ,) UNDERFLOW: T = undefined, H, = Hf = 0.
The system phase is denoted by 4 and the state variables are:
T: temperature of water.
H,: height of the water.
1Models M2 and M3 exhibit first order exponential behaviors and are, therefore, rough approximations
of the actual boiling water system.
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
r4
p5
p2 s4 p4
FSA3
t2
FSA2
2
Figure 5: Petri net controller for three FSAs.
SHf: height of the foam.
Note that the continuous models share a common set of state variables. However, in
general, state variables may be different for each M, model.
There are also some constants such as H, for the height of top of pot, Hs for the starting
height of water when poured into the pot; and ki rate constants. The initial conditions are:
4 = cold, T(O) = a, H,(O) = Hf(O) = H and knob = OFF. By including the functional
block knowledge, we create one large model called COMBINED that is defined as FSA3
with each state containing a block model (as shown in fig. 4).
2.4 Petri Network Controller
Even though we have demonstrated an FSA controlled system with a heterogeneity af
forded by blending both FSA models with block control models, we may also incorporate
additional levels and model types. For instance, a new boiling water multimodel can
be created by starting with FSA3 as a primitive. Consider a scenario with two flasks
of liquid; when both of the liquids are boiling, a human operator takes each flask and
mixes the liquids into a separate container. For modeling the flasks, we can use two six
state FSA controllers which "drive" models Mi,..., ,,. as before. A five place Petri net
serves to codify the constraint that both liquids must boil before the operator performs the
separate function of mixing the liquids into another container. We use an extended Petri
net in that 1) tokens can have attributes (i.e., have a color), 2) the net can accept a discrete
input signal from outside the system (i.e., external events can occur), and 3) transitions
can take an arbitrary amount of time (stochastic, timed network). Figure 5 shows a Petri
net controller for this purpose. The Petri net, PN, is defined as follows [17]:
PNET =< P,T,I,O >
* P ={i, ,
FSA
CIS TR93003 TBP: J. Discrete Event Dynamic Systems 9
FSA1
from pil H top3
FSA
2
from p2 ( top4
FSA
3 /300,01,10
fromp3 00,01
00,01
11 MIX 10,11 top5
INIT END
(At)
fromp4
Figure 6: Three FSAs: two vessels and the operator.
T= {t,t2, 3
I: T P
O: T P
S: pP Z+, fori e {1,...,5},p(p) = 0
SI(tl)= {p}, I(12)= {P},I(3)= {P3, P4
O(tl) {P3}, O(2)= {P4}, O(t3)= {5}
Initially, the Petri net is in state (,0, 0, 0, 0,), meaning that there are no markers in any of the
five places. There are two inputs to the Petri net: I, and I2. These inputs represent discrete
signals with values of either ON or OFF representing the state of the knob controlling
the temperature. The two places, pi and p2, accept a discretely sampled input signal from
outside the system; tokens will have one of two possible attributes corresponding to ON
and OFF. A heterogeneous refinement of the Petri net specifies that transitions tj and t2
refine to FSA1 and FSA2, respectively. In this way, the input to the Petri net corresponds
directly to the input signal for FSA1 and FSA2. Likewise, transition t3 is refined into
another FSA (FSA3) which defines the states of the human operator: initial state (INIT),
state of mixing the two liquids (MIX), and a final state (END). We specify an arbitrary
amount of time for the second, mixing, state where the time lapse (At) is sampled from a
normal probability distribution, for instance. Figure 6 displays FSA1, FSA2, and FSA3.
Let the state spaces for FSA1 and FSA2 be {ri,..., r6} and {si,..., s6} respectively. When
the state of FSA1 is r4 and the state of FSA2 is 54 then both liquids are in a boiling state.
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
The input to each FSA is a knob controlling the desired temperature, and the output from
each FSA (designating the current FSA state at any given time) is determined as follows:
When an FSA is in the boiling state, output a token, otherwise do not output anything. This
policy is illustrated, on fig. 5 by attaching the FSA state names (r4,s4) next to the relevant
transitions (1t, 12).
Now, we are in a position to describe the multimodel execution for the Petri net
controller. The Petri net is controlled by the knob input, which produces colored tokens
into places pi (for knob 1) and p2 (for knob 2). There are two colors : ON and OFF. As
this discrete signal is passed to a transition, the transition "fires." Transition firing, for
a Petri net controller, means that the systems drops down an abstraction level to both
FSAI and FSA2 in parallel. The input signals continue to drive each FSA moving it from
state to state. Each FSA state is further refined into a continuous block model which was
illustrated in section 2.3. A combination of internal and external events causes a change
in FSA state. Neither FSA produces an output until it enters the boiling state: r4 for
FSA1 and s4 for FSA2. At this time, a token is produced and is put in places p3 and p4,
depending on which flask is boiling. When both flasks are boiling, there will be tokens
in p3 and p4, causing 13 to fire. Since 13 is further refined into FSA3, we execute FSA3 to
simulate the action of the human operator in this case, we model the operator by the
amount of time spent mixing the liquids. The token produced by 13 is realized by FSA3
as an input value of 11 (representing tokens in both p3 and p4) which causes an internal
state transition to the mixing state (MIX) of FSA3. The mixing takes place for At and
then the multimodel simulation ends.
3 DEVS Representation of FSAControlled Multimodels
To better understand the operation of the FSAcontroller part of the multimodel simula
tion, we present a formalization using DEVS. An FSAcontrolled multimodel is specified
by a structure < FSA, MODELS, map, TRANSITIONS >, where
FSA is a finite state automaton whose states are called phases. The input induced
transitions, (phase, input)  phase, form the external events of the multimodel.
MODELS is a set of models, .1, each being specified as a system in the general
formalism given earlier.
map is a mapping from the states of FSA to MODELS; thus, each phase is assigned
a model e MODELS which is intended to be the one and only active model when
the multimodel is in that phase.
TRANSITIONS is a set of conditions, potentially one for each transition (pair of
phases) in the FSA. These form the internal transitions of the multimodel. Formally,
a transition condition associated with a phase is a predicate on the state set of the
model associated with that phase by map.
We can present the set of models for boiling water as an FSAcontrolled multimodel.
Our first step will be to transform the hierarchical system structure into a "flat" structure
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
IOFF
I=ONFF
TnN ,^ .  ^  ^
Heating T=100
M2 Boiling Overflow
ICold =NM4 CM5 I=ON
I=0FF Hw=0
M3 nderflow
M6 Hw=0
T a Hw 0
IOFF
I=ON or IOFF
Figure 7: Six state automaton controller for boiling water multimodel (FSA3).
by collapsing the hierarchy. Using the phase graph notation we create the graph in figure 7
by compressing the three levels in fig. 3 into a single level graph. This graph provides the
FSA coordinator for the multimodel. The input induced (external) transitions are shown
as solid arcs of the FSA. MODELS is the set of continuous models M1...5 given earlier; map
is shown as the labeling of the phases with elements from MODELS; TRANSITIONS
is shown as the set of conditions attached to the dotted arcs in fig. 7.
Even though classical system theory [10, 15] provides strong definitions for individual
systems and system networks there is little concentration on the concept of an "event."
Events were not critical to the study of systems within the classical theory. Simulation
researchers such as Zeigler [22] and Nance [13] extended the classical theory to formally
specify discrete event models and the roles of events, state and time within simulation
models. We now present a brief review of the resulting DEVS formalism as a prelude to
mapping the FSAcontrolled multimodel into a DEVS equivalent [22].
Time, in discrete event systems, is assumed to be realvalued (T = 7). The DEVS
structure [24] < U, Y, S, A, A, ta > is as follows:
U is the input event set.
Y is the output set.
S is the sequential state set.
Sx,, Q x U S is the external transition function. Q = {(s, e)s e S, 0 < e < ta(s)} is
the total state set of the model; (s, e) represents the state of having been in sequential
state s for an elapsed time e.
6,t : S  S is the internal transition function.
A : S Y is the output function.
ta : S 7 TI' is the time advance function.
The DEVS formalism, as stated in its title (Discrete Event System Specifica
tion), is a shorthand means for specifying a general system as formalized ear
lier. We can think of it pictorially as a box containing some process. This box
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
accepts inputs and produces outputs. We map an FSAcontrolled multimodel <
FSA, MODELS, map, TRANSITIONS > into a DEVS equivalent as follows. Let the
DEVS be defined as < U, Y, S, 6, A, ta >, where:
U is the input set of the FSA.
Y is the output set of the FSA (not of interest here).
QM = T x H, x Hf. QM is the common state set of MODELS.
S = P x QM where P is the set of phases of the FSA. Note that a typical element
of S is (p, q) where p is a phase and q is a state in QM. Also, a typical element of the
total state set of Q is ((p, q), e).
Se : Q x U  S is defined by:
Set((p, q), e, u) = (fsa(p, u), SM (p)(q, e))
where fsa(p, u) is the the phase into which the FSA enters when it receives an
input u in phase p, and SM(p) is the transition function of M(p), the model associated
with phase p by map. This formalizes our earlier interpretation: when the FSA
receives an input it immediately switches phases and the state of the multimodel is
updated to the state corresponding to an elapsed time of e using the model that was
in control during that time.
To define ta, we recall that a set of transition conditions is associated with a given
phase p. Let C,_>,, be the condition for an internal transition from p to pi. Let Tp_>p,
be the time at which C,_>p, first becomes true when M(p) starts in state q. Tp_>p, is the
minimum time t such that C,>p,/(6M(p)(q, t)) is true.2 Now, ta(p, q) is the minimum
of the Tp_>p,, where pl ranges over the transitions C,,p, in TRANSITIONS. Note
that this minimum could be oo when none of the conditions is satisfied along the
state trajectory starting from q in model M(p).
S nt : S S is defined by:
6sit(p,q) = (p*, 6m(p)(q, e))
where p* is the phase dictated by the winning condition, i.e., the phase pl such
Tp_>p, is equal to ta(p, q).3
A : S  Y, the output function, can be defined in terms of the output of the currently
active submodel, but is not of interest here.
In the preceding formulation of an FSAcontrolled multimodel, the phases (i.e., states)
of the FSA are mapped to MODELS. Often, however, it is possible to provide a more
concrete representation of the phases by associating them with subsets of states in the
2We assume that such a minimum is welldefined, as it will be for continuous systems.
3Applying the tiebreaking rules if necessary.
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
T
Ht Ht
Figure 8: Continuous state space for boiling water system.
common state space, QM, of the MODELS. Since the input u participates in determining
the next phase, both input and phase jointly determine partitions of QM in which the
partition blocks are placed into correspondence with the phases.
Figure 8 displays the common three dimensional state space (T, Hw, Hf) for MODELS,
and figure 9 illustrates each phase by a shaded region of state space. Table 1 provides the
formal correspondence of phases and input values with partition blocks. Let 7 (u, p) be the
partition block corresponding to the pair (u, p) where u is an input value and p is a phase.
The mapping 7 can be viewed as the labeling of partition blocks by inputphase pairs. In
this case, the internal event transitions can be expressed in terms of boundary crossings
of partition blocks. This means that a condition of the form C,,,, can be written as the
membership of a state in the partition block 7 (u, pl) where u is the input prevailing in phase
p.4 For example, in the boiling water example, the transition condition CHEATINGBOILING
under the input I = ON is specified by the entry for (BOILING, ON) in table 1. This
transition corresponds to reaching the boundary given by plane T = 100 in figure 9(c).
Our discussion of phase space partitioning applies equally as well to the Petri net
controller presented in section 2.4. Recall that each state of the FSA controller represents
a partition of lower level state space. Now consider the Petri net which coordinates the
two FSAs: each state in the Petri net represents a partition of the state space formed as a
cross product of the state spaces of FSA1 and FSA2. PN state (1, 1, 0) maps to a point,
(r4, 54), in the lower level state space product. A PN state such as (0, 1, 0) (meaning that
FSA2 is in the boiling state) maps to the region of lower level state space defined by the
set {(ri, .4),(r2, S4),(r3? S4),(r'5, 54), (r6, 54)}.
In our simplified formalization of section 3.5, the prevailing input u is assumed to be stored in the state,
q. A more detailed formalization would make it an explicit component of q.
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
T
I OFF 100
(a) Heating phase
(b) Cooling phase
T
I = ON or OFF ,
innl
HJ
Hw
(c) Boiling phase
(d) Cold phase
T
(e) Underflow phase
(f) Overflow phase
Figure 9: Phase partitions.
T
I ON 100
It
Hf
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
Table 1: Partitioning of boiling water state space.
4 Multimodel Simulation
We constructed a multilevel simulation in C that permits an execution of an FSA
controlled multimodel. For the boiling water example, there are four abstraction levels:
three FSAs and one level containing six sets of equations (or block models). Our approach
was to encode the model, as input to the simulator, as follows:
1. Output Type (1 digit). The type of output: 1) output the state variable time trajectory
specified in Output Value, 2) output the state trajectory for the abstraction level
specified in Output Value, 3) output the input state trajectory, and 4) output a phase
trajectory.
2. Output Value (1 digit). Used in conjunction with the Object Type.
3. Number of States. The number of states in the lowest FSA level.
4. External FSA Transition Table (1 line per state). The lowest level FSA (level 3 for
boiling water) transition function for external events. There are as many columns as
there are possible input values.
5. Internal FSA Transition Table (1 line per state). The lowest level FSA transition function
for internal events. Each internal event is associated with a condition and there is an
integer value assigned to each condition. For instance, condition T = 100 is assigned
the value 2.
6. FSA Abstractions. The number of FSA abstraction levels (3 for boiling water).
Phase I T H,' Hf
COLD ON p p
COLD OFF = a > OA< Ht > OA< Ht
HEATING ON > aA < 100 > OA < Ht > OA < Ht
HEATING OFF
COOLING ON
COOLING OFF > aA < 100 > OA < Ht > OA < Ht
BOILING ON = 100 > OA < Ht > OA < Ht
BOILING OFF = 100 > OA < Ht > OA < Ht
OVERFLOW ON = 100 > OA < Ht = Ht
OVERFLOW OFF p
UNDERFLOW ON =0 =0
UNDERFLOW OFF =0 =0
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
7. Abstraction Mapping Table (1 line per level). This contains the mapping from lower
level to higher level FSA states so that state/phase output can be provided at any
level during the simulation run.
Phases are labeled: 1: cold, 2: heating, 3: cooling, 4: boiling, 5: overflow, 6: underflow;
and depending on the abstraction level, there are two other assignments: 2: not cold (for
level 1) and 5: exception for level 2. Conditions are assigned: 1) T = a, 2) T = 100,
3) Hw = 0, 4) Hf = Ht. Given these assignments, the multimodel simulator is executed
with the data file watere. in) below within Unix as follows: water < water. in
> bwater.out.
2 3
6
2 2
4 5
4 5
File water. out contains coordinate values for an individual run based on the input file.
Figures 10 through 13 display the following:
Figure 10: input trajectory; turning the knob on and off over some time period. This
was chosen at random to display phase switching.
Figure 11: temperature trajectory (T vs. time). Note that the temperature rises to
T = 100 (in a first order lag) in response to the step input and then it falls before
reaching the ambient temperature of T = 20. The temperature levels off at T = 100.
The temperature is undefined when the phase changes to an overflow condition just
prior to t = 20.
Figure 12: water height trajectory (H, vs. time). The height of the water starts at 5
and then moves down using a constant slope, with steps, until it reaches a zero level
indicating an underflow condition.
* Figure 13: foam height trajectory (Hf vs. time).
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
10.0
20.0
Time
Figure 10: Knob input.
10.0 20.0
Time
Figure 11: Water Temperature (T).
ON
OFF
30.0
120.0
100.0
80.0
60.0
40.0
20.0
0.0
30.0
_Y I _
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
5.0
4.0
S3.0
o
S2.0
'o
1.0
0.0
0.0
10.0 20.0
Time
Foam Height (Hf).
Figure 13:
10.0 20.0
Time
Figure 12: Water Height (Hw).
5.0
4g
0
4.0
3.0 L
0.0
30.0
30.0
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
NOT COLD
COLD
0.0 10.0 20.0 30.0
Time
Figure 14: FSA1 phase trajectory.
Figure 14 indicates a phase trajectory for abstraction level one (FSA 1). The behavior at this
high level is simple: the system moves from state cold to not cold when the temperature
increases as a result of the step input from the knob. There is no return to phase cold
since the water evaporates completely before the temperature can be reduced. Figure 15
displays the phases present in level 3 (FSA3); from this plot we obtain a qualitative
explanation of how the system behaves.
5 Conclusions
We have used a system of boiling water to demonstrate how to create a multimodel
containing three distinct types of models: 1) Petri net controller, 2) FSA controller, and
3) block. This demonstrates that models for complex systems can be constructed from
networks of different model types. We found that by utilizing heterogeneous interlevel
coupling, and homomorphic behavior preservation, we were able to create a solution to
the problem of using only a single level model. With the multimodel, we can answer
questions from "Why did the water start to boil?" to "How long will cooling take if the
knob is turned off at time X?" In a bottomup approach to multimodel design, we divided
up the total boiling water process into distinct phases. Coordination of models for these
phases was facilitated by the phase graph associated with the FSA at the final level of
abstraction. Additionally, we extended the "single vessel system" to include two vessels
containing liquid, where an operation was performed when the liquid in both vessels
entered a boiling phase. In addition, a DEVS specification was provided to formalize
the multimodel concept in a system theoretic manner. The SimPack software toolkit
served as a good base for multimodeling since it contains the basic elements present in
various wellknown and often used models such as Petri nets, block models and
automata. A Cbased boiling water simulation was created using the SimPack tools and
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
UNDERFLOX
OVERFLOW
BOILING
COOLING
HEATING
COLD
10.0 20.0
Time
Figure 15: FSA3 phase trajectory.
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
was demonstrated in section 4. SimPack is available and may be freely obtained by
contacting the author. An accompanying text, including SimPack and multimodeling
examples is nearing completion [8].
Although we have demonstrated our multimodel approach on the system of boiling
water, we believe our method to be applicable to many more scenarios where different
levels of abstraction are coded in the model form most appropriate for those levels. The
problem of semiautomating the process of taking a conceptual, nonexecutable object
based model of the system and converting it into an executable model remains a very
hard problem, and while we have not completely solve the problem, we believe the
multimodel approach to contain inherent solutions to a wider class of dynamic systems
problems. For future work, we plan on making it easier for SimPack users to graphically
construct multimodels using a window environment.
References
[1] Francois E. Cellier. Combined Continuous System Simulation by Use of Digital Computers:
Techniques and Tools. PhD thesis, Swiss Federal Institute of Technology Zurich, 1979.
[2] Francois E. Cellier. Continuous System Modeling. Springer Verlag, 1991.
[3] Paul A. Fishwick. Hierarchical Reasoning: Simulating Complex Processes over Multiple
Levels of Abstraction. PhD thesis, University of Pennsylvania, 1986.
[4] Paul A. Fishwick. The Role of Process Abstraction in Simulation. IEEE Transactions
on Systems, Man and Cybernetics, 18(1):18 39, January/February 1988.
[5] Paul A. Fishwick. Abstraction Level Traversal in Hierarchical Modeling. In Bernard. P.
Zeigler, Maurice Elzas, and Tuncer Oren, editors, Modelling and Simulation Methodol
ogy: Knowledge Systems Paradigms, pages 393 429. Elsevier North Holland, 1989.
[6] Paul A. Fishwick. SimPack: Getting Started with Simulation Programming in C and
C++. In 1992 Winter Simulation Conference, pages 154 162, Arlington, VA, December
1992.
[7] Paul A. Fishwick. An Integrated Approach to System Modelling using a Synthesis
of Artificial Intelligence, Software Engineering and Simulation Methodologies. ACM
Transactions on Modeling and Computer Simulation, 2 (3), 1993.
[8] Paul A. Fishwick. Simulation Model Design and Execution: Building Digital Worlds.
Prentice Hall, 1993. (to be published as a textbook).
[9] Paul A. Fishwick and Bernard P. Zeigler. A Multimodel Methodology for Qualitative
Model Engineering. ACM Transactions on Modeling and Computer Simulation, 2(1):52 
81, 1992.
[10] R. E. Kalman, P. L. Falb, and M. A. Arbib. Topics in Mathematical Systems Theory.
McGrawHill, New York, 1962.
CIS TR93003 TBP: J. Discrete Event Dynamic Systems
[11] Granino A. Korn. Interactive Dynamic System Simulation. McGraw Hill, 1989.
[12] H. M. Markowitz, P. J. Kiviat, and R. Villaneuva. Simscript 11.5 Programming Language.
CACI, Inc., Los Angeles, CA, 1987.
[13] Richard E. Nance. The Time and State Relationships in Simulation Modeling. Com
munications of the ACM, 24(4):173 179, April 1981.
[14] Tuncer I. Oren. Dynamic Templates and Semantic Rules for Simulation Advisors
and Certifiers. In Paul Fishwick and Richard Modjeski, editors, Knowledge Based
Simulation: Methodology and Application, pages 53 76. Springer Verlag, 1991.
[15] Louis Padulo and Michael A. Arbib. Systems Theory: A Unified State Space Approach
to Continuous and Discrete Systems. W. B. Saunders, Philadelphia, PA, 1974.
[16] C. D. Pegden, R. P. Sadowski, and R. E. Shannon. Introduction to Simulation using
SIMAN. Systems Modeling Corporation, Sewickley, PA., 1990.
[17] James L. Peterson. Petri Net Theory and the Modeling of Systems. PrenticeHall, Inc.,
Englewood Cliffs, N.J., 1981.
[18] Herbert Praehofer. Systems Theoretic Formalisms for Combined Discrete Continuous
System Simulation. International Journal of General Systems, 19(3):219240, 1991.
[19] A. A. B. Pritsker. The GASP IV Simulation Language. John Wiley and Sons, 1974.
[20] A. A. B. Pritsker. Introduction to Simulation and SLAMII. Halsted Press, 1986.
[21] Thomas J. Schriber. An Introduction to Simulation using GPSS/H. John Wiley, 1991.
[22] Bernard P. Zeigler. Theory of Modelling and Simulation. John Wiley and Sons, 1976.
[23] Bernard P. Zeigler. MultiFacetted Modelling and Discrete Event Simulation. Academic
Press, 1984.
[24] Bernard P. Zeigler. DEVS Representation of Dynamical Systems: EventBased Intel
ligent Control. Proceedings of the IEEE, 77(1):72 80, January 1989.
[25] Bernard P. Zeigler. Object Oriented Simulation with Hierarchical, Modular Models: Intel
ligent Agents and Endomorphic Systems. Academic Press, 1990.
