Group Title: Department of Computer and Information Science and Engineering Technical Reports
Title: A Taxonomy for simulation modeling based on programming language principles
CITATION PDF VIEWER THUMBNAILS PAGE IMAGE ZOOMABLE
Full Citation
STANDARD VIEW MARC VIEW
Permanent Link: http://ufdc.ufl.edu/UF00095336/00001
 Material Information
Title: A Taxonomy for simulation modeling based on programming language principles
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 Science and Engineering, University of Florida
Place of Publication: Gainesville, Fla.
Publication Date: June 21, 1996
Copyright Date: 1995
 Record Information
Bibliographic ID: UF00095336
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.

Downloads

This item has the following downloads:

1995181 ( PDF )


Full Text



















SUBMISSION FOR SPECIAL ISSUE ON COMPUTER SIMULATION
FOR IIE TRANSACTIONS ON IE TP .- .. ,I: 'l

A Taxonomy for Simulation '.i, dealing Based on Programming Language Principles


Paul A. Fi-l', -i.
Dept. of Computer & Information Science and Engineering
University of Florida
Bldg. CSE, Room 301
Gainesville, FL 32611
E-mail: fi-~', i, -, i-, .ufl.edu
Phone and FAX: (904) 392-1414
WWW: http://www.cis.ufl.edu/~fishwick


June 21, 1996























STATEMENT OF RELEVANCE REQUIRED BY IIE TRANSACTIONS
Why is this paper important?







Abstract We present a new modeling taxonomy for computer simulation. The im-
portance of this work centers on a cohesive approach to modeling that attempts to unify
heretofore disparate modeling techniques. For example, while there exists a taxonomy for
discrete event simulation, this taxonomy does not incorporate models whose execution is
via continuous time increment. The modeling taxonomy has a similar structure to com-
puter language categories: declarative, functional and constraint. The multimodeling model
type permits the creation of a multi-level heterogeneous model that can integrate different
model types, rather than displacing them in favor of a singular modeling method. Instead
of advocating the removal of existing modeling techniques, our focus has been on organizing
modeling techniques from different disciplines to yield unification.












A TAXONOMY FOR SIMULATION MODELING BASED ON
PROGRAMMING LANGUAGE PRINCIPLES

PAUL A. FISHWICK

Dept. of Computer & Information Science and Engineering
University of Florida
Bldg. CSE, Room 301
Gainesville, FL 32611

June 21, 1996


Although many diverse areas employ simulation models, no agreed-upon taxonomy has
been developed to categorize and structure simulation models for all science and engineering
disciplines. Tli, discipline of simulation is often splintered due to this lack of structure, with
ad hoc model classes such as ,li-, i, 1, event," "(, .il iill, -" and .iiilil, ii T111 classes
most often reflect the method of execution used on a model rather than the design structure
of the model. We present a uniform model design taxonomy whose categories are inspired
from categories in programming language principles within the field of computer science.
Ti, taxonomy includes a set of primitive model types (conceptual, declarative, functional,
constraint, spatial) and a way of integrating primitive model types together (multimodeling).
T111 model types are discussed using a single application: a robot server for an assembly
line. We have found this taxonomy enables simulationists to more easily define and categorize
their models as well as to understand how model types from seemingly disparate application
areas are interrelated.

Introduction

Simulation is a tightly coupled and iterative three component process composed of 1) model
design, 2) model execution, and 3) execution analysis shown in Fig. 1. '.i,,del design can
be accomplished without any a priori data or knowledge, or one may have sample data and
prior knowledge about the normative model type used for the application. Ti!, word models
an overloaded term and can have many meanings depending on context. We proceed to first
define what we mean by the word model. i., ,dels are devices used by scientists and engineers
to communicate with one another using a concise-often visual-representation of a physical
system. In our methodology [9], a model is defined as a graph (a visual formalism consisting
of nodes, arcs and labels) with two exceptions: a set of rules or equations. Computer code
and programs are not considered to be models since code semantics are specified at too low
a level. Likewise, formal methods are viewed to specify the formal semantics for models but
do not focus on representing the kind of high-level form needed for modeling. We consider
low-level constructs defining system dynamics to be programs or formal specifications, rather


















Input-Output Analysis
Experimental Design
Serial Algorithms Model Execution Response Surface Techniques
Parallel Algorithms Execution Analysis Visualization of Data
SVerification
Validation

Figure 1: T111 study of computer simulation: three subfields.


than models. Programs and formal specifications [40, 41, 27] are a vital ingredient in the
simulation process since, without these methods, modeling approaches lack precision and
cohesion. However, our definition of modeling is positioned at a different level: models can
be translated into executable programs and formal specifications. Fi-lrh-i, 1: and Zeigler [11]
demonstrated this translation using the DEVS [41] formalism for one particular type of visual
multimodel (finite state machine model controlling a set of constraint models). If one were
to sketch a translation chain, it would be as follows: conceptual model = executable model
= {Formalism,Program}. We focus specifically on modeling as the first two links in this
chain. An indepth discussion of different model types including conceptual, constraint and
multimodel is presented in subsequent sections. '. ,dels are the visual high-level constructs
that we use to communicate system dynamics without the need for frequent communication
of low-level formalism and semantics.
We will first motivate the need for a new taxonomy by stressing issues and problems with
the existing taxonomies for computer simulation modeling. We then specify our modeling
taxonomy, and illustrate our model types using the scenario of the single server queue. This
type of queue is ubiquitous, simple and yet provides a way of describing the new taxonomy.
T!i, paper is organized as follows: we present the new modeling taxonomy. T!11,i we describe
the example scenario that is used to illustrate all model types: conceptual, declarative,
functional, constraint, spatial and multimodel. We close with a summary of the taxonomy
and its advantages, with future goals to be achieved.


