See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/319556799

Foundations of Simulation Modeling

Chapter · January 2011

DOI: 10.1002/9780470400531.eorms0336

CITATIONS READS

6 7,283

2 authors, including:

Victor W. K. Chan
Tsinghua University
152 PUBLICATIONS 1,318 CITATIONS

SEE PROFILE

All content following this page was uploaded by Victor W. K. Chan on 28 September 2019.

The user has requested enhancement of the downloaded file.

FOUNDATIONS OF SIMULATION
MODELING
WAI KIN
VICTOR CHAN
Department of Industrial and Systems
Engineering, Rensselaer Polytechnic
Institute, Troy, New York
Simulation modeling is an important step
of a simulation study. It concerns with the
creation of an efficient simulation model as
accurate as needed to mimic the behavior
of the underlying system and to reproduce
useful observations for subsequent analysis.
This introductory article discusses three
main simulation modeling methods: discrete-
event simulation, continuous simulation,
and agent-based simulation. In particular,
three discrete-event simulation modeling
paradigms are introduced: event scheduling,
process interaction, and activity scanning.
Several modeling issues are exemplified by a
simple single-server queuing system and a
slightly more complex multiple-server finite
capacity queuing system with impatient
customers. Continuous simulation is briefly
discussed to draw the differences between
discrete-event and continuous simulations.
Simulating emergent behavior as a common
purpose of agent-based simulation is demon-
strated by a classic game of life model and
a variation model. Monte-Carlo simulation
and other simulation modeling formalisms
are briefly highlighted.
INTRODUCTION
Basically, a simulation study involves three
steps: modeling, analysis, and presentation.
These three steps can be repeated until satis-
faction. Modeling is about the creation of an
efficient simulation model. Analysis here in a
broad sense includes studies of inputs to and
outputs from the simulation model, design of
experiments, and optimization. The impor-
tance of the presentation step is sometimes
Wiley Encyclopedia of Operations Research and Management Science, edited by James J. Cochran
Copyright © 2010 John Wiley & Sons, Inc.
1
underestimated. Presentation is about how
to effectively collect and present simulation
results and how to communicate with rele-
vant people to improve, verify, and validate
(or accredit) the model and results. None of
the three steps should be omitted in a profes-
sional simulation study.
This introductory article focuses on the
first step—modeling. In particular, it deals
with computer-based simulation modeling.
A computer-based simulation model has
the advantages of being low cost, fast, and
repeatable. Beginners sometimes find mode-
ling a time consuming task. This is perhaps
due to unfamiliarity with either the mod-
eling approach or the software package (or
both). This article addresses the former by
introducing different simulation modeling
approaches. References for using software
packages are provided in subsequent discus-
sion. One mistake that beginners often make
is the inclination of including as many details
as possible into their simulation models. It
should be noted that a simulation model is
created to satisfy the need of a simulation
study, rather than to duplicate the real sys-
tem exactly. Therefore, the objective of the
study matters in simulation modeling.
The modeling power of a simulation mod-
eling approach and the functionalities of the
underlying simulation package should also
be evaluated separately. It is possible that
a less convenient modeling approach imple-
mented by a powerful software platform
receives more attention than a more flexible
and scalable modeling approach that was
executed in a lower-level, less user-friendly
programming language. This article does
not review the usage, user interface, and
functionalities of simulation packages.
Depending on the state of a system and the
need of a simulation study, the corresponding
simulation model can be discrete, continu-
ous, or hybrid. Strictly speaking, a simulation
model is discrete (continuous) if all its state
variables are discrete (continuous). A model
with both discrete and continuous state vari-
ables is a hybrid simulation model. There are
2 FOUNDATIONS OF SIMULATION MODELING
also several other ways of classifying simula-
tion models including, static versus dynamic,
deterministic versus stochastic, analytic ver-
sus numeric, and physical versus computer-
based. For example, a simulation model is
dynamic if time (simulation clock) is present
and static otherwise. Monte-Carlo simula-
tion is one type of static simulation models.
Discrete-event and continuous simulations
are usually dynamic simulation models [1].
Besides discrete, continuous, and Monte-
Carlo simulations, a relatively new simulat-
ion paradigm—agent-based simulation—has
received increasing attention in various
fields over the past two decades. Basically,
agent-based simulation, being a bottom-up
approach, is capable of modeling systems
with intelligent, heterogeneous, and auto-
nomous entities. An agent-based simulation
model can be discrete, continuous, or both
depending on the type of its state variables.
One of the main purposes of agent-based
simulation is to simulate know or unknown
macroscopic behavior emerging from micro-
scopic interactions.
The rest of the article is organized as
follows. The section titled ‘‘Discrete-Event
Simulation Models’’ discusses three discrete-
event simulation modeling approaches. The
section titled ‘‘Continuous Simulation Mod-
els’’ outlines continuous simulation models.
The section titled ‘‘Agent-Based Models’’
highlights several key concepts in agent-
based simulation. The section titled ‘‘Monte-
Carlo Models’’ briefly introduces Monte-
Carlo simulation. The final section offers a
conclusion.
DISCRETE-EVENT SIMULATION MODELS
One special property of a discrete-event sys-
tem is that its state changes only at dis-
crete instants of time. These instants of time
represent the occurrences of certain events
that change the state of the system and are
referred to event occurrence times (or sim-
ply, event times). The system state remains
constant in between event times because
during which no events occur. This special
property facilitates the modeling and anal-
ysis of discrete-event simulation because it
allows modelers to focus on the events, their
relationships, and durations. To put it in a
simple way, creating a discrete-event sim-
ulation model is to identify these elements
and put them together in a correct manner.
This will be demonstrated by examples in the
following.
Several concepts in discrete-event simu-
lation modeling are of importance:
randomness, dynamics (time evolutions),
future-event list (or pending events list or
event calendar), and resident and transient
entities.
Randomness is the uncertainty in the
occurrences of events and durations. Time
evolutions are the footprints of the system
state with respect to time (both occurred
events and their times). Randomness and
time evolutions together differentiate a disc-
rete-event simulation model from a standard
computer program that is deterministic
and static (i.e., no time involved). Almost
all simulation packages provide simple
mechanisms to implement randomness
(i.e., by specifying distributions for event
durations and relationships) and handle
time evolutions (i.e., by providing access to
the current and future simulated times).
A future-event list keeps track of the
events scheduled to occur in the simulated
future. This list is updated whenever a new
event is scheduled to occur in the simulated
future. This list is automatically generated
and updated in most simulation packages.
Users sometimes can also access and modify
this list.
Resident entities are objects that reside in
the model for a long period of time compared
to the simulation run length, for example, a
facility, a server, or a queue. Transient enti-
ties on the other hand appear in the model
for a short period of time, for example, a job,
a customer, or a message. The population
of resident entities is usually much smaller
than that of transient entities. In a typical
queuing model, the number of servers is usu-
ally less than a hundred while the number
of jobs/customers can be tens of thousands
or millions. The large population of transient
entities poses a computational burden if each
of them is stored in memory and requires
a certain amount of computation. A more
 FOUNDATIONS OF SIMULATION MODELING
