HarrellGhoshBowden:

Simulation Using
ProModel, Second Edition

I. Study Chapters

The McGrawHill
Companies, 2004

4. DiscreteEvent
Simulation

DISCRETE-EVENT
SIMULATION

When the only tool you have is a hammer, every problem begins to resemble a
nail.
Abraham Maslow

4.1 Introduction
Building on the foundation provided by Chapter 3 on how random numbers and
random variates are used to simulate stochastic systems, the focus of this chapter
is on discrete-event simulation, which is the main topic of this book. A discreteevent simulation is one in which changes in the state of the simulation model
occur at discrete points in time as triggered by events. The events in the automatic
teller machine (ATM) simulation example of Chapter 3 that occur at discrete
points in time are the arrivals of customers to the ATM queue and the completion
of their transactions at the ATM. However, you will learn in this chapter that the
spreadsheet simulation of the ATM system in Chapter 3 was not technically executed as a discrete-event simulation.
This chapter rst denes what a discrete-event simulation is compared to a
continuous simulation. Next the chapter summarizes the basic technical issues related to discrete-event simulation to facilitate your understanding of how to effectively use the tool. Questions that will be answered include these:

How does discrete-event simulation work?

What do commercial simulation software packages provide?
What are the differences between simulation languages and simulators?
What is the future of simulation technology?

A manual dynamic, stochastic, discrete-event simulation of the ATM example

system from Chapter 3 is given to further illustrate what goes on inside this type
of simulation.
71

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

72

I. Study Chapters

Part I

The McGrawHill
Companies, 2004

4. DiscreteEvent
Simulation

Study Chapters

4.2 Discrete-Event versus Continuous Simulation

Commonly, simulations are classied according to the following characteristics:
Static or dynamic
Stochastic or deterministic
Discrete-event or continuous
In Chapter 3 we discussed the differences between the rst two sets of characteristics. Now we direct our attention to discrete-event versus continuous simulations. A discrete-event simulation is one in which state changes occur at discrete
points in time as triggered by events. Typical simulation events might include

The arrival of an entity to a workstation.

The failure of a resource.
The completion of an activity.
The end of a shift.

State changes in a model occur when some event happens. The state of the model
becomes the collective state of all the elements in the model at a particular point
in time. State variables in a discrete-event simulation are referred to as discretechange state variables. A restaurant simulation is an example of a discrete-event
simulation because all of the state variables in the model, such as the number of
customers in the restaurant, are discrete-change state variables (see Figure 4.1).
Most manufacturing and service systems are typically modeled using discreteevent simulation.
In continuous simulation, state variables change continuously with respect to
time and are therefore referred to as continuous-change state variables. An example of a continuous-change state variable is the level of oil in an oil tanker that is
being either loaded or unloaded, or the temperature of a building that is controlled
by a heating and cooling system. Figure 4.2 compares a discrete-change state
variable and a continuous-change state variable as they vary over time.
FIGURE 4.1
Discrete events cause
discrete state changes.

Number of
customers
in restaurant
3
2

Time
Start
Simulation

Event 1
(customer
arrives)

Event 2
(customer
arrives)

Event 3
(customer
departs)

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

The McGrawHill
Companies, 2004

4. DiscreteEvent
Simulation

73

Discrete-Event Simulation

FIGURE 4.2
Comparison of a
discrete-change state
variable and a
continuous-change
state variable.

Continuous-change
state variable

Value

Discrete-change
state variable

Time

Continuous simulation products use either differential equations or difference equations to dene the rates of change in state variables over time.

4.2.1 Differential Equations

The change that occurs in some continuous-change state variables is expressed in
terms of the derivatives of the state variables. Equations involving derivatives of
a state variable are referred to as differential equations. The state variable v, for
example, might change as a function of both v and time t:
dv(t)
= v 2 (t) + t 2
dt
We then need a second equation to dene the initial condition of v:
v(0) = K
On a computer, numerical integration is used to calculate the change in a
particular response variable over time. Numerical integration is performed at the
end of successive small time increments referred to as steps. Numerical analysis
techniques, such as Runge-Kutta integration, are used to integrate the differential
equations numerically for each incremental time step. One or more threshold values
for each continuous-change state variable are usually dened that determine when
some action is to be triggered, such as shutting off a valve or turning on a pump.

4.2.2 Difference Equations

Sometimes a continuous-change state variable can be modeled using difference
equations. In such instances, the time is decomposed into periods of length t. An
algebraic expression is then used to calculate the value of the state variable at the
end of period k + 1 based on the value of the state variable at the end of period k.
For example, the following difference equation might be used to express the rate
of change in the state variable v as a function of the current value of v, a rate of
change (r), and the length of the time period (
t):
v(k + 1) = v(k) + r
t

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

74

I. Study Chapters

Part I

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Study Chapters

Batch processing in which uids are pumped into and out of tanks can often be
modeled using difference equations.

4.2.3 Combined Continuous and Discrete Simulation

Many simulation software products provide both discrete-event and continuous
simulation capabilities. This enables systems that have both discrete-event and
continuous characteristics to be modeled, resulting in a hybrid simulation. Most
processing systems that have continuous-change state variables also have discretechange state variables. For example, a truck or tanker arrives at a ll station (a
discrete event) and begins lling a tank (a continuous process).
Four basic interactions occur between discrete- and continuous-change
variables:
1. A continuous variable value may suddenly increase or decrease as the
result of a discrete event (like the replenishment of inventory in an
inventory model).
2. The initiation of a discrete event may occur as the result of reaching a
threshold value in a continuous variable (like reaching a reorder point in
an inventory model).
3. The change rate of a continuous variable may be altered as the result of a
discrete event (a change in inventory usage rate as the result of a sudden
change in demand).
4. An initiation or interruption of change in a continuous variable may
occur as the result of a discrete event (the replenishment or depletion of
inventory initiates or terminates a continuous change of the continuous
variable).

4.3 How Discrete-Event Simulation Works

Most simulation software, including ProModel, presents a process-oriented world
view to the user for dening models. This is the way most humans tend to think
about systems that process entities. When describing a system, it is natural to do
so in terms of the process ow. Entities begin processing at activity A then move
on to activity B and so on. In discrete-event simulation, these process ow denitions are translated into a sequence of events for running the simulation: rst
event 1 happens (an entity begins processing at activity A), then event 2 occurs
(it completes processing at activity A), and so on. Events in simulation are of two
types: scheduled and conditional, both of which create the activity delays in the
simulation to replicate the passage of time.
A scheduled event is one whose time of occurrence can be determined
beforehand and can therefore be scheduled in advance. Assume, for example, that
an activity has just begun that will take X amount of time, where X is a normally
distributed random variable with a mean of 5 minutes and a standard deviation of

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

Discrete-Event Simulation

The McGrawHill
Companies, 2004

75

