Proceedings of the 1993 Winter Simulation Conference

G.W. Evans, M . Mollaghasemi, E.C. Russell, W.E. Biles (eds.)

MODELING AND SIMULATION WORLDVIEWS

John S. Carson

Carson/Banks & Associates, Inc.

4665 Lower Roswell Road, #140
Marietta, GA 30068

ABSTRACT way, depending both on the world view of the

language being used as well as the view taken by the
This paper provides a language-independent modeler.
introduction to the major simulation modeling world Many important issues of simulation are not
views for discrete-event systems simulation. A world discussed in this paper, but are discussed in other
view is the modeling framework that a modeler uses papers in the introductory series.
to represent a system and its behavior. The main
terminology and concepts include systems and 2 BASICCONCEPTS
models, system state variables, entities and their
attributes, lists, resources, events, activities and There are a number of concepts underlying all the
delays. These concepts are covered from the major world views in discrete-event simulation
perspective of the modeler. Finally, in the tutorial, modeling. These include system and model, system
we will attempt to make these ideas concrete through state, entities and attributes, lists, event and event
the use of a number of examples and exercises. notices, resources, and activities and delays.

1 INTRODUCTION 2.1 System and Model

This paper introduces the major world views of A model is simply a representation of a system.
simulation modeling from the perspective of a person The system should be defined with clear boundaries
about to begin development of his or her first model between the outside world and the portion of the
using a discrete-event simulation language. The world being simulated. Generally, the system
purpose is to give modelers increased understanding components are simulated in varying degrees of
of the world views built into the major commercially detail, depending upon their perceived importance
available simulation languages. Both the article and with respect to the modeling objectives, while the
the tutorial are introductory in nature and are meant outside world is simulated only to the extent that
for the reader new to discrete-event simulation. specific events impinge upon the system. A simple
First, we discuss the basic concepts: system state, example is random arrivals (from the outside world)
events, entities, and activities. Then we discuss the that place demands upon system resources.
event-scheduling world view, historically the first A discrete-event simulation model is a specific
approach to discrete-event systems simulation. type of model that may be contrasted to other types
Finally we discuss the process interaction and such as mathematical models, descriptive models,
transaction flow world views, and their statistical models, and input-output models. A
implementation through process procedures, block discrete-event model attempts to represent the
diagrams, or arcinode representations. components of a system and their interactions to a
In the tutorial, we will illustrate how a modeler level of detail sufficient to meet the objectives of the
may take more than one view of a given problem, study and to answer the questions appropriate to
leading to a number of possible models of one those objectives.
system. Through an example, we illustrate how a With their detailed representation of system
simple problem can be modeled in more than one components, discrete-event models stand in contrast
to some mathematical, statistical and input-output

18

Authorized licensed use limited to: Carleton University. Downloaded on December 13,2023 at 18:29:12 UTC from IEEE Xplore. Restrictions apply.
 Modeling and Simulation Worldviews 19

