Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: An Integrated approach to system modelling using a synthesis of artificial intelligence, software engineering and simulation methodologies
Full Citation
Permanent Link:
 Material Information
Title: An Integrated approach to system modelling using a synthesis of artificial intelligence, software engineering and simulation methodologies
Series Title: Department of Computer and Information Science and Engineering Technical Reports
Physical Description: Book
Language: English
Creator: Fishwick, Paul A.
Publisher: Department of Computer and Information Sciences, University of Florida
Place of Publication: Gainesville, Fla.
Copyright Date: 1992
 Record Information
Bibliographic ID: UF00095108
Volume ID: VID00001
Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.


This item has the following downloads:

199235 ( PDF )

Full Text

An Integrated Approach to System Modelling using

a Synthesis of Artificial Intelligence, Software

Engineering and Simulation Methodologies*

Paul A. Fishwick
University of Florida.

Traditional computer simulation terminology includes taxonomic divisions with
terms such as "discrete event," "continuous," and pi.... --. oriented." Even though
such terms have become familiar to simulation researchers, the terminology is distinct
from other disciplines such as artificial intelligence and software engineering which
have similar goals relating specifically to modelling dynamic systems. There is a need
to unify terminology among these disciplines so that system modelling is formalized in
a common framework. We present a perspective that serves to characterize simulation
models in terms of their procedural versus declarative orientations since these two orien-
tations are prevalent throughout most modelling disciplines that we have encountered.
We used a sample dynamic system (e.g., two jug problem) found in artificial intelli-
gence to highlight the connecting threads in system modelling within each discipline.
Moreover, in teaching simulation students using this perspective, we have had consid-
erable success in relating the field of modelling within computer simulation to other
sub-disciplines within computer science. The result is that modelling in simulation can
be more easily compared-with and contrasted-against other modelling approaches in
computer science.

Categories and Subject Descriptors: D.2.1 [Software Engineering] Require-
ments/Specifications Methodologies; D.2.2 [Software Engineering] Tools and Tech-
niques Computer-aided software engineering; D.2.10 [Software Engineering] Design
Methodologies, Representation; 1.2.0 [Artificial Intelligence] General Cognitive
Simulation; 1.2.4 [Artificial Intelligence] Knowledge Representation Formalisms and
Methods Representations; 1.6.1 [Simulation and Modeling] Simulation Theory-
Model classification, systems theory; 1.6.5 [Simulation and Modeling] Model De-
velopment Modeling methodologies. 1.6.8 [Simulation and Modeling] Types of
Simulation Combined, Discrete event, Continuous.
General Terms: Modeling.
Additional Key Words and Phrases: Multimodeling, Abstraction Levels.
*Author's Address: Paul A. Fishwick, Dept. of Computer and Information Sciences, University of Florida,
Bldg. CSE, Room 301, Gainesville, FL 32611. This paper is an enhanced and comprehensive manuscript
based on initial results [34] prepared for the Third Conference on AI, Simulation and Planning in High
Autonomy Systems.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 2

1 Introduction

Computer simulation is the creation and execution of dynamical models employed for un-
derstanding system behavior. Even though the literature base in simulation is quite large,
many simulation textbooks serving as archives for future researchers and students cover
simulation methodology using the classic taxonomies including terms such as "continuous,"
"discrete I --. ," and "event-oriented." This type of taxonomy may seem comfortable and
familiar; however, we will demonstrate that for the task of modelling, we need to strengthen
ties with artificial intelligence (AI) and software engineering (SE) to provide a more uniform
view of system modelling that is less focused on one particular simulation method (such as
discrete event simulation), and more attuned to modelling continuous, discrete models and
spatial models using a unified framework. First, we stress that "modelling" and "simulation"
are two different tasks and we will attempt not to use them interchangeably; one model may
be simulated using several different simulation algorithms. When reviewing -,-.,ild vi. "
in discrete event simulation, it is sometimes tempting to confuse a method of modelling such
as process orientation (i.e., a functional modelling approach) with a method of simulating
or executing a model such as event scheduling (i.e., an approach of simulating parallelism of
a model on a sequential architecture).
Our emphasis is on modelling methodology [89, 65, 66, 25, 24] rather than ,i,, ..ii method-
ology. Methodology in analysis has received a much more comprehensive treatment in the
general simulation literature [54, 9] as compared with methodology in modelling. The art
and science of modelling has a firm foundation within the computer science discipline, and
consequently, we find several examples in computer science that serve to bolster our argu-
ment for a more integrated modelling approach that encapsulates many of the modelling
methods in AI, SE and simulation. There are key facets of simulation modelling that are
strongly related to parts of AI and SE, and these facets appear to be more fundamental to
the nature of simulation modelling than are the current divisions along the lines of "dis-
crete event," "continuous" and "combined" or .I Ivity scanning," "event scheduling" and
"process interaction" as frequently discussed in the simulation literature. For example, the
data flow diagram (DFD) in SE and the block model in simulation and control engineering
represent the same modelling technique; the DFD has elements including functional blocks,
inputs, outputs, coupling and hierarchy; the same is true of the functional block model in
SE. In the past, the two modelling camps could be considered completely separate entities;
however, with the onset of distributed computing and the encapsulation of code in phys-
ically separated and, therefore, modelled objects, software engineers are every bit as
interested in modelling continuous and discrete data flows as are simulation modellers. In
SE, a data flow diagram represents a modelling technique utilized for a variety of models.
In simulation, we should also use this functional category of modelling to represent queuing
networks, digital logic circuits and systems for control ei .-;, I;,.-. there are some differences
in the data flow (discrete versus continuous), although this is a minor difference and does
not represent a fundamental shift in modelling practice.1
Our hypothesis is that, while the current taxonomies for modelling in simulation have
1In terms of closed form analysis, it is natural to form a dichotomy between "discrete" and "continu-
ous" since the solution methods are different. With system modelling, though, the differences are not as

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 3


CONCEPT Non-executable

Complexity DECLARATIVE FUNCTIONAL Homogeneous Nodes
Sin model graph
& Inter-node coupling

HETEROGENEOUS Heterogeneous Nodes
in model graph
& Inter-node coupling

MULTI-MODEL Inter-level coupling

Figure 1: The proposed modelling paradigm.