Motivation

Given that various taxonomies exist for modeling, it may not be clear whxy we create yet
another taxonomy. Here are our key reasons:

1. Completeness: T111 new taxonomy organizes models from several different areas in-
cluding continuous, discrete and combined models under one umbrella. T111 traditional
modeling taxonomies are currently separate. For example, models which require a con-
tinuous time slicing type of model execution, are grouped into a model category based
on the need for time slicing, not the form of the model.









2. Object-Oriented Design: Ti, new taxonomy is one based on object oriented (00)
design methodology since it is developed as an extension to 00 design. Existing
00 design for software engineering does not include the concept of modeling. Our
design extends the design approaches in software engineering to employ both static
and dynamic models for physical objects.

3. Multimodels: Ti, 1, does not exist a good modeling approach to multi-level models
where levels are defined using heterogeneous model types. Ti, new taxonomy addresses
this problem through the multimodel concept.

4. Design versus Execution: A taxonomy for modeling should be based on the design of a
model and not how it is executed. Ti, current taxonomy introduces some ambiguity as
to whether design or execution is being used to categorize models. TI new taxonomy
is one which stresses model form as ./.,iI', '..p 1 structure where possible.

5. Models versus Programs: We draw a clear parallel between the new taxonomy and
programming language categories in computer science. Ti, ability to use the same
categories (for modeling as well as for programming) lends credibility to the new tax-
onomy, and allows one to draw direct parallels between programming language and
model design constructs without inventing new category types.

While there has been significant coverage in the simulation literature for analysis meth-
ods [1, 18], the general area of modeling for simulation has lacked uniformity and indepth
coverage. Two areas of modeling termed ili-, i,, I ., I and "(, .i, iiiii, -i-" are defined in the
simulation literature. For discrete event models, the field is sub-divided into event-oriented,
process and activity-based modeling. To choose one of these sub-categories, we might ask
"What is an event-oriented model?" T1!, is no clear definition [1, 18] other than to state
that a discrete event model is one where discrete events predominate. Ti!, I is no attempt to
further categorize or classify the form taken on by an event-oriented model. In mentioning
form, we need to address the differences between syntax (form) and semantics (execution).
A program or model may be of a particular form; however, the semantics of this form may
have a variety of possibilities. A Petri net [26] has a particular form regardless of the way
in which it is executed. Ideally, then, we would like to create a model category which
classifies the form of the Petri net, apart from its potential execution characteristics. By
associating integer delay time with Petri net transitions, one can execute the Petri net using
time slicing, discrete event simulation or parallel and distributed simulation. By providing
an i.l -oriented" model category, it is not clear whether this includes only those models
which have explicitly surfaced i. in their forms (as in event graphs [35] or animation
scripts [9]) or whether a GPSS or Simscript program [23] could be considered an event-
oriented model. Our approach is to clearly separate model design (syntax) from execution
(semantics). '.i -reover, as stated earlier, programs are not considered to be models at least
for most textually-based programming languages. One can attach semantics to syntax, but
they remain orthogonal concepts.
Some model types that are similar in form are separated into different categories using
the existing terminology. An example of this can be found in block models for automatic
control and queuing networks. A functional block model and a queuing network model are









identical in form, the only differences being in the semantics for the blocks (i.e., transfer
functions) and the nature of the signal flowing through the blocks (discrete or continuous).
Our taxonomy stresses a difference in model topology and structure instead of separating
model types based on time advance or signal processing features. By using the concept of
functional model, we characterize the syntactical form of the model: functional models are
identified by a uni-directional flow through a network containing directed arcs. Likewise, this
flow is directly analogous to functional composition in functional programming languages.
Tli, field of computer science contains categories of programming languages [12, 20] that
serve to create three of the following six model categories: conceptual, declarative, func-
tional, constraint, spatial and multimodel. Declarative programming semantics are those
where data and variable declarations constitute the expression of the semantics; one speci-
fies how variables change in the program by declaring present and future variable values. Ti
form of declarative models is either graphical (automata,chains) or textual (patterns,logical
inferences). Prolog [5] is an example of a declarative language with a textual orientation.
Functional languages, such as Lisp [38], specify how variables change using compositional
function mappings. Tli, mappings conform exactly to the mathematical definition of the
term liil 1i1 .1 Constraint programming languages [19] allow both forward and backward
chains to be created to "- .1. for variable values. T!i, same categories can be used to
organize dynamic models just as they currently do for programs, with modeling and program-
ming have similar roots [10]. In Table 1, we show the base categories along with application
areas and some sample model types used by those areas. ii iindels are not listed since
they are models containing base category models as components. Ti, three model types that
have strong ties with programming languages are: declarative, functional and constraint. A
declarative simulation model is one where states and event transitions (individually or in
groups) are specified in the model directly. Production rule languages and logic-based lan-
guages based on Horn clauses (such as Prolog [17]) create a mirror image of the declarative
model for simulation. ':. 1, -eover, declarative semantics are used to define the interpretation of
programming language statements. A functional model is one where there is directionality in
flow of a signal (whether discrete or continuous). T!i, flow has a source, several possible sinks,
and contains coupled components through which material flows. Functional languages, often
based on the lambda calculus [21, 30], are very similar in principle. If programming language
statements are not viewed declaratively, they usually are defined using functional semantics.
Ti, languages Lisp [38] and .Ail [25] are two example functional languages. Lisp has some
declarative features (side effects) whereas other functional languages attempt to be iiit "
Finally, with regard to computer science metaphors, constraint languages [3, 19] reflect a way
of programming where procedures and declarations are insufficient. T!i, constraint language
CLP(R) [13] (Constraint Logic Programming) represents this type of language. Also, the
next generation Prolog (Prolog III) is constraint oriented. In constraint models, the focus is
on a model structure, which involves basic balances of units such as mass and energy.
Ti, remaining three types of models (conceptual, spatial and multimodel) have the fol-
lowing justifications. Conceptual models are highlighted in Artificial Intelligence (AI). In AI,
we find a plethora of potential conceptual model types including semantic networks, logic-
based formalisms (without a time base), frames and other schemata. We have found the
object oriented (00) paradigm [2, 32, 42] to encapsulate a favorable way of encoding con-
ceptual models. One should begin to define a system by first defining attributes, methods,










