A multimodel methodology for qualitative model engineering.
Qualitative models arising in 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 remain 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 reasoning 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 reasoning.
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
automaton).
AI researchers have also performed substantial research in modeling qualitative behavior
at different abstraction and aggregation 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 toward
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-
Foam
Water
Heating Element
Copper Pot

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 [28] developed 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 [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 studied
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:
ffl "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 "very 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 aggregated, 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.
ffl "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.
ffl "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.
ffl "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
refinement to derive two more levels of refinement. The final refinement is heterogeneous
[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:
ffl The result of the refinement is a set of models at different levels of abstraction.
ffl These models can answer various questions that relate to the proper level of abstraction.
ffl The models can be integrated into a multimodel [25, 28] that can be simulated using
one of several methods [12, 30].
ffl The semantics of the multimodel can be expressed in the DEVS formalism.
ffl The DEVS representation lends itself to further abstraction which supports more efficient
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;
classical systems theory [29, 40] is
defined as follows:
is the time set. For continuous systems
systems,
ffl U - is the input set containing the possible values of the input to the system.
is the output set.
is the state set.
ffl\Omega - 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,
\Omega is a subset of the set of all possible input functions (T ! U ).
is the transition function. It is defined as:
ffl - is the output function,
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
yields the state that results from starting the system in s and
applying the input ! 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:
ffi(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
specification.
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 formalism
[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 Y i . Specifically, the outputs connected to boxes with memory (i.e., integrator or
delay) make up the system state (
Q represents an algebraic cross product):
Y
Z tdtg
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 automaton
(FSA). In this example, outputs Y i are associated with states S i . Input conditions
involving U i provide determinism where there are multiple branches from a state.
d
d
d
dY3
Y
Y

Figure

2: Block network orientation.d4321

Figure

3: State transition orientation.

Table

2: Simulation model types.
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
2.2 Model Types
Taking the cross product of time and state space in terms of two possible values ("discrete"
and "continuous") suggests 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 event" 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 ! s are components of the state vector) at a
specific time t. Therefore, an event is of the form ! t; 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 "event" 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 event" 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;
however, it would also be possible to choose events such as NextToWaterFountain (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 NextToWaterFountain 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:
ffl 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.
ffl 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
"world view" of discrete-event simulation [20, 32], activities or actions form the basic
primitives for model expression.)
ffl In general, consider all boundary conditions. With respect to collisions between geometrical
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.
ffl Just as programs have context switches (i.e., subroutines) models can have model context
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 philosophical
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 190 ffi C; off is ff - 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 heuristics
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
output.
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-5 1 . 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."
Foam
man
ako
Exception
ako
ako
hyp
man
isa
isa
man
isa
isa
isa
model
model
model
model
model
model
Burnout
M6
Smell
Burnt_
Underflow
Overflow
Forming
Bubbles_
M3
Boiling
Heating
Cooling
not Cold
Cold
Phase

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 hierarchies
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 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 organization
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
attr
attr
attr
attr
part_of
part_of
attr
attr
isa
isa
isa
isa
Max_Temp
Type
Material
Material
Height
Handle
Body
Knob
Burner
Pot
Water
Object
part_of part_of
part_of part_of
part_of
part_of
part_of
part_of
part_of
part_of
Stovetop
Oven
Counter-3
Disposal
Stove
Counter-2
Floor
Island
Kitchen

Figure

5: Two object hierarchies.
Graphs in each State
6 State Automaton with Block
(COMBINED)
refine
refine
refine
6 State Automaton

Figure

Model refinement procedure.
model at the lowest abstraction/aggregation 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. 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 = i1 on an arc in fig. 7 defining where the state transition is accomplished
when the input becomes i1. 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
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 specification
than is available at the current level of abstraction. For example, the transition from
Exception to Boiling refers to the phase Overf low. 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 Refinement
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 H f (height of foam on the top of the water) are updated. Also, the parameter
H t is the height of the pot. In all cases, H f - Hw and Hw . 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 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 C -
being the flow of heat from the
heating element to the water. We will let C 1 be the capacitance of the metal pot, C 2 be the
capacitance of water, and C be the total capacitance. Newton's law of cooling states that
is the temperature of the source (heating element), and T 2 is
the temperature of the water. Since T 2 is our state variable we let
Boiling
from
(I=OFF and
F
I=OFF
I=ON
I=ON or I=OFF
I=ON
I=ON,
I=OFF
I=OFF
I=ON
I=ON
I=OFF
I=ON
I=ON or I=OFF
I=ON
I=OFF
F
Exception
Exception
a
not Cold
to
Boiling
from
Overflow
Underflow
to
Boiling
Cooling
Heating
a
Cold
not
Cold
from
Cold
Cold
Boiling

Figure

7: Homogeneous FSA refinement.
I=OFF
I=ON
I=ON
I=ON
a
Cooling
to
Boiling
to
Cold
from
Cooling
from
Fk
Heating

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:
(1)
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
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 Hw = 0.
The low-level continuous models M are defined as follows: 2
1.
2.
3.
first order exponential behaviors and are, therefore, rough approximations
of the actual boiling water system.
A
Internal Transition
External Transition
LEGEND

Figure

9: Generic phase graph.
4. (M 4
5. same as BOILING with constraint H
The system phase is denoted by \Phi and the state variables are:
of water.
height of the water.
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 i model.
There are also some constants such as H t for the height of top of pot, H s for the starting
height of water when poured into the pot; and k i rate constants. The initial conditions are:
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 M 1 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 i 1 is received, the phase immediately
moves to B and the model is M 1 starting in a state determined by the state of M 5 when the
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(X 2
is interpreted as follows: if the state variable X 2 "reaches" the value 4:2 (i.e.,
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
multimodel.
Let us summarize our example formulation of an FSA-controlled multimodel. In fig. 9,
the following variables are used:
and C are phases.
ffl I is an input variable. i 1 and i 2 are the values that I can assume; the input has an
immediate effect on the phase.
is a sample state variable on the continuous model level.
ffl f is an arbitrary predicate with a true or false value.
is a lower level continuous model containing transition functions defined on state
variables X j .
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 understand
the operation of such simulation, we first present a formalization.
An FSA-controlled multimodel is specified by a structure ! FSA, MODELS, map,
TRANSIT IONS ?, where
ffl FSA is a finite state automaton whose states are called phases. The input induced
phase, form the external events of the multimodel.
ffl MODELS is a set of models, M i , each being specified as a system in the general
formalism given earlier.
ffl map is a mapping from the states of FSA to MODELS; thus, each phase is assigned
a model 2 MODELS which is intended to be the one and only active model when
the multimodel is in that phase.
ffl TRANSIT IONS 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 M 1:::5 given
is shown as the labeling of the phases with elements from MODELS; TRANSIT IONS is
shown as the set of conditions attached to the dotted arcs in fig. 10.
A formal interpretation for the structure ! FSA;MODELS;map;TRANSIT IONS ?
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:
ffl 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
ffl 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
). The DEVS
structure ta ? is as follows:
3 Actually, 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.
4 There must be a tie-breaking mechanism for handling cases where more than one condition simultaneously
becomes true.
M6
M3
Heating
I=OFF
I=ON
I=ON or I=OFF
I=OFF
I=ON I=OFF
I=ON
I=ON
I=OFF
I=ON
Hf=Ht
Underflow
Overflow
Cold
Boiling
Cooling
a

Figure

10: Six state automaton controller for boiling water multimodel (FSA-3).
ffl U is the input event set.
ffl Y is the output set.
ffl S is the sequential state set.
is the external transition function.
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.
is the internal transition function.
Y is the output function.
ta
0;1 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;TRANSIT IONS ? into
a DEVS equivalent as follows. Let the DEVS be defined as ! U; Y; ta ?, where:
ffl U is the input set of the FSA.
ffl Y is the output set of the FSA (not of interest here).
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).
where fsa(p; u) is the the phase into which the FSA enters when it receives an input
u in phase p, and ffi M(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.
ffl To define ta, we recall that a set of transition conditions is associated with a given
phase p. Let C p\Gamma?p0 be the condition for an internal transition from p to p0. Let
T p\Gamma?p0 be the time at which C p\Gamma?p0 first becomes true when M(p) starts in state q.
T p\Gamma?p0 is the minimum time t such that C p\Gamma?p0 (ffi M(p) (q; t)) is true. 5 Now, ta(p; q) is the
minimum of the T p\Gamma?p0 , where p0 ranges over the transitions C p;p0 in TRANSIT IONS.
Note that this minimum could be 1 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
. The direct solution for this
differential equation is . Now, to calculate the elapsed time starting
at until the condition occurs, we must solve e to obtain
where p   is the phase dictated by the winning condition, i.e., the phase p0 such T p\Gamma?p0
is equal to ta(p; q). 6
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; Hw
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 -(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 - 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 p!p0 can be written as the
membership of a state in the partition block -(u; p0) where u is the input prevailing in phase
5 We assume that such a minimum is well-defined, as it will be for continuous systems.
6 Applying the tie-breaking rules if necessary.
aa
ta
f

Figure

11: Continuous state space for boiling water system.
p. 7 For example, in the boiling water example, the transition condition CHEAT ING!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
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-
7 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.
a
ta
f
(a) Heating phase
a
ta
f
(b) Cooling phase
ON or OFF
a
Ha
f
(c) Boiling phase
a
ta
f
(d) Cold phase
ON or OFF
T is undefined
aa
Ha
f
Underflow phase
aa
ta
f
(f) Overflow phase

Figure

12: Phase partitions.

Table

3: Partitioning of boiling water state space.
Phase I T Hw H f
COLD ON OE OE OE
HEATING OFF OE OE OE
COOLING ON OE OE OE
OVERFLOW OFF OE OE OE
UNDERFLOW ON
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 establish
the morphism between a similar FSA-controlled multimodel structure and its DEVS
equivalent.
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
"routines") that gain control of the simulation when a scheduled event on a future event
list is initiated (or "caused"). 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
checks for internal events.
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:
ffl "Q-Type" means category of question. There are 4 types of questions specified PRED
(prediction), DIAG (diagnostic), EXP (explanation), and REF (reference). A predictive
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 reference
question is one that does not involve analysis or simulation such as "What is the
material in the pot?"
ffl "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).
ffl "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 "burnt 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 suggests
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 suggests 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.
Conclusions
We have used a system of boiling water to demonstrate how to create an FSA-controlled multimodel
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, heterogeneous
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
"warm" 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 associated
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 illustrates
how the approaches of AI and simulation methodology can be combined to achieve
artificial systems capable of modeling and reasoning about physical systems. Heuristic approaches
to event identification for qualitative modeling were suggested 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 suggests one
way of designing and executing multi-models. The advantage to the suggested 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.



--R

Reasoning about Assumptions in Graphs of Models.
Combining Qualitative and Quantitative Simulation: In Brief.
Qualitative Reasoning about Physical Systems.
Combined Continuous System Simulation by Use of Digital Computers: Techniques and Tools.
A Qualitative Physics Based on Confluences.
Hierarchical Reasoning: Simulating Complex Processes over Multiple Levels of Abstraction.
The Role of Process Abstraction in Simulation.
Abstraction Level Traversal in Hierarchical Modeling.
Extracting Rules from Fuzzy Simulation.
Fuzzy Simulation: Specifying and Identifying Qualitative Models.
Heterogeneous Decomposition and Coupling for Combined Modeling.
Computer Simulation Modeling: Methodology
Qualitative Simulation Modeling and Analysis.
Knowledge Based Simulation: Methodology and Application.
Qualitative Physics: Towards the Automation of Systems Problem Solving.
Qualitative Physics: Past

Topics in Mathematical Systems Theory.
Architecture of Systems Problem Solving.
System Simulation: Programming Styles and Languages.
Qualitative Simulation.
Taming Intractable Branching in Qualitative Simulation.
The Time and State Relationships in Simulation Modeling.
A Conical Methodology: A Framework for Simulation Model Devel- opment

Model Symbolic Processing: Taxonomy.

Dynamic Templates and Semantic Rules for Simulation Advisors and Certifiers.
Systems Theory: A Unified State Space Approach to Continuous and Discrete Systems.
System Theoretic Foundations for Combined Discrete-Continuous System Simulation
The GASP IV Simulation Language.
Introduction to Simulation and SLAM II.
The Philosophy of Space and Time.
Second AAAI Workshop on Model Based Reasoning (Boston
Introduction to System Dynamics.
Global Filters for Qualitative Behaviors.
Combining Discrete and Continuous Process Models.
The Use of Aggregation in Causal Simulation.
Readings in Qualitative Reasoning about Physical Systems (Palo Alto
A Mathematical Theory of Systems Engineering: The Elements.
Theory of Modelling and Simulation.

Multifaceted Systems Modeling: Structure and Behavior at a Multiplicity of Levels.
DEVS Representation of Dynamical Systems: Event-Based Intelligent Control
Object Oriented Simulation with Hierarchical
--TR
Multifacetted modelling and discrete event simulation
Qualitative reasoning about physical systems
Introduction to Simulation and SLAM II (3rd ed.)
System simulation programming styles and languages
Qualitative simulation
The use of aggregation in causal simulation
Hierarchical reasoning: simulating complex processes over multiple levels of abstraction
Role of process abstraction in simulation
Qualitative physics: past, present, and future
Object-oriented simulation with hierarchical, modular models: intelligent agents and endomorphic systems
Readings in qualitative reasoning about physical systems
A qualitative physics based on confluences
Knowledge-based simulation
Dynamic templates and semantic rules for simulation advisors and certifiers
Qualitative simulation modeling and analysis
Qualitative physics: towards the automation of systems problem solving
Heterogeneous decomposition and inter-level coupling for combined modeling
The time and state relationships in simulation modeling
Theory of Modelling and Simulation

--CTR
Arnold J. Almanzor , Paul R. Work, The modeling methodology, model specifications and development of CASI: CASE/Architecture Simulation Integration, Proceedings of the 25th conference on Winter simulation, p.657-661, December 12-15, 1993, Los Angeles, California, United States
Victor T. Miller , Paul A. Fishwick, Graphic modeling using heterogeneous hierarchical models, Proceedings of the 25th conference on Winter simulation, p.612-617, December 12-15, 1993, Los Angeles, California, United States
Paul Fishwick , Jinho Lee , Minho Park , Hyunju Shim, Next generation modeling I: RUBE: a customized 2d and 3d modeling framework for simulation, Proceedings of the 35th conference on Winter simulation: driving innovation, December 07-10, 2003, New Orleans, Louisiana
Herbert Praehofer , Dietmar Pree, Visual modeling of DEVS-based multiformalism systems based on higraphs, Proceedings of the 25th conference on Winter simulation, p.595-603, December 12-15, 1993, Los Angeles, California, United States
Paul A. Fishwick, SimPack: getting started with simulation programming in C and C++, Proceedings of the 24th conference on Winter simulation, p.154-162, December 13-16, 1992, Arlington, Virginia, United States
Moon-Ho Hwang , Byoung-Kyu Choi, GK-DEVS: geometric and kinematic DEVS Formalism for simulation modeling of 3-dimensional multi-component systems, Transactions of the Society for Computer Simulation International, v.18 n.3, p.159-173, September 2001
Jin Joo Lee , Paul A. Fishwick, Simulation-based planning for multi-agent environments, Proceedings of the 29th conference on Winter simulation, p.405-412, December 07-10, 1997, Atlanta, Georgia, United States
Paul A. Fishwick, Multimodeling as a unified modeling framework, Proceedings of the 25th conference on Winter simulation, p.580-581, December 12-15, 1993, Los Angeles, California, United States
Taewoo Kim , Jinho Lee , Paul Fishwick, A two-stage modeling and simulation process for web-based modeling and simulation, ACM Transactions on Modeling and Computer Simulation (TOMACS), v.12 n.3, p.230-248, July 2002
Paul A. Fishwick, Heterogeneous decomposition and inter-level coupling for combined modeling, Proceedings of the 23rd conference on Winter simulation, p.1120-1128, December 08-11, 1991, Phoenix, Arizona, United States
Paul A. Fishwick, Simulation model design, Proceedings of the 26th conference on Winter simulation, p.173-175, December 11-14, 1994, Orlando, Florida, United States
Paul A. Fishwick, An architectural design for digital objects, Proceedings of the 30th conference on Winter simulation, p.359-366, December 13-16, 1998, Washington, D.C., United States
Paul A. Fishwick, Simulation model design, Proceedings of the 27th conference on Winter simulation, p.209-211, December 03-06, 1995, Arlington, Virginia, United States
Frederick K. Frantz, A taxonomy of model abstraction techniques, Proceedings of the 27th conference on Winter simulation, p.1413-1420, December 03-06, 1995, Arlington, Virginia, United States
David P. Miller , R. James Firby , Paul A. Fishwick , Jeff Rothenberg, AI: what simulationists really need to know, ACM Transactions on Modeling and Computer Simulation (TOMACS), v.2 n.4, p.269-284, Oct. 1992
Paul A. Fishwick , Hanns-Oskar A. Porr, Using discrete event modeling for effective computer animation control, Proceedings of the 23rd conference on Winter simulation, p.1156-1164, December 08-11, 1991, Phoenix, Arizona, United States
Ashvin Radiya, Discrete event simulation modeling: directions for the '90s, Proceedings of the 24th conference on Winter simulation, p.773-782, December 13-16, 1992, Arlington, Virginia, United States
John A. Reed , Gregory J. Follen , Abdollah A. Afjeh, Improving the aircraft design process using Web-based modeling and simulation, ACM Transactions on Modeling and Computer Simulation (TOMACS), v.10 n.1, p.58-83, Jan. 2000
Francesco Amigoni , Alessandro Beda , Nicola Gatti, Multiagent systems for cardiac pacing simulation and control, AI Communications, v.18 n.3, p.217-228, August 2005
Kangsun Lee , Paul A. Fishwick, Dynamic model abstraction, Proceedings of the 28th conference on Winter simulation, p.764-771, December 08-11, 1996, Coronado, California, United States
John A. Reed , Abdollah A. Afjeh, An object-oriented framework for distributed computational simulation of aerospace propulsion systems, Proceedings of the 4th conference on USENIX Conference on Object-Oriented Technologies and Systems (COOTS), p.11-11, April 27-30, 1998, Santa Fe, New Mexico
Fernando J. Barros, A Formal Representation of Hybrid Mobile Components, Simulation, v.81 n.5, p.381-393, May       2005
Gnter Gans , Matthias Jarke , Gerhard Lakemeyer , Dominik Schmitz, Deliberation in a metadata-based modeling and simulation environment for inter-organizational networks, Information Systems, v.30 n.7, p.587-607, November 2005
Levent Yilmaz, Toward Next-Generation, Simulation-Based Computational Tools for Conflict and Peace Studies, Social Science Computer Review, v.25 n.1, p.48-60, February  2007
Levent Yilmaz , Tuncer I. ren , Nasser Ghasem-Aghaee, Simulation-based problem-solving environments for conflict studies, Simulation and Gaming, v.37 n.4, p.534-556, December 2006
Paul A. Fishwick, An integrated approach to system modeling using a synthesis of artificial intelligence, software engineering and simulation methodologies, ACM Transactions on Modeling and Computer Simulation (TOMACS), v.2 n.4, p.307-330, Oct. 1992
combined simulation;abstraction levels;qualitative simulation;homomorphism;systems theory;multimodeling