efficient modeling approach is to keep track
of the aggregated information of the tran-
sient entities, such as the total number of
jobs in queue or the total waiting time of
jobs in the system, rather than the indi-
vidual information, such as the individual
waiting time of each job. Because this aggre-
gated information is usually associated with
some resident entities, e.g., the queue size,
this approach is called the resident-entity
approach. The drawback of this approach
is that the individual characteristics of the
transient entities are lost. Nevertheless, this
approach has been shown to significantly
improve simulation speed and memory usage
[2, 3]. Indeed, it is sometimes possible to
avoid memorizing individual characteristics
and still be able to obtain the same accuracy
Discrete-Event Simulation Execution Algorithm
Initialize
Do until stop condition is satisfied
Advance clock to the time of next event
Execute event
Perform actions: change state variables, schedule events, collect statistics, etc.
Event Scheduling
We will use a single-stage multiple-server
queuing system with finite capacity and
impatient customers (i.e., G/G/c/K) to
illustrate several basic modeling issues of
discrete-event simulation. In this system,
there is only one type of transient entities
(called customers) and they arrive at the
system in accordance with an arbitrary
stochastic process. Each arriving customer is
admitted if the current queue size is less than
its capacity (denoted by K). Upon joining the
queue, each customer starts a random impa-
tient time period; if he/she does not receive
service by the end of the impatient time,
he/she will depart the system without being
served. The c servers are identical with no
vacation and breakdown. This simple model
can represent many real-world systems, for
example, a bank waiting line with multiple
clerks, or a computer communication system
(or a call center) in which the entities are the
messages or requests stored in buffer and the
3
in the simulation results. This is demon-
strated in the following example.
A discrete-event simulation model can be
created using different world views, which
were first discussed in Kiviat [4] and Lack-
ner [5]. Three popular world views: event
scheduling, process interaction, and activity
scanning, are introduced in the following.
Before that, let us first outline a typical algo-
rithm for executing a discrete-event simula-
tion model. This algorithm is essentially an
event-scheduling algorithm. Most software
packages employ a similar execution algo-
rithm. If one prefers not to use existing sim-
ulation packages, he/she can also implement
the algorithm by using a general-purpose pro-
gramming language, such as C/C++.
servers are the parallel CPUs (or operators)
handling these messages/requests.
A good starting point of building a
discrete-event simulation model is to have a
textual description of a simplified model and
try to identify and combine the key events,
event relationships, and conditions into a
desired logic. After the simplified model
is finished, other features can be added to
augment the simplified model to create the
final model. We will employ this practice to
first develop a single-server queuing system
with infinite capacity and no impatient
customers, and then modify this simplified
model to model the original system. A tex-
tual description of the single-server queuing
simulation is given in the following.
‘‘A simulation begins by having the first
job enter the system. New jobs enter the sys-
tem at random intervals of arrivals. When a
job enters, if the resource is available the job
can start service. Once a job starts, it will
leave after a service time delay. Whenever
4 FOUNDATIONS OF SIMULATION MODELING
a job leaves, if there is more work waiting,
then service can start on the next job’’ [6].
Almost all information necessary to build
this single-server model is embedded in above
paragraph. To see this, we highlight the key
words in three different formats: bold face,
underline, and italics. The words in bold face
represent the events: ‘‘enter,’’ ‘‘start,’’ ‘‘leave,’’
and the initial event ‘‘begin,’’ which only exe-
cutes once. The underlined words denote the
random time durations. Here, ‘‘random inter-
vals of arrivals’’ are the interarrival times of
the arriving entities, and ‘‘service time delay’’
is the service time duration of each service.
The italicized words signify event-scheduling
conditions. To build the actual model, circle
the events and add arcs starting from the
corresponding preceding event and ending at
the corresponding succeeding event in each
sentence (see Fig. 1). These arcs represent
the event relationships. The delay time on
each arc is specified by the underlined words
if present, or zero otherwise. The condition
on each arc is given by the italicized words on
that sentence if present, or unconditional oth-
erwise. The resulting simulation model (the
right panel of Fig. 1) is an event-scheduling-
based simulation model, which is represented
by a simulation modeling language called
event relationship graphs, or simply event
graphs [7]. Two state variables (Q and R) and
two random variables (a and s) are needed:
Q returns or sets the current number of
customers in the queue, R returns or sets
the current number of available servers, a
A simulation begins by having the first job enter the system.
New jobs enter the system at random intervals of arrivals.
When a job enters, if the resource is available the job can start service.
Once a job starts, it will leave after a service time delay.
Whenever a job leaves, if there is more work waiting, then service can start on the next job.
Figure 1. From textual description to simulation model.
returns an interarrival time generated from a
given distribution (i.e., a = Fa−1 (u), where u is
a uniform random number between 0 and 1),
s returns a service time duration generated
from a given distribution (i.e., s = Fs−1 (u)).
We now ready to extend this model
to our final multiple-server system with
queue capacity and impatient customers.
Two important discrete-event simulation
modeling techniques are used: Boolean
expressions and look-ahead capability. To
model the queue capacity, we note that
when a customer arrives, the queue size will
increase by one if the current queue size is
less than K (i.e., the customer is admitted),
and remains unchanged otherwise (i.e.,
the customer is rejected). This logic can be
implemented by using the following Boolean
expression:
Q = Q + (Q < K), (1)
where (Q < K) = 1 if the condition is true and
zero otherwise.
To model impatient customers without
storing the waiting times of all customers
(i.e., without resorting to the transient entity
approach), we use the look-ahead capabil-
ity to obtain information in the simulated
future. For ease of exposition, we will use
a two-server queuing system (i.e., c = 2) to
illustrate the idea (it can be extended to more
than two servers). The idea is as follows.
When a customer arrives (say customer i), if
he knows the maximum duration he needs
(Q)
a
(R)
Begin Enter Start s Leave
Q=0 Q=Q+1 Q=Q–1 R=R+1
R=1 R=R–1