served their purpose, we need to consider another taxonomy that fits more closely with re-
lated modelling efforts in the AI and SE communities. The modelling of dynamic systems
has become a widespread phenomenon and is no longer specific to the simulation discipline;
we need to embrace these competing areas to derive a common taxonomy or -.-,ild view"
with regard to system modelling. This alternative taxonomy is based on a set of modelling
approaches depicted in figure 1. In fig. 1, the first type of model is the concept model which
corresponds to an object model within SE or a system entity structure [91]. The concept
model is non-executable, and serves as a knowledge base for the system. From the concept
model, one can derive either one of two basic modelling forms: declarative and functional.
Declarative models emphasize state transitions, while functional models emphasize opera-
tional or event oriented modelling. Declarative and functional model forms are prevalent
in all three disciplines. For instance, programming languages are often categorized into ei-
ther declarative [1, 49] or functional [48, 6] types. The declarative programming languages
(such as Prolog) emphasize changes in state where "states" are best coded as particular data
structures -a simple variable being the most commonly used form for a state. Functional
programming languages concentrate on functional composition while de-emphasizing side
effects2. One may combine these forms to synthesize heterogeneous models where model
graph nodes may be of different types. Finally, the multimodel [33, 57, 37] is the most com-
prehensive type of model that supports multiple models tied together with homomorphic
mappings from one model to another -'"]. The multimodel approach is a generalization of
combined simulation modelling [18, 71] where models may be of many different types
not just a mixture of discrete event and continuous components. The proposed taxonomy
is an extension to the object oriented modelling paradigm. While we adhere to the object
model as a good basis for conceptual, non-executable models, we depart from the norm
2The -.1. I. . I for software encoding dynamical system behavior are actually the states of the system.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 4

when introducing how additional modelling techniques such as production systems, track-
based animation and System Dynamics fit within the overall framework. In the usual object
oriented modelling approach within SE [79, 16], specific modelling methods such as FSA
modelling and DFDs are promoted. We treat these two types of models as instances of a
class rather than a class by itself. Our approach is to stress the utility of having functional
and declarative classes of models. In our declarative modelling class, for instance, we list
several types of models including FSAs, production rules, and logic based models.
We are interested in overviewing the commonalities in the modelling process as well
as asking fundamentally interesting historical questions such as "What are the causes or
catalysts aiding in the relatively recent convergence in AI, SE and simulation modelling?"
and "How, precisely, will modellers and decision makers benefit in this convergence?" The
integrated style is being used by several simulation researchers [92, 60, 78, 66, 33, 3]; however,
it has not yet penetrated the general simulation textbook literature as a more powerful
paradigm for modelling dynamical systems. Although the introduction of new dichotomies,
taxonomies and reorganizations is a philosophical issue, we have had first hand experience
in teaching the proposed simulation modelling methodology to college seniors and first year
graduate students at the University of Florida with much success. Students who take, for
instance, courses in AI and SE can take a class in simulation that builds upon rather than
replaces recently learned model forms.
Two key aspects of the view shown in fig. 1 are the declarative versus the functional per-
spectives. These two modelling views form a dichotomy in that most modelling methods in
simulation are oriented toward one view rather than the other. System Dynamics models [74]
and block models, for instance have functional orientations. The term "dichotomy" is used
somewhat loosely, though, since there exist several kinds of modelling methods such as Petri
nets [70] that have equal shares of declarative (i.e., place) and functional (i.e., transition)
We first overview why we chose these two categories in our attempt to synthesize system
modelling techniques in AI, SE and simulation. Within the context of a two jug problem in
AI, we then discuss how the jug system can be viewed from these two perspectives. Finally,
the multimodel approach is illustrated to demonstrate how models of different types may be
coupled together to form a multimodel or "model database." We close with some conclusions
and research currently underway to extend these ideas.

2 Synthesis of Modelling Techniques

2.1 AI & Simulation Models

Within AI, one is concerned with how to model human thought and decision making. Often,
the decision making is heuristically based, and there is incomplete knowledge about the
domain [56]. This "incomple n .. should be programmed into the dynamical model where
it is present. For the past decade, the interface area between AI and simulation has grown,
and several papers and texts have appeared [63, 64, 84, 36, 43]. Simulation models have
characteristically been composed of simple entities and objects; however, the introduction of
autonomous agents within the queue into a model has .-1. 1 that simulationists use AI

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 5

models in places where autonomy is present. While a simple queuing network avoids the use
of knowledge based simulation models, a more detailed model would include beliefs, plans and
intentions of the autonomous agents in the queue at some level of detail. Trajectories of
projectiles and three phase motors are comparatively simple to model because these objects
operate in accordance with natural laws that are controlled through eni.-,li.. !;i-. the laws
and control methods for non-autonomous objects are fairly simple with regard to model
complexity. Models of intelligent agents are much more complicated due to the sophisticated
reasoning abilities of humans and of robots that are endowed with human-like reasoning.
Autonomy has, therefore, spawned the creation of knowledge based models that contain
a variety of natural, artificial and intelligent objects interacting and reasoning in a complex
environment. The fields of qualitative reasoning and qualitative physics [83, 13] are evidence
of the AI interest in system modelling from the perspective of mathematical reasoning. In
addition to autonomy playing a critical role, incomplete knowledge is ever present within
models and AI researchers have -,,.-i-- -1. .1 new ways of representing this type of knowledge.
While simulationists have used probability theory for representing abstracted quantities,
one can also use heuristic rules and constraint based modelling techniques. These types of
techniques have been used for declarative and functional modelling [S i]; however, they are
most useful within conceptual models that serve to enhance our ability to diagnose symptoms,
plan future actions and provide common-sense explanations of device behavior [83, 22].

2.2 SE & Simulation Models

Software engineers are pioneering new and novel methods for building system models; tools
such as Foresight [5] provide the modeller with the capability of modelling dynamic systems
using finite state automata and block modelling all under the umbrella of object organiza-
tion. Software engineers have developed a keen interest in simulation; there is an apparent
convergence between these two areas [76, 68, 7, 8, 61, 45, 46]. Some of our previous re-
search [31, 30, 32, 37] has -.-' 1. 1 the study of model engineering as a direct analog to
software engineering. Within the simulation community, Zeigler presents a theory for mod-
elling autonomous agents [92] while implementing a model engineering methodology. The
historical reason for the convergence of the SE and simulation fields lies in the area of
distributed and real-time design [72] and computing. Technology has seen the computer
decrease in size and cost while increasing in power. This combination of circumstances natu-
rally leads to the use of computers in almost every electro-mechanical device. When software
engineers had to concern themselves with modelling only mainframe or workstation software,
the modelling process dealt with functional decompositional methods: creating hierarchical
routines and stubs while gradually expanding the size and complexity of the program. Now,
however, with the ever expanding migration of the microprocessor, the structural compo-
nents of software models are beginning to act and appear like the physical objects in which
the processors live. Modelling distributed software, with its emphasis on communication
protocols, is similar to modelling the physical objects for which the software is written.
Thus, the convergence of SE and simulation models stems largely from distributed com-
puting. There are key differences, though, between the end results one obtains. Software
engineers want an executable program, while simulationists want to model the performance
and lumped behavior of the system. While these two avenues appear to diverge, there is

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 6

