Академический Документы
Профессиональный Документы
Культура Документы
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:
HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition
72
I. Study Chapters
Part I
The McGrawHill
Companies, 2004
4. DiscreteEvent
Simulation
Study Chapters
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.
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.
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
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).
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
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.
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
Yes
No
Any
customers
in queue?
End
End
Event
type?
i=i+1
4. DiscreteEvent
Simulation
FIGURE 4.5
No
Arrive
Is ATM
idle?
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
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
No new events
No new events
4. DiscreteEvent
Simulation
(4, Depart,
(_, End,
(8, Arrive,
(_, End,
(8, Arrive,
(5, Depart,
Entity Number
I. Study Chapters
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
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.
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
T2 0.1
t3
10
11
12
t4
14
T6 0.17
T5 2.63
13
Simulation time, T 22
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
i=1 (Ti xi )
12
=
i=1 (ti
ti1 )NQi1
T
Average NQ =
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.
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).
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.
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.
Resource utilization.
Queue sizes.
Waiting times.
Processing rates.
HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition
I. Study Chapters
Chapter 4
4. DiscreteEvent
Simulation
Discrete-Event Simulation
The McGrawHill
Companies, 2004
93
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).
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
Simulators
Languages
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
Easy
FIGURE 4.14
Low
High
Flexibility
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.
HarrellGhoshBowden:
Simulation Using
ProModel, Second Edition
I. Study Chapters
Chapter 4
4. DiscreteEvent
Simulation
Discrete-Event Simulation
The McGrawHill
Companies, 2004
101
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.