to wait in queue, he can determine to stay
or leave right away. The key modeling ques-
tion here is how to know such maximum wait
duration. We use two auxiliary variables, T1
and T2 , which record the first and second
earliest available times of the two servers.
T1 and T2 are updated whenever a customer
arrives and decides to stay (recall that the
state of a discrete-event simulation model
changes only at discrete instants). We add a
Stay event after the Enter event to update
T1 and T2 (see Fig. 2). The new values of
T1 and T2 will include the service duration
of customer i even though his service have
not started yet. Calculating the finish time of
every customer even before the beginning of
their services resolves the key modeling ques-
tion and provides future information for the
next arriving customer to decide whether to
stay or depart. The waiting time of each cus-
tomer is also calculated at the same moment.
The Start and Finish events can be sched-
uled to occur after, respectively, the waiting
time and waiting time plus service time (see
Fig. 2).
In particular, let D be the decision variable
of whether to stay or not (stay if D == 1 and
leave if D == 0). Let Tc be current simulation
time, which can be obtained by using some
system function in most simulation packages
(e.g., CLK in Sigma [6] and TNOW in Arena
[8]). Let p be the impatient time period of
a customer generated from a given distri-
bution, that is, p ∼ Fp (p). The state changes
that take place when an Enter event occurs
are as follows:
D = (Q < K)&(T1 < Tc + p),
Q = Q + D.
The first equation says that a customer
will stay (i.e., D == 1) if the queue size is
less than K(i.e., (Q < K) == 1) and the time
a
w+s
(D)
Begin Enter Stay w Start
Q = 0, R = 1 Q=Q–1
T1 = T2 = 0 R=R–1
FOUNDATIONS OF SIMULATION MODELING 5
he needs to wait is less than his impatient
time p(i.e., (T1 < Tc + p) == 1). The second
equation will increase the queue size by one
if the customer stays (i.e., Q = Q + 1).
The state changes under the Stay event
are
s = Fs−1 (u)
w = (T1 − Tc )+
T1 = min{Tc + w + s, T2 }
T2 = max{Tc + w + s, T2 }.
The first equation simply generates and
stores the service time duration of a customer
in s. The second equation computes the actual
waiting time of the customer. It is equal to
0 if the arriving customer finds an avail-
able server (i.e., T1 − Tc < 0). Otherwise, it
is equal to the amount of time before one
of the servers is available (i.e., T1 − Tc ). The
notation ‘‘(.)+ ’’ represents the positive part of
the waiting time (i.e., max{T1 − Tc , 0}). The
third and the last equations update the two
earliest available times of the servers due to
this new arriving customer.
In Fig. 2, the impatient customers in
fact never joined the queue. If their con-
tributions to the queue size are important,
a new event can be added to include them
into the queue. This event is scheduled
by the Enter event with a condition of
D == 0, a delay of p, and a state change
of Q = Q − 1. The second equation of
the state changes in the Enter event
will be modified to Q = Q + 1 × (Q < K).
The random impatient time p will also need
to be generated first and stored because it
is used in both the calculation of D and the
time delay of the new event.
One remark observed from this model is
regarding the trade-off between speed and
memory. Sometimes, a small amount of aux-
iliary memory (variables) can greatly reduce
Leave
R=R+1 Figure 2. A two-server queue with lim-
ited capacity and impatient customers.
6 FOUNDATIONS OF SIMULATION MODELING
the speed or complexity of the simulation
model, such as this one.
Process Interaction
Another popular simulation modeling para-
digm is the process-interaction approach.
Loosely speaking, for simple systems the
process interaction approach is WYSIWYG
(What You See Is What You Get) in the sense
that what you create in the model is what
you observe in the real simple system (see
Fig. 3 and explanation in next paragraph).
(However, this intuitive view diminishes
when the complexity of the system increases).
This intuitive view is attractive to beginners
because it deals directly with the actual
objects of a real system. Together with their
animation capability, process-interaction-
based simulation packages are by far the
most common in industry.
To illustrate the intuitive view of
process-interaction models, we model the
single-server queueing system by using three
process-interaction modules to mimic the
three processes of the real system: (i) the
process of customer arrivals, (ii) the process
of queuing customers for service, and (iii) the
process of customer departures. We then con-
nect the three modules sequentially so that
the entities (customers) can flow through
the three modules as they do in the real
system. Figure 3 shows the implementation
of this model using the simulation package
Arena 11 [8]. The mapping between the
three modules and the three real processes
are also shown in the figure.
To create the model in Arena, just drag the
modules from a built-in template of Arena,
paste them into the model workspace, con-
nect them based on the job flow, and specify
Simulation
Model
Figure 3. Process-interaction single- Real
server queuing model and its real- System
world counterpart.
the data for each module (such as interar-
rival time and service time distributions, and
defining the server) by double clicking the
modules. See Kelton et al. [8] for details of
using Arena.
Two issues of the process-interaction
approach should be mentioned: deadlock
and virtual entities. Deadlock could occur
when two entities are trying to seize the
same resources in a wrong sequence. For
example, consider two entities (A1 and A2)
and two machines (M1 and M2). Let us
suppose that A1 is holding M1 and is trying
to seize M2 to start a process. At the same
time, E2 is holding M2 and needs M1 to start
another process. In this situation, unless
some mechanism is introduced to break the
conflict, both entities and machines will
be waiting forever. Therefore, acquisition
of resources should be carefully planned
when building a process-interaction model.
One good rule in practice is to seize all
required resources at one time. In the case
where several resources must be seized
sequentially (e.g., Process 1 requires only
Machine 1 and then immediately Process
2 requires both Machines 1 and 2), then
release the previously seized resources first
and then seize all needed resources at one
time (e.g., release Machine 1 first and then
seize both Machines 1 and 2).
Virtual entities are needed when one
needs to model some abstract mechanisms
or logics that have no physical counterparts
in the real system. This is because almost
everything in a process-interaction model
(including activities, logics, controls, and
assigning values to variables) must be driven
by flowing entities. For instance, to simulate
a traffic intersection, the right-of-way can
be modeled as a ‘‘virtual resource’’ and
Enter Start Leave
96 85
7
Queue Service
 FOUNDATIONS OF SIMULATION MODELING 7