models that represent a system's inputs and outputs events. For example, interarrival times may be
explicitly, but attempt to represent the inner workings characterized by a statistical distribution and
by a mathematical or statistical relationship derived generated in the model by sampling from this
empirically or on some other ad hoc basis, not by a distribution. This is one way among many of
detailed representation of the actual inner workings. generating (i.e. computing) the time of occurrence of
Some mathematical models, for example those from a future arrival event.
physics, are based on a theory and are not merely The so-called event times are recorded in event
empirical as are many statistical models based solely notices and placed in a list called the event list. The
on data. event list is managed by the underlying simulation
Discrete-event models are dynamic with respect to software system in such a way (discussed later) as to
time. In other words, time plays a crucial role in the cause events to occur at proper times in the model.
sense that the variables defining system state are Note that an event occu~sat an instant of time; it does
functions of time. Many mathematical, statistical and not have a duration.
spreadsheet models are static; they represent a Examples: an arrival to a system; the completion
system's state at a fixed point in time. of service at a particular service center; a breakdown
Discrete-event models can also be differentiated of a machine.
from continuous models, based on the nature of the In Section 2.6, we distinguish two types of event,
variables needed to track system state. The system the primary or unconditional event, and the
state variables in a discrete-event model remain secondary or conditional event.
constant over intervals of time and change value only
at certain well-defined epochs (points in time) called 2.4 Entities, Attributes and Lists
event times. On the other hand, continuous models
have system state variables defined by differential or An entity in a model represents some object or
difference equations and thus its variables change element of the system that needs to be explicitly
continuously over time. Some models are mixed modeled. An entity may be dynamic in nature in the
continuous and discrete, simply due to the nature of sense that it "moves" through the system, or it may
the system being modeled or because of modeling be static in the sense that it services other entities.
efficiencies. For instance, in some circumstances, Examples: a customer in a queueing system
discrete systems can be efficiently modeled with (dynamic entity); a server in a service system
continuous models, and continuous systems with (dynamic or static depending on how modeled).
discrete models. An entity may have one or more attributes, or
We give a more precise definition of discrete-event properties, that belong to that entity. There may be
modeling after further discussion of system state and many entities of a particular entity class, all having
events. the same attributes but each having its own value for
an attribute.
2.2 System State Variables Examples: (1) The set of all customers is an
entity class with attributes of demand, due date and
As implied in the previous section, system state priority. Each individual customer entity may have
variables are the collection of all variables needed to unique values for demand, due date and priority.
define system state to a level of detail sufficient to (2) A server may have a service rate
meet the project's objectives. Determining those and a schedule.
variables is matter of art and experience as much as Typically, entities are managed by attaching them
science. Fortunately, for the most part, the act of to resources (discussed next in section 2.5) that
modeling, of putting a model together, will bring to provide service to them, by attaching them to event
the fore any initial oversights in identifying system notices (thus suspending their activity until some
state variables. future time). or by placing them into an ordered list.
Lists of entities are used to represent queues, places
2.3 Events and Event Notices in a system where entities are forced to wait due to
scarce resources or other system conditions. In the
An event in a model corresponds to a happening in simulation literature (and in simulation languages),
the real system that changes or potentially changes lists are variously referred to as queues, files, chains
the state of the system. In a model, future events are or some other similar term. A list may have a FIFO
modeled by making assumptions or using collected ordering ( f i t - i n , first-out), so that entities are joined
data regarding the times of occurrences of these to the back of the list and removed from the front of

Authorized licensed use limited to: Carleton University. Downloaded on December 13,2023 at 18:29:12 UTC from IEEE Xplore. Restrictions apply.
 20 Carson

the list. In fact, a list may be FIFO, LIFO (last-in, state, or is at most a computable function of past and
first-out), or sequenced by a specified attribute of an current system state. As we will see, an activity time
entity. For example, a set of entities representing usually "holds" a dynamic entity for its duration.
orders may be sequenced on a list from smallest to Examples: service times, time to failure of a
largest due date, representing the priority in which machine or component, time between arrivals
orders are to be handled. Some typical examples include:

2.5 Resources WAIT FOR 3 MINUTES

A resource is a type of entity that provides service where MINUTES refers to simulated time units, or
to other entities. A resource may have a capacity,
typically representing a number of servers in parallel. WAIT FOR EXPONENTIAL(10.2) MINUTES
Typically, a dynamic entity may request one or more
units of a resource. If denied, the entity joins a where the wait is for a random amount of time
queue to wait or takes some other specified action; if generated as a sample from an exponential
not denied, the entity captures the units of the distribution having mean 10.2 minutes.
resource for a duration of time and eventually In contrast to an activity time, a delay is an
releases the units of the resource. indefinite duration of time that is caused by some
Typically at minimum, a single-unit resource has a combination of system conditions. The nature of a
status attribute representing busy and idle states; delay is expressed by the pseudo-code:
more generally, a multi-unit resource has an attribute
for number of captured or busy units. In many WAIT UNTIL CONDITION y IS TRUE
language implementations of these concepts, a
resource may have additional attributes representing meaning that a process or entity is "held" until some
other possible states. These may have a name such as specific system condition becomes true. Typically in
availability (two values: available and unavailable). complex real-world models, a delay is a complex
Examples: a single server in a queueing system; a function of current and future system states and
bank teller; a machine; a grouping of two automated cannot be computed ahead of time. Only the dynamic
teller machines. "working out" of the simulation logic can determine
A resource is manipulated by two actions, here the duration of a delay. Specific examples of delays
called CAPTURE and FREE, and typified by the include:
following pseudo-code referring to a resource called
MACHINE: WAIT IN A QUEUE TO BE SERVICED