1.2 minutes. At the start of the activity, a normal random variate is generated
based on these parameters, say 4.2 minutes, and an activity completion event is
scheduled for that time into the future. Scheduled events are inserted chronologically into an event calendar to await the time of their occurrence. Events that
occur at predened intervals theoretically all could be determined in advance and
therefore be scheduled at the beginning of the simulation. For example, entities
arriving every ve minutes into the model could all be scheduled easily at the start
of the simulation. Rather than preschedule all events at once that occur at a set frequency, however, they are scheduled only when the next occurrence must be determined. In the case of a periodic arrival, the next arrival would not be scheduled
until the current scheduled arrival is actually pulled from the event calendar for
processing. This postponement until the latest possible moment minimizes the
size of the event calendar and eliminates the necessity of knowing in advance how
many events to schedule when the length of the simulation may be unknown.
Conditional events are triggered by a condition being met rather than by the
passage of time. An example of a conditional event might be the capturing of a
resource that is predicated on the resource being available. Another example
would be an order waiting for all of the individual items making up the order to be
assembled. In these situations, the event time cannot be known beforehand, so
the pending event is simply placed into a waiting list until the conditions can be
satised. Often multiple pending events in a list are waiting for the same condition. For example, multiple entities might be waiting to use the same resource
when it becomes available. Internally, the resource would have a waiting list for all
items currently waiting to use it. While in most cases events in a waiting list are
processed rst-in, rst-out (FIFO), items could be inserted and removed using a
number of different criteria. For example, items may be inserted according to item
priority but be removed according to earliest due date.
Events, whether scheduled or conditional, trigger the execution of logic that is
associated with that event. For example, when an entity frees a resource, the state
and statistical variables for the resource are updated, the graphical animation is updated, and the input waiting list for the resource is examined to see what activity to
respond to next. Any new events resulting from the processing of the current event
are inserted into either the event calendar or another appropriate waiting list.
In real life, events can occur simultaneously so that multiple entities can be
doing things at the same instant in time. In computer simulation, however, especially when running on a single processor, events can be processed only one at a time
even though it is the same instant in simulated time. As a consequence, a method or
rule must be established for processing events that occur at the exact same simulated
time. For some special cases, the order in which events are processed at the current
simulation time might be signicant. For example, an entity that frees a resource and
then tries to immediately get the same resource might have an unfair advantage over
other entities that might have been waiting for that particular resource.
In ProModel, the entity, downtime, or other item that is currently being
processed is allowed to continue processing as far as it can at the current simulation time. That means it continues processing until it reaches either a conditional

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

76

I. Study Chapters

Part I

The McGrawHill
Companies, 2004

4. DiscreteEvent
Simulation

Study Chapters

FIGURE 4.3

Start

Logic diagram of how

discrete-event
simulation works.
Create simulation
database and schedule
initial events.

Advance clock to
next event time.

Termination
event?

Yes

Update statistics
and generate
output report.

No
Process event and
schedule any new
events.

Stop

Update statistics,
state variables,
and animation.

Yes

Any conditional
events?
No

event that cannot be satised or a timed delay that causes a future event to be
scheduled. It is also possible that the object simply nishes all of the processing
dened for it and, in the case of an entity, exits the system. As an object is being
processed, any resources that are freed or other entities that might have been created as byproducts are placed in an action list and are processed one at a time in a
similar fashion after the current object reaches a stopping point. To deliberately

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

The McGrawHill
Companies, 2004

4. DiscreteEvent
Simulation

77

Discrete-Event Simulation

suspend the current object in order to allow items in the action list to be processed,
a zero delay time can be specied for the current object. This puts the current item
into the future events list (event calendar) for later processing, even though it is
still processed at the current simulation time.
When all scheduled and conditional events have been processed that are
possible at the current simulation time, the clock advances to the next scheduled
event and the process continues. When a termination event occurs, the simulation
ends and statistical reports are generated. The ongoing cycle of processing scheduled and conditional events, updating state and statistical variables, and creating
new events constitutes the essence of discrete-event simulation (see Figure 4.3).

4.4 A Manual Discrete-Event Simulation Example

To illustrate how discrete-event simulation works, a manual simulation is presented
of the automatic teller machine (ATM) system of Chapter 3. Customers arrive to
use an automatic teller machine (ATM) at a mean interarrival time of 3.0 minutes
exponentially distributed. When customers arrive to the system, they join a queue
to wait for their turn on the ATM. The queue has the capacity to hold an innite
number of customers. The ATM itself has a capacity of one (only one customer at a
time can be processed at the ATM). Customers spend an average of 2.4 minutes exponentially distributed at the ATM to complete their transactions, which is called
the service time at the ATM. Assuming that the simulation starts at time zero, simulate the ATM system for its rst 22 minutes of operation and estimate the expected
waiting time for customers in the queue (the average time customers wait in line for
the ATM) and the expected number of customers waiting in the queue (the average
number of customers waiting in the queue during the simulated time period). If you
are wondering why 22 minutes was selected as the simulation run length, it is because 22 minutes of manual simulation will nicely t on one page of the textbook.
An entity ow diagram of the ATM system is shown in Figure 4.4.

4.4.1 Simulation Model Assumptions

We did not list our assumptions for simulating the ATM system back in Chapter 3
although it would have been a good idea to have done so. In any simulation,
FIGURE 4.4
Entity ow diagram for example automatic teller machine (ATM) system.
Arriving customers
(entities)

ATM queue
(FIFO)

ATM server
(resource)

Departing
customers
(entities)

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

78

I. Study Chapters

Part I

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Study Chapters

certain assumptions must be made where information is not clear or complete.

Therefore, it is important that assumptions be clearly documented. The assumptions we will be making for this simulation are as follows:
There are no customers in the system initially, so the queue is empty and
the ATM is idle.
The move time from the queue to the ATM is negligible and therefore
ignored.
Customers are processed from the queue on a rst-in, rst-out (FIFO) basis.
The ATM never experiences failures.

4.4.2 Setting Up the Simulation

A discrete-event simulation does not generate all of the events in advance as was
done in the spreadsheet simulation of Chapter 3. Instead the simulation schedules
the arrival of customer entities to the ATM queue and the departure of customer
entities from the ATM as they occur over time. That is, the simulation calls a
function to obtain an exponentially distributed interarrival time value only when
a new customer entity needs to be scheduled to arrive to the ATM queue. Likewise, the simulation calls a function to obtain an exponentially distributed service
time value at the ATM only after a customer entity has gained access (entry) to the
ATM and the entitys future departure time from the ATM is needed. An event
calendar is maintained to coordinate the processing of the customer arrival and
customer departure events. As arrival and departure event times are created, they
are placed on the event calendar in chronological order. As these events get
processed, state variables (like the contents of a queue) get changed and statistical
accumulators (like the cumulative time in the queue) are updated.
With this overview, lets list the structured components needed to conduct the
manual simulation.
Simulation Clock
As the simulation transitions from one discrete-event to the next, the simulation
clock is fast forwarded to the time that the next event is scheduled to occur. There
is no need for the clock to tick seconds away until reaching the time at which the
next event in the list is scheduled to occur because nothing will happen that
changes the state of the system until the next event occurs. Instead, the simulation
clock advances through a series of time steps. Let ti denote the value of the simulation clock at time step i, for i = 0 to the number of discrete events to process.
Assuming that the simulation starts at time zero, then the initial value of the simulation clock is denoted as t0 = 0. Using this nomenclature, t1 denotes the value
of the simulation clock when the rst discrete event in the list is processed, t2 denotes the value of the simulation clock when the second discrete-event in the list
is processed, and so on.
Entity Attributes
To capture some statistics about the entities being processed through the system,
a discrete-event simulation maintains an array of entity attribute values. Entity

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Discrete-Event Simulation

79