108 Create 108

Enter Not Full? Assign ID Dummy Start Leave
Timer
127 70
108 38
19
Remove
Impatient Original Dispose Duplicated
Customer Entities If Found
Dispose from Queue 32
Customers due Impatient Search
to Capacity Duration Retrieve ID Customer Removed Entity
exceed from Queue Found Impatient
19 Customers Leave
10 Not Found 32

Dispose Duplicated
Entities If Not
Found 66

Figure 4. Process-interaction model of a capacitated queue with multiple servers and impatient
customers.

traffics from any directions will need to seize
this virtual resource in order to pass the
intersection.
Another example of ‘‘virtual entities’’
appears in the multiple-server queuing
system with impatient customers. In a
process-interaction model, an entity in queue
is a passive object in the sense that it cannot
proactively trigger activities by itself when
certain condition is met. Some mechanism
must be created to trigger the correspond-
ing activity. For example, to trigger the
departure of an impatient customer whose
impatient time has expired, a virtual entity
is needed. We use the Arena model shown in
Fig. 4 to explain this issue.
An arriving customer, if accepted by the
diamond ‘‘Not Full?’’ module based on the
current queue size, is assigned an ID in
the ‘‘Assign ID’’ module. This customer is
then duplicated before joining the queue
(the ‘‘Start’’ module). This duplicate is a
virtual entity and will stay in the ‘‘Impatient
Duration’’ module for a random impatient
duration. When the impatient period expires,
this virtual entity first identifies itself in
the ‘‘Retrieve ID’’ module (because there
could be other virtual entities representing
other customers). It then enters the ‘‘Search
Customer from Queue’’ module to see if the
customer that it represents is still waiting
in the queue. If not found, the customer
either is being served or has left, and this
virtual entity can be disposed. If found,
the virtual entity will enter the ‘‘Remove
Impatient Customer from Queue’’ module
and trigger the departure of the customer
from the queue. Both the virtual entity
and impatient customer (if found) are then
disposed.
From a computational point of view, the
process of searching a customer from a queue
could be inefficient when the queue size is
large. Moreover, the search is done for every
customer regardless of whether the customer
has left or not. A more efficient approach
such as Fig. 2 is therefore recommended for
large-scale congested systems.
Other situations where virtual entities are
needed include the modeling of resource pre-
ventive maintenance and failures, or random
events that could change the state of the
system. Indeed, virtual entities, when appro-
priately and professionally handled, can be a
powerful modeling technique.
Activity Scanning
An activity-scanning simulation model works
by scanning activities of the model and fires
(i.e., activates) the ones that meet certain
given conditions. One of the main benefits
of the activity-scanning approach is its ana-
lytical property, which facilitates the con-
struction of mathematical models and the-
oretical analysis. The main representative
approach of activity scanning is Petri-net
8 FOUNDATIONS OF SIMULATION MODELING
models [9]. A Petri net is a bipartite graph
(i.e., a graph with two types of elements and
no two elements of the same type connect
to each other). The two types of elements
are circles (called places) and bars (called
transitions). Besides these two types of ele-
ments, users can also add tokens to the graph
to make the Petri net run. Tokens, which
are solid dots, are used to represent objects
(e.g., jobs or machines) and model logics (e.g.,
failure events). Each transition represents a
certain activity of the model. All the input
places to a transition denote the conditions
required for the transition to fire. All the out-
put places from a transition are the results
of the firing of the transition. In a standard
Petri net, a transition is enabled when there
is at least one token in each input place.
After a time delay associated with the tran-
sition (which can be random, deterministic,
or zero), the transition fires and one token
is removed from each input place. Imme-
diately, one token is added to each output
place. The number of tokens entering and
leaving from a transition may or may not
equal. If the number of tokens in any place is
always below a certain number at any time,
the Petri net is called bounded, otherwise,
unbounded. At any time of the simulation,
a snapshot of the token distribution (their
locations) gives the current state of the sim-
ulation. This token distribution is called a
marking.
The aforementioned firing rule is called
remove-on-fire, in that the tokens are rem-
oved when the transition fires. Another firing
rule is remove-on-enable, which removes the
tokens when the transition is enabled. It can
be shown that these two rules are equivalent.
To build a Petri-net simulation model, the
following four-step procedure can be used:
R R
A Q
a s a s
E S E S
Step 1 Step 2
Figure 5. Activity scanning model of a single-server queuing system.
1. Identify all activities, including zero
time activities (one transition for each
activity) of the system,
2. Identify the conditions for each activity
(one place for each condition),
3. Connect the places and transitions to
make the net alive according to the
model logic, and
4. Add tokens to represent the initial state
of the system.
Fig. 5 presents the four-step implementation
of the Petri-net simulation model of the
single-server queuing system without capac-
ity and no impatient customers. There are
two activities in this simple system: arrivals
of customers and services for customers,
which are modeled by the two transitions, E
and S (which respectively stand for ‘‘Enter’’
and ‘‘Start’’). The single token in Place A
denotes the arrival stream of customers (i.e.,
the process of arrivals). Every a random
time units, Transition E fires; it then places
one token to Place Q, denoting an arrival
of a customer to the queue, and also puts
one token back to Place A, initiating the
arrival of the next customer. The token in
Place R represents the single machine which
is available right now (adding more tokens
here extends the model to a multiple-server
system). Transition S has two input places,
signifying the two conditions for a service to
start (i.e., an available server and a waiting
customer). When these two conditions are
satisfied, Transition S is enabled; and after
s random time units, it fires, denoting the
completion of a service. One token is then
placed in Place R, which allows the server to
work on the next customer if there is any.
One token is also deposited to Place L, which
represents a processed customer.
R
L Q L A Q L
A
a s a s
E S E S
Step 3 Step 4
 FOUNDATIONS OF SIMULATION MODELING