Table 1: Sample '.l, del Categories and Associated Applications.


classes, along with ;,---.-ii -.i,.ii, and association hierarchies. An ;,-.-ii -.i,.ii hierarchy is one
involving a p1ii c of" relation between the children and the parent in a tree. A generalization
relation involves a "is a kind of" relation. T111 resulting hierarchies are not executable but
they serve as a mechanism to organize objects and their relations to one another. Spatial
models, such as partial differential equations (PDEs) and cellular automata, are common
where we have detailed parametric information about the system from a geometric perspec-
tive. We organize spatial models using class and object ; --i i. i, .ii which are approaches
in object-oriented design. ', lilt ii ndels are defined as models containing other models. This
recursive definition allows for powerful model-building to take place where large scale models
can be constructed out of simpler primitive ones.

Modeling Taxonomy

Fig. 2 illustrates the modeling taxonomy. T111 top level of Fig. 2 refers to the multimodel
type since this type is composed of all sub-types previously discussed: declarative, functional,
constraint and spatial. Conceptual models are generated before multimodels since conceptual
models are non-executable and reflect relations among classes. Each of these sub-types has
two sub-categories:


Base '. ,del Type Application Area .oldeling Technique
Conceptual Artificial Intelligence Semantic ''; 1 works, Frames
Software Engineering Object Oriented Designs
Soft Systems Science Primitive ldel Types
Declarative Computer Science (TI !,ry) Automata
Computer Animation Scripts and Tracks
Engineering Task Clii i 1.li-i.
Programming Languages Logic Programs
Operating Systems Petri :.; i-.
Physics Space-Time Diagrams
Functional Automatic Control Block '., dels
Electrical Engineering Digital Circuits
Performance Analysis Queuing .': i" works
Biology and :.I l ili, i1, Compartmental '.ldels
Industrial Systems System Dynamics
Constraint Dynamics Equations
Electrical Engineering Analog Circuits
'.1 lI ii, Engineering Bond graphs
Spatial Complex Systems Cellular Automata
Engineering Fiii, Element '.ldeling,PDEs


















Pictorial Text Function Variable Space Entity





State Event Equational Graph

Figure 2: '.i, del taxonomy.

Conceptual models are either in pictorial form or in natural language 1\" form.
For our purposes, we have chosen to represent conceptual models as ;--_-1, i .*,iii and
generalization hierarchies, commonly found in object-oriented design [32].

Declarative models focus on patterns associated with states or events. An example
declarative model type with a state focus is the finite state automaton. Ti, event
graph is an example with the event focus.

Functional models are networks whose main components are either functions (as in
block models) or variables (as in the levels found in systems dynamics).

Constraint models are represented as equation sets or as graphs. An example constraint
graph is an analog electrical circuit or a bond graph [4].

Spatial models have a focus on either the whole space or an entity. Space-based orien-
tations involve the updated state of the entire space by convolution of a template over
that space (as with the numerical solution of PDEs). Entity-based orientations involve
the dynamics of individual objects (i.e., entities) which move around a space.

Scenario

Having provided justification for the new model taxonomy, we now proceed to illustrate
the different dynamic models types using a single server queue. Ti, single server queue is
ubiquitous in engineering and business. In science, it is present where higher order living
entities must block each other, waiting for service. For lower order entities and non-organic
materials, the general concept of capacitance serves to emulate queuing to some extent.
Consider a two-link robot arm that accepts parts, performs a service, and releases the
parts. Tli, overall top view of the process is shown in Fig. 3. Fig. 4 displays a subset of the
robot tasks that are performed:









End-Effector
Infrared
Receiver
\^ Camera

Conveyor

Flow of Parts



infrared Release
Transmitter Point
Robot

Reject Parts Bin

Figure 3: Top view of single server queue process.


1. Grasp part: move from the default reset position to grab the next part waiting for
service.

2. Move part to camera: move the part to the camera so that it can be inspected for
flaws.