attributes are characteristics of the entity that are maintained for that entity until
the entity exits the system. For example, to compute the amount of time an entity
waited in a queue location, an attribute is needed to remember when the entity entered the location. For the ATM simulation, one entity attribute is used to remember the customers time of arrival to the system. This entity attribute is called the
Arrival Time attribute. The simulation program computes how long each customer entity waited in the queue by subtracting the time that the customer entity
arrived to the queue from the value of the simulation clock when the customer entity gained access to the ATM.
State Variables
Two discrete-change state variables are needed to track how the status (state) of the
system changes as customer entities arrive in and depart from the ATM system.
Number of Entities in Queue at time step i, NQi.
ATM Statusi to denote if the ATM is busy or idle at time step i.
Statistical Accumulators
The objective of the example manual simulation is to estimate the expected
amount of time customers wait in the queue and the expected number of customers waiting in the queue. The average time customers wait in queue is a simple
average. Computing this requires that we record how many customers passed
through the queue and the amount of time each customer waited in the queue. The
average number of customers in the queue is a time-weighted average, which is
usually called a time average in simulation. Computing this requires that we not
only observe the queues contents during the simulation but that we also measure
the amount of time that the queue maintained each of the observed values. We
record each observed value after it has been multiplied (weighted) by the amount
of time it was maintained.
Heres what the simulation needs to tally at each simulation time step i to
compute the two performance measures at the end of the simulation.
Simple-average time in queue.
Record the number of customer entities processed through the queue,
Total Processed. Note that the simulation may end before all customer
entities in the queue get a turn at the ATM. This accumulator keeps track
of how many customers actually made it through the queue.
For a customer processed through the queue, record the time that it waited
in the queue. This is computed by subtracting the value of the simulation
clock time when the entity enters the queue (stored in the entity attribute
array Arrival Time) from the value of the simulation clock time when the
entity leaves the queue, ti Arrival Time.
Time-average number of customers in the queue.
For the duration of the last time step, which is ti ti1 , and the number of
customer entities in the queue during the last time step, which is NQi1 ,
record the product of ti ti1 and NQi1 . Call the product
(ti ti1 )NQi1 the Time-Weighted Number of Entities in the Queue.

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

80

I. Study Chapters

Part I

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Study Chapters

Events
There are two types of recurring scheduled events that change the state of the system: arrival events and departure events. An arrival event occurs when a customer
entity arrives to the queue. A departure event occurs when a customer entity completes its transaction at the ATM. Each processing of a customer entitys arrival
to the queue includes scheduling the future arrival of the next customer entity to
the ATM queue. Each time an entity gains access to the ATM, its future departure
from the system is scheduled based on its expected service time at the ATM. We
actually need a third event to end the simulation. This event is usually called the
termination event.
To schedule the time at which the next entity arrives to the system, the simulation needs to generate an interarrival time and add it to the current simulation
clock time, ti . The interarrival time is exponentially distributed with a mean of
3.0 minutes for our example ATM system. Assume that the function E(3.0) returns an exponentially distributed random variate with a mean of 3.0 minutes. The
future arrival time of the next customer entity can then be scheduled by using the
equation ti + E(3.0).
The customer service time at the ATM is exponentially distributed with a
mean of 2.4 minutes. The future departure time of an entity gaining access to the
ATM is scheduled by the equation ti + E(2.4).
Event Calendar
The event calendar maintains the list of active events (events that have been
scheduled and are waiting to be processed) in chronological order. The simulation
progresses by removing the rst event listed on the event calendar, setting the
simulation clock, ti , equal to the time at which the event is scheduled to occur, and
processing the event.

4.4.3 Running the Simulation

To run the manual simulation, we need a way to generate exponentially distributed
random variates for interarrival times [the function E(3.0)] and service times [the
function E(2.4)]. Rather than using our calculators to generate a random number
and transform it into an exponentially distributed random variate each time one is
needed for the simulation, lets take advantage of the work we did to build the
spreadsheet simulation of the ATM system in Chapter 3. In Table 3.2 of Chapter 3,
we generated 25 exponentially distributed interarrival times with a mean of
3.0 minutes and 25 exponentially distributed service times with a mean of
2.4 minutes in advance of running the spreadsheet simulation. So when we need a
service time or an interarrival time for our manual simulation, lets use the values
from the Service Time and Interarrival Time columns of Table 3.2 rather than
computing them by hand. Note, however, that we do not need to generate all
random variates in advance for our manual discrete-event simulation (thats one
of its advantages over spreadsheet simulation). We are just using Table 3.2 to
make our manual simulation a little less tedious, and it will be instructive to

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

Discrete-Event Simulation

The McGrawHill
Companies, 2004

81

compare the results of the manual simulation with those produced by the spreadsheet simulation.
Notice that Table 3.2 contains a subscript i in the leftmost column. This subscript denotes the customer entity number as opposed to the simulation time step.
We wanted to point this out to avoid any confusion because of the different uses
of the subscript. In fact, you can ignore the subscript in Table 3.2 as you pick values from the Service Time and Interarrival Time columns.
A discrete-event simulation logic diagram for the ATM system is shown in
Figure 4.5 to help us carry out the manual simulation. Table 4.1 presents the results of the manual simulation after processing 12 events using the simulation
logic diagram presented in Figure 4.5. The table tracks the creation and scheduling of events on the event calendar as well as how the state of the system changes
and how the values of the statistical accumulators change as events are processed
from the event calendar. Although Table 4.1 is completely lled in, it was initially
blank until the instructions presented in the simulation logic diagram were executed. As you work through the simulation logic diagram, you should process the
information in Table 4.1 from the rst row down to the last row, one row at a time
(completely lling in a row before going down to the next row). A dash () in a
cell in Table 4.1 signies that the simulation logic diagram does not require you to
update that particular cell at the current simulation time step. An arrow ( ) in a
cell in the table also signies that the simulation logic diagram does not require
you to update that cell at the current time step. However, the arrows serve as a reminder to look up one or more rows above your current position in the table to determine the state of the ATM system. Arrows appear under the Number of Entities
in Queue, NQi column, and ATM Statusi column. The only exception to the use of
dashes or arrows is that we keep a running total in the two Cumulative subcolumns in the table for each time step. Lets get the manual simulation started.
i = 0, t0 = 0. As shown in Figure 4.5, the rst block after the start position
indicates that the model is initialized to its starting conditions. The
simulation time step begins at i = 0. The initial value of the simulation
clock is zero, t0 = 0. The system state variables are set to ATM Status0 
Idle; Number of Entities in Queue, NQ0 = 0; and the Entity Attribute
Array is cleared. This reects the initial conditions of no customer entities
in the queue and an idle ATM. The statistical accumulator Total Processed is
set to zero. There are two different Cumulative variables in Table 4.1: one to
accumulate the time in queue values of ti Arrival Time, and the other to
accumulate the values of the time-weighted number of entities in the queue,
(ti ti1 )NQi1 . Recall that ti Arrival Time is the amount of time that
entities, which gained access to the ATM, waited in queue. Both Cumulative
variables (ti Arrival Time) and (ti ti1 )NQi1 are initialized to zero.
Next, an initial arrival event and termination event are scheduled and placed
under the Scheduled Future Events column. The listing of an event is
formatted as (Entity Number, Event, and Event Time). Entity Number
denotes the customer number that the event pertains to (such as the rst,
second, or third customer). Event is the type of event: a customer arrives, a

82
Yes

Depart

Discrete-event simulation logic diagram for ATM system.

Yes

No

Update Entity Attribute

Array by deleting departed
customer entity from first
position of the array.
Change ATM Statusi to Idle.

Any
customers
in queue?

Update Entity Attribute Array by

deleting departed customer entity
from first position in the array and
shifting waiting customers up.
Subtract 1 from NQi, Number of
Entities in Queue.
Schedule departure event for
customer entity entering the ATM
to occur at time ti + E(2.4).
Update Entities Processed
through Queue statistics to reflect
customer entering ATM.
- Add 1 to Total Processed.
- Compute Time in Queue
value for ti - Arrival Time and
update Cumulative.
Update Time-Weighted Number of
Entities in Queue statistic.
- Compute value for (ti ti 1)NQi 1
and update Cumulative.

End

Update statistics and generate output report.

End

Event
type?