Enrichments of Petri nets include using
colored tokens to represent different types
of entities, allowing multiple tokens to be
removed from or deposited into a place, and
using inhibitor arcs to resolve conflictions
by assigning priorities to different activities.
The inclusion of inhibitor arcs increases the
modeling power of Petri nets to a Turing
machine.
Other Discrete-Event Modeling World Views
A discrete-event system can also be charac-
terized by a state machine represented by
a state-transition diagram. A state machine
includes all the system states, transitions
between states, and the corresponding
actions. For example, in the single-server
queuing system, the state could be the
number of customers in the system, the
transitions are the two events ‘‘arrival of a
new customer’’ and ‘‘departure of finished
customer,’’ and the actions are either to
increase the number of customers in the
system by one (when the arrival transition
occurs) or decrease the number of customers
in the system by one (when a departure tran-
sition occurs). There is no need to include the
transition for the start of a service because
the state is the number of customers in
the system, which does not change when a
service begins. There is a mapping between
the states, transitions, and actions of a state
machine and the state variables, events, and
conditions and state changes of an event
relationship graph. Therefore, the modeling
powerful of an event relationship graph is
equivalent to a state machine (or a Turing
machine) (see a formal proof in Savage
et al. [10]).
Besides graphical representations, a
discrete-event can also be represented for-
mally as a mathematical model. One example
is the formalism called Discrete event system
specification (DEVS). The DEVS formalism
describes a discrete-event system by defining
all the events, how the states change, how
the times of different activities advance,
how the events change the states and vice
versa both externally and internally [11].
Another well-known discrete-event modeling
formalism is the generalized semi-Markov
process (GSMP). GSMP is a formal way of
9
describing the dynamics of a discrete-event
system. It facilitates mathematical analysis
of the underlying system [12]. Another
representation of discrete-event systems is
based on optimization models. In this repre-
sentation, events are represented as decision
variables, event relationships are modeled
by constraints, event times are captured by
the right-hand-sides of the constraints, and
event scheduling (i.e., execute an event as
soon as feasible) is realized by the objective
function of the optimization model. The
benefits of the optimization representation
include using dual variables for sensitivity
analysis, identifying deadlocks by examining
feasibility of the optimization model, obtain-
ing more efficient simulation models by
eliminations of redundant constraints [13].
CONTINUOUS SIMULATION MODELS
Continuous simulation models simulate
systems with state variables that change
continuously in time. One popular type of
continuous simulation is system dynamics.
This method is suitable for systems with
feedback structures and for modeling high-
level of abstraction of a real system. In a
system dynamics simulation model, the state
of the system is represented by stocks and the
rate of change in the state as flows. The stock
variables accumulate all past state values
and therefore, represent the current system
state (e.g., x(t) and y(t) in the example below).
The flow variables (can also be parameters)
are measured per unit of time such as the
changes in a state variable per second (e.g.,
the growth and death rates in the example
below). Another type of continuous simula-
tion models frequently used in modeling and
simulating queuing systems is stochastic
fluid (flow) models. Continuous simulation
has been widely used in many fields, includ-
ing electrical engineering, chemistry, biology,
mechanical engineering, business, and so on.
One simple continuous simulation model
is the Lotka-Volterra’s predator-prey model,
which models the competition between two
types of populations: prey and predators
[1]. Let x(t) and y(t) denote, respectively,
the number of individuals in the prey and
10 FOUNDATIONS OF SIMULATION MODELING
predator populations at time t. Each popu-
lation is determined by two quantities, the
pure change rate of the population itself and
the interaction rate due to the interaction
with the other population. The pure change
rate of the prey is their growth rate in the
absence of the predators (denoted by a), while
the pure change rate of the predators is their
death rate (or starvation rate) due to the
absence of the prey (denoted by −b, which
is negative because it is decreasing). The
interaction rate of the prey is the decrease
in their numbers due to the presence of
the predators (denoted by −cy(t), which is
proportional to the number of predators)
and the interaction rate of the predators is
the increase in their population due to the
presence of the prey (denoted by dx(t), which
is proportional to the number of prey).
This model assumes exponential growth
(or death) in both populations in the absence
of the other, that is, the prey’s growth is
x (t) = ax(t) and the predators’ death is y (t) =
−by(t). The interaction between the two pop-
ulations are captured by the product of their
population sizes, that is, the decrease in the
prey due to the predators is −cx(t)y(t) and
the increase in the predators due to the prey
is dx(t)y(t). Combining the pure change and
interaction terms for each population gives
two differential equations
x (t) = ax(t) − cx(t)y(t), (2)