CAPTURE 1 UNIT OF MACHINE

WAIT FOR 10 MINUTES
FREE 1 UNIT OF MACHINE WAIT UNTIL LEVEL IN TANK IS c 2400
GALLONS
2.6 Activities and Delays

An activity is a definite duration of time that is

explicitly defined by the modeler. It may be a WAIT UNTIL MACHINE A IS AVAILABLE
constant duration, a random duration (definition AND IDLE
based on a random number generator), a formula, or
a value from an input data file; it may be computed All discrete-event simulations contain activities,
by any means within the model. The key is that it is else time does not advance in the simulation.
definite and known to the model at the instant it Virtually all such models have entities queueing,
begins. The nature of an activity is expressed by the resulting in delays to these entities.
following pseudo-code: The beginning and end of activities and delays are
events. A primary or non-conditional event is one
WAIT FOR x TIME UNITS that occurs at the end of an activity time. A
secondary or conditional event is one that occurs as a
where x is explicitly defined by the modeler and is consequence of a primary event occurring during a
either independent of past, current and future system particular system state, or that occurs at the end of a

Authorized licensed use limited to: Carleton University. Downloaded on December 13,2023 at 18:29:12 UTC from IEEE Xplore. Restrictions apply.
 Modeling and Simulation Worldviews 21

delay time. change value

For example, if arrivals to a system are defined in - One or more conditional events may be
terms of a constant interarrival time, an arrival triggered to occur now, as a combined consequence
becomes a primary event. On the other hand, when a of this event and current system state
customer in a queue begins service is a secondary or - One or more primary events may be
conditional event. "scheduled" to occur at some future simulation time
Warning: Simulation languages and packages do
not all use the same standard terminology. Some At time zero during model initialization, the
languages use "delay" for what we have called an modeler must do the following:
activity time. - Initialize all system state variables
- Initialize all resource capacities and states
2.7 Discreteevent simulation model - Generate and schedule at least one primary
event
With the above definitions and concepts in mind, Scheduling an event consists of, first, creating an
we can now give a more complete definition of a event notice, that is, a record that contains event type
discrete-event model, and a hint for how such a and (future) event time, and secondly, placing the
simulation is carried out. event notice on a special list of event notices called
A discrete-event model is one in which the system the event list or future event list. Event notices on
state variables change only at those discrete points in the event list are ranked from smallest to largest event
time at which events occur. Events OCCUT from time time. The event notice at the top of the event list
to time as a consequence of activity times and delays. defines the imminent event or the event to occur next
Entities may compete for system resources. possibly in simulated time.
joining queues while waiting for a free resource. Every simulation has one stopping event, the event
Activity and delay times may "hold" entities for that designates simulation completion. It may be a
durations of time. primary event, as for example, "stop the simulation
Such a discrete-event model is carried out over after exactly 8 simulated hours". Or it may be a
time (or "run", not solved) by a mechanism that conditional event, such as "stop the simulation after
moves simulated time forward from current event to 100 customers have completed service".
next event, updating system state at each event time, The event oriented world view is implemented by
and freeing and capturing system resources. The the event scheduling algorithm:
underlying mechanism involves event "scheduling" 1. Initialize the model, as described above.
and event execution in proper order with respect to 2. Remove the event notice for the imminent
simulated time. event from the event list (event notice with smallest
event time.)
3 WORLD VIEWS 3. Advance the simulation clock to the event
time of the imminent event.
The representation of a discrete-event model and 4. Execute the imminent event.
the implementation of the event-scheduling 5. If the simulation is not complete, go to step
mechanism is a function of the world view. We will 2.
discuss the major world views used by the popular Otherwise, stop the simulation and report
and time-tested major simulation languages in use in results.
the USA today. These world views are event In Step 4, one of the event routines is executed. In
orientation, process interaction, and transaction flow. this manner a simulation is carried forward in time,
from event to event, until the stopping event occurs.
3.1 Event oriented world view Event oriented simulations may contain entities
that are created upon the occurrence of certain events,
When using the event oriented world view, a whose attributes change when other events occur, and
modeler first identifies all events and their effect on which capture resources and join queues. However,
system state. Then he or she writes event routines the point of view is that of an event and to envision
that completely define the consequence of each event. the "flow" of an entity through the system takes
Recall that an event occurs in an instant of time, so imagination and an understanding of the entity's
that an event routine occuls in zero simulated time. interaction with the possibly many events affecting it.
The consequences of an event may include: Event scheduling simulations are traditionally
- One or more system state variables may implemented in a general purpose programming