actually a confluence. The confluence is best seen at a higher level in the decision making
process that oversees the use of software engineers and simulationists. That is, the deci-
sion maker who wants to create efficient and correct distributed software for his inter-bank
transaction project, for instance, is also highly concerned with the efficiency of the entire
distributed architecture. Whereas, a decade ago, a project might have involved simulation
before or during actual construction of hardware, communications pathways and distributed
software, now a project can be created while cleanly integrating the tasks of performance
analysis with software development. The ultimate simulation is the actual creation of the
software which is then executed; lumped statistical behaviors can easily be obtained when
one has the lowest level performance traces. The ultimate software development tool is one
that permits modelling the software at a variety of abstraction levels -the lowest level
providing detailed behavior of the sort normally associated with program input and output
traces. Given this view, simulation is the process of creating abstract versions of programs;
the final most detailed simulation is simply the executable program.

3 Terminology

3.1 Using Systems Theory as a Starting Point

For the fundamental building primitives comprising models that represent time-dependent
system behavior, we have found systems theory [69, 87, 52, 51] to provide the most mathe-
matically consistent foundation. Systems theory has developed since the early 1960s into a
field that made precise the core components of - iin-;" regardless of the specific discipline
(i.e., computer science, biology, chemistry, physics, operations research) [12, 4]. The first
formal theories for discrete event simulation [88, 89, 91] were founded upon systems theory,
and much recent work has continued this trend. Even though our proposed paradigm is
consistent with object oriented modelling, we were surprised at the lack of system theoretic
formalism present in AI and SE general; the formal emphasis within SE seems to be within
formal verification and correctness of programs. AI has many formalisms of which mathe-
matical logic is the most prominent. On the other hand, simulation literature is relatively
weak in its use of logic and in its emphasis on correct programs implementing models; how-
ever, recently there has been renewed interest within the use of logic to both verify and
simulate models [62].

3.2 The Generic Model Structure

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

T is the time set. For continuous systems [19], 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.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 7

Q is the state set.

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

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

A is the output function, A : T x Q Y.

A system is time invariant if its behavior is not a function of a particular interval of time.
This simplifies 6 to be of the following form: 6 : Q xT x -- Q. Here, 6(s, t, ) yields the
state that results from starting the system in s and applying the input w for a duration of
t time units.
This formalism, although concise, is quite general. For structural reasons we employ
techniques such as level coupling, inter-level coupling and hierarchy to make the overall sys-
tem more manageable; however, we first identify some key pieces within the above definition.
Q is also known as the state space of the system. An element s G Q is termed the state of
the system, where the state represents a value that the state components can assume. The
state of an ice hockey puck would be (x, y) whereas the state of a two-queue system would
be (ql, q2) where qi represents the number of entities in queue i. Normally the state has a
structure of an n-tuple: {sl, s2,... s8} however, it is best generalized as a data structure
-a tuple being one type of data structure. Superstates provide flexibility in describing
some model forms [35]. A superstate is a subset of a state, therefore, "goal" is the subset
of the hockey puck state representing the geometrical region where the goal net is located3.
A pair consisting of a time and a state (t, s) where s e Q is called an event. Events are
points in event space just as states are points in state space. Event space is defined as
Q x T. Events normally represent values of state that correspond to definite cognitive or
lexical mappings [10, 11]. For instance, in a queueing model we identify an event as an
"arrival" but we may not have words to represent the values of other states whose values
do not correspond to a cognitive or lexical association. State and Event are critical aspects
of any system and by focussing on one or the other, we form two different sorts of models:
declarative models that focus on the concept of state, and functional models that focus on the
concept of event. States represent a "snapshot" of a system, while events, even though they
occur at points in time, are naturally associated with functions (i.e, routines, procedures).
A change in state is associated with an event, and vice versa; so, there is a duality between
states and events. Declarative and functional orientations are discussed widely in both AI
and SE, and we propose that they share a common bond with simulation modelling as well.
Given basic elements such as states and events, we can structure models in various ways
to aid us in better analyzing systems. By coupling functions or states, and by making
networks and hierarchies we can simplify the overall model organization. We will call one
model an "abstraction level" or a "perspective." Abstraction levels are discussed by many
researchers in SE [58], AI [82] and simulation L-'; 29]. A model can contain homogeneous or
heterogeneous node types; simple modelling constructs are homogeneous (such as FSAs), and
more complex constructs are heterogeneous (such as System Dynamics graphs, Petri nets or
3The concept of superstate in SE is discussed by Davis [21]

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 8

bond graphs). If the hierarchical organization is not purely representational (i.e., all levels
can be collapsed into a single model) then we can have multimodels where many models are
attached to one another via behavior-preserving homomorphic links.

4 Concept Models

Models whose components have not been clearly identified in terms of system theoretic
categories such as state, event and function are called "concept mod.l 1" [81]. Conceptual
models are a logical first step to modelling; research in these models has many connections in
AI, SE, systems science and simulation. At first, it would appear that non-executable models
should play no part in simulation. Simulationists have historically not spent a considerable
amount of time on "model engineering" (with exceptions noted in the previous section);
even though the need for iterating through the modelling process is well understood and
appreciated, there is little textbook methodology present to aid simulationists in this key
area. Model engineering does not lend itself to a nice neat formalism, and therefore the
engineering aspect of simulation modelling is often part art and part science [80]. Despite this
difficulty in formalization, model engineering is a critical task and should be a central activity
within the simulation field; we want to better understand the very nature of modelling
including how and why we choose the models that we do during the course of systems
analysis. The area of Systems Dynamics [42, 41, 74, 75] focuses, not only on the formalism
for a dynamic model but also, on several key steps during the model building process:
1) causal model without signed information, 2) causal model with signed arcs and loops,
3) flow graph, and finally 4) equations (or program). These steps provide clues as to how we
might engineer more generic models. This is not to -i-'-. -1 that we should abandon all of
our modelling methods in favor of the Systems Dynamics approach. Instead, we note that
one success of the approach is its clearly emphasized model engineering steps.
The first type of model that we want to create is a concept model that emphasizes a
objects and their relations to one another. From such a model, we can gradually progress to
more system theoretic constructs. The concept model in AI is termed a semantic network [ii.
27, 17], while equivalent model in SE is the object model with attribute definition [79, 15, 16,
14]. Most work in simulation, concerning concept models, has been performed along the lines
of model specifications [59, 68] and the system entity structure [89, 92]. Since simulation has
its formal roots in systems theory and science, we find work relating to conceptual modelling
in these areas as well [20, 52, 38]. The semantic network, even though it can serve as a rough
cut of a simulation model, was often built as an end in itself, or to facilitate qualitative
reasoning via link traversal. Semantic networks are traversed to answer simple questions
about a system. Simulationists need such models to augment their mathematical system
models since there is often a need to ask more than simply "predict when object XYZ
reaches point B" or "give the mean idle time for the cashier." It would also be useful for
simulationists to be able to ask more abstract questions about a system, and furthermore, to
obtain abstract answers that serve in forming a causal explanation of system behavior [77].
The typical AI semantic network would be very weak at producing precise quantitative
answers; however, similar claims can be made against an equational simulation model -it
produces precise answers but cannot produce simple explanations of behavior in "close-to"

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 9