y (t) = −by(t) + dx(t)y(t). (3)
This simple differential-equation model
can be solved exactly to obtain analytical
solutions for x(t) and y(t). With boundary con-
ditions and given values for all parameters,
one can determine (i.e., simulate) the system
state at any time t. There is no randomness in
this simple model. To model randomness, one
can include (e.g., add) random factors, which
can also be functions of t, to above equations,
for example, Gaussian noises. This will
increase the complexity of the model. Indeed,
simulation models of many real-world
systems are so complex that no closed-form
solutions can be obtained. Numerical meth-
ods, such as the Runge-Kutta method, can
be used to find approximate solutions [14].
AGENT-BASED MODELS
In this section, we first discuss the connection
between agent-based simulation and the two
simulation approaches: discrete-event and
continuous simulations. We then introduce
some concepts of agent-based simulation
(such as agents and interactions) and
outline a general algorithm for executing an
agent-based simulation model. We exemplify
these concepts by using a simple agent-based
simulation model.
Loosely speaking, an agent-based simu-
lation model is a hybrid discrete-conti-
nuous simulation model with proactive,
autonomous, and intelligent entities. Recall
that entities in a discrete-event simulation
model are rather simple with limited capabil-
ities, and can only react to state changes. In
the process-interaction queuing model with
impatient customers, the customer entities
cannot actively leave the system when their
impatient times expire. A separated mech-
anism by using virtual entities is needed
to trigger the departure of the impatient
customers. The servers in this model are also
reactive. For instance, if we model vacations
or breakdown (e.g., sick), then separated
mechanisms (such as vacation timers or
failure timers) will be needed.
Agent-based simulation extends the cap-
ability of entities to allow autonomy and
intelligence. The resulting autonomous obje-
cts (called agents) are able to proactively
interact with other agents and the environ-
ment in which they situate. If an agent-based
simulation model includes both discrete and
continuous state variables, it is a hybrid
discrete-continuous simulation model with
proactive autonomous entities.
The popularity of agent-based simulation
is driven by the increasing complexity of
real-world systems and its capability of
handling these complex systems. A real-
world complex system often contains a
large number of interacting units that are
autonomous, goal-driven, and adaptive (i.e.,
‘‘agents’’). For example, a large-scale health-
care network may consist of a number of
units from large facilities such as hospitals,
medical supply warehouses, blood banks
to small service units such as ambulances,
 FOUNDATIONS OF SIMULATION MODELING