Authorized licensed use limited to: Carleton University. Downloaded on December 13,2023 at 18:29:12 UTC from IEEE Xplore. Restrictions apply.
 22 Carson

language such as FORTRAN, Pascal, or C. There because active processes may interact as they compete
are a number of commercially available libraries of for limited resources and in other ways. This process
routines in FORTRAN and other languages to interaction is handled essentially automatically by
facilitate the programming of event oriented languages that utilize the process world view.
simulation models. These libraries of event- As an example, consider customers arriving at a
scheduling routines implement tasks common to all bank and queueing for service from the three tellers
event oriented models, such as management of the on duty. Here is some pseudo-code representing a
event list, management of lists of entities (queues), customer process:
statistics collection for output reporting, and
management of resources. CUSTOMER PROCESS:
A number of commercially available simulation CUSTOMER ARRIVES (arrival event)
languages that emphasize a process interaction or 'A' I F ALL UNITS OF TELLER (entity joins list)
transaction flow world view also have an (optional) RESOURCE ARE BUSY,
built-in event-scheduling world view, and allow a JOIN TELLER-QUEUE
model to be a mix of process and event oriented ELSE (capture resource)
routines. 'C' CAPTURE ONE TELLER
Example: A simple single server queue can be WAIT FOR x TIME UNITS
modeled with three primary events: FREE TELLER (free resource)
- Arrival event ENDIF
- Service completion event CUSTOMER DEPARTS (departure event)
- Stopping event
Consequently, the model will have three event Actually, to have a complete model requires at
routines. The arrival routine would increment the least two other abstract processes, or the customer
number of customers in the system (i.e. change entity must take on additional duties that do not,
system state) and conditionally trigger a "begin strictly speaking, correspond to customer activity in
service" event. That is, if the server's status was idle the real world. The two processes referred to are one
upon arrival, the server becomes busy. Beginning to create additional future arrivals and the second to
service is a conditional event. Similarly, the modeler remove a CUSTOMER entity from the list called
would have to develop the logic and code for the TELLER-QUEUE whenever a service completion
other two primary events. event occurs.
The arrival process can be modeled in several
3.2 Process interaction world view different ways. One is to envision the line
"CUSTOMER ARRIVES'' above as a subsidiary
The process interaction world view provides a way process that is used to "generate" future arrivals, as
to represent a system's behavior from the point of illustrated by the following pseudo-code:
view of the dynamic entities moving through the
system. A process is a time-ordered sequence of CUSTOMER ARRIVAL PROCESS:
events, activities and delays that describe the flow of ' S ' GENERATE T = INTERARFUVAL TIME
a dynamic entity through a system. WAIT FOR T TIME UNITS
Languages implementing a process interaction CREATE NEW CUSTOMER ENTITY
world view require the modeler to write process SEND NEW CUSTOMER ENTITY TO
routines, which are quite different from event CUSTOMER PROCESS, LOCATION
routines. While event routines occur in zero time, 'A'
process routines may contain both activities and GO TO 'S'
delays. Process routines are not possible in ordinary
programming language such as FORTRAN and Many process interaction languages implement
Pascal; they require special mechanisms for such an entity arrival process in one statement in the
interrupting and suspending the execution of a language, so that a modeler does not have to
routine, and resuming execution at a later simulated explicitly program such processes.
time under the control of an intemal event scheduler. We also may need to create an abstract process, or
(Internally but hidden from the view of the modeler, extend the customer entity's duties, to bring the first
there are still events being scheduled and an event list customer off the queue whenever a teller becomes
being manipulated.) idle, perhaps as follows:
This world view is call process interaction,