IJug A Jug B
3 gallons 4 gallons

Figure 2: Two jug system.

natural language expression. Therefore, concept models not only provide a "specification"
for a simulation model, they are simulation models at high levels of abstraction.
The object modelling approach in SE has produced the equivalent of the AI semantic
network, but for a different purpose: to permit a software engineer to prototype a large
software system. Our approach is similar to object oriented design principles espoused in
SE: begin with an object representation and then produce declarative and functional model
types. Let's consider the water jug problem in AI [53, 73]. In the water jug problem, there
are two water jugs (one with a three gallon capacity, and the other with four gallons). Jug A
is the three gallon jug and jug B is the four gallon jug (see figure 2). There are water spigots
and no markings on either jug. There are three basic operations that can be performed in
this system: emptying a jug, filling a jug, or transferring water from one jug to the other. A
concept model can be created by concentrating on key objects, concepts and actions within
the system. Rumbaugh et al. [79] present a useful checklist for deriving the object model:

1. Identify objects and classes.

2. Prepare a data dictionary.

3. Identify associations and .-.-!. -.t ions among objects.

4. Identify attributes and objects and links.

5. Organize and simplify object classes using inheritance.

There are no hard rules for developing an object model; however, this checklist serves
as a starting point by suggesting guidelines. The complete process would involve iterative
refinement of the rules. Let's consider each guideline with respect to the two jug system. An
object graph will be composed of vertices and arcs, so we start by defining the nodes. Objects
will be considered either classes, which define broad categories, or instances, which define
examples within classes. Nouns are often a good place to start when identifying classes. For
instance, the noun "tap" is a good class since there are many different types of taps including
the two used in the system. If we use the statement of the system description, we arrive
at the following classes: tap and container. We consider tapA and tapB to be examples of

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 10



Figure 3: Class model: two jug system.

a tap, and jug and barrel to be sub-classes of container. JugA and JugB compose every
known jug in this closed v.,uild." We can then create a data dictionary where encyclopedic
information about the classes and instances are stored. Our associations often take the
form of verbs or operations associated with the system; therefore, fill, ,'pl/i and transfer
are natural selections for associations. The choice of attributes depends on the kinds of
questions that we will be asking of the system. If we will in the section on declarative
modelling define the operations in terms of integral amounts of water, then level of water
and rate of water flow will be key attributes. After some additional iteration we arrive at
the concept and instance models depicted in figures 3 and 4.

5 Declarative Models

In declarative modelling, we build models that focus on state representations and state-to-
state transitions: given a state and a transition, the model will provide the next state. This

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 11



Figure 4: Instance model: two jug system.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 12

simple metaphor provides for a whole class of models. The FSA and Markov models in
simulation are the most basic declarative model types.4 In SE, the state transition model is
termed the "dynamic" or "state" model. Harel [44] extends the basic state model to form
state charts containing embedded hierarchies of FSA levels. The use of the word "dynamic" is
somewhat unusual from a simulationist's perspective since data flow diagrams are also a valid
form of dynamic model representing input, transfer functions and outputs coupled within
a block network diagram. On the other hand, in SE, the reference to "dynamic" reflects
that state change is at the heart of dynamics. This is in agreement with systems theory and
all three disciplines although memoryless functions can also represent dynamical systems.
Moreover, if FSAs are embedded within another formalism (such as a data flow diagram)
then that formalism is also considered dynamic. In AI, the declarative approach to system
modelling is quite advanced since there are several AI declarative representations that can
be useful in modelling. From AI, we can enrich the state-oriented declarative modelling ap-
proach to include logic, rules, and production systems. The declarative approach need not be
limited to simple state to state transitions. For instance, in AI we often find pattern match-
ing or constraint approaches in the unification process present within logic programming;
pattern matching over a state space Q provides a convenient method of defining superstates
(i.e., subsets of state space). For instance, if Q = X1 x X2 for a two dimensional hockey
rink then the goal net location could be specified by the constraint {(X, Y) Y < 10}. Logic
programming and, especially, constraint based programming [55, 47] typify the declarative
approach to modelling using state space partitions to create superstates. The production
system, constraint and logic approaches utilize unification and pattern matching to afford
declarative methods the capability of representing complex behaviors with a modicum of
mathematical notation.
Methods of production systems [23] and formal logic [26] (either standard or temporal)
may be used as a basis for simulation modelling. We need to define the concept of state,
input and time with respect to these models:

State is defined as the current set of facts or truths in a formal system. For pred-
icate logic this equivalences to a set of predicates. For expert systems, the rule or
"knowledge" base is the state of the system.

For production systems, inputs are known as "operators" which are executed by the
controlling agent. A sequence of parameterized calls to the operators serve as the input
stream that controls the system. We will associate time durations with input events
by saying that whenever an input event occurs (which causes a change in state), the
ensuing state will last for some specified period of time.

Time can be assigned to each production or inference so that the process of forward
chaining produces a temporal flow. We could make state variables vary continuously
or discretely.

The state of the water jug model will be identified by a set of predicates. Note that
predicates and arguments are both in lower case. The state is defined as (X, Y) where X is
the amount of water (in gallons) in the 3 gallon jug, and Y is the amount of water in the 4

4In systems theory, the the FSA is sometimes termed a "local transition function."

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 13