3. Inspection: execute image processing and vision programs to segment the image and
determine if a correct match can be made against a stored I, iiipl,, image.

4. Move part to release point: if the part is acceptable, it is moved back to the conveyor
at the release point. Otherwise, the part is placed in a bin for rejected parts.

5. Release part: release the part onto the conveyor.

6. Reset: reset the robot so that it is prepared for the next inspection. Synchronize the
motors and end-effectors so that they are correctly positioned.

Ti, incoming conveyor for the robot stops when the infrared transmitter-receiver pair indi-
cates a part is ready. Tli, part is then grabbed by the robot's end-effector and presented to
the camera for visual inspection. After the part is grasped and moved, the conveyor resumes
operation to deliver the next part for service. Service of a part is based on the speed of the
arm as well as the image processing time. Let us now proceed with defining each model for
this scenario.


Conceptual Model

Conceptual models are "first cut" descriptions of what we know about a process. We could,
for instance, describe our knowledge of the robot and the process using a variety of schemata
including frames, semantic networks or entity-relationship diagrams. Instead, we choose
to follow the object-oriented paradigm, which .--.-, --. that we form classes along with


















(a) Grasp (b) (c) Move (d)
Move and Re-
and Release set
in-
spect


Figure 4: Phases of robot server pick and place operations.


encapsulated attributes and methods. Specifically, we form a hierarchy or set of hierarchies
which specify two hierarchical relations among all classes: ;---i t -i.iii and generalization.
Fig. 5 provides a conceptual model which contains two ;--, iI -.i i. relations (using a box
to designate the relation) and one generalization relation (using a circle). In this figure, we
have decided to include both types of relations in the same hierarchy, but it is acceptable to
separate hierarchies if needed. Other relations, aside from generalization and ;-.--ii .-Ilil, .ii
are possible; however, we focus on these two relations since they involve an implicit transfer
of class structure. For generalization, this transference is called inheritance -the inheriting
of attributes and methods from a base class (such as Camera) to derived classes (child nodes
of Camera: CCD and Film). For ;I.- .-- i, t11 the transfer of class structure is bottom-up
instead of top-down as it was for generalization. A Robot class logically .;.-,-ii -._11i h all sub-
class structure. Tli, topmost class World contains the objects below it. T11i 1, fi re the four
objects Camera, Conveyor, Robot and Part ;i.-.-regate together to form World. T! 1,1,
are two types of cameras: CCD and Film. As it turns out, we will not be using any camera
attributes or methods in our models, but we include this knowledge in our conceptual model
anyway. Tli, larger goal of conceptual modeling is to capture all knowledge about a physical
set of objects, whereas a single modeling exercise may use only a subset of what is stored
in the conceptual model. Ti, I are several reasons for using an object-oriented design for
the conceptual model, including the use of advantageous features such as polymorphism and
inheritance [36]; however, the primary reason is that the design is "(! I.. to reality-at least
in the way that we categorize the world with natural language. Conceptual models comprise
both ;.-i, 1-,i; i.i1ii and generalization hierarchies [32, 2]. Generalization hierarchies specify
relationships based on type: a robot may be of several types such as welding, pick-and-place
or inspection, or some combination of these. A.-:.--n, -. ii .u11 hierarchies specify a relation based
on composition: a robot is composed of a base, links and an end-effector. Within an object
(ref. Fig. 5) attributes are above the horizontal center line and methods are below the line.
Tli, conveyor's attribute of width reflects the width of the conveyor belt whereas the method
run describes a method that is associated with the belt drive. An example of polymorphism
is shown in the link and effector objects. Ti, method position is common to both. Ti,


























Figure 5: Conceptual model including ;-.--i.i iin and generalization.

Class Name

S_----Variables
Attributes Variables
SStatic Models


Methods Code
Dynamic Models


Figure 6: Structure of a Class.


program knows which method to use only through determining which object is affected at
run time.
Once the conceptual model has been constructed, one must "fill in" the attributes and
methods for each class. Some attributes and methods are shown in Fig. 5. vWe extend the
existing 00 design paradigm to include modeling in the following sense. An attribute can
be a variable, whose value is one of the common data types, or a static model. A method
can be code, whose form depends on the programming language, or a dynamic model. Tli1
structure of a class is seen in Fig. 6. Variables and code are described in 00 languages
such as C++ [36]. IWe define a static model as a graph of objects and a dynamic model as a
graph of attributes and methods. Ti,1 model types we focus on in this paper are all dynamic,
however, the concept of static model complements the concept of dynamic model: methods
operate on attributes to effect change in an object. Likewise, dynamic models operate on
static models to effect change. Objects are instantiations of classes. For example, one creates
a robot object called Robot35 by making an instance of the class Robot.












