Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: A multimodel methodology for qualitative model engineering
Full Citation
Permanent Link:
 Material Information
Title: A multimodel methodology for qualitative model engineering
Alternate Title: Department of Computer and Information Science and Engineering Technical Report
Physical Description: Book
Language: English
Creator: Fishwick, Paul A.
Zeigler, Bernard P.
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 1991
 Record Information
Bibliographic ID: UF00095052
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

199011 ( PDF )

Full Text

A Multimodel Methodology for Qualitative Model


Paul A. Fishwick
University of Florida
Bernard P. Zeigler
University of Arizona

Qualitative models arising in the artificial intelligence domain often concern real
systems that are difficult to represent with traditional means. However, some promise
for dealing with such systems is offered by research in simulation methodology. Such
research produces models that combine both continuous and discrete event formalisms.
Nevertheless, the aims and approaches of the AI and the simulation communities re-
main rather mutually ill-understood. Consequently, there is a need to bridge theory
and methodology in order to have a uniform language when either analyzing or rea-
soning about physical systems. This article introduces a methodology and formalism
for developing multiple, cooperative models of physical systems of the type studied in
qualitative physics. The formalism combines discrete event and continuous models and
offers an approach to building intelligent machines capable of physical modeling and

Categories and Subject Descriptors: 1.2.4 [Artificial Intelligence] Knowledge Repre-
sentation Formalisms and Methods representations; 1.6.1 [Simulation and Model-
ing] Simulation Theory model classification, systems theory; 1.6.5 [Simulation and
Modeling] Model Development modeling methodologies. 1.6.8 [Simulation and
Modeling] Types of Simulation combined, discrete event, continuous.
General Terms: Combined Simulation, Systems Theory, Qualitative Simulation.
Additional Key Words and Phrases: Multimodeling, Abstraction Levels, Homomor-
*One author (Fishwick) is grateful for partial funding of this research through grants from the National
Science Foundation IRI-8909152 and the Florida High Technology and Industry Council UPN 911 '-'".-'i The
other author (Zeigler) acknowledges the support of NASA Grant "A Simulation Environment for Laboratory
Management by Robotic Organizations." Author's Addresses: Paul A. Fishwick, Dept. of Computer and
Information Sciences, University of Florida, Bldg. CSE, Room 301, Gainesville, FL 32611; Bernard P.
Zeigler, Dept. of Electrical and Computer Engineering, University of Arizona, Tucson, AZ .".;-'L.

Table 1: AI/Simulation terminology.

Artificial Intelligence Simulation
Process System
Envisionment Reachability
Landmark Discrete Event
Ontology Model Specification

1 Introduction

Humans appear to use qualitative models when answering questions such as "What happens
after the pot of water heats up?" or "What caused the water to overflow the pot?" Whether
they actually do use qualitative models is not something that we will address in this paper.
We will address, instead, the relationship between qualitative and quantitative modeling from
the perspective of systems and simulation theory and methodology [13, 14]. This work was
prompted by two needs: (1) a need to bridge gaps between the artificial intelligence (AI)
and simulation communities' representations of system models, and (2) a need to derive
more formal approaches to the development of models for systems typically studied by AI
qualitative modellers. With respect to the AI and simulation communities, both groups
have terminology that is very similar in focus. For instance, an "envisionment" [5] would
be termed a "reachability tree" or "finite state automaton" in the systems literature, and a
"landmark" [21] would be termed a "discrete event." There are many other correlations; we
name four of them in table 1. A more complete discussion of the commonalities and points of
controversy is given by Fishwick and Zeigler [15]. In any event, there are enough similarities
in the goals of AI and simulation research to contend that methods in simulation modeling
can play a strong role in AI.
There has been a considerable amount of research performed in the AI sub-disciplines of
qualitative reasoning [3, 39] and simulation [21], qualitative physics [17] and model based
reasoning [34]. The chief problems being addressed by AI researchers in qualitative simula-
tion, for instance, revolve around reducing the explosive number of states obtained during
envisionment [22, 36] by applying more constraints. The explosion is a result of having a
model whose structure and parameters are too ill-defined. Simulation researchers have dealt
with fuzzy parameters [10, 9]; however, there has been little simulation research into the
problem of studying systems whose structural rather than parametric constraints are
uncertain (i.e., not knowing whether two states are joined in the structure of a finite state
AI researchers have also performed substantial research in modeling qualitative behav-
ior at different abstraction and .,.--. -.-., ion levels [37, 38, 2]. It is this latter interest with
which we are most concerned. We use an example from recent AI literature to demonstrate
how certain simulation methods can be reoriented and extended to help AI modellers to-
ward their goals. Consider a paper by Forbus [16] which presents a comprehensive overview
of the field of qualitative physics. Forbus notes that "some device ontologies are unnatu-



Copper Pot

- Heating Element

Figure 1: A pot of boiling water.

ral." For instance, it is difficult to model a pot of boiling water (see fig. 1) or a bouncing
ball when expressed within system dynamics. Although system dynamics [35] is inadequate
for representing systems containing phase transitions and complicated boundary conditions,
simulation methodology developed concepts to model complex systems over multiple levels
of abstraction [6, 7, 8]. Oren j-"] developed a concept of multimodel to formalize mod-
els 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 con-
tinuous modeling within the same system description. Pritsker [31, 32] first implemented
combined modeling in the GASP modeling language. Cellier [4] developed an approach to
combined continuous/discrete event models implemented in a GASP language extension.
Praehofer [30] extended the Discrete Event System Specification (DEVS) [45] to provide a
formalism and a simulation environment for specifying combined continuous/discrete event
models. In this article, we build on these developments by providing a methodology and
formalism for developing multiple, cooperative models of physical systems of the type stud-
ied in qualitative physics. The formalism should help to build intelligent machines capable
of physical modeling and reasoning. Our approach has similar goals to the work of Forbus
and Falkenheiner in their SIMGEN [17] system and the work of Addanki et al. [1] in their
graphs of models approach to supporting multiple models. Our work is similar in that we
build multiple models that can fit together to aid in question-answering at different levels.
Our method differs from the AI work in two fundamental ways: (1) our models are based on
the canonical systems definition (described in the next section), and (2) we place a strong
emphasis on behavior preservation among models during a traversal. Using the canonical
model definition as a base permits us to specify many varieties of models from Petri nets
to cellular automata; most system models in systems theory [29, 18] and science [19] are
predicated on the canonical formulation. The emphasis on behavior preservation through
homomorphic mapping insures maximal consistency when dynamically mapping between
abstraction levels.
We will use the system of boiling water to illustrate our methods. Although at first

glance, it appears too simplistic, the boiling water system is appropriate for demonstrating
a wide range of discrete and continuous behaviors as well as levels of abstraction. Let's
consider some questions that we might ask an intelligent system (such as an autonomous
robot) about systems that relate to heat transfer:

"How hot is the water?" We see that our robot must first understand natural language
which poses many difficulties for complete autonomy. In answering this question we
must incorporate intensional and contextual knowledge. If the question is asked within
the home (i.e., a pot of hot water), then the robot should determine whether we
"intend" to receive an answer such as -. l hot" or "98 degrees Celsius." The level
of answer is not clear as it depends on the personality and knowledge of the human
asking the question. What kind of system model would be necessary so that the robot
can answer the question? Clearly, it would be best to have both detailed mathematical
models of heat transfer as well as more ..--i. -..,i.ed, so-called, lumped models [42, 43].
Such lumped models serve two purposes: 1) their relatively reduced computational
complexity enables them to be used to obtain answers quickly, and 2) they serve to
form cognitive and linguistic links between different knowledge representation levels.
We see the need for multiple models and effective methods for linking models using
behavior preserving morphisms. The "behavior preserving" aspect is critical if our
robot is to be able to maintain consistency among the various models in its model
base [45]. A more advanced robot might even be capable of forming correct system
analogies and metaphors using such morphism concepts.