i=i+1

4. DiscreteEvent
Simulation

FIGURE 4.5

No

Arrive

Store current customer

entitys Arrival Time in last
position of Entity Attribute
Array to reflect customer
joining the queue.
Add 1 to NQi, Number of
Entities in Queue.
Update Time-Weighted
Number of Entities in Queue
statistic.
- Compute value for
(ti ti 1)NQi 1 and
update Cumulative.

Is ATM
idle?

Schedule arrival event

for next customer entity
to occur at time ti + E(3).

i=i+1
Update Event Calendar: Insert Scheduled Future Events in chronological order.
Advance Clock, ti, to the Time of the first event on the calendar and process the event.

I. Study Chapters

Schedule departure event for

current customer entity entering
ATM to occur at time ti + E(2.4).
Store current customers
Arrival Time in first position of
Entity Attribute Array.
Change ATM Statusi to Busy.
Update Entities Processed
through Queue statistics to
reflect customer entering ATM.
- Add 1 to Total Processed.
- Record Time in Queue of 0 for
ti - Arrival Time and update
Cumulative.
Update Time-Weighted Number
of Entities in Queue statistic.
- Record value of 0 for
(ti ti 1)NQi 1 and update
Cumulative.

i=i+1

Initialize variables and schedule initial arrival event and termination event (Scheduled Future Events).

i=0

Start
HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition
The McGrawHill
Companies, 2004

(1, Arrive,
(_, End,
(1, Depart,
(2, Arrive,
(_, End,
(2, Arrive,
(_, End,
(2, Depart,
(3, Arrive,
(_, End,
(3, Arrive,
(_, End,
(4, Arrive,
(3, Depart,
(_, End,
(5, Arrive,
(3, Depart,
(_, End,
(3, Depart,
(6, Arrive,
(_, End,
(6, Arrive,
(4, Depart,
(_, End,
(7, Arrive,
(4, Depart,
(_, End,

12

11

10

20.50)
22.00)
22.53)
22.00)
22.53)
24.62)

2.18)
22.00)
2.28)
7.91)
22.00)
7.91)
22.00)
12.37)
15.00)
22.00)
15.00)
22.00)
15.17)
18.25)
22.00)
15.74)
18.25)
22.00)
18.25)
18.75)
22.00)
18.75)
20.50)
22.00)
19.88)
20.50)
22.00)

Clock, ti
22.00

20.50

19.88

18.75

18.25

15.74

15.17

15.00

12.37

7.91

2.28

2.18

Event
End

Depart

Arrive

Arrive

Depart

Arrive

Arrive

Arrive

Depart

Arrive

Depart

Arrive

*(4, 15.17)
(5, 15.74)
(6, 18.75)
*(4, 15.17)
(5, 15.74)
(6, 18.75)
(7, 19.88)
*(5, 15.74)
(6, 18.75)
(7, 19.88)

*(3, 15.00)
(4, 15.17)
(5, 15.74)
*(4, 15.17)
(5, 15.74)

*(3, 15.00)
( )
*(3, 15.00)
(4, 15.17)

*(2, 7.91)
( )
*( )
( )

*( )
( )
*(1, 2.18)
( )
*( )
( )

Busy
Idle
Busy

Idle

Busy

ATM Statusi
Idle

Total Processed

Entities Processed
through Queue

4.76

3.08

7.84

7.84

3.08

3.08

3.08

Time-Weighted
Number of Entities
in Queue

3.00

1.86

2.26

0.50

5.02

0.57

13.21

10.21

8.35

6.09

5.59

0.57

(5, Depart, 24.62)

(8, Arrive, 22.53)

(7, Arrive, 19.88)

(4, Depart, 20.50)

(6, Arrive, 18.75)

(4, Arrive, 15.17)

(3, Depart, 18.25)
(5, Arrive, 15.74)

No new events

(3, Arrive, 15.00)

(2, Depart, 12.37)

No new events

(1, Arrive, 2.18)

(_, End,
22.00)
(2, Arrival, 7.91)
(1, Depart, 2.28)

4. DiscreteEvent
Simulation