0 1 1 An-i2 n s(-1



(a) Markov chain (b) Event graph (c) Petri net


Figure 7: Declarative model types.

Declarative Model

'.idels that permit dynamics to be encoded as state-to-state or event-to-event transitions
are declarative. Ti, idea behind declarative modeling is to focus on the structure of the state
(or event) from one time period to the next, while de-emphasizing functions or constraints
that define the transition. '., dels such as finite state automata [14], '.i, .!,v models, event
graphs [35] and temporal logic models [22] fall into the declarative category. Declarative
models are state-based (FSAs), event-based (event graphs) or hybrid (Petri nets [26]). For
the robot scenario, example states for the robot object are .,-i, i,-p- l, fiif. (for
high abstraction levels) or the number of parts waiting for service on the conveyor (for low
abstraction levels). Tli, level of information and abstraction of models is discussed more in
the Multimodel section. Tli, following types of declarative models represent an appropriate
subset of declarative modeling types:

Stochastic process: a :.i,~;.,v model can be used to specify state to state transitions
based on arrival A and departure i rates.

Event ipl,,/ two events (arrival,departure) are used.

Petri net: the part waiting at the infrared beam (in Fig. 3) can be expressed as a
resource contention where the part contends for the robot resource.

Fig. 7 displays these three model types. Ti, first type ('.i A l;.,v) represents a stochastic
process that has a memory of unit length -the state of the system at the current time
is dependent on the state at the previous time, and not on any times prior to this. Ti,
declarative nature of the model shows itself because our model is composed, literally, of
state specifications. Tli, event graph in Fig. 7 is somewhat different because it illustrates
a focus on events that transpire, A (arrival) and D (departure). Events A and D are not
primitive since these events are actually place holders (or sets) including primitive events,
each of which represents an event for one specific part. This type of modeling reflects the
capability of declarative models to use patterns as well as unit state/event descriptors. Event
A schedules another arrival using an exponential distribution for interarrival times a (i.e., a
Poisson input process), and A also schedules D to occur in o (service) time. Ti, term s(X)
means !i liil -. using parameter X." Ti, Petri net in Fig. 7 models the robot server by
stressing resource contention as a key model design aspect. Ti, part (represented by a solid










Table 2: Times for four successive parts.


P# TSLA ACT ST SB SE PW SI
1 5.0 5.0 6.5 5.0 11.5 0.0 5.0
2 6.3 11.3 7.3 11.5 18.8 0.2 0.0
3 6.0 17.3 5.2 18.8 24.0 1.5 0.0
4 7.8 25.1 6.2 25.1 31.3 0.0 1.1
Totals 1.7 6.1


black circle) flows through a simplified assembly-line system, while encountering three types
of transactions: grasp by the robot, inspection, and release of the part. Tli, key aspect of
the Petri net is seen in the feedback arc, which dictates that the next part on the line must
wait for the robot to come back to grasp it before it can proceed to be serviced.

Functional Model

Functional models represent a directional flow of a signal (discrete or continuous) among
transfer functions (boxes or blocks). When the system is viewed as a set of blocks commu-
nicating with messages or signals, the functional paradigm takes hold. Ti, use of functional
models is found in control engineering [6, 24] (continuous and discrete time signals) as well
as in queuing networks (discrete signals). Some functional systems focus not so much on
the functions, but more on the variables. Such models include signal flow graphs, compart-
mental models [15], and Systems Dynamics graphs [31]. In this latter group of models, the
function is often an implicit linear one, with the pronounced variables shown in the graph
representing state variables along with parameters.
Ti, functional way of modeling the robot is to consider the robot as a transfer func-
tion, modeling a relation between input and output. Ti, input signal, for our purpose, is
a continuous-time, discrete-state signal reflecting the arrival of parts. Ti, output signal
specifies the time-based departure of parts. Consider Table 2, which provides some data for
the parts (P), their time since last arrival (TSLA), the arrival clock time (ACT), service time
(ST), service begin time (SB), service end time (SE), part wait time (PW) and robot server
idle time (SI). Fig. 8 displays the functional model for the robot as a transfer function, along
with the input and output trajectories. Tli, model, in this case, is the block in the center; the
trajectories are shown to illustrate the response. For a single server this model seems fairly
pointless; however, for multiple servers coupled in a network, the functional model represents
an effective modeling approach. We still have not described, in modeling nomenclature, how
the transfer function operates. It is often useful to put one type of model in another for this
purpose. For the functional model, we can refine the block into a declarative model to create
a multimodel composed of two models.











4 4
3 Server 3
2 --'-Transfer 2
1 __I Function ____
0 5 10 15 20 25 Model 10 15 20 25 30 35
time time
Input Trajectory Output Trajectory

Figure 8: Functional model for the server.


Constraint Model

Th, 1, are two types of constraint models: equational and graph-based. Constraint models
are models where a balance (or constraint) is at the heart of the model design. In such a
case, an equation is often the best characterization of the model since a directional approach
such as functional modeling is insufficient. Equational systems include difference models,
ordinary differential equations and delay differential equations. Graphical models such as
bond graphs [4, 16] and electrical network graphs [29] are also constraint based. To model
the robot server by constraint modeling techniques, we encode the model as a balance of
parts in Eq. 1:

Transition Probability Rate = Parts Arriving Parts Released (1)

This is represented by Kolmogorov's forward equation for a birth-death process in Eq. 2:

d Pij(t) = Aj_iPij_i(t) + /1j^lPij)l(t- (A + ij)Pij(t) (2)
dt
Rate Parts Arriving Parts Released

Spatial Model

If a system is spatially decomposed as for cellular automata (CA) [37, 39], Ising systems,
PDE-based solutions or finite element models, then the system is being modeled using a
spatial modeling technique. Spatial models are used to model systems in great detail, where
individual pieces of physical phenomena are modeled by discretizing the geometry of the
system. Spatial models are ll ii; -Ii-i i or -1wi' -based." Entity-based spatial models
focus on a fixed space where the entity dynamics are given whereas space-based models
focus on how the space changes by convolving a template over the space at each time step.
PDEs are space-based where the template defines the integration method. L-Systems [28]
are entity-based since the dynamics are based on how the organism grows over a fixed space.
A CA represents a simple way of modeling a single server queue. Fig. 9 illustrates a CA
with parts waiting for service from the robot. Thi, CA is one dimensional and is represented
as a contiguous group of 8 squares. Each square can be blank or contain one of the icons
in Fig. 10. Since the CA represents a discrete time approximation, we use integer values
for times. Til, service time is 4 units and is represented by a cell that changes state for
the correct number of phases before accepting the next part to be serviced. Thl solid circle










Time I

Time I+1

Time I+2

Time I+3

Time I+4

Time I+5


parts robot

S...
SS UI


* 0
000

S...

* U
__ee^ __
^^*^--^


Figure 9: Cellular automaton for single server queue.


Move Right Hold #2

*** + ++C
Block Hold # 3


Hold #1 Release

Figure 10: CA rules.

represents a part. Ti, shaded circle and polygons represent the phases of the server and the
cross is a wildcard that matches any other cell. Ti, rules in Fig. 10 are I I ..ck rules" [37] and
are used as patterns used in a convolution procedure over the background CA space. A rule
is applied by a search for the pattern on the left hand side of the rules in Fig. 10. If there
is a match of the pattern against any part of the one dimensional space, the original part
of that space (against which the pattern matched successfully) is replaced by the right hand
part of the rule. For example, consider the CA at time I in Fig. 9. vWe ask ourselves: which
left hand block in Fig. 10 matches some portion of the CA in Fig. 9 at time I? Tli, Block
rule in Fig. 10 matches, but this results in no change, whereas the HII,/ 1 rule matches and
results in the replacement of the matching part of Fig. 9 at time I with the corresponding
right hand block in Fig. 10 for Hu,Il 1, resulting in a new CA for time I + 1 in Fig. 9. Ti1
simulation of the CA model proceeds using this same logic. Ti, is a lag in the queue as
parts move from left to right toward service. This is an artifact of the CA since, with a
continuous belt feed, this lag would not appear -the queue elements would move in unison.
Another set of CA rules can associate a number of contiguous cells for use by the server.
This represents a transport delay and would achieve the same effect as using the multiple
state cells in Fig. 10.









1..ire complex spatial models can represent the single server queue as well. '.1i, 2D
and 3D graphically oriented simulations provide for queuing as a by-product of their visual
layout. Ti, simulation of a server and queue involves two important requirements: 1) to
store cells or parts, and 2) to detect collisions or adjacent, occupied spatial areas. Tli, first
requirement, which is normally satisfied in non-spatial models through the use of facility
queues, is satisfied automatically by employing spatial data structures [33, 34]. Tli, second
requirement is satisfied through adjacency tests or collision detection algorithms.