gallon jug. We define states to vary using discrete jumps so that filling an initially empty
jug A, for instance, would cause a jump from state (0, 0) to (3, 0). We will assume an initial
state of (0, 0) (i.e. both jugs are empty). Time will be measured in minutes, therefore rates
are measured in terms of gallons per minute. Filling is somewhat slow and proceeds at a
rate of 2 gallons per minute. All other operations take 10 gallons per minute. There are 4
operators defined as follows:

The operator and description.

Conditions for the operator to be applied (i.e., fire).

The time duration AT of the operator if it is applied. The duration is associated with
the current state.

1. OPERATOR 1: errn.l,(J).

(a) Empty jug J {A, B}.
(b) For J = A, (X, Y X > 0) (0, Y) and AT
(c) For J = B, (X,Y Y > 0) (X, 0) and AT


2. OPERATOR 2: fill(J).

(a) Fill jug J {A,B}.
(b) For J = A, (X, Y X < 3) (3, Y) and AT
(c) For J = B, (X, YY < 4) (X,4) and AT

(3- X)/2.
(4 Y)/2.

3. OPERATOR 3: xferall(J1, J2).

(a) Transfer all water from jug J1 to jug J2.
(b) For Jl = A, (X, YIX + Y 4AX > OA Y

< 4) -- (0,X + Y), and AT

(c) For Jl =B, (X, YX +Y 3 A Y > O AX < 3) (X+Y,O), and AT

4. OPERATOR 4: xferfull(J1, J2).

(a) Transfer enough water from jug J1 to fill J2.
(b) For J1 = A, (X,YX + Y > 4 A X > 0 A Y < 4) (X (4 Y),4), and
AT = (4 Y)/10.
(c) For Jl = B, (X, YX + Y > 3 A Y > 0 A X < 3) (3,Y (3 X)), and
AT = (4 Y)/10.

The application of various operators will change the current state to new state. For instance,
given the initial system state as being (0, 0) we see that we can apply only operator fill.
Specifically, we can do either fill(A) or fill(B). Both operations take a certain amount of
time AT. The AT is associated with the current state. Let's look at the time taken to fill
jug A. We note that the production rule associated with this operation is: "For J = A,
(X, YIX < 3) -- (3, Y) and AT = (3 X)/2." To go from state (0, 0) to (3, 0), for instance,


CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 14

will take a total time of T = (3 0)/2 or T = 1.5. This is interpreted as: "if the system is in
the state (0, 0) and the operator fill is input to the system then the system will enter state
(3, 0) in 1.5 minutes." In other words, the system remains in state (0, 0) for 1.5 minutes
before immediately transitioning to state (3, 0).
If we consider each operator as representing an external, controlling input from outside
the jug system, then we can create a an FSA that represents the production system. Figure 8
displays this FSA where the following acronyms are defined:

1. Ex: Empty jug x.

2. Fx: Fill jug x.

3. TAxy: Transfer all water from jug x to jug y. No overflowing of water is permitted.

4. TFxy: Transfer all water from jug x to jug y. until jug y is full.

Even though the state space contains 20 states there are only 14 possible states in the FSA.
The two jug system dynamics are quite complex; this attests, primarily, to the power of
production rules (with pattern matching) over simple FSAs (without pattern matching).
We can simplify the system by partitioning state or event space. There is no automatic
method for state space partitioning; however, we can use a heuristic to help us: form new
states using participles created from the object model. That is, the present participle form of
"fill" is "filling." A similar approach creates the state "emptying." We can combine both
the emptying state and filling state to form a stated called In-between or E',,l.i,i.i',,i-r-filling.
Figures 5 through 7 -i-.-- a partitioning of state space that provides a lumped, more
qualitative model. Since these segments overlap, and do not form a minimal partition, we
must combine substates reflecting levels in jugs A and B to form 9 new states. The
greatest "lumping" effect is contained in the state (Jug A filling, Jug B filling) where the
term "filling" means neither empty nor full. It is important not to underestimate the
lumping effect when considering other possible, but similar, systems. For instance, if the
jugs could contain arbitrarily large amounts then the state space for fig. 8 would also be
large, but the state space for the lumped model would remain the same (9 states). It is
possible to further reduce the number of states by mapping and partitioning state or event
space in accordance with natural language terminology; state space could easily be broken
into -.. I and "dry" where dry corresponds to both jugs being empty, and wet covering the
remainder of state space. Models at varying levels of abstraction [29] are created in response
to the questions asked of them [37].

6 Functional Models

We will use a liberal interpretation of the word "functional" to include modelling approaches
that stress procedural or "process-oriented" models [34]. A purely functional model is termed
memoryy. since there is no state information; so we define a functional model as one that
focuses on "function" rather than state to state transition. Functional models, therefore,
will often contain FSAs embedded within the definition of a functional block; the model is
considered "functional" if this view dominates any subsidiary declarative representations. A

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 15

SJug B

0 0 *

0 0 0

0 0

0 0 0

SJug B

4 0 0

3 (



0 Oc
Jug A
2 3 0

(a) Jug A full.

0 0 0

0 0 0

0 0 0

1 2 3 Jug A
1 2 3

(b) Jug B full.

Figure 5: Full phase.

A Jug B

4 O O 0

3 O O 0

2 O O 0

1 0 0 0




1 (

0 0 EOO 0
0 1 2 3 Jug A
0 1 2 3

(a) Jug A empty.

SJug B


0 0 0

0 0 0

0 0 0

- -- Ju
Jug A
0 1 2 3

(b) Jug B empty.

Figure 6: Empty phase.

3 ()





CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 16

SJug B Jug B

4 )* O 4 O O O

3 )* 0 3 *

2 0 0 0 2 *

1 1 *0

0C 0 00
Jug A Jug A
0 1 2 3 0 1 2 3

(a) Jug A In-between. (b) Jug B In-between.

Figure 7: In-between phase.