"How long will it take for the pot of water to boil over?" This question requires a
detailed mathematical model for its answer since a human would most likely prefer an
accurate time.

"If you boil the water, what will happen next?" Initial a priori physical knowledge of
fluids will help in answering this question, but so will knowledge induced from the robot
having visually sensed previous occurrences of what happens to water when boiled. A
robot is likely to make a prediction of common situations, such as boiling water, by
inducing rules and simple models from multiple instances of pattern recognition. New,
simpler system models can be constructed by the robot in this manner. The new
models are then homomorphically linked to the existing models of boiling water.

"If I put fiberglass insulation in the walls, how much money will I save?" Assuming that
our robot will have a general knowledge of heat transfer, it will see that this question
and the previous one are really very similar heat transfer problems with generalized
dynamical features of effort (across variables) and flow (through variables). The robot
should have the capability to see that the room wall, pot and the pot water are all
generalized capacitances and that each material has a generalized resistance. Without
this generic knowledge, the robot's system knowledge would be very limited.

Studying these questions, we recognize that there is a need for the following capabilities
of an autonomous agent:

1. Multiple models of the same process geared to answering different questions about it.

2. A methodology and formalisms to create models.

3. An a priori knowledge base of basic physical system properties.

4. An ability to deduce new knowledge.

5. An ability to induce new knowledge.

6. Methods for traversing levels of abstraction.

This paper deals only with items one, two and six [7, 19, 45, 24]. We propose that the
concepts of events and partitions, formulated within general systems theory, can support the
construction of multimodels for high autonomy systems. We conjecture that it is while we
partition system components into linguistic and cognitive pieces that we learn how to create
qualitative models. For instance, in modeling an evacuation procedure for a skyscraper we
forgo the need to model articulated figures (humans) moving in real time -instead we
make abstract those features that will allow us to create a simplified model consisting of
a queuing network; we recognize that when humans encounter boundaries (a door, a wall,
other humans in line) that key events occur. We leave out the quantitative information that
is not the focal point of our modeling and analysis.
We first review formal definitions of systems and key system concepts that are essential
at any abstraction level. Then using the boiling water system as illustration, we show how
models can be derived in a top-down approach. We start with an abstract model expressed
as an FSA (finite state automaton) and perform homogeneous (i.e., staying within the same
formalism) refinement to derive two more levels of refinement. The final refinement is het-
erogeneous [11] in that the automaton is decomposed into block networks each representing
a continuous process such as "heating" or "cooling." This methodology has a number of
interesting features:

The result of the refinement is a set of models at different levels of abstraction.

These models can answer various questions that relate to the proper level of abstraction.

The models can be integrated into a multimodel [25, 28] that can be simulated using
one of several methods [12, 30].

The semantics of the multimodel can be expressed in the DEVS formalism.

The DEVS representation lends itself to further abstraction which supports more effi-
cient discrete-event simulation.

After the review of systems concepts and discussion of the refinement process, we justify
the claims just made. We introduce a concept of an FSA-controlled multimodel, create
a formal specification using DEVS concepts, and demonstrate its use in answering both
symbolic and dynamic questions about system structure and behavior.

2 Defining a System

2.1 Formal Specification

A deterministic system < T, U, Y, Q, 0, > within classical systems theory [29, 40] is
defined as follows:

T is the time set. For continuous systems T = R (reals), and for discrete time
systems, T = Z (integers).

U is the input set containing the possible values of the input to the system.

Y is the output set.

S is the state set.

0 is the set of admissible (or acceptable) input functions. This contains a set of input
functions that could arise during system operation. Often, due to physical limitations,
Q is a subset of the set of all possible input functions (T -- U).

6 is the transition function. It is defined as: 6 : S T T T Q S.

A is the output function, A : Tx S -- Y.

A system is said to be time-invariant when its behavior does not depend on the absolute
value of time. In this case, the transition function can be simplified to the form: 6 : S x
T x -- S. Here, 6(s, t, ) yields the state that results from starting the system in s and
applying the input w for a duration of t time units. In discrete-event systems, the effect
of the input can be captured in a resetting of the initial state. As we shall see, a useful
form of transition function then is so-called input-free where the input argument is dropped:
6(s,t) is the state reached starting from state s after a duration t. We will use this form
of the transition function later in our application of the DEVS formalism to multimodel
The system formalism is very general. For instance, figures 2 and 3 show two sample
models that can be represented using a 1) block network, and 2) state transition method,
respectively. Both of these formalisms can be shown to be sub-classes of the system for-
malism [41]. In fig. 2, transfer functions are represented as boxes with inputs and outputs
connected to each box. This is termed a "block model" in systems engineering or a "data
flow" graph in software engineering. The state vector for this system is a cross product of
the outputs Yi. Specifically, the outputs connected to boxes with memory (i.e., integrator or
delay) make up the system state (H represents an algebraic cross product):

S= J{|6l -f dt}

Fig. 3 displays a system by emphasizing state-to-state transitions instead of using a block
network orientation. An important class of state transition model is the finite state au-
tomaton (FSA). In this example, outputs Yi are associated with states Si. Input conditions
involving Ui provide determinism where there are multiple branches from a state.

S =l{Yi 18i = integrate}

Figure 2: Block network orientation.

U/ 6
1 1


Figure 3: State transition orientation.

Table 2: Simulation model types.

2.2 Model Types