Authorized licensed use limited to: Carleton University. Downloaded on December 13,2023 at 18:29:12 UTC from IEEE Xplore. Restrictions apply.
 Modeling and Simulation Worldviews 23

FREE TELLER PROCESS:

IF TELLER-QUEUE IS NON-EMPTY, 4 SUMMARY
REMOVE FIRST CUSTOMER ENTITY
FROM TELLER-QUEUE In the tutorial, we will give one or more examples
SEND CUSTOMER IMMEDIATELY and exercises to illustrate the concepts discussed in
TO LOCATION 'C' this paper. With one example, we will provide a
ENDIF model from a number of different perspectives,
illustrating how two people can develop quite
Note that the "FREE TELLER PROCESS" occuts different though equally accurate models of the same
in zero time; there are no activities or delays. In system.
effect, it is an event. (A zero time process procedure
is equivalent to an event routine.) Many simulation REFERENCES
languages implement the equivalent of the "FREE
TELLER PROCESS" automatically, so the modeler Banks, J. and J.S. Carson, 1984. Discrete-Event
does not need to explicitly address the handling of the System Simulation. Prentice-Hall.
customer queue. Law, A.M. and W.D. Kelton, 1992. Simulation
The process world view is the most popular world Modeling and Analysis, 2nd Edition. McGraw-
view in terms of commercially available simulation Hill, New York.
languages in the USA.
AUTHOR BIOGRAPHY
3.3 Transaction flow world view
JOHN S. CARSON is a founder and president of
A transaction flow world view is a special case of Carson/Banks & Associates, Inc., a firm specializing
the (possibly) more general process interaction world in simulation model development, services and
view. A transaction is nothing but another name for training. He has developed numerous large-scale
a dynamic entity that flows through a system. simulation models with application to manufacturing,
In the transaction world view, transactions are material handling, warehousing, distribution,
viewed as flowing through a block diagram or a transportation and rapid transit, port operations and
network of arcs and nodes. In the block diagram shipping, medical delivery systems, and reservations
framework, epitomized by GPS&M and also adopted systems. He has served on the faculties of the
by SIMANTM, blocks represent either immediate Georgia Institute of Technology and the University of
events, activities or delays. Languages such as GPSS Florida. With Jerry Banks, he is the co-author of the
and SIMAN have a collection of blocks to represent widely-used texts Discrete-Event Svstems Simulation
capture and release of resources, modeler (Prentice-Hall, 1984)and Getting Started with
manipulation of lists of transactions, and activities GPSS/H (Wolverine Software Corp., 1989). He is a
(explicitly defined passages of time). The block member of IIE, ORSA, and TIMS. Dr. Carson
diagram, similar to a process flow diagram, is a set of received his Ph.D. in Industrial Engineering and
blocks connected by arrows, representing the Operations Research from the University of
transaction process. Wisconsin at Madison (1978).
Other simulation languages, such as SLAM IITM
and SLAMSystemTM,adopt a nodelarc point of view,
with arcs representing activities and nodes
representing all other events and actions. The
node/arc p i n t of view is similar in philosophy to the
block diagram point of view.
In the transaction flow world view, process code
similar to that in the preceding section is viewed as
being executed by the entity or transaction as it
moves from statement (block, node or arc) to
statement (next block, node or arc). For some
implementations of this world view, this makes the
transaction flow world view somewhat more
restrictive than the process interaction world view.

Authorized licensed use limited to: Carleton University. Downloaded on December 13,2023 at 18:29:12 UTC from IEEE Xplore. Restrictions apply.