(4, Depart,
(_, End,
(8, Arrive,
(_, End,
(8, Arrive,
(5, Depart,

Entity Number

Scheduled Future Events

I. Study Chapters

(Entity Number, Event, Time)

*Entity Using ATM,

array position 1

Entities Waiting in
Queue, array
positions 2, 3, . . .

Entity Attribute
Array (Entity
Number, Arrival
Time)
Number of Entities
in Queue, NQi

Statistical Accumulators

Time in Queue,
ti Arrival Time

System State

Cumulative,
(ti Arrival Time)

Processed Event

(ti ti1)NQi1

Event Calendar

(Entity Number, Event, Time)

TABLE 4.1 Manual Discrete-Event Simulation of ATM System

Cumulative,
(ti ti1)NQi1

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition
The McGrawHill
Companies, 2004

83

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

84

I. Study Chapters

Part I

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Study Chapters

customer departs, or the simulation ends. Time is the future time that the
event is to occur. The event (1, Arrive, 2.18) under the Scheduled Future
Events column prescribes that the rst customer entity is scheduled to arrive
at time 2.18 minutes. The arrival time was generated using the equation
t0 + E(3.0). To obtain the value returned from the function E(3), we went
to Table 3.2, read the rst random variate from the Interarrival Time column
(a value of 2.18 minutes), and added it to the current value of the simulation
clock, t0 = 0. The simulation is to be terminated after 22 minutes. Note the
(__, End, 22.00) under the Scheduled Future Events column. For the
termination event, no value is assigned to Entity Number because it is not
relevant.
i = 1, t1 = 2.18. After the initialization step, the list of scheduled future
events is added to the event calendar in chronological order in preparation
for the next simulation time step i = 1. The simulation clock is fast forwarded
to the time that the next event is scheduled to occur, which is t1 = 2.18
(the arrival time of the rst customer to the ATM queue), and then the event
is processed. Following the simulation logic diagram, arrival events are
processed by rst scheduling the future arrival event for the next customer
entity using the equation t1 + E(3.0) = 2.18 + 5.73 = 7.91 minutes. Note
the value of 5.73 returned by the function E(3.0) is the second random
variate listed under the Interarrival Time column of Table 3.2. This future
event is placed under the Scheduled Future Events column in Table 4.1 as
(2, Arrive, 7.91). Checking the status of the ATM from the previous
simulation time step reveals that the ATM is idle (ATM Status0  Idle).
Therefore, the arriving customer entity immediately ows through the
queue to the ATM to conduct its transaction. The future departure event of
this entity from the ATM is scheduled using the equation t1 + E(2.4) =
2.18 + 0.10 = 2.28 minutes. See (1, Depart, 2.28) under the Scheduled
Future Events column, denoting that the rst customer entity is scheduled to
depart the ATM at time 2.28 minutes. Note that the value of 0.10 returned
by the function E(2.4) is the rst random variate listed under the Service
Time column of Table 3.2. The arriving customer entitys arrival time is
then stored in the rst position of the Entity Attribute Array to signify that it
is being served by the ATM. The ATM Status1 is set to Busy, and the
statistical accumulators for Entities Processed through Queue are updated.
Add 1 to Total Processed and since this entity entered the queue and
immediately advanced to the idle ATM for processing, record zero minutes
in the Time in Queue, t1 Arrival Time, subcolumn and update this
statistics cumulative value. The statistical accumulators for Time-Weighted
Number of Entities in the Queue are updated next. Record zero for
(t1 t0 )NQ0 since there were no entities in queue during the previous time
step, NQ0 = 0, and update this statistics cumulative value. Note the arrow
entered under the Number of Entities in Queue, NQ1 column. Recall
that the arrow is placed there to signify that the number of entities waiting
in the queue has not changed from its previous value.

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

Discrete-Event Simulation

The McGrawHill
Companies, 2004

85

i = 2, t2 = 2.28. Following the loop back around to the top of the simulation
logic diagram, we place the two new future events onto the event calendar
in chronological order in preparation for the next simulation time step
i = 2. The simulation clock is fast forwarded to t2 = 2.28, and the
departure event for the rst customer entity arriving to the system is
processed. Given that there are no customers in the queue from the previous
time step, NQ1 = 0 (follow the arrows up to get this value), we simply
remove the departed customer from the rst position of the Entity Attribute
Array and change the status of the ATM to idle, ATM Status2  Idle.
The statistical accumulators do not require updating because there are no
customer entities waiting in the queue or leaving the queue. The dashes ()
entered under the statistical accumulator columns indicate that updates are
not required. No new future events are scheduled.
As before, we follow the loop back to the top of the simulation logic diagram,
and place any new events, of which there are none at the end of time step i = 2,
onto the event calendar in chronological order in preparation for the next simulation time step i = 3. The simulation clock is fast forwarded to t3 = 7.91, and the
arrival of the second customer entity to the ATM queue is processed. Complete the
processing of this event and continue the manual simulation until the termination
event (__, End, 22.00) reaches the top of the event calendar.
As you work through the simulation logic diagram to complete the manual
simulation, you will see that the fourth customer arriving to the system requires
that you use logic from a different path in the diagram. When the fourth customer
entity arrives to the ATM queue, simulation time step i = 6, the ATM is busy
(see ATM Status5) processing customer entity 3s transaction. Therefore, the
fourth customer entity joins the queue and waits to use the ATM. (Dont forget
that it invoked the creation of the fth customers arrival event.) The fourth entitys arrival time of 15.17 minutes is stored in the last position of the Entity Attribute Array in keeping with the rst-in, rst-out (FIFO) rule. The Number of
Entities in Queue, NQ6 , is incremented to 1. Further, the Time-Weighted Number
of Entities in the Queue statistical accumulators are updated by rst computing
(t6 t5 )NQ5 = (15.17 15.00)0 = 0 and then recording the result. Next, this
statistics cumulative value is updated. Customers 5, 6, and 7 also arrive to the
system nding the ATM busy and therefore take their place in the queue to wait
for the ATM.
The fourth customer waited a total of 3.08 minutes in the queue (see the
ti Arrival Time subcolumn) before it gained access to the ATM in time step
i = 8 as the third customer departed. The value of 3.08 minutes in the queue for
the fourth customer computed in time step i = 8 by t8 Arrival Time 
18.25 15.17 = 3.08 minutes. Note that Arrival Time is the time that the fourth
customer arrived to the queue, and that the value is stored in the Entity Attribute
Array.
At time t12 = 22.00 minutes the simulation terminates and tallies the nal
values for the statistical accumulators, indicating that a total of ve customer
entities were processed through the queue. The total amount of time that these ve

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

86

I. Study Chapters

Part I

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Study Chapters

customers waited in the queue is 7.84 minutes. The nal cumulative value for
Time-Weighted Number of Entities in the Queue is 13.21 minutes. Note that at the
end of the simulation, two customers are in the queue (customers 6 and 7) and one
is at the ATM (customer 5). A few quick observations are worth considering
before we discuss how the accumulated values are used to calculate summary statistics for a simulation output report.
This simple and brief (while tedious) manual simulation is relatively easy to
follow. But imagine a system with dozens of processes and dozens of factors inuencing behavior such as downtimes, mixed routings, resource contention, and
others. You can see how essential computers are for performing a simulation of
any magnitude. Computers have no difculty tracking the many relationships and
updating the numerous statistics that are present in most simulations. Equally as
important, computers are not error prone and can perform millions of instructions
per second with absolute accuracy. We also want to point out that the simulation
logic diagram (Figure 4.5) and Table 4.1 were designed to convey the essence of
what happens inside a discrete-event simulation program. When you view a trace
report of a ProModel simulation in Lab Chapter 8 you will see the simularities
between the trace report and Table 4.1. Although the basic process presented is
sound, its efciency could be improved. For example, there is no need to keep
both a scheduled future events list and an event calendar. Instead, future
events are inserted directly onto the event calendar as they are created. We separated them to facilitate our describing the ow of information in the discrete-event
framework.

4.4.4 Calculating Results

When a simulation terminates, statistics that summarize the models behavior are
calculated and displayed in an output report. Many of the statistics reported in a
simulation output report consist of average values, although most software reports
a multitude of statistics including the maximum and minimum values observed
during the simulation. Average values may be either simple averages or time
averages.
Simple-Average Statistic
A simple-average statistic is calculated by dividing the sum of all observation values of a response variable by the number of observations:

n
xi
Simple average = i=1
n
where n is the number of observations and xi is the value of ith observation. Example simple-average statistics include the average time entities spent in the system
(from system entry to system exit), the average time entities spent at a specic
location, or the average time per use for a resource. An average of an observationbased response variable in ProModel is computed as a simple average.

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

The McGrawHill
Companies, 2004

4. DiscreteEvent
Simulation

87

Discrete-Event Simulation

The average time that customer entities waited in the queue for their turn on
the ATM during the manual simulation reported in Table 4.1 is a simple-average
statistic. Recall that the simulation processed ve customers through the queue.
Let xi denote the amount of time that the i th customer processed spent in the
queue. The average waiting time in queue based on the n = 5 observations is

5
Average time in queue =
=

i=1

xi

0 + 0 + 0 + 3.08 + 4.76
5

7.84 minutes
= 1.57 minutes
5

The values necessary for computing this average are accumulated under the
Entities Processed through Queue columns of the

manual simulation table (see the
last row of Table 4.1 for the cumulative value (ti Arrival Time) = 7.84 and
Total Processed = 5).
Time-Average Statistic
A time-average statistic, sometimes called a time-weighted average, reports the
average value of a response variable weighted by the time duration for each
observed value of the variable:

n
Time average =

i=1 (Ti x i )

where xi denotes the value of the i th observation, Ti denotes the time duration of
the i th observation (the weighting factor), and T denotes the total duration over
which the observations were collected. Example time-average statistics include
the average number of entities in a system, the average number of entities at a location, and the average utilization of a resource. An average of a time-weighted
response variable in ProModel is computed as a time average.
The average number of customer entities waiting in the queue location for
their turn on the ATM during the manual simulation is a time-average statistic.
Figure 4.6 is a plot of the number of customer entities in the queue during the
manual simulation recorded in Table 4.1. The 12 discrete-events manually simulated in Table 4.1 are labeled t1 , t2 , t3 , . . . , t11 , t12 on the plot. Recall that ti denotes the value of the simulation clock at time step i in Table 4.1, and that its initial value is zero, t0 = 0.
Using the notation from the time-average equation just given, the total simulation time illustrated in Figure 4.6 is T = 22 minutes. The Ti denotes the duration of time step i (distance between adjacent discrete-events in Figure 4.6). That
is, Ti = ti ti1 for i = 1, 2, 3, . . . , 12. The xi denotes the queues contents
(number of customer entities in the queue) during each Ti time interval. Therefore, xi = NQi1 for i = 1, 2, 3, . . . , 12 (recall that in Table 4.1, NQi1 denotes
the number of customer entities in the queue from ti1 to ti ). The time-average

88

t0

T1
2.18

Number of customers in queue

T3
7.91  2.28
5.63

T2
0.1

t3

10

11

12

t4

14

T6
0.17

T5
2.63

13

Simulation time, T
22

T4
12.37  7.91
4.46

Number of customers in the queue during the manual simulation.

t1 t2

T8
2.51

17

T7
0.57

16

t5 t6 t7

15

t8

18

20

T12
1.50

19

t11

21

t12

22

4. DiscreteEvent
Simulation

FIGURE 4.6

I. Study Chapters

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition
The McGrawHill
Companies, 2004

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Discrete-Event Simulation

89

number of customer entities in the queue (lets call it Average NQ) is

12
Average NQ =

i=1 (Ti xi )

12
=

i=1 (ti

ti1 )NQi1
T

Average NQ =

(2.18)(0) + (0.1)(0) + (5.63)(0) + (4.46)(0) + (2.63)(0) + (0.17)(0) + (0.57)(1) + (2.51)(2) + + (1.5)(2)

22

Average NQ =

13.21
= 0.60 customers
22

12
(ti ti1 )NQi1 )
You may recognize that the numerator of this equation ( i=1
calculates the area under the plot of the queues contents during the simulation
(Figure 4.6). The values necessary for computing this area are accumulated under
the Time-Weighted Number of Entities in Queue column of Table 4.1 (see the
Cumulative value of 13.21 in the tables last row).

4.4.5 Issues
Even though this example is a simple and somewhat crude simulation, it provides
a good illustration of basic simulation issues that need to be addressed when conducting a simulation study. First, note that the simulation start-up conditions can
bias the output statistics. Since the system started out empty, queue content statistics are slightly less than what they might be if we began the simulation with
customers already in the system. Second, note that we ran the simulation for only
22 minutes before calculating the results. Had we ran longer, it is very likely that
the long-run average time in the queue would have been somewhat different (most
likely greater) than the time from the short run because the simulation did not
have a chance to reach a steady state.
These are the kinds of issues that should be addressed whenever running a
simulation. The modeler must carefully analyze the output and understand the signicance of the results that are given. This example also points to the need for
considering beforehand just how long a simulation should be run. These issues are
addressed in Chapters 9 and 10.

4.5 Commercial Simulation Software

While a simulation model may be programmed using any development language
such as C++ or Java, most models are built using commercial simulation software
such as ProModel. Commercial simulation software consists of several modules
for performing different functions during simulation modeling. Typical modules
are shown in Figure 4.7.

4.5.1 Modeling Interface Module

A modeler denes a model using an input or modeling interface module. This
module provides graphical tools, dialogs, and other text editing capabilities for

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

90

I. Study Chapters

Part I

The McGrawHill
Companies, 2004

4. DiscreteEvent
Simulation

Study Chapters

FIGURE 4.7
Typical components of
simulation software.

Modeling
interface

Modeling
processor

Simulation
interface

Model Simulation
data
data

Simulation
processor

Output
interface

Output
data

Output
processor

Simulation
processor

entering and editing model information. External les used in the simulation are
specied here as well as run-time options (number of replications and so on).

4.5.2 Model Processor

When a completed model is run, the model processor takes the model database,
and any other external data les that are used as input data, and creates a simulation database. This involves data translation and possibly language compilation.
This data conversion is performed because the model database and external les
are generally in a format that cannot be used efciently by the simulation processor during the simulation. Some simulation languages are interpretive, meaning
that the simulation works with the input data the way they were entered. This allows simulations to start running immediately without going through a translator,
but it slows down the speed at which the simulation executes.
In addition to translating the model input data, other data elements are created
for use during simulation, including statistical counters and state variables. Statistical counters are used to log statistical information during the simulation such as
the cumulative number of entries into the system or the cumulative activity time
at a workstation.

4.5.3 Simulation Interface Module

The simulation interface module displays the animation that occurs during the
simulation run. It also permits the user to interact with the simulation to control
the current animation speed, trace events, debug logic, query state variables,

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

Discrete-Event Simulation

The McGrawHill
Companies, 2004

91

request snapshot reports, pan or zoom the layout, and so forth. If visual interactive
capability is provided, the user is even permitted to make changes dynamically to
model variables with immediate visual feedback of the effects of such changes.
The animation speed can be adjusted and animation can even be disabled by
the user during the simulation. When unconstrained, a simulation is capable of
running as fast as the computer can process all of the events that occur within the
simulated time. The simulation clock advances instantly to each scheduled event;
the only central processing unit (CPU) time of the computer that is used is what is
necessary for processing the event logic. This is how simulation is able to run in
compressed time. It is also the reason why large models with millions of events
take so long to simulate. Ironically, in real life activities take time while events
take no time. In simulation, events take time while activities take no time. To slow
down a simulation, delay loops or system timers are used to create pauses between
events. These techniques give the appearance of elapsing time in an animation. In
some applications, it may even be desirable to run a simulation at the same rate as
a real clock. These real-time simulations are achieved by synchronizing the simulation clock with the computers internal system clock. Human-in-the-loop (such
as operator training simulators) and hardware-in-the-loop (testing of new equipment and control systems) are examples of real-time simulations.

4.5.4 Simulation Processor

The simulation processor processes the simulated events and updates the statistical accumulators and state variables. A typical simulation processor consists of
the following basic components:
Clock variablea variable used to keep track of the elapsed time during
the simulation.
Event calendara list of scheduled events arranged chronologically
according to the time at which they are to occur.
Event dispatch managerthe internal logic used to update the clock and
manage the execution of events as they occur.
Event logicalgorithms that describe the logic to be executed and
statistics to be gathered when an event occurs.
Waiting listsone or more lists (arrays) containing events waiting for a
resource or other condition to be satised before continuing processing.
Random number generatoran algorithm for generating one or more
streams of pseudo-random numbers between 0 and 1.
Random variate generatorsroutines for generating random variates
from specied probability distributions.

4.5.5 Animation Processor

The animation processor interacts with the simulation database to update the
graphical data to correspond to the changing state data. Animation is usually

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

92

I. Study Chapters

Part I

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Study Chapters

displayed during the simulation itself, although some simulation products create
an animation le that can be played back at the end of the simulation. In addition
to animated gures, dynamic graphs and history plots can be displayed during the
simulation.
Animation and dynamically updated displays and graphs provide a visual representation of what is happening in the model while the simulation is running.
Animation comes in varying degrees of realism from three-dimensional animation
to simple animated owcharts. Often, the only output from the simulation that is of
interest is what is displayed in the animation. This is particularly true when simulation is used for facilitating conceptualization or for communication purposes.
A lot can be learned about model behavior by watching the animation (a picture is worth a thousand words, and an animation is worth a thousand pictures).
Animation can be as simple as circles moving from box to box, to detailed, realistic graphical representations. The strategic use of graphics should be planned in
advance to make the best use of them. While insufcient animation can weaken
the message, excessive use of graphics can distract from the central point to be
made. It is always good to dress up the simulation graphics for the nal presentation; however, such embellishments should be deferred at least until after the
model has been debugged.
For most simulations where statistical analysis is required, animation is no
substitute for the postsimulation summary, which gives a quantitative overview of
the entire system performance. Basing decisions on the animation alone reects
shallow thinking and can even result in unwarranted conclusions.

4.5.6 Output Processor

The output processor summarizes the statistical data collected during the simulation run and creates an output database. Statistics are reported on such performance measures as

Resource utilization.
Queue sizes.
Waiting times.
Processing rates.

In addition to standard output reporting, most simulation software provides the

ability to write user-specied data out to external les.

4.5.7 Output Interface Module

The output interface module provides a user interface for displaying the output
results from the simulation. Output results may be displayed in the form of reports
or charts (bar charts, pie charts, or the like). Output data analysis capabilities such
as correlation analysis and condence interval calculations also are often provided. Some simulation products even point out potential problem areas such as
bottlenecks.

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

Discrete-Event Simulation

The McGrawHill
Companies, 2004

93

4.6 Simulation Using ProModel

ProModel is a powerful, yet easy-to-use, commercial simulation package that is
designed to effectively model any discrete-event processing system. It also has
continuous modeling capabilities for modeling ow in and out of tanks and other
vessels. The online tutorial in ProModel describes the building, running, and
output analysis of simulation models. A brief overview of how ProModel works is
presented here. The labs in this book provide a more detailed, hands-on approach
for actually building and running simulations using ProModel.

4.6.1 Building a Model

A model is dened in ProModel using simple graphical tools, data entry tables,
and ll-in-the-blank dialog boxes. In ProModel, a model consists of entities (the
items being processed), locations (the places where processing occurs), resources
(agents used to process and move entities), and paths (aisles and pathways along
which entities and resources traverse). Dialogs are associated with each of these
modeling elements for dening operational behavior such as entity arrivals and
processing logic. Schedules, downtimes, and other attributes can also be dened
for entities, resources, and locations.
Most of the system elements are dened graphically in ProModel (see
Figure 4.8). A graphic representing a location, for example, is placed on the layout
to create a new location in the model (see Figure 4.9). Information about this
location can then be entered such as its name, capacity, and so on. Default values
are provided to help simplify this process. Dening objects graphically provides a
highly intuitive and visual approach to model building. The use of graphics is
optional, and a model can even be dened without using any graphics. In addition
to graphic objects provided by the modeling software, import capability is available to bring in graphics from other packages. This includes complete facility
layouts created using CAD software such as AutoCAD.

4.6.2 Running the Simulation

When running a model created in ProModel, the model database is translated or
compiled to create the simulation database. The animation in ProModel is
displayed concurrently with the simulation. Animation graphics are classied as
either static or dynamic. Static graphics include walls, aisles, machines, screen text,
and others. Static graphics provide the background against which the animation
FIGURE 4.8
Sample of ProModel
graphic objects.

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

94

I. Study Chapters

Part I

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Study Chapters

FIGURE 4.9
ProModel animation provides useful feedback.

takes place. This background might be a CAD layout imported into the model. The
dynamic animation objects that move around on the background during the simulation include entities (parts, customers, and so on) and resources (people, fork
trucks, and so forth). Animation also includes dynamically updated counters,
indicators, gauges, and graphs that display count, status, and statistical information
(see Figure 4.9).

4.6.3 Output Analysis

The output processor in ProModel provides both summary and detailed statistics
on key performance measures. Simulation results are presented in the form of reports, plots, histograms, pie charts, and others. Output data analysis capabilities
such as condence interval estimation are provided for more precise analysis.
Outputs from multiple replications and multiple scenarios can also be summarized and compared. Averaging performance across replications and showing
multiple scenario output side-by-side make the results much easier to interpret.
Summary Reports
Summary reports show totals, averages, and other overall values of interest.
Figure 4.10 shows an output report summary generated from a ProModel simulation run.

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

The McGrawHill
Companies, 2004

4. DiscreteEvent
Simulation

Chapter 4

95

Discrete-Event Simulation

FIGURE 4.10
Summary report of simulation activity.
-------------------------------------------------------------------------------General Report
Output from C:\ProMod4\models\demos\Mfg_cost.mod [Manufacturing Costing Optimization]
Date: Feb/27/2003
Time: 06:50:05 PM
-------------------------------------------------------------------------------Scenario
: Model Parameters
Replication
: 1 of 1
Warmup Time
: 5 hr
Simulation Time : 15 hr
--------------------------------------------------------------------------------

LOCATIONS

Location
Name
----------Receive
NC Lathe 1
NC Lathe 2
Degrease
Inspect
Bearing Que
Loc1

Scheduled
Hours
--------10
10
10
10
10
10
10

Capacity
-------2
1
1
2
1
100
5

Total
Entries
------21
57
57
114
113
90
117

Average
Minutes
Per Entry
--------57.1428
10.1164
9.8918
10.1889
4.6900
34.5174
25.6410

Average
Contents
-------2
0.961065
0.939725
1.9359
0.883293
5.17762
5

Maximum
Contents
-------2
1
1
2
1
13
5

Current
Contents
-------2
1
1
2
1
11
5

RESOURCES

Resource
Name
-------CellOp.1
CellOp.2
CellOp.3
CellOp

Units
----1
1
1
3

Scheduled
Hours
--------10
10
10
30

Number
Of Times
Used
-------122
118
115
355

Average
Minutes
Per
Usage
-------2.7376
2.7265
2.5416
2.6704

Average
Minutes
Travel
To Use
-------0.1038
0.1062
0.1020
0.1040

Average
Minutes
Moving

Average
Minutes
Wait for
Res, etc.
--------31.6055
3.2269
2.4885
35.5899

Average
Minutes
Travel
To Park
-------0.0000
0.0000
0.0000
0.0000

% Blocked
In Travel
--------0.00
0.00
0.00
0.00

ENTITY ACTIVITY

Entity
Name
------Pallet
Blank
Cog
Reject
Bearing

Total
Exits
----19
0
79
33
78

Current
Quantity
In System
--------2
7
3
0
12

Average
Minutes
In
System
--------63.1657
52.5925
49.5600
42.1855

-------0.0000
0.8492
0.8536
0.0500

Average
Minutes
In
Operation
--------1.0000
33.5332
33.0656
0.0000

Average
Minutes
Blocked
--------30.5602
14.9831
13.1522
6.5455

% Util
-----57.76
55.71
50.67
54.71

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

96
FIGURE 4.11
Time-series graph
showing changes in
queue size over time.

FIGURE 4.12
Histogram of queue
contents.

I. Study Chapters

Part I

Study Chapters

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

97

Discrete-Event Simulation

Time Series Plots and Histograms

Sometimes a summary report is too general to capture the information being
sought. Fluctuations in model behavior over time can be viewed using a time
series report. In ProModel, time series output data are displayed graphically so
that patterns can be identied easily. Time series plots can show how inventory
levels uctuate throughout the simulation or how changes in workload affect resource utilization. Figure 4.11 is a time series graph showing how the length of a
queue uctuates over time.
Once collected, time series data can be grouped in different ways to show patterns or trends. One common way of showing patterns is using a histogram. The
histogram in Figure 4.12 breaks down contents in a queue to show the percentage
of time different quantities were in that queue.
As depicted in Figure 4.12, over 95 percent of the time, there were fewer than
12 items in the queue. This is more meaningful than simply knowing what the
average length of the queue was.

4.7 Languages versus Simulators

A distinction is frequently made between simulation languages and simulators.
Simulation languages are often considered more general purpose and have fewer
predened constructs for modeling specic types of systems. Simulators, on the
other hand, are designed to handle specic problemsfor example, a job shop simulator or a clinic simulator. The rst simulators that appeared provided little, if any,
programming capability, just as the rst simulation languages provided few, if any,
special modeling constructs to facilitate modeling. Consequently, simulators acquired the reputation of being easy to use but inexible, while simulation languages
were branded as being very exible but difcult to use (see Figure 4.13).
Over time, the distinction between simulation languages and simulators has
become blurred as specialized modeling constructs have been added to generalpurpose simulation languages, making them easier to use. During the same period,
general programming extensions have been added to simulators, making them
more exible. The most popular simulation tools today combine powerful industryspecic constructs with exible programming capabilities, all accessible from an
intuitive graphical user interface (Bowden 1998). Some tools are even congurable, allowing the software to be adapted to specic applications yet still retaining programming capability. Rather than put languages and simulators on opposite
ends of the same spectrum as though exibility and ease of use were mutually exclusive, it is more appropriate to measure the exibility and ease of use for all
simulation software along two separate axes (Figure 4.14).
FIGURE 4.13

Simulators

Languages

Old paradigm that

polarized ease of use
and exibility.

Ease of use

Flexibility

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

98

I. Study Chapters

Part I

The McGrawHill
Companies, 2004

4. DiscreteEvent
Simulation

Study Chapters

Early
simulators

Current best-of-breed
products

Ease of use

Early
languages

Hard

New paradigm that

views ease of use and
exibility as
independent
characteristics.

Easy

FIGURE 4.14

Low

High
Flexibility

4.8 Future of Simulation

Simulation products have evolved to provide more than simply stand-alone simulation capability. Modern simulation products have open architectures based on
component technology and standard data access methods (like SQL) to provide
interfacing capability with other applications such as CAD programs and enterprise planning tools. Surveys reported annually in Industrial Engineering Solutions show that most simulation products have the following features:

Input data analysis for distribution tting.

Point-and-click graphical user interface.
Reusable components and templates.
Two- (2-D) and three-dimensional (3-D) animation.
Online help and tutorials.
Interactive debugging.
Automatic model generation.
Output analysis tools.
Optimization.
Open architecture and database connectivity.

Simulation is a technology that will continue to evolve as related technologies improve and more time is devoted to the development of the software. Products will become easier to use with more intelligence being incorporated into the
software itself. Evidence of this trend can already be seen by optimization and
other time-saving utilities that are appearing in simulation products. Animation
and other graphical visualization techniques will continue to play an important
role in simulation. As 3-D and other graphic technologies advance, these features
will also be incorporated into simulation products.

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

Discrete-Event Simulation

The McGrawHill
Companies, 2004

99

Simulation products targeted at vertical markets are on the rise. This trend is
driven by efforts to make simulation easier to use and more solution oriented.
Specic areas where dedicated simulators have been developed include call center management, supply chain management, and high-speed processing. At the
same time many simulation applications are becoming more narrowly focused,
others are becoming more global and look at the entire enterprise or value chain
in a hierarchical fashion from top to bottom.
Perhaps the most dramatic change in simulation will be in the area of software interoperability and technology integration. Historically, simulation has
been viewed as a stand-alone, project-based technology. Simulation models were
built to support an analysis project, to predict the performance of complex
systems, and to select the best alternative from a few well-dened alternatives.
Typically these projects were time-consuming and expensive, and relied heavily
on the expertise of a simulation analyst or consultant. The models produced were
generally single use models that were discarded after the project.
In recent years, the simulation industry has seen increasing interest in extending the useful life of simulation models by using them on an ongoing basis
(Harrell and Hicks 1998). Front-end spreadsheets and push-button user interfaces
are making such models more accessible to decision makers. In these exible simulation models, controlled changes can be made to models throughout the system
life cycle. This trend is growing to include dynamic links to databases and other
data sources, enabling entire models actually to be built and run in the background
using data already available from other enterprise applications.
The trend to integrate simulation as an embedded component in enterprise
applications is part of a larger development of software components that can be
distributed over the Internet. This movement is being fueled by three emerging
information technologies: (1) component technology that delivers true object
orientation; (2) the Internet or World Wide Web, which connects business communities and industries; and (3) Web service technologies such as JZEE and
Microsofts .NET (DOTNET). These technologies promise to enable parallel
and distributed model execution and provide a mechanism for maintaining distributed model repositories that can be shared by many modelers (Fishwick 1997).
The interest in Web-based simulation, like all other Web-based applications, continues to grow.

4.9 Summary
Most manufacturing and service systems are modeled using dynamic, stochastic,
discrete-event simulation. Discrete-event simulation works by converting all activities to events and consequent reactions. Events are either time-triggered or
condition-triggered, and are therefore processed either chronologically or when a
satisfying condition has been met.
Simulation models are generally dened using commercial simulation software that provides convenient modeling constructs and analysis tools. Simulation

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

100

I. Study Chapters

Part I

4. DiscreteEvent
Simulation

The McGrawHill
Companies, 2004

Study Chapters

software consists of several modules with which the user interacts. Internally,
model data are converted to simulation data, which are processed during the
simulation. At the end of the simulation, statistics are summarized in an output
database that can be tabulated or graphed in various forms. The future of simulation is promising and will continue to incorporate exciting new technologies.

4.10 Review Questions

1. Give an example of a discrete-change state variable and a continuouschange state variable.
2. In simulation, the completion of an activity time that is random must be
known at the start of the activity. Why is this necessary?
3. Give an example of an activity whose completion is a scheduled event
and one whose completion is a conditional event.
4. For the rst 10 customers processed completely through the ATM
spreadsheet simulation presented in Table 3.2 of Chapter 3, construct a
table similar to Table 4.1 as you carry out a manual discrete-event
simulation of the ATM system to
a. Compute the average amount of time the rst 10 customers spent in
the system. Hint: Add time in system and corresponding cumulative
columns to the table.
b. Compute the average amount of time the rst 10 customers spent in
the queue.
c. Plot the number of customers in the queue over the course of the
simulation and compute the average number of customers in the
queue for the simulation.
d. Compute the utilization of the ATM. Hint: Dene a utilization
variable that is equal to zero when the ATM is idle and is equal to 1
when the ATM is busy. At the end of the simulation, compute a timeweighted average of the utilization variable.
5. Identify whether each of the following output statistics would be
computed as a simple or as a time-weighted average value.
a. Average utilization of a resource.
b. Average time entities spend in a queue.
c. Average time entities spend waiting for a resource.
d. Average number of entities waiting for a particular resource.
e. Average repair time for a machine.
6. Give an example of a situation where a time series graph would be
more useful than just seeing an average value.
7. In real life, activities take time and events take no time. During a
simulation, activities take no time and events take all of the time.
Explain this paradox.

HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition

I. Study Chapters

Chapter 4

4. DiscreteEvent
Simulation

Discrete-Event Simulation

The McGrawHill
Companies, 2004

101

8. What are the main components of simulation software?

9. Look up a simulation product on the Internet or in a trade journal and
describe two promotional features of the product being advertised.
10. For each of the following simulation applications identify one discreteand one continuous-change state variable.
a. Inventory control of an oil storage and pumping facility.
b. Study of beverage production in a soft drink production facility.
c. Study of congestion in a busy trafc intersection.

References
Bowden, Royce. The Spectrum of Simulation Software. IIE Solutions, May 1998,
pp. 4446.
Fishwick, Paul A. Web-Based Simulation. In Proceedings of the 1997 Winter Simulation
Conference, ed. S. Andradottir, K. J. Healy, D. H. Withers, and B. L. Nelson. Institute
of Electric and Electronics Engineers, Piscataway, NJ, 1997. pp. 100109.
Gottfried, Byron S. Elements of Stochastic Process Simulation. Englewood Cliffs, NJ:
Prentice Hall, 1984, p. 8.
Haider, S. W., and J. Banks. Simulation Software Products for Analyzing Manufacturing
Systems. Industrial Engineering, July 1986, p. 98.
Harrell, Charles R., and Don Hicks. Simulation Software Component Architecture for
Simulation-Based Enterprise Applications. Proceedings of the 1998 Winter Simulation Conference, ed. D. J. Medeiros, E. F. Watson, J. S. Carson, and M. S. Manivannan.
Institute of Electrical and Electronics Engineers, Piscataway, New Jersey, 1998,
pp. 171721.