Taking the cross product of time and state space in terms of two possible values ("discrete"
and "continuous") -i.-.-. -1-. four possible model types. Table 2 displays these combinations
with example model formalisms for each. Discrete event models cannot be localized within
table 2 since the concept of "discrete -. I refers to a discrete updating process rather than
to the discrete or continuous character of time or state (see [42, 32] for characterizations
of discrete event models). Discrete event simulations can be performed over models with a
discrete state space (i.e., first column in table 2). What about continuous events? In the
simulation literature [32, 27, 26], one finds reference only to discrete events. Continuous
events might be defined in terms of the start and end of an arbitrary numerical integration
interval. However, this concept is not adequate since it depends on a simulation process, and
is not an intrinsic characteristic of the model. It appears that events, which are discussed in
greater detail in section 2.3 are discrete since they map to cognitive and linguistic concepts
connected with the processes that we model. In the next section, we attempt to provide a
conceptual framework for understanding discrete events.
A combined model combines two or more of the above model types. For instance, a
combined discrete event/continuous model has two distinct model types: a discrete event
model and a continuous model. These two models are coupled with discrete events [4, 30].

2.3 Event Identification

An event is a state < sl,...,s, > (where si are components of the state vector) at a
specific time t. Therefore, an event is of the form < t,sl,...,s, >. This definition of
event was first used in physics [33], and is defined in systems theory [29, page 198]. In
the simulation literature [32, 23], the term ". ,l" is usually associated with a linguistic
or cognitive mapping. Even though an event can legally occur at any time (regardless of
linguistic association), we will use the term event to mean "key ,. I or "nominal event."
To derive or identify events based on segmentation and partition criteria involves a strong
knowledge representation of the physical system to be studied. The study of segmentation
and partitioning is by no means trivial and is usually determined by a human domain expert.
For instance, Arrivals and Departures are key events determined for a single server queue;

Discrete State Space Continuous State Space
Discrete Time Difference Equations Difference Equations
(with integer states) (with real states)
Cellular Automata
Finite State Automata

Continuous Time Queuing Models Differential Equations
Digital Logic Models

however, it would also be possible to choose events such as NextTo WaterFountain (signifying
when a person jumps out of line for 5 seconds to get a drink of water) or StartPhaseOne-
OfService (for when the person is entering the first phase within a larger service process).
Events are defined as points in time relative to the level of abstraction associated with the
model; many events such as NextTo WaterFountain can be modeled as activities (rather than
as events) in a model defined at a lower abstraction level. We can utilize several heuristics
that can help in semi-automating the event identification procedure. Here are some heuristics
for partitioning the trajectories of a complex process:

In general, an event can occur when a significant (or marked) change occurs in one of
the following trajectories: input, output, state. Consider an input trajectory that is
a square wave. Leading and trailing edges are good potential locations for events. In
continuous systems, state variables specify orders of derivatives. The sign change for
a state variable denotes a potential event location.

Form a list of questions to be asked of the model. If objects are part of the question then
they should be represented in the simulation model, and interaction with the objects
are possible events. In general, actions are applied to objects and have a beginning
and end -these are possible locations for events. (Indeed, in the activity scanning
buildd view" of discrete-event simulation [20, 32], activities or actions form the basic
primitives for model expression.)

In general, consider all boundary conditions. With respect to collisions between geo-
metrical objects, the points of collision indicate events. Example events are when a
projectile hits a target or when an articulated figure comes into physical contact with
the environment.

Just as programs have context switches (i.e., subroutines) models can have model con-
text switches. When a model is deliberately composed of separate sub-models then each
sub-model can be seen as a phase where events demarcate phase boundaries. We will
use this particular heuristic to partition our system of boiling water to be discussed.

When discussing the identification of discrete events, we might ask some basic philosoph-
ical questions about what kind of situations might not be seen as "events?" We propose
that events are associated with definite cognitive associations. For instance, a spot in the
air three feet above a floor most likely has no cognitive or linguistic mapping; therefore, we
do not normally specify an event at this location even if an object passes through this spot
during a motion trajectory. Although, if the ball hits the floor then this serves as an event
since we have a strong cognitive mapping for "floor."

3 Example System: Boiling Water

3.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 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 system
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 state-to-state transitions with input being labeled on each arc.
A dataflow model, on the other hand, focuses on the transfer function between input and

3.2 Knowledge Base

We have a large selection of model formalisms from which to choose: FSAs, Petri nets, bond
graphs, block graphs, compartmental models, pulse processes, differential equations, and
difference equations to name a few. The individual components can be chosen with the aid
of an existing knowledge base which is created manually, along with all models necessary for
the simulation. Our knowledge base approach is similar, in function, to the system entity
structure (SES) [42]. We do not focus on the knowledge base schemata in this paper, but
present the sort of infrastructure needed to form models at different abstraction levels. All
model knowledge is provided by the human modeller (i.e., not automatically inferred).
Our knowledge base contains two types of semantic networks that represent knowledge
about the boiling water domain: action and object. These particular networks are devoid
of cycles and are displayed in tree form in figures 4-51. In this paper, we focus on the
action hierarchy for information as to which model to use and which level to model. The
top part of the action tree resembles a class hierarchy (isa relations break down each higher
level phase). The model relation points to a set of differential equations that model that
particular phase. The man relation specifies observable manifestations of particular phases;
1 ako in fig. 4 is an acronym for "a kind of."

Cold ot Col
model isa ako

M1 Cooling Heating Boiling Exception

mode / model man ia

M3 M2 M4 Bubbles Overflow Und flow
Forming/ mo/ hy
man mode ma /
Smodel hypa
Foam M5 Burnt M6 Burnout

Figure 4: Action hierarchy.

manifestation relations are useful during diagnosis. The hyp relation specifies a reached
hypothesis -this can also be used for diagnosis and causal reasoning.
To create models, we must review the purpose and goals of the simulation. If a set of
questions deals with classes and instances then we will most often refer to the object hier-
archies in fig. 5. For our purpose, 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 = 90OC?" 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 6. Our hierarchy is representational in nature. We define a hierarchical orga-
nization since future question-answering 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 sub-model. 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 FSA-2. Each
level represents a more detailed representation of a given state in the layer above.

3.3 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 block networks.
In this way, the modeller can build a hierarchy of models without having to represent one


attr attr

Temp Height


partof partof

Body Handle







atr attr

Temp Material


Temp Material

it en
part of partof
part of

Island Floor Counter-

part of \ part of pa f rt of part of
part pt \part of

Counter-2 Stove Sink Disposal Counter-3

part of part of

Oven Stovetop

Figure 5: Two object hierarchies.

6 State Automaton with Block
Graphs in each State

Figure 6: Model refinement procedure.