Multimodel

Large scale models are built from one or more abstraction levels, each level being designed
using one of the aforementioned primitive model types. Ti1, lowest level of abstraction for a
system will often implement a spatial model whereas the highest level may use a declarative
finite state machine. Intermediate levels will often use functional and constraint techniques.
'.idels that are composed of other models are termed multimodels [7, 8, 11]. By utilizing
abstraction levels, we can switch levels during the simulation and use the abstraction most
appropriate at that given time. This approach gives us multiple levels of explanation and
is computationally more efficient than simulating the system at one level. '.ill; iin, dels will
be necessary as we strive for a more holistic (bringing together formerly disparate model
types) attitude toward modeling. A li.i;r l! object" is defined by an object that stores
both geometry and dynamics which correspond to the physical object -at multiple levels
of detail. Ti1, digital object will operate like its physical counterpart, providing the right
responses when prompted to do so.
We will discuss two aspects of multimodeling for the robot scenario: A.-.-!, .- il.iin (Ab-
straction) and Di-.----regation (Refinement). Even though we are modeling a single server
queue, we could easily imagine modeling an entire assembly line that includes our robot
server as one component. In doing this, we create higher level transfer functions that serve
as ;-. i -,.- i, for the lower level servers. This is an example of ;.-.-i .-i,.ii -II lumping
together low level system components to create a simplified, ;i.-.--egate component. An ex-
ample of di-.--r'egation (or process refinement) is a sub-model that models in greater detail
the semantics of service. In our previous models, we have "abstracted I'-," the issues of
automatic control and physical variables such as force, torque and position; however, many
modelers may be interested in observing the system at this level of detail. Let us analyze
the procedure of service:

1. Part is sensed by the infrared beam.

2. Robot is initially in a reset state.

3. Gripper moves to part that is waiting at the acquisition point.

4. Gripper opens and closes on part.

5. Part is moved to camera for inspection.

6. Part is either moved to the "rejects '"in" or moved to the release point.


























Figure 11: PID speed controller for robot arm.


7. Robot is reset.