function will be represented as a block with inputs and outputs. Inputs and outputs can
represent data flows or control flows, and they are defined as such within SE [5]. From our
perspective, these flows are all data flows regardless of whether a function treats its input
data from a control perspective. The functional SE box structuring techniques of Mills [58]
bear remarkable resemblance to those of systems and simulation theory [69, 88]. This further
demonstrates a convergence in model theory between SE and simulation.
If we consider each tap and each jug to be a function then we can create a functional block
model illustrated in figure 9. This dynamical model could be simulated as it is represented;
that is, messages would be input to blocks that would ,1, 1,, the corresponding outputs to
represent the passage of time. Use of a delay, therefore, represents a simple way to create an
abstract model. If we want to increase model detail, the delay can be further decomposed
into an FSA. For the tap dynamics, we use a delay; however, for the jug dynamics, we choose
an FSA. The dynamics for jug A are shown in figure 10. The entire functional model shown
in fig. 9 has four functional blocks with two of the blocks (jugs A and B) having an internal
FSA to further refine state to state behavior. It is worthwhile to contrast this model with the
declarative model in fig. 8. In the declarative model, each state represents the state of the
entire system whereas, for the functional model, states are "local" to the specific function.
In the object oriented sense, these states are hidden or encapsulated within the block. The
aspect of locality is what has made the functional approach more acceptable to the systems
community a system is broken into functional blocks, each of which represents a physical
subcomponent of the system, and each subcomponent has its own dynamics. The declarative
approach of a rule-based production system while it accurately represents the jug system

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 17



Figure 8: FSA for the jug system.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 18

(Fill) r


(Xfer, Empty)



Figure 9: Functional model of two jug system.


(Xfer, Empty)



Figure 10: FSA for jug A.


CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 19

dynamics partitions state space without an accompanying separation of function. Despite
these differences, there is not an inherent advantage of using the functional approach over
the declarative approach since the production rule model separates behaviors according to
pattern matches in state space; it is simply another way of viewing the system.

7 Multimodels

A multimodel is a model composed of other models. The purpose of a multimodel is to
have a unifying system representation that contains many different levels of abstraction and
perspective views within the system. Within the simulation field, the term multimodel was
introduced by Oren [67] and subsequently refined by Fishwick and Zeigler [37]. Recently,
AI researchers such as Addanki [2] and Forbus [39, 40] have also performed research dealing
with multiple models.
Each level or segment of a multimodel can be represented by a different type of model; By
permitting different types [33] of models, we create a more flexible modelling environment
where each level is represented by its most appropriate form. In the previous section, we
defined a functional model where two of the functions contained embedded models of the FSA
variety; this model was a simple example of a multimodel consisting of two heterogeneous
models. Let's summarize a progression of increasingly complex model forms:

An FSA as depicted in fig. 8 is perhaps one of the simplest forms of models. The FSA
is depicted graphically as a set of circles and arcs; however, their is also an implicit
function box placed around the entire graph. The input to the function box is the
same input referred to on the FSA arc labels; the output from the box is the same as
the FSA output represented using either the Moore or Mealy [50] conventions.

A functional block model captures system dynamics from a functional or procedural
perspective rather than the declarative form of the FSA. In most functional models [69],
the only representation of state is the one in the integrator and ,l, 1,,.i blocks. For
instance, an integrator functional block using a single step approach keeps track of the
last value for a state variable. Graphically, one can envision a functional block with a
single circle representing the saved state.

The DEVS model [90, 92] extends the standard functional notation by permitting, not
only a collection of states within a function block, but also an FSA within each func-
tional block. The semantics for the functional block now has two transition functions
associated with it: transitions for input events Sext and transitions for state events
it. For this reason, the DEVS model is quite powerful as it permits more detailed
semantics within the canonical functional block model.

With respect to FSA semantics, one can view DEVS models as functional block net-
works where each function contains an optional FSA. We can extend this notion by
permitting other models with the blocks -such as Petri nets. Moreover, we can take
each state within the FSA and call it a phase of a more detailed process associated
with the phase. This necessitates a formal partitioning of a more complex state space

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 20

as described in [33, 37], and we must also carefully define the level traversal semantics
so that the transition among phases is well-defined.

Figure 11 is a multimodel that contains several layers -or abstraction levels. Note that
as we proceed down the figure, we use more powerful refinment techniques. The topmost two
levels represents a homogeneous refinement [33] which is common in most model languages.
In this case, we have taken a single function and hierarchically decomposed it into 4 sub-
The breakdown is "homogeneous" since each level uses the same type of model -func-
tional block. The dynamics of JugA is performed by an FSA. In such a model, there are
external events which occur as a result of changing input and internal events which occur as
a result of a time advance specification.5 If we cannot specify a time advance then we can
represent the dynamics for this state by associating yet another level of detail with the state.
In this case, the state becomes a "phase" and we heterogeneously decompose the phase into
a functional block model. In fig. 11 we represent the act of water filling (or emptying) by
a first order differential equation X = U kX where U is the control input and X is the
continuously changing level of the water.

8 Conclusions

We demonstrated the need for a simulation modelling taxonomy to take a form more com-
patible with system modelling efforts in SE and AI that are related to modelling system
dynamics. Currently, the terminology within the simulation field is somewhat fragmented.
A declarative/functional dichotomy already exists within each discipline and, therefore, this
was shown to serve as a point of convergence for all three disciplines. By presenting a com-
mon focal point, students and researchers in AI, SE and simulation can talk about dynamics
using similar terminology; without a common terminological base there might be reinvent-
ing of the wheel and misunderstanding among colleagues who are in different disciplines
working on the same basic system problems. We gave definitions of two views declarative
and functional using a simple example of jug dynamics taken from a frequently cited AI
problem in discrete search spaces.
Several simulation researchers have pointed out the need for further integration with
SE and AI, but most simulation texts fall behind in their discussions of modelling and
how it relates, for example, to system models within the object oriented design approach.
Simulation has much to offer the fields of SE and AI; however, we have slanted this discussion
to talk of a general integration of terminology and general taxonomic breakdown. All three
fields have contributions for each other; formal studies in precisely how system models differ
is a good beginning, and this has been our motivation behind the presented work. Our
immediate goals are to finish a simulation modelling textbook using the integrated view,
and to build a software environment that encourages a stepwise creation of models from
conceptual through multimodel.
5In DEVS, the time specification is denoted by creating a time advance function ta(). A time advance
value is created by analytically solving for the underlying equation representing dynamics for that state.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 21



/ \

Tap A Tap B

JugA Jug B



Empty Full



U '(T r I

Figure 11: Heterogeneous refinement in the jug multimodel.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 22


The motivation for writing this paper came from numerous sources including special work-
shops and conferences on simulation and private correspondence with many people. For
four years, I participated in AI and Simulation workshops and an annual conference entitled
"Artificial Intelligence, Simulation and Planning in High Autonomy Systems." These work-
shops in addition to the Modelling Track at the annual Winter Simulation Conference have
collectively served as a springboard for issues that -i.- -. -1. .1 ways in which modelling in AI,
SE and simulation can relate and contribute to each another.


[1] ABRAMSKY, S., AND HANKIN, C. Abstract Interpretation of Declarative Languages.
Ellis Horwood Limited/John Wiley and Sons, 1987.

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