model at the lowest abstraction/,,.--. ion level.
Figure 7 displays three levels of finite state automata for the boiling water process. Note
that the states in each of the 3 levels are chosen by directly referring to the action hierarchy
(fig. 4) within the knowledge base. A level in the refinement corresponds to a level in the
action hierarchy. The topmost FSA in fig. 7 displays a simple two state automaton with
input. We label this FSA-1. 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. 7 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 FSA-1, we create FSA-2 (a complete
model of the boiling process). FSA-3 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 question-answering using a variety of abstractions.
This is discussed further in sec. 4. Alternatively, the modeller may decide to terminate the
refinement process leaving the transition non-deterministically specified. Indeed, the decision
whether to continue refinement should be based on the modeling objectives, the accuracy
required, and the computational resources available [41, 42].

3.4 A 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 that
when a transition fires within the Petri net, one may "drop down" into the functional block
level. For the last FSA in fig. 7 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 Hf (height of foam on the top of the water) are updated. Also, the parameter
Ht is the height of the pot. In all cases, Hf > Hw and Hw, Hf < Ht. The end result will
eventually be a multimodel that will be coordinated by FSA-3.
The continuous models contained within states heating and cooling require some physical
theory before stating them. We model heat conduction since convection and radiation do
not play major roles in this system. To derive a good continuous model for heating and
cooling, we first define resistance. There is thermal resistance R = H/kA (H is the height
of water, A is the surface area of the pot, and k is the thermal conductivity of water). We
will ignore the resistance of the pot since it is not as significant as the resistance of water.
The definition for thermal capacitance C is CT = qj with qj being the flow of heat from the
heating element to the water. We will let C1 be the capacitance of the metal pot, C2 be the
capacitance of water, and C be the total capacitance. Newton's law of cooling states that
Rqh = AT = T1 T2 where T1 is the temperature of the source (heating element), and T2 is
the temperature of the water. Since T2 is our state variable we let T = T2 for convenience.



P not Cold

