1) or a bouncing ... build multiple models that can t together to aid in question-answering at di erent ... homomorphic mapping insures maximal consistency when dynamically ... 5. An ability to induce new knowledge. 6. Methods for traversing levels of .... The liquid level (height) does not increase until the liquid starts to boil.
A Multimodel Methodology for Qualitative Model Engineering Paul A. Fishwick University of Florida and Bernard P. Zeigler University of Arizona Abstract
Qualitative models arising in the arti cial intelligence domain often concern real systems that are dicult to represent with traditional means. However, some promise for dealing with such systems is o ered 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 o ers an approach to building intelligent machines capable of physical modeling and reasoning. Categories and Subject Descriptors: I.2.4 [Arti cial Intelligence] Knowledge Representation Formalisms and Methods - representations; I.6.1 [Simulation and Modeling] Simulation Theory - model classi cation, systems theory; I.6.5 [Simulation and Modeling] Model Development - modeling methodologies. I.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, Homomorphism. 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 91092520. 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 85721.
Table 1: AI/Simulation terminology. Arti cial Intelligence Process Envisionment Landmark Ontology
Simulation System Reachability Discrete Event Model Speci cation
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 over ow 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 arti cial 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 \ nite 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 simulation, 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-de ned. 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 nite state automaton). AI researchers have also performed substantial research in modeling qualitative behavior at di erent 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 eld of qualitative physics. Forbus notes that \some device ontologies are unnatu2
Foam Water
Copper Pot
Heating Element
Figure 1: A pot of boiling water. ral." For instance, it is dicult to model a pot of boiling water (see g. 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 [28] developed a concept of multimodel to formalize modof abstraction [6, 7, 8]. Oren els containing several submodels, only one of which is put into e ect 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] rst 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 Speci cation (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 t together to aid in question-answering at di erent levels. Our method di ers from the AI work in two fundamental ways: (1) our models are based on the canonical systems de nition (described in the next section), and (2) we place a strong emphasis on behavior preservation among models during a traversal. Using the canonical model de nition 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 rst 3
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 rst understand natural language which poses many diculties 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 di erent knowledge representation levels. We see the need for multiple models and e ective 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
uids 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 berglass 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 e ort (across variables) and ow (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 di erent questions about it. 4
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 gures (humans) moving in real time | instead we make abstract those features that will allow us to create a simpli ed 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 rst review formal de nitions 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 ( nite state automaton) and perform homogeneous (i.e., staying within the same formalism) re nement to derive two more levels of re nement. The nal re nement 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:
The result of the re nement is a set of models at di erent 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 ecient discrete-event simulation. After the review of systems concepts and discussion of the re nement process, we justify the claims just made. We introduce a concept of an FSA-controlled multimodel, create a formal speci cation using DEVS concepts, and demonstrate its use in answering both symbolic and dynamic questions about system structure and behavior.
5
2 De ning a System
2.1 Formal Speci cation
A deterministic system < T; U; Y; Q; ; ; > within classical systems theory [29, 40] is de ned 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. - 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,
is a subset of the set of all possible input functions (T ! U ). - is the transition function. It is de ned as: : S T T ! S . is the output function, : T 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 simpli ed to the form: : S T ! S . Here, (s; t; !) 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 e ect 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: (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 speci cation. The system formalism is very general. For instance, gures 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 g. 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
ow" graph in software engineering. The state vector for this system is a cross product of the outputs Yi. Speci cally, the outputs connected to boxes with memory (i.e., integrator or Q delay) make up the system state ( represents an algebraic cross product):
Y
S = fYiji
Zt 0
dtg
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 nite state automaton (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. 6
U
δ
δ
Y1 1
Y4 4
δ
Y2
Y 3
δ 3
2
S =Π {Yi | δ i
= integrate}
Figure 2: Block network orientation.
U/ δ 1 1
S/Y 1 1
δ
3
S/Y 2 2
U/ δ 2 2
S/Y 3 3
Figure 3: State transition orientation.
7
S/Y 4 4
Table 2: Simulation model types. Discrete State Space Continuous State Space Di erence Equations Di erence Equations (with integer states) (with real states) Cellular Automata Finite State Automata
Discrete Time
Continuous Time Queuing Models Digital Logic Models
Di erential Equations
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., rst column in table 2). What about continuous events? In the simulation literature [32, 27, 26], one nds reference only to discrete events. Continuous events might be de ned 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 Identi cation
An event is a state < s ; : : : ; sn > (where si are components of the state vector) at a speci c time t. Therefore, an event is of the form < t; s ; : : : ; sn >. This de nition of event was rst used in physics [33], and is de ned 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; 1
1
8
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 StartPhaseOneOfService (for when the person is entering the rst phase within a larger service process). Events are de ned 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 de ned at a lower abstraction level. We can utilize several heuristics that can help in semi-automating the event identi cation procedure. Here are some heuristics for partitioning the trajectories of a complex process: In general, an event can occur when a signi cant (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 \world 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 geometrical objects, the points of collision indicate events. Example events are when a projectile hits a target or when an articulated gure comes into physical contact with the environment. 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 identi cation 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 de nite cognitive associations. For instance, a spot in the air three feet above a oor 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 oor then this serves as an event since we have a strong cognitive mapping for \ oor."
3 Example System: Boiling Water
3.1 Overview
Consider a pot of boiling water on a stovetop electric heating element. Initially, the pot is lled to some predetermined level with water. A small amount of detergent is added to 9
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 o (on is 190 C ; o is - 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 over ows the pot or the knob is turned o . 4. The liquid level decreases during the boiling and over ow 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 e ective way then our model engineering process will be simpli ed 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 speci ed system components. Key components of any system model are input, output, state, event, time and parameter. Di erent modeling methods include these components in di erent ways. For instance, an FSA focuses on state-to-state transitions with input being labeled on each arc. A data ow 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, di erential equations, and di erence 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 di erent 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 gures 4-5 . 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 di erential equations that model that particular phase. The man relation speci es observable manifestations of particular phases; 1
1 ako
in g. 4 is an acronym for \a kind of."
10
Phase ako
ako
Cold model
not Cold isa
ako isa
M1
Cooling model
M3
isa
Boiling
Heating model
M2
model
Exception
man
isa isa
M4
Bubbles_ Overflow Forming model
man
Foam
M5
Underflow model
man
Burnt_ M6 Smell
hyp
Burnout
Figure 4: Action hierarchy. manifestation relations are useful during diagnosis. The hyp relation speci es 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 g. 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 o when T = 90C ?" In the following sections, we discuss a stepwise re nement process to create multiple models of the boiling water system. Our re nement procedure is shown in gure 6. Our hierarchy is representational in nature. We de ne 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 speci c 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 Re nements
Homogeneous re nement is the re nement 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 de ned 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 11
Object isa
isa
isa
Water attr
Pot
attr
Temp
isa
Body
attr
Handle
attr
attr
Type
Max_Temp
attr
attr
Temp
Knob
part_of
part_of
Height
Burner
attr
Material Temp
Material
Kitchen part_of
part_of part_of
Island part_of
part_of
Counter-2
Stove
part_of
Oven
Counter-1
Floor
part_of
part_of
part_of
Sink
Disposal
part_of
Stovetop
Figure 5: Two object hierarchies.
12
Counter-3
2 State Automaton (FSA-1)
refine 5 State Automaton (FSA-2)
refine 6 State Automaton (FSA-3)
refine 6 State Automaton with Block Graphs in each State (COMBINED)
Figure 6: Model re nement procedure.
13
model at the lowest abstraction/aggregation level. Figure 7 displays three levels of nite 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 ( g. 4) within the knowledge base. A level in the re nement corresponds to a level in the action hierarchy. The topmost FSA in g. 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 g. 7 de ning 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 T = ) 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 speci cation 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 re nement 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 re nement process leaving the transition non-deterministically speci ed. Indeed, the decision whether to continue re nement should be based on the modeling objectives, the accuracy required, and the computational resources available [41, 42].
3.4 A Heterogeneous Re nement
Heterogeneous re nement takes homogeneous re nement 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 res within the Petri net, one may \drop down" into the functional block level. For the last FSA in g. 7 we choose to represent each state as a continuous model. Speci cally, each state will de ne 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 rst de ne 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 signi cant as the resistance of water. The de nition for thermal capacitance C is C T_ = qh with qh being the ow of heat from the heating element to the water. We will let C be the capacitance of the metal pot, C be the capacitance of water, and C be the total capacitance. Newton's law of cooling states that Rqh = T = T ? T where T is the temperature of the source (heating element), and T is the temperature of the water. Since T is our state variable we let T = T for convenience. 1
1
2
2
1
2
2
2
14
I=ON
not Cold
Cold
I=OFF
I=ON or I=OFF
T=α
from Cold
I=ON
not Cold
Heating
(I=OFF and Φ
T=100 Boiling
I=ON I=ON
= Overflow)
Hf = Ht
Exception
I=OFF I=OFF I=ON
Ι=ΟΝ,
Cooling
to Cold
(I=OFF and Φ = Underflow)
T= α
I=OFF
from Boiling
from Boiling
to Boiling Hf = Ht
Exception
I=OFF
Hw = 0 Underflow
Overflow
Hw=0
I=ON
I=ON or I=OFF
Figure 7: Homogeneous FSA re nement.
15
from Cooling
Heating
from Cold I=ON
to Boiling
I=ON
T=100 T(0)=α
F
T 1
k
. T
+ -
T
k
I=ON I=OFF
to Cooling
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: k = CRC+CC (1) T_ = k(T ? T ) (2) Hence, equation (2) is a rst order lag with a step input representing the sudden change in temperature as e ected by a control knob. Figure 8 displays a block diagram of heating within the heating state. Proper coupling is essential in heterogeneous re nements. That is, it must be made clear how components at one level match components at the higher level. Note, in g. 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. Speci cally, the block labeled 'F' performs the mapping from 'ON/OFF' to real-valued temperatures T 100. Due to the latent heat e ect, 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 under ow state since Hw = 0. The low-level continuous models M ; : : :; M are de ned as follows: 1. (M ) COLD: T = , H_w = 0, H_f = 0. 2. (M ) HEATING: T_ = k (100 ? T ), H_w = 0, H_f = 0. 3. (M ) COOLING: T_ = k ( ? T ), H_w = 0, H_f = ?k . 2 Models M and M exhibit rst order exponential behaviors and are, therefore, rough approximations 2 3 1
2
1
2
1
1
2
5
1
2
1
3
2
3
of the actual boiling water system.
16
I=i1
B M1 A M5
LEGEND I=i1
I=i2
External Transition
Internal Transition f(X2)
C M2
Figure 9: Generic phase graph. 4. (M ) BOILING: T = 100, H_w = ?k , H_f = k . 5. (M ) OVERFLOW: same as BOILING with constraint Hf = Ht . 6. (M ) UNDERFLOW: T = undefined, Hw = Hf = 0. The system phase is denoted by and the state variables are: T : temperature of water. Hw : 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 di erent 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: = cold, T (0) = , Hw (0) = Hf (0) = Hs and knob = OFF . By including the functional block knowledge, we create one large model called COMBINED that is de ned as FSA-3 with each state containing a block model (as shown in g. 8). 4
4
5
5
6
3.5 Forming a Multimodel
3.5.1 General Case
We have presented a re nement 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 de ned can be coordinated so that exactly one submodel is active at any time. A multimodel can be created from g. 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 . 17
A di erent model is associated with each phase; for instance, in phase B , the underlying model M will generate the state trajectories. External events are denoted in g. 9 with a solid arc. If in phase A, for instance, and an input of i is received, the phase immediately moves to B and the model is M starting in a state determined by the state of M when the input i occurred; otherwise the phase remains A. Internal (also called state) events occur when the state of a model satis es speci c transition conditions. They are denoted by dashed lines from one phase to another. For instance, in phase A, let f (X ) equal(X ; 4:2). This is interpreted as follows: if the state variable X \reaches" the value 4:2 (i.e., X = 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 multimodel. Let us summarize our example formulation of an FSA-controlled multimodel. In g. 9, the following variables are used: 1
1
1
5
1
2
2
2
2
A, B , and C are phases. I is an input variable. i and i are the values that I can assume; the input has an 1
2
immediate e ect on the phase. X 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 de ned on state variables Xj . 2
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 rst present a formalization. An FSA-controlled multimodel is speci ed by a structure < FSA, MODELS , map, TRANSITIONS >, where FSA is a nite 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 speci ed 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 2 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. 18
We can present the set of models for boiling water as an FSA-controlled multimodel. Our rst step will be to transform the hierarchical system structure into a \ at" structure by collapsing the hierarchy. Using the phase graph notation we create the graph in gure 10 by compressing the three levels in g. 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 ::: 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 g. 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. We refrain from giving this mapping here and restrict our comments to the following: 1
5
3
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. 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 speci cations, 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. 4
3.6 DEVS Abstraction of FSA-Controlled Multimodels
Even though classical system theory [18, 29] provides strong de nitions 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 = R ). The DEVS structure [44] < U; Y; S; ; ; ta > is as follows: 3 Actually, this is strictly true only for the case where the MODELS are restricted to be continuous, + 0
discrete time or discrete event. However, the extension to the general case would not be dicult. 4 There must be a tie-breaking mechanism for handling cases where more than one condition simultaneously becomes true.
19
I=OFF I=ON Heating M2
Cold M1
T=100
Boiling M4
I=ON I=ON
Overflow M5
I=ON
Hf=Ht
I=OFF Hw=0
I=OFF Cooling M3
I=ON
T=α
Underflow M6
Hw=0
I=OFF
I=ON or I=OFF
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. ext : Q U ! S is the external transition function. Q = f(s; e)js 2 S; 0 e ta(s)g 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. int : S ! S is the internal transition function. : S ! Y is the output function. ta : S ! R ;1 is the time advance function. The DEVS formalism, as stated in its title (Discrete Event System Speci cation), 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 de ned as < U; Y; S; ; ; ta >, where: U is the input set of the FSA. Y is the output set of the FSA (not of interest here). S = P 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). ext : Q U ! S is de ned by: ext((p; q); e; u) = (fsa(p; u); M p (q; e)) + 0
( )
where fsa(p; u) is the the phase into which the FSA enters when it receives an input u in phase p, and M p is the transition function of M (p), the model associated with ( )
20
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 de ne ta, we recall that a set of transition conditions is associated with a given phase p. Let Cp?>p0 be the condition for an internal transition from p to p0. Let Tp?>p0 be the time at which Cp?>p0 rst becomes true when M (p) starts in state q. Tp?>p0 is the minimum time t such that Cp?>p0(M p (q; t)) is true. Now, ta(p; q) is the minimum of the Tp?>p0, where p0 ranges over the transitions Cp;p0 in TRANSITIONS . Note that this minimum could be 1 when none of the conditions is satis ed along the state trajectory starting from q in model M (p). These procedures can be best illustrated by referring to the example of g. 9. Consider the following continuous model de nition for M : X_ = X . The direct solution for this di erential equation is X (t) = X (0)et. Now, to calculate the elapsed time starting at t = 0 until the condition X = 4:2 occurs, we must solve et = 4:2=X (0) to obtain t = ln(4:2) ? ln(X (0)). int : S ! S is de ned by: 5
( )
5
2
2
2
2
2
2
2
int(p; q) = (p; M p (q; e)) ( )
where p is the phase dictated by the winning condition, i.e., the phase p0 such Tp?>p0 is equal to ta(p; q). : S ! Y , the output function, can be de ned 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 ; Hf ) for MODELS, and gure 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 Cp!p0 can be written as the membership of a state in the partition block (u; p0) where u is the input prevailing in phase 6
5 6
We assume that such a minimum is well-de ned, as it will be for continuous systems. Applying the tie-breaking rules if necessary.
21
T
100
α
Ht
Ht
Hw
H
f
Figure 11: Continuous state space for boiling water system.
p. For example, in the boiling water example, the transition condition CHEATING!BOILING under the input I = ON is speci ed by the entry for (BOILING; ON ) in table 3. This transition corresponds to reaching the boundary given by plane T = 100 in gure 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 a ords a more ecient 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 corre7
In our simpli ed 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. 7
22
T
T
I = ON
I = OFF
100
α
α
Ht
Ht
Ht
Hw
H
Ht
Hw
f
H
(a) Heating phase
T
I = OFF
100
100
α
α
Ht
Ht
Ht
Hw
H
Ht
Hw
f
H
(c) Boiling phase
f
(d) Cold phase T
T is undefined
I = ON or OFF
f
(b) Cooling phase
T
I = ON or OFF
100
I = ON
100
100
α
α
Ht
Ht
Ht
Hw
H
Ht
Hw
f
(e) Under ow phase
H
(f) Over ow phase
Figure 12: Phase partitions. 23
f
Table 3: Partitioning of boiling water state space.
Phase COLD COLD HEATING HEATING COOLING COOLING BOILING BOILING OVERFLOW OVERFLOW UNDERFLOW UNDERFLOW
I ON OFF ON OFF ON OFF ON OFF ON OFF ON OFF
T = > ^ < 100 > ^ < 100 = 100 = 100 = 100
Hw > 0^ < Ht > 0^ < Ht > 0^ < Ht > 0^ < Ht > 0^ < Ht > 0^ < Ht =0 =0
Hf > 0^ < Ht > 0^ < Ht > 0^ < Ht > 0^ < Ht > 0^ < Ht = Ht =0 =0
spondence between the states of the two systems is preserved under corresponding transitions. 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 DEVSbased 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 gures 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 speci ed 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 de nite boundary crossing. The control of the boiling water system is driven by the discrete event simulation of the FSA in g. 10. The low level di erential equation models are simulated using Runge-Kutta integration while performing boundary 24
checks for internal events.
4 Question Answering and Choice of Model Now that we have speci ed 3 automata levels, one functional block level and a DEVS speci cation, 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 speci ed 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?" \Model" refers to the level of abstraction as speci ed 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 speci ed 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 over ow state by the manifestation link in the action tree in g. 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 di erent classes of questions about the system. De nition 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 a orded 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 rst 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 de ned then a variety of graph oriented modeling methods and the DEVS speci cation language 25
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.
5 Conclusions We have used a system of boiling water to demonstrate how to create an FSA-controlled multimodel which eciently 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 o at time X?" On the negative side, since our focus is on the formal structure of multimodels, we have ignored some dicult 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; however, 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 nite 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 nal level of abstraction. In addition, a DEVS speci cation was provided to formalize the multimodel concept in a system theoretic manner. The DEVS formulation also allowed casting the multimodel into a form for ecient discrete-event simulation. 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 arti cial systems capable of modeling and reasoning about physical systems. Heuristic approaches to event identi cation 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 di erent 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 26
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.
References [1] Addanki, S., Cremonini, R., and Penberthy, J. S. Reasoning about Assumptions in Graphs of Models. In Eleventh International Joint Conference on Arti cial 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 Autonomy Systems (Cocoa Beach, FL, April 1991), pp. 233 { 240. [3] Bobrow, D. G. Qualitative Reasoning about Physical Systems. MIT Press, 1985. [4] Cellier, F. E. Combined Continuous System 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 Con uences. In Qualitative Reasoning about Physical Systems, D. G. Bobrow, Ed. MIT Press, 1985, pp. 7 { 83. [6] Fishwick, P. A. Hierarchical Reasoning: Simulating Complex Processes over Multiple Levels of Abstraction. PhD thesis, University of Pennsylvania, 1986. [7] Fishwick, P. A. The Role of Process Abstraction in Simulation. IEEE Transactions on Systems, Man and Cybernetics 18, 1 (January/February 1988), 18 { 39. [8] Fishwick, P. A. Abstraction Level Traversal in Hierarchical Modeling. In Modelling and Simulation Methodology: Knowledge Systems 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 Systems with Applications 3, 3 (1991), 317 { 327. [10] Fishwick, P. A. Fuzzy Simulation: Specifying and Identifying Qualitative Models. International Journal of General Systems 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. 27
[12] Fishwick, P. A. Computer Simulation Modeling: Methodology, Algorithms and Programs. 1992. (to be published as a textbook). [13] Fishwick, P. A., and Luker, P. A., Eds. Qualitative Simulation Modeling and Analysis. Springer Verlag, 1991. [14] Fishwick, P. A., and Modjeski, R. B., Eds. Knowledge Based Simulation: Methodology and Application. Springer Verlag, 1991. [15] Fishwick, P. A., and Zeigler, B. P. Qualitative Physics: Towards the Automation of Systems Problem Solving. Journal of Theoretical and Experimental Arti cial Intelligence 3 (1991), 219 { 246. [16] Forbus, K. D. Qualitative Physics: Past, Present and Future. In Exploring Arti cial Intelligence, H. Shrobe, Ed. Morgan Kaufmann, 1988, pp. 239 {296. [17] Forbus, K. D., and Falkenhainer, B. Self-Explanatory Simulations: An Integration of Qualitative and Quantitative Knowledge. In AAAI (1990), pp. 380 { 387. [18] Kalman, R. E., Falb, P. L., and Arbib, M. A. Topics in Mathematical Systems Theory. McGraw-Hill, New York, 1962. [19] Klir, G. J. Architecture of Systems Problem Solving. Plenum Press, 1985. [20] Kreutzer, W. System Simulation: Programming Styles and Languages. Addison Wesley, 1986. [21] Kuipers, B. Qualitative Simulation. Arti cial Intelligence 29, 3 (September 1986), 289 { 338. [22] Kuipers, B., and Chiu, C. Taming Intractable Branching in Qualitative Simulation. In Tenth International Joint Conference in Arti cial Intelligence (Milan, 1987), pp. 1079 { 1085. [23] Nance, R. E. The Time and State Relationships in Simulation Modeling. Communications of the ACM 24, 4 (April 1981), 173 { 179. [24] Nance, R. E. A Conical Methodology: A Framework for Simulation Model Development. 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 ModelBased Methodologies: An Integrative View. Springer Verlag, 1984, pp. 3 { 40. [26] Oren, T. I. Simulation Model Symbolic Processing: Taxonomy. In Systems and Control Encyclopedia. Pergammon Press, 1987, pp. 4377 { 4381. [27] Oren, T. I. Simulation: Taxonomy. In Systems and Control Encyclopedia. Pergammon Press, 1987, pp. 4411 { 4414. 28
[28] Oren, T. I. Dynamic Templates and Semantic Rules for Simulation Advisors and Certi ers. In Knowledge Based Simulation: Methodology and Application. Springer Verlag, 1991, pp. 53 { 76. [29] Padulo, L., and Arbib, M. A. Systems Theory: A Uni ed State Space Approach to Continuous and Discrete Systems. W. B. Saunders, Philadelphia, PA, 1974. [30] Praehofer, H. System Theoretic Foundations for Combined Discrete-Continuous System 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, 1986. [33] Reichenbach, H. The Philosophy 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 System Dynamics. Addison Wesley, 1967. [36] Struss, P. Global Filters for Qualitative Behaviors. In AAAI (1988), pp. 275 {279. [37] Weld, D. S. Combining Discrete and Continuous Process Models. In Ninth International Joint Conference on Arti cial Intelligence (August 1985), IJCAI, pp. 140 { 143. [38] Weld, D. S. The Use of Aggregation in Causal Simulation. Arti cial Intelligence 30, 1 (October 1986), 1 { 34. [39] Weld, D. S., and de Kleer, J., Eds. Readings in Qualitative Reasoning about Physical Systems (Palo Alto, CA, 1990), Morgan Kaufmann. [40] Wymore, A. W. A Mathematical Theory of Systems Engineering: The Elements. Krieger Publishing Co., 1977. [41] Zeigler, B. P. Theory 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 Multiplicity of Levels. In Individual Development and Social Change: Explanatory Analysis. Academic Press, 1985, 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: Intelligent Agents and Endomorphic Systems. Academic Press, 1990. 29
Appendices We rst include some background information on SimPack and then specify pseudo-code for simulating the models in gures 9 and 10. SimPack is a collection of C-based programs and libraries for simulation. For the algorithms speci ed in appendices A and B, we require two basic simulation approaches 1) the ability to simulate a nite state machine, and 2) the ability to simulate a set of di erential equations. For the rst 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) combined2: di erence and di erential equations "Delay di erential equation x0 = a x(t ? 1)" 2. dec: Declarative modeling (a) fsa: nite state automata with timed states (b) markov: Markov model with timed states (c) pulse: Pulse process 3. equation: Equational modeling (a) di erence : Di erence equation modeling i. log1: Logistic equation ( rst order) ii. log2: Logistic equation (second order) iii. di 1: Circular queue simulation method on log1 iv. bifurc: Bifurcation analysis on log1 (b) di erential: Di erential equation modeling i. deq: Equation parser and solver ii. integrate: Sample Euler and RK4 integrations 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 30
(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(&E) 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 T is the amount of time to elapse before executing event E. 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 di erential 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 speci c 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 dicult to determine which event comes rst: (1) a speci c input value, or (2) a state event occurrence.
Appendix A
Algorithm for Simulating Model in Fig. 9 next event(&event); save-state(); switch(event) f /* external events - list all input values as cases */ i1: switch(phase) f A: schedule(B,0); break; C: schedule(B,0); break; g /* end switch */
break;
31
i: 2
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),M5) < time input(i1)) schedule(C,time state(f(X2 ),M5 )); B:
break;
phase = B; instantiate(M1 ,get-state()) break; C: phase = C; instantiate(M2 ,get-state()) break; g /* end switch */
Appendix B
Algorithm for Simulating Model in Fig. 10 next event(&event); save-state(); switch(event) f /* external events - list all input values as cases */ on: switch(phase) f cold: schedule(heating,0); break; cooling: schedule(heating,0); break; g /* end switch */ o :
break; switch(phase) f
heating: schedule(cooling,0); break; boiling: schedule(cooling,0); break; over ow: schedule(boiling,0); break; g /* end switch */
break;
/* internal events - list all phases in graph as cases */ cold: phase = cold; instantiate(M1 ,get-state()); break; heating: phase = heating; instantiate(M2 ,get-state()); if(time state(equal(T,100),M2 ) < time input(o )) schedule(boiling,time state(equal(T,100),M2 )); cooling:
break;
phase = cooling; instantiate(M3 ,get-state()); if(time state(equal(T, ),M3 ) < time input(on)) schedule(cold,time state(equal(T, ),M3 ));
32
boiling:
over ow:
break;
phase = boiling; instantiate(M4 ,get-state()); if(time state(equal(Hf ,Ht),M4 ) < time input(o )) schedule(over ow,time state(equal(Hf ,Ht ),M4));
break;
phase = over ow; instantiate(M5 ,get-state()); if(time state(equal(Hw ,0),M5 ) < time input(o )) schedule(under ow,time state(equal(Hw ,0),M5 ));
break;
under ow: phase = under ow;
33
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 OFF. 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 74C . How long will it take to cool to room temperature if the knob is turned o 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 over owing 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 100 C which caused the water to boil.
34