If the control for the robot is fully automatic, there needs to be a control program set up to
guide the robot through these actions. Two types of control are important for our purpose:
position and speed control. Tli, control system should produce a stable movement so that
the gripper moves more or less linearly with input. Fig. 11 demonstrates one of our sub-
models necessary for the correct operation of the robot: a proportional-integral-derivative
(PID) controller. This represents one of several possible methods for compensation. This
controller controls the speed of the robot. Ti, desired speed is issued as a signal to the first
comparator (circle with a cross-bar) and is balanced by the actual speed reading from the
tachometer (Tach) senses the motor (actuator) speed. Ti, error is produced as a result, and
this error is fed into the PID section. This model is a multimodel because there are two
model types present: 1) the declarative automaton model of low detail, and 2) the functional
control model of high detail. A section of the high level model (finite state automaton) has
three states (phases) in which the robot finds itself during its operations: 1) Resetting,
2) '.l,,ving and 3) Inspecting. Tli, '-.lving" state is refined (or di-._.r'egated) to include
the PID controller. .ul iidels with more than two levels and model types are detailed
in [9].

Summary

Tli, existing taxonomy for simulation modeling was found to have several flaws, which are
rectified using the new taxonomy. Some flaws include the lack of a clear distinction between
syntax and semantics, and an unnatural separation of model types whose form is identical (as
for functional block networks containing server functions versus functional block networks
containing transfer functions). Ti, presented taxonomy of base model types, including
multimodeling, provides a cohesive view on system modeling for simulation with an eye
to clustering types together based on programming language categories. Programs and









models are similar in that both have syntax (form) and semantics (execution). T1i similarity
between models and programs lends support to providing a taxonomy for modeling which is
isomorphic to the taxonomy for programming language principles.
XWe have used this taxonomy for the past four years at the University of Florida in
both undergraduate and graduate classes in computer simulation. T111 classes were taught
within a Computer Science curriculum, therefore, students were able to easily identify with
terms such as i l!,,ili;ve," liiit, in, i~ !" and "( c l-t,_i "I since these terms are associated
with programming language principles. Students with an artificial intelligence background
could easily identify with conceptual (symbolic) modeling, and engineering students were
well versed in dynamics and the need for equationally based conservation laws and spatial
models. Our emphasis is for students to first create conceptual models for a physical scenario,
by defining the ;- ....,-ii, 111., and generalization class hierarchies. After this procedure, one
fills in the attributes and methods, some of which represent static and dynamic models. At
this stage, the physical scenario is well-organized in terms of this extended object-oriented
design. Simulation is made more comprehensible.

Acknowledgments

I would like to acknowledge the following funding sources which have contributed towards our
study of modeling and implementation of a multimodeling simulation environment: (1) Rome
Laboratory, Griffiss Air Force Base, ';, i- York under contract F30602-95-C-0267 and grant
F30602-95-1-0031; (2) Department of the Interior under grant 14-45-0009-1544-154 and the
(3) i:',ti i, iiI! Science Foundation Engineering Research Center (ERC) in Particle Science and
Technology at the University of Florida (with Industrial Partners of the ERC) under grant
EEC-94-02989.

References

[1] Jerry Banks and John S. Carson. Discrete Event System Simulation. Prentice Hall,
1984.

[2] Grady Booch. Object Oriented Design. Benjamin Cummings, 1991.

[3] Alan H. Borning. THINGLAB A Constraint-Oriented Simulation Laboratory. Tech-
nical report, Xerox PARC, 1979.

[4] Peter C. Breedveld. A Systematic '.1 1,'l,,i to Derive Bond Graph '.i, dels. In Second
European Simulation Congress, Antwerp, Belgium, 1986.

[5] Alain Colmerauer. Prolog in 10 figures. Communications of the ACM, '-'(12):1296
1310, December 1' ,.

[6] Richard C. Dorf. Modern Control Systems. Addison Wesley, 1986.

[7] Paul A. Fi-li' i, :. An Integrated Approach to System '.i, delling using a Synthesis
of Artificial Intelligence, Software Engineering and Simulation :.1 !,,i, ,!,.i -. ACM
Transactions on Modeling and Computer Simulation, 1992. (submitted for review).









[8] Paul A. FIi-li,-i' :. A Simulation Environment for i.iindeling. Discrete Event Dy-
namic Systems: TI .. and Applications, 3:151-171, 1993.

[9] Paul A. Fi-lh, i, !:. Simulation Model Design and Execution: Building Digital Worlds.
Prentice Hall, 1995.

[10] Paul A. Fi-l, i, !:. Toward a Convergence of Systems and Software Engineering. IEEE
Transactions on Systems, Man and Cybernetics, .ily, 1996. Submitted for review.

[11] Paul A. Fi-lh-, i, 1 and Bernard P. Zeigler. A iih!liindel ':. I I, i, .1, ..gy for Qualitative
.idel Engineering. ACM Transactions on Modeling and Computer Simulation, 2(1):52
81, 1992.

[12] Carlo Ghezzi and :'.1 lilii Jazayeri. Programming Language Concepts. John Wiley, 1982.

[13] Nevin Heintze, Joxan Jaffar, Spiro .i'iI Iiylov, Peter Stuckey, and Roland Yap. TI,
CLP(7R) Programmer's Manual: Version 1.1, November 1991.

[14] John E. Hopcroft and Jeffrey D. Ullman. Introduction to Automata T7.. j, Languages
and Computation. Addison Wesley, 1979.