T=100 (I=OFF and =Overflow
SVI=0N (Boiling X^Hf=Ht xceptio |


I=-N .

T= 0 - I-/'= OFF *'

from from to
Boiling Boling Boing
Boing .: .. tion Hf = Ht I=OFF

,------------------------ - -- -- -- --- 00:

S Underflow Overflow

Hw-0 I=ON

Figure 7: Homogeneous FSA refinement.





(I=OFF and
Q= Underflow)

Hw= 0



I-ON Boiling
-O\ T=100


F k T




Figure 8: Decomposition of heating state.

By combining Newton's law with the capacitance law, and using the law of capacitors in
series, we arrive at:

Ck 1 + C2
k RCC2 (1)
T= k(T1 T) (2)

Hence, equation (2) is a first order lag with a step input representing the sudden change in
temperature as effected by a control knob. Figure 8 displays a block diagram of heating
within the heating state. Proper coupling is essential in heterogeneous refinements. That
is, it must be made clear how components at one level match components at the higher
level. Note, in fig. 8, the transfer function taking the ON/OFF input detected by the FSA
and converting these input values to temperature values for the block network. Specifically,
the block labeled 'F' performs the mapping from 'ON/OFF' to real-valued temperatures
a < T < 100. Due to the latent heat effect, T of water cannot exceed 100 unless all the
water has vaporized. After all of the water has turned to steam, the temperature increases
beyond 100; however, the system passes to the underflow state since H, = 0.
The low-level continuous models M1,..., M5 are defined as follows:2

1. (M1) COLD: T = a, H = 0, H = 0.

2. (M2) HEATING: T = ki(100 T), H, = 0, Hf = 0.

3. (M3) COOLING: T = k2(a T), H, = 0, Hf = -k3.

2Models M2 and M3 exhibit first order exponential behaviors and are, therefore, rough approximations
of the actual boiling water system.


5 I=il External Transition
I=i2 --

Internal Transition
C ------

Figure 9: Generic phase graph.

4. (M4) BOILING: T = 100, H, = -k4, Hf = k5.

5. (Ms) OVERFLOW: same as BOILING with constraint Hf = Ht.

6. (1,.) UNDERFLOW: T = undefined, H, = Hf = 0.

The system phase is denoted by ) and the state variables are:

T: temperature of water.

H,: height of the water.

Hf: 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 Mi model.
There are also some constants such as Ht 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:
1 = cold, T(0) = a, H,(0) = Hf(0) = Hs and knob = OFF. By including the functional
block knowledge, we create one large model called COMBINED that is defined as FSA-3
with each state containing a block model (as shown in fig. 8).

3.5 Forming a Multimodel
3.5.1 General Case
We have presented a refinement of graphs from the 2 state automaton to the block graph at
the lowest level. To form a multimodel, we need to specify how the set of models that we
have defined can be coordinated so that exactly one submodel is active at any time.
A multimodel can be created from fig. 7 by treating each of the states as a phase, and
associating a model with each phase. For ease of exposition, before considering the general
case, let's consider an example. Figure 9 displays a phase graph with 3 phases A, B, and C.

A different model is associated with each phase; for instance, in phase B, the underlying
model M1 will generate the state trajectories. External events are denoted in fig. 9 with a
solid arc. If in phase A, for instance, and an input of ii is received, the phase immediately
moves to B and the model is M1 starting in a state determined by the state of Ms when the
input ii occurred; otherwise the phase remains A. Internal (also called state) events occur
when the state of a model satisfies specific transition conditions. They are denoted by dashed
lines from one phase to another. For instance, in phase A, let f(X2) equal(X2, 4.2). This
is interpreted as follows: if the state variable X2 i' ... I .." the value 4.2 (i.e., X2 = 4.2) then
the phase becomes C.
Note that a phase graph is an FSA augmented with the capability of recognizing changes
in state events (internal events) as well as input events (external events). The phase graph
will become the means of coordinating the transitions and activations of the submodels in a
Let us summarize our example formulation of an FSA-controlled multimodel. In fig. 9,
the following variables are used:

A, B, and C are phases.

I is an input variable. il and i2 are the values that I can assume; the input has an
immediate effect on the phase.

X2 is a sample state variable on the continuous model level.

f is an arbitrary predicate with a true or false value.

Mi is a lower level continuous model containing transition functions defined on state
variables Xj.

Such an FSA-controlled multimodel can be simulated in a combined continuous/discrete
event environment such as those of Cellier [4] and Praehofer [30]. However, to fully under-
stand the operation of such simulation, we first present a formalization.
An FSA-controlled multimodel is specified by a structure < FSA, MODELS, map,

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, Mi, 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 FSA-controlled multimodel.
Our first step will be to transform the hierarchical system structure into a "flat" structure
by collapsing the hierarchy. Using the phase graph notation we create the graph in figure 10
by compressing the three levels in fig. 7 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. 10.
A formal interpretation for the structure < FSA, MODELS, map, TRANSITIONS >
can be given by mapping it into the DEVS&DESS formalism [30] for combined continuous
and discrete event models.3 We refrain from giving this mapping here and restrict our
comments to the following:

Note that zero, one, or more transition conditions may be associated with any phase.
In the case that there are no internal transitions out of a phase, the multimodel will
remain in the phase forever unless there is an external event that can send it to another
phase. In the case of one transition condition emerging from a phase, the multimodel
will remain in the phase until the condition becomes true -then it will immediately
switch to the new phase indicated. In the case of several transition conditions, the
multimodel will remain in the current phase until one of the conditions becomes true
-and will immediately switch to the phase corresponding to that transition.4

When the multimodel switches from one phase to another (either due to an external or
internal event) the state of the model in the new phases must be determined in some
relation to that of the model in the old phase. In general, this will require a set of
initialization specifications, one for each transition. For simplicity, we do not consider
this requirement here. Instead, we assume that the MODELS all share a common
state set and that in a transition, the new model starts in the same state that the old
model was at the time the transition occurred.

3.6 DEVS Abstraction of FSA-Controlled Multimodels

Even though classical system theory [18, 29] 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 [41] and Nance [23] 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 FSA-controlled
multimodel into a DEVS equivalent [41].
Time, in discrete event systems, is assumed to be real-valued (T = 7'R). The DEVS
structure [44] < U, Y, S, 6, A, ta > is as follows:
3Actually, this is strictly true only for the case where the MODELS are restricted to be continuous,
discrete time or discrete event. However, the extension to the general case would not be difficult.
4There must be a tie-breaking mechanism for handling cases where more than one condition simultane-
ously becomes true.



Cold .... . MS I-ON
1-0N -'I=0 "H
M=FF Hw= 0
", FF Cooling I=ON Hw
-- *M3 nderflow -,
---** M6 Hw=


Figure 10: Six state automaton controller for boiling water multimodel (FSA-3).

U is the input event set.

Y is the output set.

S is the sequential state set.

St : Q x U -- S is the external transition function. Q = {(s, e)ls 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.

Sit : S -- S is the internal transition function.

A : S Y is the output function.

ta : S -- oR+ is the time advance function.

The DEVS formalism, as stated in its title (Discrete Event System Specification), is a
shorthand means for specifying a general system as formalized earlier. We can think of it
pictorially as a box containing some process. This box accepts inputs and produces outputs.
We map an FSA-controlled multimodel < FSA, MODELS, map, TRANSITIONS > into
a DEVS equivalent as follows. Let the DEVS be defined as < U, Y, S, A, ta >, where:

U is the input set of the FSA.

Y is the output set of the FSA (not of interest here).

S = P x QM where P is the set of phases of the FSA and QM is the common state
set of the MODELS. 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).

Sxt : Q x U S is defined by:
Sext((p, q), e, u) = (fsa(p, u), 6M(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 5M(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 Cp_>p, be the condition for an internal transition from p to pi. Let
Tp_>,, be the time at which Cp_>p, first becomes true when M(p) starts in state q.
T,_>p, is the minimum time t such that Cp_>>p,,(6M(p)(q, )) is true.5 Now, ta(p, q) is the
minimum of the T,_>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).
These procedures can be best illustrated by referring to the example of fig. 9. Consider
the following continuous model definition for Ms: X2 = X2. The direct solution for this
differential equation is X2(t) = X2(0)e'. Now, to calculate the elapsed time starting
at t = 0 until the condition X2 = 4.2 occurs, we must solve et = 4.2/X2(0) to obtain
t= In(4.2) n(X2(0)).

Sint : S S is defined by:

6st(p,q) = (p*, M(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).6

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 FSA-controlled 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 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 11 displays the common three dimensional state space (T, H,, Hy) for MODELS,
and figure 12 illustrates each phase by a shaded region of state space. Table 3 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 w can be viewed as the labeling of partition blocks by input-phase 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, pi) where u is the input prevailing in phase
5We assume that such a minimum is well-defined, as it will be for continuous systems.
6Applying the tie-breaking rules if necessary.

Figure 11: Continuous state space for boiling water system.

p.7 For example, in the boiling water example, the transition condition CHEATING-BOILING
under the input I = ON is specified by the entry for (BOILING, ON) in table 3. This
transition corresponds to reaching the boundary given by plane T = 100 in figure 12(c).
In summary, an important special case of an FSA-controlled multimodel occurs where the
component models share a common state space that can be partitioned so that each block
is labeled by a phase as well as being the region in which a particular model is active. The
more restricted case where all partition blocks have the same continuous model is non-trivial;
it leads to a DEVS representation of the model [45].
It should be clear from the above construction that a discrete event model of a system
affords a more efficient simulation than a continuous implementation of the same system.
The continuous approach requires a step-by-step generation of successive model states while
the discrete event form computes state changes only at event times. To do this the DEVS
model employs its time-advance and internal transition function to predict the time and
state of next internal event; it also employs its external transition function to update its
state when a change in input occurs.
Zeigler [42] showed that a DEVS representation of general system is in a homomorphic
relation to the original system called a system morphism. In such a morphism, a corre-
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.


I OFF 100

(a) Heating phase

(b) Cooling phase

I = ON or OFF t



(c) Boiling phase

(d) Cold phase


(e) Underflow phase

(f) Overflow phase

Figure 12: Phase partitions.


I ON 100



Table 3: Partitioning of boiling water state space.

spondence between the states of the two systems is preserved under corresponding transi-
tions. Thus the state behavior of the original system is preserved although in the form of
macrostate, rather than microstate, transitions. Future research should rigorously estab-
lish the morphism between a similar FSA-controlled multimodel structure and its DEVS

3.7 Discrete Event Simulation of Multimodels

The DEVS equivalent of an FSA-controlled multimodel provides the basis for discrete-event
simulation of multimodels. A simulation of the multimodel could be carried out in DEVS-
based simulation environments such a DEVS-Scheme [43]. To provide a concrete example of
such simulation, in this article we will present algorithms that are represented in SimPack [12]
(a set of simulation tools). An FSA-controlled multimodel can be converted to a discrete
event simulation by translation of its graph to the core of a discrete event simulation: the
event switch statement. The switch statement is composed of event statement blocks (or
!i. il i es") that gain control of the simulation when a scheduled event on a future event
list is initiated (or .i.., ,1"). To show this, we use the following routines: In appendices
A and B, we present the switch statements corresponding to the graphs in figures 9 and 10
respectively. We remark that a more careful statement of some of the conditions is actually
required in the pseudo-code in appendices A and B. This occurs when the state trajectory in
the model approaches, but never actually reaches, the threshold specified in the condition.
For example, the heating model exponentially approaches the boiling temperature according
to the model's behavior. In such cases, a tolerance around the limiting value has to be set
which will provide a definite boundary crossing. The control of the boiling water system
is driven by the discrete event simulation of the FSA in fig. 10. The low level differential
equation models are simulated using Runge-Kutta integration while performing boundary

Phase I T H,. Hy
COLD ON 0 0 0
COLD OFF = a > OA < Ht > OA < Ht
HEATING ON > aA < 100 > OA < Ht > OA < Ht
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

checks for internal events.

4 Question Answering and Choice of Model

Now that we have specified 3 automata levels, one functional block level and a DEVS spec-
ification, we can use these models to answer questions about the system. The query system
is not yet implemented; however, we present sample questions and answers that can be
practically derived from the presented multimodel. Given an arbitrary question as shown in
table 4, a model is chosen on which to base the answer.
Note the following acronyms:

"Q-Type" means category of question. There are 4 types of questions specified PRED
(prediction), DIAG (diagnostic), EXP (explanation), and REF (reference). A predic-
tive question is one where simulation is required to generate the answer. A diagnostic
question yields a short answer specifying the immediate cause, whereas an explanation
is more lengthy and may involve a summary of information to be presented. A refer-
ence question is one that does not involve analysis or simulation such as "What is the
material in the pot?"

"Model" refers to the level of abstraction as specified with the models discussed so far.
FSA-1 is the most abstract, 2 state model. FSA-2 and FSA-3 are the 5 and 6 state
models respectively. The lowest level -block model- is labeled COMB (i.e., combined).

"Knowledge" refers to any additional knowledge that is needed to answer the question.
The knowledge base helps to provide answers to these questions. Recall the ACTION
and OBJECT knowledge trees specified for the boiling water domain.

Note that some questions require more information that can possibly be provided by the
dynamical model alone. For instance, the I,! iii, smell" can be attributed to the overflow
state by the manifestation link in the action tree in fig. 4.

4.1 Relation to qualitative modeling

The levels of abstraction just discussed demonstrate how causal models within AI could,
potentially, be mapped into a systems view. The resulting set of formal models can then be
used to answer different classes of questions about the system. Definition of the most abstract
levels of such a multi-layer system is similar to the causal modeling method within AI. Indeed,
many of the questions asked of such high level models could also be asked of the automata
that we have presented; although, further investigation is necessary to support this claim. If
one is to use the predictive and diagnostic power afforded by system representations it is vital
to 1) break down informal system representations into the appropriate formal models (such
as automata, block graphs or Petri nets), and 2) use extra knowledge about the system to
answer a greater percentage of questions asked of the models. The first requirement -,11 -- 1 -
that informal system descriptions (such as those of boiling water in a pot) need to be broken
down into well known entities such as state, phase and event. Once these entities are defined
then a variety of graph oriented modeling methods and the DEVS specification language

can be used. The second requirement -,i.-I-- -, that we need knowledge bases in which to
house our models. In this manner, multimodel hierarchies can be created based on the type
of questions to be answered.

5 Conclusions

We have used a system of boiling water to demonstrate how to create an FSA-controlled mul-
timodel which efficiently represents a system using multiple homogeneous and heterogeneous
models. The multimodel approach was demonstrated on an AI problem that represented a
challenge for system modeling. We found that by utilizing combined modeling, heteroge-
neous inter-level coupling, and homomorphic behavior preservation, we were able to create
a solution to the AI modeling problem that permits reasoning at a variety of levels. For
instance, with the multimodel, we could potentially 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?" On
the negative side, since our focus is on the formal structure of multimodels, we have ignored
some difficult problems associated with the question answering. For instance, in the case of
the question "If the system is warm, how can it become cold?" we manually equivalenced
'..! l" to "not cold" and used FSA-1 (the topmost level of abstraction). How did we know
to perform these procedures? We are investigating possible answers to this question; how-
ever, there remains much to be done with regard to implementing a fully realizable natural
language interface that integrates the knowledge base and model hierarchy.
The models represent a "combined" simulation in that there are three finite state
automata levels and a functional block level. The individual FSA levels of abstraction
were shown to be useful in answering certain high level system questions. A combined
continuous/discrete-event model divided up the total boiling water process into distinct
phases. Coordination of models for these phases was facilitated by the phase graph associ-
ated with the FSA at the final level of abstraction. In addition, a DEVS specification was
provided to formalize the multimodel concept in a system theoretic manner. The DEVS
formulation also allowed casting the multimodel into a form for efficient discrete-event sim-
ulation. Such simulation provides answers to questions concerning the dynamical behavior
of a system that cannot be answered by the more symbolic levels of abstraction. This illus-
trates how the approaches of AI and simulation methodology can be combined to achieve
artificial systems capable of modeling and reasoning about physical systems. Heuristic ap-
proaches to event identification for qualitative modeling were -i.--i. -1. .1 and illustrated with
a multimodel characterization of boiling water -an example introduced by Forbus [16].
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. We started with
FSAs and utilized continuous system formalisms for the detailed simulation. It would also be
possible to start with a functional block model and link Petri nets or other model formalisms
to it. The problem of semi-automating the process of taking a conceptual, non-executable
object based model of the system and converting it into an executable model remains a
very hard problem that has taken form in AI, simulation and software engineering. We
have not completely solved this problem with our method; instead, our method -,,.--. -1 -. one

way of designing and executing multi-models. The advantage to the -i.--- -1. .1 multi-model
approach is that a complex system that would otherwise necessitate the encoding of a single
level of abstraction, can be alternatively modelled as a multi-model thereby allowing the
analyst to 1) create and maintain an integrated model base, and 2) reason about system
behavior at a variety of abstraction levels.
We have described a conceptual foundation for supporting the design and execution of
multimodels. For the future, we plan several projects including constructing implementations
of the knowledge representation and natural language query schemes, and justifying the
heuristic approaches by supporting them with theory-based tools.


[1] ADDANKI, S., CREMONINI, R., AND PENBERTHY, J. S. Reasoning about Assump-
tions in Graphs of Models. In Eleventh International Joint Conference on Artificial
Intelligence (August 1989), IJCAI, pp. 1432 1438.

[2] BERLEANT, D. Combining Qualitative and Quantitative Simulation: In Brief. In
Second Conference on AI, Simulation and Planning in High A/,Ir,,,i S.i., ,,. (Cocoa
Beach, FL, April 1991), pp. 233 -240.

[3] BOBROW, D. G. Qualitative Reasoning about Pl,. ',J S-./ i,,, MIT Press, l1'-

[4] CELLIER, F. E. Combined Continuous Sill. ,, Simulation by Use of Digital Computers:
Techniques and Tools. PhD thesis, Swiss Federal Institute of Technology Zurich, 1979.

[5] DE KLEER, J., AND BROWN, J. S. A Qualitative Physics Based on Confluences. In
Qualitative Reasoning about Pl,.1'.'- S./, ,,,1 D. G. Bobrow, Ed. MIT Press, l'K
pp. 7 -83.

[6] FISHWICK, P. A. Hierarchical Reasoning: Simulating Complex Processes over Multiple
Levels of Abstraction. PhD thesis, University of Pennsylvania, 1'I~I.

[7] FISHWICK, P. A. The Role of Process Abstraction in Simulation. IEEE Transactions
on Sil,' ,,.i. Man and C1" i ,,i /.'. 18, 1 (January/February 1'i"), 18 -39.

[8] FISHWICK, P. A. Abstraction Level Traversal in Hierarchical Modeling. In Modelling
and Simulation M, ll.ll,;,,i Knowledge ,Sill ,, Paradigms, B. P. Zeigler, M. Elzas,
and T. Oren, Eds. Elsevier North Holland, 1989, pp. 393 -429.

[9] FISHWICK, P. A. Extracting Rules from Fuzzy Simulation. Expert Si, ,,1 with Ap-
plications 3, 3 (1991), 317 -327.

[10] FISHWICK, P. A. Fuzzy Simulation: Specifying and Identifying Qualitative Models.
International Journal of General S,/l' i ,, 9, 3 (1991), 295 -316.

[11] FISHWICK, P. A. Heterogeneous Decomposition and Coupling for Combined Modeling.
In 1991 Winter Simulation Conference (Phoenix, AZ, December 1991), pp. 1199 1208.

[12] FISHWICK, P. A. Computer Simulation Modeling: M, ll..'.l.,;ii. Algorithms and Pro-
grams. 1992. (to be published as a textbook).

[13] FISHWICK, P. A., AND LUKER, P. A., Eds. Qualitative Simulation Modeling and
A,il... Springer Verlag, 1991.

[14] FISHWICK, P. A., AND MODJESKI, R. B., Eds. Knowledge Based Simulation: Method-
ology and Application. Springer Verlag, 1991.

[15] FISHWICK, P. A., AND ZEIGLER, B. P. Qualitative Physics: Towards the Automa-
tion of Systems Problem Solving. Journal of Ti l..retical and Experimental Artificial
Intelligence 3 (1991), 219 -246.

[16] FORBUS, K. D. Qualitative Physics: Past, Present and Future. In Exploring Artificial
Intelligence, H. Shrobe, Ed. Morgan Kaufmann, 1'-l" pp. 239 296.

[17] FORBUS, K. D., AND FALKENHAINER, B. Self-Explanatory Simulations: An Integra-
tion of Qualitative and Quantitative Knowledge. In AAAI (1990), pp. :;l 387.

[18] KALMAN, R. E., FALB, P. L., AND ARBIB, M. A. Topics in Mathematical Sil., ,,.
Ti .. ry. McGraw-Hill, New York, 1962.

[19] KLIR, G. J. Architecture of S.l, ,,,, Problem Solving. Plenum Press, l''.

[20] KREUTZER, W. Sil lI ,, Simulation: Programming Stil, 1 and Languages. Addison
Wesley, 1'lI1.

[21] KUIPERS, B. Qualitative Simulation. Artificial Intelligence 29, 3 (September 1'-i'),
2-' 338.

[22] KUIPERS, B., AND CHIU, C. Taming Intractable Branching in Qualitative Simulation.
In Tenth International Joint Conference in Artificial Intelligence (Milan, 1987), pp. 1079

[23] NANCE, R. E. The Time and State Relationships in Simulation Modeling. Communi-
cations of the ACM 24, 4 (April 1981), 173 179.

[24] NANCE, R. E. A Conical Methodology: A Framework for Simulation Model Devel-
opment. In Conference on Methodology and Validation (San Diego, CA., April 1987),
Society for Computer Simulation, pp. 38 -43.

[25] OREN, T. I. Model-Based Activities: A Paradigm Shift. In Simulation and Model-
Based Methodologies: An Integrative View. Springer Verlag, 1984, pp. 3 -40.

[26] OREN, T. I. Simulation Model Symbolic Processing: Taxonomy. In Sil ,,' and
Control F,,, .lo 1,pedia. Pergammon Press, 1987, pp. 4377 -4381.

[27] OREN, T. I. Simulation: Taxonomy. In Sil/, ,,. and Control F,, .. 1,pedia. Pergammon
Press, 1987, pp. 4411 4414.

j"] OREN, T. I. Dynamic Templates and Semantic Rules for Simulation Advisors and
Certifiers. In Knowledge Based Simulation: Methodology and Application. Springer
Verlag, 1991, pp. 53 -76.

[29] PADULO, L., AND ARBIB, M. A. Sil,, ,,, Tl r.. y: A Unified State Space Approach to
Continuous and Discrete Sil.-/, W. B. Saunders, Philadelphia, PA, 1974.

[30] PRAEHOFER, H. Sil,, w. Tl '..retic Foundations for Combined Discrete-Continuous
SillI ,, Simulation. PhD thesis, Johannes Kepler University of Linz, 1991.

[31] PRITSKER, A. A. B. The GASP IV Simulation Language. John Wiley and Sons, 1974.

[32] PRITSKER, A. A. B. Introduction to Simulation and SLAM II. Halsted Press, 1','I.

[33] REICHENBACH, H. The Pi.'I.....,1,,*i of Space and Time. Dover, 1957. First published
by General Publishing Company, Toronto, Ontario.

[34] SCARL, E., Ed. Second AAAI Workshop on Model Based Reasoning (Boston, MA,
1990), AAAI Conference.

[35] SHEARER, J. L., MURPHY, A. T., AND RICHARDSON, H. H. Introduction to Sil., i,.
Dii.,,.'ii.- Addison Wesley, 1967.

[36] STRUSS, P. Global Filters for Qualitative Behaviors. In AAAI (l''), pp. 275 279.

[37] WELD, D. S. Combining Discrete and Continuous Process Models. In Ninth Inter-
national Joint Conference on Artificial Intelligence (August 'ir), IJCAI, pp. 140

[38] WELD, D. S. The Use of A,-.-. -.i ion in Causal Simulation. Artificial Intelligence 30,
1 (October 1'li), 1 34.

[39] WELD, D. S., AND DE KLEER, J., Eds. Readings in Qualitative Reasoning about
Pl,,'.'., Si,'l ,,,- (Palo Alto, CA, 1990), Morgan Kaufmann.

[40] WYMORE, A. W. A Mathematical Tbi. ry of Sil-/, ,,. Engineering: The Elements.
Krieger Publishing Co., 1977.

[41] ZEIGLER, B. P. Ti .. ry of Modelling and Simulation. John Wiley and Sons, 1976.

[42] ZEIGLER, B. P. Multi-Facetted Modelling and Discrete Event Simulation. Academic
Press, 1984.

[43] ZEIGLER, B. P. Multifaceted Systems Modeling: Structure and Behavior at a Multi-
plicity of Levels. In Individual Development and Social Change: Explanatory A,lii.,-'.
Academic Press, l'r. pp. 265 -293.

[44] ZEIGLER, B. P. DEVS Representation of Dynamical Systems: Event-Based Intelligent
Control. Proceedings of the IEEE 77, 1 (January 1989), 72 -80.

[45] ZEIGLER, B. P. Object Oriented Simulation with Hierarchical, Modular Models: Intel-
ligent Agents and Endomorphic Sil,/ ,,, Academic Press, 1990.



We first include some background information on SimPack and then specify pseudo-code
for simulating the models in figures 9 and 10. SimPack is a collection of C-based programs
and libraries for simulation. For the algorithms specified in appendices A and B, we require
two basic simulation approaches 1) the ability to simulate a finite state machine, and 2) the
ability to simulate a set of differential equations. For the first task, one may use either the
FSA simulator or a more general discrete event approach. Runge-Kutta integration is used
to simulate the equations of heating and cooling based on Newton's law. Below, we list the
current features in the SimPack toolkit:

1. combined: Combined modeling

(a) combined: discrete event and continuous "Simulation of a cashier with a moving
belt for groceries"
(b) combined: difference and differential equations "Delay differential equation =
a x(t 1)"

2. dec: Declarative modeling

(a) fsa: finite state automata with timed states
(b) markov: Markov model with timed states
(c) pulse: Pulse process

3. equation: Equational modeling

(a) difference : Difference equation modeling
i. logl: Logistic equation (first order)
ii. log2: Logistic equation (second order)
iii. diffl: Circular queue simulation method on logl
iv. bifurc: Bifurcation analysis on logl
(b) differential: Differential equation modeling
i. deq: Equation parser and solver
ii. integrate: Sample Euler and RK4 integration

4. func: Functional modeling

(a) XSimCode: X window interactive queuing network simulator
(b) clock: discrete event model of a clock
(c) cpudisk: 1CPU/4Disk discrete event simulation
(d) gas: two methods of simulating gas/molecule dynamics
(e) logic: digital logic simulator with nominal gate delays
(f) network: communications network simulator

(g) petri: timed petri net simulator
(h) qnet: general queuing network simulator
(i) slice: block simulator (ala CSMP)
(j) ssq: single server queue simulation with graphical tracing
5. minigpss: Mini GPSS compiler (small subset of GPSS)

6. queuing: Queuing library (contains all routines for queuing)

The following is a list of routines referenced in the pseudo-code:

next_event(6E) takes the next event from the front of the future event list and places
it in E.

schedule(E, T) schedules an event to occur by placing it in the future event list. E is
the event that is to occur, and Tis the amount of time to elapse before executing event

instantiate(M, Q) provides a context switch so that continuous model M now "controls"
the system behavior, instantiate causes a new initial state Q for M so that simulation
can begin. Each M has a set of state variables and state variable relationships (such
as a set of differential equations).

time_state(C,M) yields the time elapsed in model M for condition C to become true.

save-state() saves the state of the model in the current phase.

get-state() gets the current state saved previously by save-state().

time_input(I) yields the time elapsed until a specific input enters the system.

This scheme presumes a deterministic simulation where the input stream to be fed into the
simulation is produced and therefore known in advance. In this way, it is not difficult to
determine which event comes first: (1) a specific input value, or (2) a state event occurrence.

Appendix A
Algorithm for Simulating Model in Fig. 9

next_event(l i, t);
switch(event) {
/* external events list all input values as cases */
i : switch(phase) {
A: schedule(B,0); break;
C: schedule(B,O); break;
} /* end switch *

i2: if(phase == B) schedule(C,0); break;
/* internal events list all phases in graph as cases */
A: phase = A;
instantiate (M5, get-state ());
if (time_state(f(X2),MV) < time_input(iJ))
B: phase = B;
instantiate (M ,get-state )) break;
C: phase = C;
instantiate (11, get-state )) break;
} /* end switch */

Appendix B
Algorithm for Simulating Model in Fig. 10

next_event(L 1' ,,t);
switch(event) {
/* external events list all input values as cases */
on: switch(phase) {
cold: schedule (heating, 0); break;
cooling: schedule (heating, 0); break;
} /* end switch *
off: switch(phase) {
heating: schedule(cooling, 0); break;
boiling: schedule(cooling, 0); break;
overflow: schedule(boiling,0); break;
} /* end switch *
/* internal events list all phases in graph as cases */
cold: phase = cold;
instantiate (MI ,get-state )); break;
heating: phase = heating;
instantiate (11 get-state ());
if(time_state(equal(T,100),M2) < time_input(off))
schedule(boiling, time_state (equal(T, 100),M2));
cooling: phase = cooling;
instantiate (M3, get-state ));
if(time_state(equal(T,a),M3) < time_input(on))
schedule (cold,time_state(equal(T,a),M3));

boiling: phase = boiling;
instantiate (M4, get-state ));
if(time_state(equal(Hf,Ht),M4) < time_input(off))
schedule(overflow,time_state(equal(Hf ,Ht),M4));
overflow: phase = overflow;
instantiate (M5, get-state ());
if(time_state(equal(H,0),OM,) < time_input(off))
schedule(underflow, time_state(equal(H,, 0),M)));
underflow: phase = underflow;

Table 4: Question-answering using the multimodel.

Question Q-Type Model Knowledge Answer
What happens if I turn the PRED FSA-1 none System moves to "not cold."
knob (water is cold)?
If the system is warm, DIAG FSA-1 none System becomes cold when
how can it become cold? the water temperature equals
the ambient temperature.
The water is now cooling. DIAG FSA-2 none The system was either "heating"
What happened before? with knob being turned OFF, or
"boiling" with knob being turned
What is the maximum REF None OBJECT 190 C
temperature of the burner?
The water is heating PRED COMB none 15.4 minutes.
and the temperature is
now 740C. How long
will it take to cool to
room temperature if the
knob is turned off now?
There is a burnt smell! EXP FSA-3 ACTION The water was originally room
How did that happen? temperature. Then it began to
heat when the knob was turned on.
Eventually, the water boiled until
the foam reached the top of the pot.
The overflowing foam caused the
burnt smell.
Why did the water start DIAG FSA-2 none The water was being heated and
to boil? the temperature reached 1000C
which caused the water to boil.

University of Florida Home Page
© 2004 - 2010 University of Florida George A. Smathers Libraries.
All rights reserved.

Acceptable Use, Copyright, and Disclaimer Statement
Last updated October 10, 2010 - - mvs