[3] AKKERMANS, H. A., AND DIJKUM, C. V. Worlds Apart? The Modeling Cycle,
Paradigms and the World View in Simulation Modeling. In European Simulation Multi-
Conference (Nuremberg, Germany, June 1990), Society for Computer Simulation, pp. 99

[4] ASHBY, W. R. An Introduction to Ci,1I,,. i,. John Wiley and Sons, 1963.

[5] ATHENA SYSTEMS. Foresight User's Manual, February 1989.

[6] BAILEY, R. Functional Programming with HOPE. Ellis Horwood Limited/Simon and
Schulster, 1990.

[7] BALCI, O., AND NANCE, R. E. Simulation Model Development Environments: A
Research Prototype. Journal of the Operational Research S.' .', l.i 38, 8 (1987), 753

[8] BALCI, O., NANCE, R. E., DERRICK, E. J., PAGE, E., AND BISHOP, J. L. Model
Generation Issues in a Simulation Support Environment. In 1990 Winter Simulation
Conference (New Orleans, LA, December 1990), pp. 257 -263.

[9] BANKS, J., AND CARSON, J. S. Discrete Event Sil-/ ,, Simulation. Prentice Hall,

[10] BECK, H. W., AND FISHWICK, P. A. Incorporating Natural Language Descrip-
tions into Modeling and Simulation. Simulation Journal (March", volume=52, num-
ber=3,pages = "102 109 1989).

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 23

[11] BECK, H. W., AND FISHWICK, P. A. Natural Language, Cognitive Models and
Simulation. In Qualitative Simulation Modeling and A,., lii P. A. Fishwick and P. A.
Luker, Eds. Springer Verlag, 1990. (in press).

[12] BERTALANFFY, L. V. General Si.,/. ,, Ti...ry. George Braziller, New York, 1968.

[13] BOBROW, D. G. Qualitative Reasoning about P1,.*-'.l,1 Sl/, ,,, MIT Press, 1'-.

[14] BOOCH, G. Object-Oriented Development. IEEE Transactions on Software Engineer-
ing 12, 2 (Feb. 1',1.), 211 -221.

[15] BOOCH, G. On the Concepts of Object-Oriented Design. In Modern Software Engi-
neering, P. A. Ng and R. T. Yeh, Eds. Van Nostrand Reinhold, 1990, ch. 6, pp. 165

[16] BOOCH, G. Object Oriented Design. Benjamin Cummings, 1991.

[17] BRACHMAN, R., AND LEVESQUE, H., Eds. Readings in Knowledge Representation.
Morgan Kaufman, l1'i

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

[19] CELLIER, F. E. Continuous, ,,r Modeling. Springer Verlag, 1991.

[20] CHECKLAND, P. B. Sil./. w,, Tl,.,, ., y, Sill. ,,. Science. John Wiley and Sons, 1981.

[21] DAVIS, A. M. A Comparison of Techniques for the Specification of External System
Behavior. Communications of the ACM 31, 9 (September l'i), 1098 -1115.

[22] DAVIS, E. Representations of Commonsense Knowledge. Morgan Kaufmann, 1990.

[23] DAVIS, R., AND KING, J. An overview of production systems. Machine Intelligence 8

[24] ELZAS, M. S., OREN, T. I., AND ZEIGLER, B. P. Modelling and Simulation Method-
ology in the Artificial Intelligence Era. North Holland, l'Ii.

[25] ELZAS, M. S., OREN, T. I., AND ZEIGLER, B. P. Modelling and Simulation Method-
ology: Knowledge Sil.lw, ,,' Paradigms. North Holland, 1989.

[26] ENDERTON, H. A Mathematical Introduction to Logic. Academic Press, 1972.

[27] FINDLER, N. V., Ed. Associate Networks: Representation and Use of Knowledge By
Computers. Academic Press, 1979.

2] FISHWICK, P. A. Hierarchical Reasoning: Simulating Complex Processes over Multiple
Levels of Abstraction. PhD thesis, University of Pennsylvania, 1',i.

[29] FISHWICK, P. A. The Role of Process Abstraction in Simulation. IEEE Transactions
on S,/ il,,' Man and Cil," i, i.'. 18, 1 (January/February li'), 18 -39.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 24

[30] FISHWICK, P. A. Qualitative Methodology in Simulation Model Engineering. Simula-
tion Journal 52, 3 (March 1989), 95 -101.

[31] FISHWICK, P. A. Studying how Models Evolve: An Emphasis on Simulation Model
Engineering. In Advances in AI and Simulation (Tampa, FL, 1989), pp. 74 -79.

[32] FISHWICK, P. A. Toward an Integrated Approach to Simulation Model Engineering.
International Journal of General S.,l'i ,, 17, 1 (May 1990), 1 -19.

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

[34] FISHWICK, P. A. A Functional/Declarative Dichotomy for Characterizing Simulation
Models. In AI, Simulation and Planning in High A ,/-,.- i,,i S.'.il, i,- (Perth, Australia,
1992), IEEE Computer Society Press, pp. 102 -109.

[35] FISHWICK, P. A. Computer Simulation Modeling: M, Il.'.il.l.,-ii. Algorithms and Pro-
grams. 1992. (to be published as a textbook in early 1993).

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

[37] FISHWICK, P. A., AND ZEIGLER, B. P. A Multimodel Methodology for Qualitative
Model Engineering. ACM Transactions on Modeling and Computer Simulation 2, 1

[38] FLOOD, R. L., AND CARSON, E. R. Dealing with C,.n',II, ,.,:"i An Introduction to the
Ti .. ry and Application of Sill- i, Science. Plenum Press, 1'l"

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

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

[41] FORRESTER, J. W. Urban D;w,,,w.;,- MIT Press, Cambridge, MA, 1969.

[42] FORRESTER, J. W. World D.I.,,.:. Wright-Allen Press, 1971.

[43] FUTO, I., AND GERGELY, T. Artificial Intelligence in Simulation. Ellis Horwood
Limited/John Wiley and Sons, 1990.

[44] HAREL, D. On Visual Formalisms. Communications of the ACM 31, 5 (May li ),
514 -530.

[45] HAREL, D. STATEMATE: A Working Environment for the Development of Complex
Reactive Systems. IEEE Transactions on Software Engineering 16, 3 (April 1990), 403

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 25

[46] HAREL, D. Biting the Silver Bullet: Toward a Brighter Future for System Development.
IEEE Computer 25, 1 (January 1992), 8 -20.

CLP(R) Programmer's Manual: Version 1.1, November 1991.

[48] HENDERSON, P. Functional Programming: Application and Implementation. Prentice
Hall International, 1'i'ii

[49] HOGGER, C. J. Essentials of Logic Programming. Oxford University Press, 1990.

[50] HOPCROFT, J. E., AND ULLMAN, J. D. Introduction to Automata Tli .'ry, Languages
and Computation. Addison Wesley, 1979.

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

[52] KLIR, G. J. Architecture of Sill ,,, Problem Solving. Plenum Press, lI'.

[53] KOWALSKI, R. Logic for Problem Solving. Elsevier North Holland, 1979.

[54] LAW, A. M., AND KELTON, D. W. Simulation Modeling & An,,,..'. McGraw Hill,
1991. Second edition.

[55] LELER, W. Constraint Programming Languages: Tl. .r Specification and Generation.
Addison Wesley, 1 '""

R. J. AI: What Simulationists Really Need to Know. In 1990 Winter Simulation
Conference (New Orleans, LA, December 1990), pp. 204 -209.

[57] MILLER, V. T., AND FISHWICK, P. A. Heterogeneous Hierarchical Models. In Arti-
ficial Intelligence X: Knowledge Based Siil, ,,, (Orlando, FL, April 1992), SPIE.

[58] MILLS, H. D. Stepwise Refinement and Verification in Box-Structured Systems. IEEE
Computer 21, 6 (June l'I"), 23 -36.

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

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

[61] NANCE, R. E. Modeling and Programming: An Evolutionary Convergence, April 1'l""
Unpublished overheads requested from author.

[62] NARAIN, S., AND ROTHENBERG, J. Qualitative modeling using the causality relation.
Transactions of the S .'... for Computer Simulation 7, 3 (1990), 265 -2"'.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 26

[63] NIELSEN, N. R. Applications of AI Techniques to Simulation. In Knowledge Based
Simulation: Methodology and Application, P. Fishwick and R. Modjeski, Eds. Springer
Verlag, 1991, pp. 1 19.

[64] O'KEEFE, R. M. The Role of Artificial Intelligence in Discrete Event Simulation. In
Artificial Intelligence, Simulation & Modeling, L. E. Widman, K. A. Loparo, and N. R.
Nielsen, Eds. John Wiley and Sons, 1989, pp. 359 -379.

[65] OREN, T. I. Model-Based Activities: A Paradigm Shift. In Simulation and Model-
Based Methodologies: An Integrative View, T. I. Oren, B. P. Zeigler, and E. M. S., Eds.
Springer Verlag, 1984, pp. 3 -40.

[66] OREN, T. I. Simulation: Taxonomy. In Sill/ ,,. and Control F,.. .1. lpedia, M. G.
Singh, Ed. Pergammon Press, 1987, pp. 4411 -4414.

[67] OREN, T. I. Dynamic Templates and Semantic Rules for Simulation Advisors and
Certifiers. In Knowledge Based Simulation: Methodology and Application, P. Fishwick
and R. Modjeski, Eds. Springer Verlag, 1991, pp. 53 -76.

[68] OVERSTREET, C. M., AND NANCE, R. E. A Specification Language to Assist in
Analysis of Discrete Event Simulation Models. Communications of the ACM .' 2
(February l'i), 190 -201.

[69] PADULO, L., AND ARBIB, M. A. Sil/, ,,, T ... ry: A Unified State Space Approach to
Continuous and Discrete Sil /, W. B. Saunders, Philadelphia, PA, 1974.

[70] PETERSON, J. L. Petri Net Tli ..ry and the Modeling of Si./, ,,, Prentice-Hall, Inc.,
Englewood Cliffs, N.J., 1981.

[71] PRAEHOFER, H. Sil-/, T.... retic Foundations for Combined Discrete-Continuous
Silli. ,, Simulation. PhD thesis, Johannes Kepler University of Linz, 1991.

[72] PRESSMAN, R. S. Software Engineering: A Practitioner's Approach. McGraw Hill,

[73] RICH, E., AND KNIGHT, K. Artificial Intelligence. McGraw-Hill, 1991.

[74] RICHARDSON, G. P., AND PUGH, A. L. Introduction to Sil,/ ir, Dw.,ii.:i. Modeling
with DYNAMO. MIT Press, Cambridge, MA, 1981.

troduction to Computer Simulation: A Sill/,, Doi.nii,.:i Approach. Addison-Wesley,

[76] ROTHENBERG, J. Object-Oriented Simulation: Where do we go from here? Tech. rep.,
RAND Corporation, October 1989.

[77] ROTHENBERG, J. Knowledge-Based Simulation at the RAND Corporation. In Knowl-
edge Based Simulation: Methodology and Application, P. Fishwick and R. Modjeski,
Eds. Springer Verlag, 1991, pp. 133 -161.

CIS TR92-006 TBP: ACM Transactions on Modeling & Computer Simulation, V2, N4 27

[78] ROZENBLIT, J. W., AND ZEIGLER, B. P. Knowledge-Based Simulation and Design
Methodology: A Flexible Test Architecture Application. Transactions of the S'. ., li.
for Computer Simulation 7, 3 (1990).

W. Object-Oriented Modeling and Design. Prentice Hall, 1991.

[80] SHANNON, R. E.,- ,,r Simulation: The Art and Science. Prentice Hall, 1975.

[81] SOWA, J. F. Conceptual Structures: Information Processing in Mind and Machine.
Addison-Wesley, 1984.

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

[83] WELD, D. S., AND DEKLEER, J. Readings in Qualitative Reasoning about P1il.,.',',
Sil ./ ,,' Morgan Kaufmann, 1990.

[84] WIDMAN, L. E., LOPARO, K. A., AND NIELSEN, N. R. Artificial Intelligence, Sim-
ulation and Modeling. John Wiley and Sons, 1989.

[; l] WINOGRAD, T. Frame Representations and the Declarative/Procedural Controversy.
In Representation and Understanding, D. Bobrow and A. Collins, Eds. Academic Press,
1975, pp. S- 210.

[i".] WOODS, W. A. What's in a Link: Foundations for Semantic Networks. In Representa-
tion and Understanding, D. Bobrow and A. Collins, Eds. Academic Press, 1975, pp. 35

[87] WYMORE, A. W. A Mathematical Ti .,'ry of Sii/., ,,, Engineering: The Elements.
Krieger Publishing Co., 1977.

[88] ZEIGLER, B. P. Tl -. ry of Modelling and Simulation. John Wiley and Sons, 1976.

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

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

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

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

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

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