operating rooms, and from personnel such
as doctors and nurses to patients and
other service providers. All these units can
be considered as autonomous agents. For
example, warehouses react to demands by
providing inventory based on a certain rule,
ambulances operate in accordance with some
dispatch policies and physical mechanical
rules, and patients try to intelligently select
doctors. In many cases, agents, while operat-
ing based on their own strategies, cooperate
or compete with each other in accordance
with certain mutual rules or agreements.
It is natural to model agents as objects
in a computer program and simulate their
interactions to see what interaction rules
lead to what consequences (i.e., emergent
behavior). Mechanisms or policies can then
Agent-Based Simulation Execution Algorithm
Initialize
Do until stop condition is satisfied
Advance clock by a given amount of time (e.g., a tick count)
Update all continuous state variables
For each agent (select an agent randomly or based on a specific order)
Perform actions: change state, communicate with other agents or environment, etc.
We now use the Conway’s Game of Life
model to illustrate the modeling of agents,
their interactions, and the resulting emerg-
ing behavior. Imagine that there is a two-
dimensional grid of size n × n, where n is the
number of rows (or columns) in the grid. Each
entry of the grid lives a cell. The cells cannot
move. Each cell has only two states: alive and
dead. Each cell changes its state based on
the following three simple rules that describe
its interactions with its eight neighbors (up,
down, left, right, and four diagonal cells). See
the left panel of Fig. 6 for a visual description
of the rules.
1. A live cell with exactly two or three live
neighbors will remain alive in the next
time step.
2. A dead cell with exactly three live
neighbors will come to life in the next
time step.
11
be enforced to discourage bad behavior and
promote good ones. Emergent behavior here
means arising coherent patterns of macro-
scopic behavior resulting from microscopic
actions and interactions. This leads to the
agent-based simulation approach, which has
been developed rapidly over the past two
decades. It has been widely used in vari-
ous fields including military, biology, social
science, economics, business, and so on. The
theoretical basis of agent-based simulation
lies mainly in cellular automata [15–17],
complex system modeling, artificial life, and
swarm intelligence [18,19].
The algorithm for executing an agent-
based simulation model varies greatly across
different agent-based platforms. A general
scheme is outlined below.
3. Otherwise, the cell will die either of
loneliness or crowdedness in the next
time step.
Implementing this model in a standard
agent-based simulation package (such as
Repast [20] or NetLogo [21]) and running
it for about one hundred iterations yields
a distribution of relatively stable patterns
of live cells as shown in the right panel of
Fig. 6. Note that the middle panel of Fig. 6 is
the initial distribution of live cells.
In fact, this example is so simple that it
can be considered as a cellular automaton.
A cellular automaton model considers a set
of cells residing in a two-dimensional lattice.
Moreover, this model only includes discrete
state variables and therefore can also be mod-
eled by using the discrete-event simulation
approach.
To demonstrate the flexibility of this model
in arriving different emergent behaviors, we
generalize the original Game of Life model
12 FOUNDATIONS OF SIMULATION MODELING
Time t Time t + 1
Rule 1: Stay alive
Rule 2:
Come to life
Die of loneliness
Rule 3:
Die of crowdedness
Figure 6. Agent-based simulation model of Conway’s game of life.
by simply changing the number of live neigh-
bors in Rules 1 and 2 to X, Y, and Z as defined
below. To better visualize the emergent pat-
terns, we also color the cells based on the
number of live neighbors (see the legend of
Fig. 7).
The variation of Conway’s game of life
model is as follows:
1. A live cell with the number of live neigh-
bors between X and Y, inclusively, will
remain alive in the next time step,
2. A dead cell with exactly Z live neighbors
will come to life in the next time step,
3. Otherwise, the cell will die either of
loneliness or crowdedness in the next
time step,
where 0 ≤ X, Y, Z ≤ 8 and X ≤ Y.
This variation has a total of 288 possi-
ble combinations of rules, (X, Y, Z). Some
of them are trivial but some produce clear
emergent patterns as shown in Fig. 7. These
patterns also evolve in time. One can also use
a sequence of multiple rules to obtain differ-
ent combinations of patterns. The patterns
shown in Fig. 7 are obtained by using this
sequence of rules: (0, 7, 8)—(0, 7, 3)—(0, 7,
6)—(0, 7, 5)—(0, 7, 4)—(0, 5, 4)—(3, 5, 4),
where the first rule is to initialize the states
of all cells to dead.
Although cellular automata are already
Turing complete, agent-based simulation
allows agents to have a greater degree of
flexibilities and functionalities (such as
learning and adaptation) and can accommo-
date more complicated interaction rules both
between agents and agents, and between
agents and their environment. Agents can
also have internal memories and perceptions
to respond to outside and adjust their inside.
Agent-based simulation also allows different
kinds of spatial environments, such as ring,
lattice, random, or maps (such as GIS maps).
Agents can move freely in its environment.
This makes it applicable for modeling and
visualizing complex behavior in physical
systems, such as simulations of traffic,
evacuations, biological systems, mechanical
systems, and so on.
One issue in agent-based simulation is the
order in which the agents’ states are updated
in each time step. If one agent is updated
before its neighbors are updated, then its
state at the current time step can affect the
states of its neighbors at this time step, oth-
erwise, its state at the current time step will
affect its neighbors in the next time step.
One common practice is to randomize the
updating order.
The computational requirement of the
agent-based simulation execution algorithm
is high because it has to loop through all
agents in each time step. Methods have been
proposed to avoid looping all agents, for
example, only updating those agents whose
state changes matter. Another approach is to
employ the discrete-event simulation algo-
rithm to advance the clock based on events
and only update the continuous variables in
every time step. Different hardware (such
as parallel CPUs or graphics processing
units—GPU) have also been used to improve
the efficiency of agent-based simulation
models. It has been shown that execution
speed can be improved by thousands of times
when using GPU [22].
 FOUNDATIONS OF SIMULATION MODELING