[15] John A. Jacquez. Compartmental Analysis in B'. ,I,.,i and Medicine. University of
.I[ Kii li; Press, 1' .. Second edition.

[16] Dean C. Karnopp, Donald L. lirgolis, and Ronald C. Rosenberg. System Dynamics.
John Wiley and Sons, 1990.

[17] Robert Kowalski. Logic for Problem Solving. Elsevier North Holland, 1979.

[18] Averill ':. Law and David W. Kelton. Simulation Modeling & Analysis. .1 Graw-Hill,
1991. Second edition.

[19] William Leler. Constraint Programming Languages: TI, : Specification and Generation.
Addison Wesley, 1988.

[20] Bertrand :.' 1 Introduction to the T7 .... of Programming Languages. Prentice Hall
International Series, 1990.

[21] Greg Ii, !-, 1- 'i An Introduction to Functional Programming through Lambda Calculus.
Addison Wesley, 1989.

[22] Ben .i -.l. )wski. Executing Temporal Logic Programs. Cambridge Press, Cambridge,
1986.

[23] Richard E. N.iii, Simulation Programming Languages: An Abridged History. In 1995
Winter Simulation Conference, pages 1307 -1313, Washington, DC, December 1995.

[24] Katsuhiko Ogata. Modern Control Engineering. Prentice Hall, 1970.

[25] L. C. Paulson. ML for the Working Programmer. Cambridge University Press, 1991.

19









[26] James L. Peterson. Petri Net T7, j and the Modeling of Systems. Prentice-Hall, Inc.,
Englewood Cliff- N.J., 1981.

[27] Herbert Praehofer. Systems Thi retic Formalisms for Combined Discrete-Continuous
System Simulation. International Journal of General Systems, 19(3):219-240, 1991.

[28] Przemyslaw Prusinkiewicz and Aristid Lindenmeyer. TI7 Algorithmic Beauty of Plants.
Springer-Verlag, 1990.

[29] R. Raghuram. Computer Simulation of Electronic Circuits. John Wiley, 1989.

[30] G. Revesz. Lambda Calculus Combinators and Functional Programming. Cambridge
University Press, 1988.

[31] :' li'y Roberts, David Andersen, Ralph Deal, 'ii., 11, Garet, and William ,li.f1 ,
Introduction to Computer Simulation: A Systems Dynamics Approach. Addison-Wesley,
1983.

[32] James Rumbaugh, `.i .i, I1 Blaha, William Premerlani, Eddy Frederick, and William
Lorenson. Object-Oriented Modeling and Design. Prentice Hall, 1991.

[33] Hanan Samet. Applications of Spatial Data 5n.., i,,res: Computer Graphics, Image
Processing, and GIS. Addison-Wesley, 1990.

[34] Hanan Samet. T7, Design and Analysis of Spatial Data S,, i l,,res. Addison-Wesley,
1990.

[35] Lee W. Schruben. Simulation modelingn g with Event Graphs. Communications of the
ACM, 26(11), 1983.

[36] Bjarne Stroustrup. T/I, C++ Programming Language. Addison Wesley, 2 edition, 1991.

[37] Tommaso Toffoli and Norman lirgolus. Cellular Automata Machines: A New Envi-
ronment for Modeling. .liT Press, 1987. Second edition.

[38] Patrick Henry Winston and Berthold Klaus Paul Horn. LISP. Addison Wesley, second
edition, 1984.

[39] Stephen Wolfram. Tl... j and Applications of Cellular Automata. World Scientific
Publishing, Singapore, 1986. (includes selected papers from 1983 1986).

[40] Bernard P. Zeigler. Towards a Formal T1,, ,ry of '.i delling and Simulation: Structure
Preserving 'I 1,rphisms. Journal of the Association for Computing Machinery, 19(4):7 Ii'
764, 1972.

[41] Bernard P. Zeigler. DEVS Representation of Dynamical Systems: Event-Based Intelli-
gent Control. Proceedings of the IEEE, 77(1):72 -80, January 1989.

[42] Bernard P. Zeigler. Object Oriented Simulation with Hierarchical, Modular Models:
Intelligent Agents and Endomorphic Systems. Academic Press, 1990.

20









Paul A. Fi- li-'i 1: is an Associate Professor in the Department of Computer and Informa-
tion Science and Engineering at the University of Florida. He received the PhD in Computer
and Information Science from the University of Pennsylvania in 1986. He also has six years of
industrial/government production and research experience working at i' -"ort .', Ship-
building and Dry Dock Co. (doing CAD/CA'. 1 parts definition research) and at NASA Lan-
gley Research Center (studying engineering data base models for structural engineering). His
research interests are in computer simulation modeling and analysis methods for complex
systems. He is a senior member of the IEEE and the Society for Computer Simulation. He is
also a member of the IEEE Society for Systems, '.1ii and Cybernetics, A ':.1 and AAAI. Dr.
Fi-hli" i-, founded the comp.simulation Internet news group (Simulation Digest) in 1987.
He has chaired workshops and conferences in the area of computer simulation, and will serve
as General Cli, ir of the 2000 Winter Simulation Conference. He was chairman of the IEEE
Computer Society technical committee on simulation (TCSIM) for two years (1988-1990) and
he is on the editorial boards of several journals including the ACM Transactions on Model-
ing and Computer Simulation, IEEE Transactions on Systems, Man and Cybernetics, T',
Transactions of the Society for Computer Simulation, International Journal of Computer
Simulation, and the Journal of Systems Engineering. Dr. Fi-l' -i, 1's WWW home page is
http://www.cis.ufl.edu/~fishwick and his E-mail address is fishwick@cis.ufl.edu.




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