Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
C H A P T E R
4 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 discrete-
event 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 exe-
cuted 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 re-
lated to discrete-event simulation to facilitate your understanding of how to effec-
tively 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: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
Time
Start Event 1 Event 2 Event 3
Simulation (customer (customer (customer
arrives) arrives) departs)
HarrellGhoshBowden: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
FIGURE 4.2
Continuous-change
Comparison of a state variable
discrete-change state
variable and a
continuous-change Value
Discrete-change
state variable.
state variable
Time
Batch processing in which uids are pumped into and out of tanks can often be
modeled using difference equations.
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 chronologi-
cally 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 fre-
quency, however, they are scheduled only when the next occurrence must be de-
termined. 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 condi-
tion. 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 up-
dated, 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, espe-
cially 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 simula-
tion time. That means it continues processing until it reaches either a conditional
HarrellGhoshBowden: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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.
No
Stop
Process event and
schedule any new
events.
Update statistics,
state variables,
and animation.
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 cre-
ated 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: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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 sched-
uled and conditional events, updating state and statistical variables, and creating
new events constitutes the essence of discrete-event simulation (see Figure 4.3).
FIGURE 4.4
Entity ow diagram for example automatic teller machine (ATM) system.
8 7 6 5 4 3 2 1
HarrellGhoshBowden: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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 simu-
lation 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 sim-
ulation 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 de-
notes 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: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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 en-
tered the location. For the ATM simulation, one entity attribute is used to remem-
ber the customers time of arrival to the system. This entity attribute is called the
Arrival Time attribute. The simulation program computes how long each cus-
tomer 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 en-
tity 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 cus-
tomers 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: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
Events
There are two types of recurring scheduled events that change the state of the sys-
tem: 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 com-
pletes 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 simu-
lation 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) re-
turns 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.
compare the results of the manual simulation with those produced by the spread-
sheet simulation.
Notice that Table 3.2 contains a subscript i in the leftmost column. This sub-
script 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 val-
ues 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 re-
sults of the manual simulation after processing 12 events using the simulation
logic diagram presented in Figure 4.5. The table tracks the creation and schedul-
ing 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 exe-
cuted. 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 re-
minder to look up one or more rows above your current position in the table to de-
termine 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 sub-
columns 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
Start
i=0
82
Initialize variables and schedule initial arrival event and termination event (Scheduled Future Events).
i=i+1
i=i+1 Update Event Calendar: Insert Scheduled Future Events in chronological order. i=i+1
Simulation Using
Advance Clock, ti, to the Time of the first event on the calendar and process the event.
HarrellGhoshBowden:
End
Schedule departure event for Store current customer Update Entity Attribute Array by Update Entity Attribute
current customer entity entering entitys Arrival Time in last deleting departed customer entity Array by deleting departed
position of Entity Attribute from first position in the array and customer entity from first
Simulation
Arrival Time in first position of Subtract 1 from NQi, Number of Change ATM Statusi to Idle.
Entity Attribute Array. Add 1 to NQi, Number of Entities in Queue.
Change ATM Statusi to Busy. Entities in Queue. Schedule departure event for
Update Entities Processed Update Time-Weighted customer entity entering the ATM
through Queue statistics to Number of Entities in Queue to occur at time ti + E(2.4).
reflect customer entering ATM. statistic. Update Entities Processed
- Add 1 to Total Processed. - Compute value for through Queue statistics to reflect
- Record Time in Queue of 0 for (ti ti 1)NQi 1 and customer entering ATM.
ti - Arrival Time and update update Cumulative. - Add 1 to Total Processed.
Cumulative. - Compute Time in Queue
Update Time-Weighted Number value for ti - Arrival Time and
of Entities in Queue statistic. update Cumulative.
- Record value of 0 for Update Time-Weighted Number of
(ti ti 1)NQi 1 and update Entities in Queue statistic.
Cumulative. - Compute value for (ti ti 1)NQi 1
and update Cumulative.
Companies, 2004
The McGrawHill
FIGURE 4.5
Discrete-event simulation logic diagram for ATM system.
TABLE 4.1 Manual Discrete-Event Simulation of ATM System
Event Calendar Processed Event System State Statistical Accumulators Scheduled Future Events
Simulation Using
Entity Attribute
Array (Entity Time-Weighted
Number, Arrival Entities Processed Number of Entities
HarrellGhoshBowden:
I. Study Chapters
3 (2, Arrive, 7.91) 7.91 2 Arrive *(2, 7.91) Busy 2 0 0 0 0 (3, Arrive, 15.00)
(_, End, 22.00) ( ) (2, Depart, 12.37)
4. DiscreteEvent
83
HarrellGhoshBowden: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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 simula-
tion 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 en-
titys arrival time of 15.17 minutes is stored in the last position of the Entity At-
tribute 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: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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 sta-
tistics 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 in-
uencing 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 sepa-
rated them to facilitate our describing the ow of information in the discrete-event
framework.
Simple-Average Statistic
A simple-average statistic is calculated by dividing the sum of all observation val-
ues 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. Exam-
ple 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 observation-
based response variable in ProModel is computed as a simple average.
HarrellGhoshBowden: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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
xi 0 + 0 + 0 + 3.08 + 4.76
Average time in queue = i=1
=
5 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
i=1 (Ti x i )
Time average =
T
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 lo-
cation, 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 simu-
lated in Table 4.1 are labeled t1 , t2 , t3 , . . . , t11 , t12 on the plot. Recall that ti de-
notes the value of the simulation clock at time step i in Table 4.1, and that its ini-
tial value is zero, t0 = 0.
Using the notation from the time-average equation just given, the total simu-
lation time illustrated in Figure 4.6 is T = 22 minutes. The Ti denotes the dura-
tion 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. There-
fore, 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
Simulation Using
HarrellGhoshBowden:
4
I. Study Chapters
2
Simulation
4. DiscreteEvent
Simulation time, T 22
FIGURE 4.6
Companies, 2004
13.21
Average NQ = = 0.60 customers
22
12
You may recognize that the numerator of this equation ( i=1 (ti ti1 )NQi1 )
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 con-
ducting a simulation study. First, note that the simulation start-up conditions can
bias the output statistics. Since the system started out empty, queue content statis-
tics 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 sig-
nicance 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.
FIGURE 4.7
Typical components of
simulation software.
Simulation Simulation
processor 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).
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 simu-
lation clock with the computers internal system clock. Human-in-the-loop (such
as operator training simulators) and hardware-in-the-loop (testing of new equip-
ment and control systems) are examples of real-time simulations.
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 rep-
resentation 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 simula-
tion is used for facilitating conceptualization or for communication purposes.
A lot can be learned about model behavior by watching the animation (a pic-
ture 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, real-
istic 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 presenta-
tion; 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.
FIGURE 4.8
Sample of ProModel
graphic objects.
HarrellGhoshBowden: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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 simu-
lation 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).
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 simula-
tion run.
HarrellGhoshBowden: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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
Average
Location Scheduled Total Minutes Average Maximum Current
Name Hours Capacity Entries Per Entry Contents Contents Contents
----------- --------- -------- ------- --------- -------- -------- --------
Receive 10 2 21 57.1428 2 2 2
NC Lathe 1 10 1 57 10.1164 0.961065 1 1
NC Lathe 2 10 1 57 9.8918 0.939725 1 1
Degrease 10 2 114 10.1889 1.9359 2 2
Inspect 10 1 113 4.6900 0.883293 1 1
Bearing Que 10 100 90 34.5174 5.17762 13 11
Loc1 10 5 117 25.6410 5 5 5
RESOURCES
ENTITY ACTIVITY
FIGURE 4.11
Time-series graph
showing changes in
queue size over time.
FIGURE 4.12
Histogram of queue
contents.
HarrellGhoshBowden: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
FIGURE 4.14
Easy
New paradigm that
views ease of use and
Early Current best-of-breed
exibility as
simulators products
independent
Ease of use
characteristics.
Early
languages
Hard
Low High
Flexibility
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 cen-
ter 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 soft-
ware 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 ex-
tending 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 sim-
ulation 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 com-
munities 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 dis-
tributed model repositories that can be shared by many modelers (Fishwick 1997).
The interest in Web-based simulation, like all other Web-based applications, con-
tinues 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 ac-
tivities 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 soft-
ware that provides convenient modeling constructs and analysis tools. Simulation
HarrellGhoshBowden: I. Study Chapters 4. DiscreteEvent The McGrawHill
Simulation Using Simulation Companies, 2004
ProModel, Second Edition
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 simula-
tion is promising and will continue to incorporate exciting new technologies.
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 Simula-
tion 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.