Figure 7. Emergent behavior of variation of Conway’s game of life model.
MONTE-CARLO MODELS
Monte-Carlo simulation approach is based
on repeated sampling from an algorithm, a
set of equations, or a given computer model.
Sampling here means two steps: (i) generate
random numbers and (ii) evaluate the target
values using the generated random num-
bers. In general, the sampling targets can
be static or dynamics, continuous or discrete,
or deterministic or stochastic. Sampling from
a deterministic target is needed when the
response space of the target is large and only
a certain amount of computing budget is allo-
cated to sample a fraction of the whole space.
13
Legend
# of alive
neighbors 0 1 2 3 4 5 6 7 8
Color:
The relationship between Monte-Carlo
simulation and other simulations such as
discrete-event or continuous simulations
is subtle and depends on how one defines
Monte-Carlo simulation. If one considers
Monte-Carlo simulation as a static model
that does not involve time or represents a
system at a particular time (as discussed
in the section titled ‘‘Introduction’’), then
Monte-Carlo simulation is a special case of
other simulations that involve time. The
relationship turns around if one allows the
sampling target to evolve in time.
While different definitions of Monte-
Carlo simulations can be found in the
14 FOUNDATIONS OF SIMULATION MODELING
literature, one popular definition is by
Law (2006) in which Monte-Carlo simu-
lation is defined as ‘‘a scheme employing
random numbers. . .used for solving certain
stochastic or deterministic problems where
the passage of time plays no substantive
role.’’ This definition is well accepted in
the discrete-event simulation area as it
clearly differentiates discrete-event dynamic
simulation and static pure-sampling-based
simulation.
Monte-Carlo simulation has various appli-
cations in physics, mathematics, and finance,
such as simulating molecular dynamics,
global warming impacts, earthquakes,
solving diverse mathematical problems
(from numerical integration to Markov
chains, and from heuristics optimization
algorithms to games), and evaluation and
prediction (e.g., simulation of Economet-
rics models such as geometric Brownian
motion, diffusion models, and GARCH
models) [23].
CONCLUSION
This introductory article introduces basic
modeling concepts in discrete-event simula-
tion, continuous simulation, and agent-based
simulation. It also highlights the relationship
among these modeling approaches as well
as different world views of discrete-event
simulation models.
Besides these modeling approaches,
new simulation modeling methods are also
being proposed and developed. Classical
approaches tend to focus on aspects of effi-
ciency, easy-to-learn, and animation-frien-
dly. New approaches are moving toward the
need of an integrated simulation framework,
in which modeling, analysis, and presen-
tation are integrated. How a simulation
model is created directly influences experi-
mentations (analysis), and data collections
and interpretation (presentation), which in
turn affect the validity (or credibility) of the
simulation model and results. Therefore,
the construction of a simulation model
should be tied to the corresponding analysis
and presentation based on the need of the
underlying simulation study.
REFERENCES
1. Law A. Simulation modeling and analysis. 4th
ed. Boston: McGraw-Hill; 2006.
2. Law A, Kelton WD. Simulation modeling and
analysis. 3rd ed. Boston: McGraw-Hill; 2000.
3. Schruben LW, Roeder TM. Fast simulations
of large-scale highly congested systems. Sim-
ulation 2003;79(3):115–125.
4. Kiviat PJ. Digital computer simulation: com-
puter programming languages. Santa Monica
(CA): The Rand Corporation; 1969. Memoran-
dum RM-5883-PR.
5. Lackner MR. Digital simulation and system
theory. Santa Monica (CA): System Develop-
ment Corporation, SDC SP- 12; 1964.
6. Schruben D, Schruben LW. Graphical simu-
lation modeling using SIGMA, Ithaca (NY):
Custom Simulation; 2001.
7. Schruben L. Simulation modeling with event
graphs. Comm ACM 1983;26(11):957–963.
8. Kelton WD, Sadowski RP, Sturrock DT. Sim-
ulation with Arena. 4th ed. New York (NY):
McGraw-Hill; 2007.xxiv,668.
9. Peterson JL. Petri net theory and the mod-
eling of systems. New Jersey: Prentice-Hall;
1981.290.
10. Savage EL, Schruben LW, Yucesan E. On the
generality of event graph models. INFORMS
J Comput 2005;17(1):3–9.
11. Zeigler BPA. Theory of modelling and simu-
lation. Melbourne: Krieger Publishing Com-
pany; 1984. p. 460. Reprinted.
12. Glynn P. A GSMP Formalism for Discrete
Event Systems, Proceedings of the IEEE;
1989.
13. Chan WKV, Schruben LW. Optimization mod-
els of discrete-event system dynamics. Oper
Res 2008;56:1218–1237.
14. Cellier F, Kofman E. Continuous system sim-
ulation. New York: Springer; 2006.
15. Von Neumann J. Theory of self-reproducing
automata. Champaign (IL): University of Illi-
nois Press; 1966. p. 388.
16. Beyer WA, Sellers PH, Waterman MS. Stanis-
law M. Ulam’s contributions to theoretical
theory. Lett Math Phys 1985;10:231–242.
17. Wolfram S. Universality and complexity in
cellular automata. Phys Nonlinear Phenom
1984;10D:1–35.
18. Bonabeau EA, Dorigo MA, Theraulaz GA.
Swarm intelligence: from natural to artificial
systems. New York: Oxford University Press;
1999.
 FOUNDATIONS OF SIMULATION MODELING
19. Macal CM, North MJ. Tutorial on agent-based
modeling and simulation part 2: how to model
with agents. Proceedings of the 2006 Win-
ter Simulation Conference. Monterey (CA),
Piscataway (NJ): Institute of Electrical and
Electronics Engineers; 2006.
20. North MJ, Collier NT, Vos JR. Experiences
creating three implementations of the repast
agent modeling toolkit. ACM Trans Model
Comput Simulat 2006;16(1):1–25.
View publication stats
15
21. Wilensky U, NetLogo. http://ccl.northwestern.
edu/netlogo/. Center for Connected Learning
and Computer-Based Modeling, Northwestern
University, Evanston (IL). 1999.
22. Lysenko M, D’Souza RM. A framework for
megascale agent based model simulations on
graphics processing units. J Artif Soc Soc Sim-
ulat 2008;11(4):10.
23. Hammersley JM, Handscomb DC. Monte
Carlo methods. London: Methuen; 1964.