harrell ghosh bowden cap1

Harrell−Ghosh−Bowden: Simulation Using ProModel, Second Edition

I. Study Chapters 4. Discrete−Event Simulation

© The McGraw−Hill Companies, 2004

C H A P T E R

4 DISCRETE-EVENTSIMULATION

71

4.1 IntroductionBuilding on the foundation provided by Chapter 3 on how random numbers andrandom variates are used to simulate stochastic systems, the focus of this chapteris 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 modeloccur at discrete points in time as triggered by events. The events in the automaticteller machine (ATM) simulation example of Chapter 3 that occur at discretepoints in time are the arrivals of customers to the ATM queue and the completionof their transactions at the ATM. However, you will learn in this chapter that thespreadsheet simulation of the ATM system in Chapter 3 was not technically exe-cuted as a discrete-event simulation.

This chapter first defines what a discrete-event simulation is compared to acontinuous 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 examplesystem from Chapter 3 is given to further illustrate what goes on inside this typeof simulation.

“When the only tool you have is a hammer, every problem begins to resemble anail.”—Abraham Maslow




72 Part I Study Chapters

StartSimulation

Number ofcustomers

in restaurant

3

2

1

Event 1(customerarrives)

Event 2(customerarrives)

Event 3(customerdeparts)

Time

…

FIGURE 4.1Discrete events causediscrete state changes.

4.2 Discrete-Event versus Continuous Simulation Commonly, simulations are classified according to the following characteristics:

• Static or dynamic

• Stochastic or deterministic

• Discrete-event or continuous

In Chapter 3 we discussed the differences between the first two sets of character-istics. Now we direct our attention to discrete-event versus continuous simula-tions. A discrete-event simulation is one in which state changes occur at discretepoints 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 modelbecomes the collective state of all the elements in the model at a particular pointin time. State variables in a discrete-event simulation are referred to as discrete-change state variables. A restaurant simulation is an example of a discrete-eventsimulation because all of the state variables in the model, such as the number ofcustomers in the restaurant, are discrete-change state variables (see Figure 4.1).Most manufacturing and service systems are typically modeled using discrete-event simulation.

In continuous simulation, state variables change continuously with respect totime and are therefore referred to as continuous-change state variables. An exam-ple of a continuous-change state variable is the level of oil in an oil tanker that isbeing either loaded or unloaded, or the temperature of a building that is controlledby a heating and cooling system. Figure 4.2 compares a discrete-change statevariable and a continuous-change state variable as they vary over time.




Chapter 4 Discrete-Event Simulation 73

Time

Continuous-changestate variable

Value Discrete-changestate variable

FIGURE 4.2Comparison of adiscrete-change statevariable and acontinuous-changestate variable.

Continuous simulation products use either differential equations or differ-ence equations to define 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 interms of the derivatives of the state variables. Equations involving derivatives ofa state variable are referred to as differential equations. The state variable v, forexample, might change as a function of both v and time t:

dv(t)

dt= v2(t) + t2

We then need a second equation to define the initial condition of v:

v(0) = K

On a computer, numerical integration is used to calculate the change in aparticular response variable over time. Numerical integration is performed at theend of successive small time increments referred to as steps. Numerical analysistechniques, such as Runge-Kutta integration, are used to integrate the differentialequations numerically for each incremental time step. One or more threshold valuesfor each continuous-change state variable are usually defined that determine whensome 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 differenceequations. In such instances, the time is decomposed into periods of length t. Analgebraic expression is then used to calculate the value of the state variable at theend 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 rateof change in the state variable v as a function of the current value of v, a rate ofchange (r), and the length of the time period (�t):

v(k + 1) = v(k) + r�t





Batch processing in which fluids are pumped into and out of tanks can often bemodeled using difference equations.

4.2.3 Combined Continuous and Discrete Simulation

Many simulation software products provide both discrete-event and continuoussimulation capabilities. This enables systems that have both discrete-event andcontinuous characteristics to be modeled, resulting in a hybrid simulation. Mostprocessing systems that have continuous-change state variables also have discrete-change state variables. For example, a truck or tanker arrives at a fill station (adiscrete event) and begins filling a tank (a continuous process).

Four basic interactions occur between discrete- and continuous-changevariables:

1. A continuous variable value may suddenly increase or decrease as theresult of a discrete event (like the replenishment of inventory in aninventory model).

2. The initiation of a discrete event may occur as the result of reaching athreshold value in a continuous variable (like reaching a reorder point inan inventory model).

3. The change rate of a continuous variable may be altered as the result of adiscrete event (a change in inventory usage rate as the result of a suddenchange in demand).

4. An initiation or interruption of change in a continuous variable mayoccur as the result of a discrete event (the replenishment or depletion ofinventory initiates or terminates a continuous change of the continuousvariable).

4.3 How Discrete-Event Simulation WorksMost simulation software, including ProModel, presents a process-oriented worldview to the user for defining models. This is the way most humans tend to thinkabout systems that process entities. When describing a system, it is natural to doso in terms of the process flow. Entities begin processing at activity A then moveon to activity B and so on. In discrete-event simulation, these process flow defin-itions are translated into a sequence of events for running the simulation: firstevent 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 twotypes: scheduled and conditional, both of which create the activity delays in thesimulation to replicate the passage of time.

A scheduled event is one whose time of occurrence can be determinedbeforehand and can therefore be scheduled in advance. Assume, for example, thatan activity has just begun that will take X amount of time, where X is a normallydistributed random variable with a mean of 5 minutes and a standard deviation of





1.2 minutes. At the start of the activity, a normal random variate is generatedbased on these parameters, say 4.2 minutes, and an activity completion event isscheduled for that time into the future. Scheduled events are inserted chronologi-cally into an event calendar to await the time of their occurrence. Events thatoccur at predefined intervals theoretically all could be determined in advance andtherefore be scheduled at the beginning of the simulation. For example, entitiesarriving every five minutes into the model could all be scheduled easily at the startof 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 scheduleduntil the current scheduled arrival is actually pulled from the event calendar forprocessing. This postponement until the latest possible moment minimizes thesize of the event calendar and eliminates the necessity of knowing in advance howmany events to schedule when the length of the simulation may be unknown.

Conditional events are triggered by a condition being met rather than by thepassage of time. An example of a conditional event might be the capturing of aresource that is predicated on the resource being available. Another examplewould be an order waiting for all of the individual items making up the order to beassembled. In these situations, the event time cannot be known beforehand, sothe pending event is simply placed into a waiting list until the conditions can besatisfied. 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 resourcewhen it becomes available. Internally, the resource would have a waiting list for allitems currently waiting to use it. While in most cases events in a waiting list areprocessed first-in, first-out (FIFO), items could be inserted and removed using anumber of different criteria. For example, items may be inserted according to itempriority but be removed according to earliest due date.

Events, whether scheduled or conditional, trigger the execution of logic that isassociated with that event. For example, when an entity frees a resource, the stateand 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 torespond to next. Any new events resulting from the processing of the current eventare inserted into either the event calendar or another appropriate waiting list.

In real life, events can occur simultaneously so that multiple entities can bedoing 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 timeeven though it is the same instant in simulated time. As a consequence, a method orrule must be established for processing events that occur at the exact same simulatedtime. For some special cases, the order in which events are processed at the currentsimulation time might be significant. For example, an entity that frees a resource andthen tries to immediately get the same resource might have an unfair advantage overother entities that might have been waiting for that particular resource.

In ProModel, the entity, downtime, or other item that is currently beingprocessed 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





Start

Stop

Create simulationdatabase and schedule

initial events.

Advance clock tonext event time.

Terminationevent?

Process event andschedule any new

events.

Update statistics,state variables,and animation.

Any conditionalevents?

No

No

Yes

Yes Update statisticsand generateoutput report.

FIGURE 4.3Logic diagram of howdiscrete-eventsimulation works.

event that cannot be satisfied or a timed delay that causes a future event to bescheduled. It is also possible that the object simply finishes all of the processingdefined for it and, in the case of an entity, exits the system. As an object is beingprocessed, 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 asimilar fashion after the current object reaches a stopping point. To deliberately





5

Arriving customers(entities)

ATM queue(FIFO)

ATM server(resource)

Departingcustomers(entities)

8 7 6 4 3 2 1

FIGURE 4.4Entity flow diagram for example automatic teller machine (ATM) system.

suspend the current object in order to allow items in the action list to be processed,a zero delay time can be specified for the current object. This puts the current iteminto the future events list (event calendar) for later processing, even though it isstill processed at the current simulation time.

When all scheduled and conditional events have been processed that arepossible at the current simulation time, the clock advances to the next scheduledevent and the process continues. When a termination event occurs, the simulationends and statistical reports are generated. The ongoing cycle of processing sched-uled and conditional events, updating state and statistical variables, and creatingnew events constitutes the essence of discrete-event simulation (see Figure 4.3).

4.4 A Manual Discrete-Event Simulation ExampleTo illustrate how discrete-event simulation works, a manual simulation is presentedof the automatic teller machine (ATM) system of Chapter 3. Customers arrive touse an automatic teller machine (ATM) at a mean interarrival time of 3.0 minutesexponentially distributed. When customers arrive to the system, they join a queueto wait for their turn on the ATM. The queue has the capacity to hold an infinitenumber of customers. The ATM itself has a capacity of one (only one customer at atime can be processed at the ATM). Customers spend an average of 2.4 minutes ex-ponentially distributed at the ATM to complete their transactions, which is calledthe service time at the ATM. Assuming that the simulation starts at time zero, sim-ulate theATM system for its first 22 minutes of operation and estimate the expectedwaiting time for customers in the queue (the average time customers wait in line forthe ATM) and the expected number of customers waiting in the queue (the averagenumber of customers waiting in the queue during the simulated time period). If youare wondering why 22 minutes was selected as the simulation run length, it is be-cause 22 minutes of manual simulation will nicely fit on one page of the textbook.An entity flow 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 3although it would have been a good idea to have done so. In any simulation,





certain assumptions must be made where information is not clear or complete.Therefore, it is important that assumptions be clearly documented. The assump-tions we will be making for this simulation are as follows:

• There are no customers in the system initially, so the queue is empty andthe ATM is idle.

• The move time from the queue to the ATM is negligible and thereforeignored.

• Customers are processed from the queue on a first-in, first-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 wasdone in the spreadsheet simulation of Chapter 3. Instead the simulation schedulesthe arrival of customer entities to the ATM queue and the departure of customerentities from the ATM as they occur over time. That is, the simulation calls afunction to obtain an exponentially distributed interarrival time value only whena new customer entity needs to be scheduled to arrive to the ATM queue. Like-wise, the simulation calls a function to obtain an exponentially distributed servicetime value at the ATM only after a customer entity has gained access (entry) to theATM and the entity’s future departure time from the ATM is needed. An eventcalendar is maintained to coordinate the processing of the customer arrival andcustomer departure events. As arrival and departure event times are created, theyare placed on the event calendar in chronological order. As these events getprocessed, state variables (like the contents of a queue) get changed and statisticalaccumulators (like the cumulative time in the queue) are updated.

With this overview, let’s list the structured components needed to conduct themanual simulation.

Simulation ClockAs the simulation transitions from one discrete-event to the next, the simulationclock is fast forwarded to the time that the next event is scheduled to occur. Thereis no need for the clock to tick seconds away until reaching the time at which thenext event in the list is scheduled to occur because nothing will happen thatchanges the state of the system until the next event occurs. Instead, the simulationclock 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 valueof the simulation clock when the first discrete event in the list is processed, t2 de-notes the value of the simulation clock when the second discrete-event in the listis processed, and so on.

Entity AttributesTo capture some statistics about the entities being processed through the system,a discrete-event simulation maintains an array of entity attribute values. Entity





attributes are characteristics of the entity that are maintained for that entity untilthe entity exits the system. For example, to compute the amount of time an entitywaited 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 customer’s time of arrival to the system. This entity attribute is called theArrival Time attribute. The simulation program computes how long each cus-tomer entity waited in the queue by subtracting the time that the customer entityarrived to the queue from the value of the simulation clock when the customer en-tity gained access to the ATM.

State VariablesTwo discrete-change state variables are needed to track how the status (state) of thesystem 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 AccumulatorsThe objective of the example manual simulation is to estimate the expectedamount 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 simpleaverage. Computing this requires that we record how many customers passedthrough the queue and the amount of time each customer waited in the queue. Theaverage number of customers in the queue is a time-weighted average, which isusually called a time average in simulation. Computing this requires that we notonly observe the queue’s contents during the simulation but that we also measurethe amount of time that the queue maintained each of the observed values. Werecord each observed value after it has been multiplied (weighted) by the amountof time it was maintained.

Here’s what the simulation needs to tally at each simulation time step i tocompute 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 customerentities in the queue get a turn at the ATM. This accumulator keeps trackof how many customers actually made it through the queue.

• For a customer processed through the queue, record the time that it waitedin the queue. This is computed by subtracting the value of the simulationclock time when the entity enters the queue (stored in the entity attributearray Arrival Time) from the value of the simulation clock time when theentity 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 − ti−1, and the number of

customer entities in the queue during the last time step, which is NQi−1,record the product of ti − ti−1 and NQi−1. Call the product(ti − ti−1)NQi−1 the Time-Weighted Number of Entities in the Queue.





EventsThere 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 customerentity arrives to the queue. A departure event occurs when a customer entity com-pletes its transaction at the ATM. Each processing of a customer entity’s arrivalto the queue includes scheduling the future arrival of the next customer entity tothe ATM queue. Each time an entity gains access to the ATM, its future departurefrom the system is scheduled based on its expected service time at the ATM. Weactually need a third event to end the simulation. This event is usually called thetermination 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 simulationclock time, ti . The interarrival time is exponentially distributed with a mean of3.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. Thefuture arrival time of the next customer entity can then be scheduled by using theequation ti + E(3.0).

The customer service time at the ATM is exponentially distributed with amean of 2.4 minutes. The future departure time of an entity gaining access to theATM is scheduled by the equation ti + E(2.4).

Event CalendarThe event calendar maintains the list of active events (events that have beenscheduled and are waiting to be processed) in chronological order. The simulationprogresses by removing the first event listed on the event calendar, setting thesimulation clock, ti , equal to the time at which the event is scheduled to occur, andprocessing the event.

4.4.3 Running the Simulation

To run the manual simulation, we need a way to generate exponentially distributedrandom variates for interarrival times [the function E(3.0)] and service times [thefunction E(2.4)]. Rather than using our calculators to generate a random numberand transform it into an exponentially distributed random variate each time one isneeded for the simulation, let’s take advantage of the work we did to build thespreadsheet 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 of3.0 minutes and 25 exponentially distributed service times with a mean of2.4 minutes in advance of running the spreadsheet simulation. So when we need aservice time or an interarrival time for our manual simulation, let’s use the valuesfrom the Service Time and Interarrival Time columns of Table 3.2 rather thancomputing them by hand. Note, however, that we do not need to generate allrandom variates in advance for our manual discrete-event simulation (that’s oneof its advantages over spreadsheet simulation). We are just using Table 3.2 tomake our manual simulation a little less tedious, and it will be instructive to





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 usesof 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 inFigure 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 simulationlogic 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 changesand how the values of the statistical accumulators change as events are processedfrom the event calendar. Although Table 4.1 is completely filled in, it was initiallyblank until the instructions presented in the simulation logic diagram were exe-cuted. As you work through the simulation logic diagram, you should process theinformation in Table 4.1 from the first row down to the last row, one row at a time(completely filling in a row before going down to the next row). A dash (—) in acell in Table 4.1 signifies that the simulation logic diagram does not require you toupdate that particular cell at the current simulation time step. An arrow (↑) in acell in the table also signifies that the simulation logic diagram does not requireyou 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 Entitiesin Queue, NQi column, and ATM Statusi column. The only exception to the use ofdashes or arrows is that we keep a running total in the two Cumulative sub-columns in the table for each time step. Let’s get the manual simulation started.

i = 0, t0 = 0. As shown in Figure 4.5, the first block after the start positionindicates that the model is initialized to its starting conditions. Thesimulation time step begins at i = 0. The initial value of the simulationclock is zero, t0 = 0. The system state variables are set to ATM Status0 �“Idle”; Number of Entities in Queue, NQ0 = 0; and the Entity AttributeArray is cleared. This reflects the initial conditions of no customer entitiesin the queue and an idle ATM. The statistical accumulator Total Processed isset to zero. There are two different Cumulative variables in Table 4.1: one toaccumulate the time in queue values of ti − Arrival Time, and the other toaccumulate the values of the time-weighted number of entities in the queue,(ti − ti−1)NQi−1. Recall that ti − Arrival Time is the amount of time thatentities, which gained access to the ATM, waited in queue. Both Cumulativevariables (ti− Arrival Time) and (ti − ti−1)NQi−1 are initialized to zero.Next, an initial arrival event and termination event are scheduled and placedunder the Scheduled Future Events column. The listing of an event isformatted as “(Entity Number, Event, and Event Time)”. Entity Numberdenotes the customer number that the event pertains to (such as the first,second, or third customer). Event is the type of event: a customer arrives, a




• U

pdat

e E

vent

Cal

enda

r: I

nser

t Sch

edul

ed F

utur

e E

vent

s in

chr

onol

ogic

al o

rder

.•

Adv

ance

Clo

ck, t

i, to

the

Tim

e of

the

first

eve

nt o

n th

e ca

lend

ar a

nd p

roce

ss th

e ev

ent.

End

Sta

rt

Initi

aliz

e va

riabl

es a

nd s

ched

ule

initi

al a

rriv

al e

vent

and

term

inat

ion

even

t (S

ched

uled

Fut

ure

Eve

nts)

.

i = 0

i = i

+ 1

i =

i +

1

i = i

+ 1

Eve

ntty

pe?

Arr

ive

Yes

No

Yes

No

Dep

art

End

Is A

TM

idle

?

Any

cust

omer

sin

que

ue?

Upd

ate

stat

istic

s an

d ge

nera

te o

utpu

t rep

ort.

• S

ched

ule

depa

rtur

e ev

ent f

or

curr

ent c

usto

mer

ent

ity e

nter

ing

ATM

to o

ccur

at t

ime

t i +

E(2

.4).

• S

tore

cur

rent

cus

tom

er’s

A

rriv

al T

ime

in fi

rst p

ositi

on o

f

Ent

ity A

ttrib

ute

Arr

ay.

• C

hang

e AT

M S

tatu

s ito

Bus

y.•

Upd

ate

Ent

ities

Pro

cess

ed

thro

ugh

Que

ue s

tatis

tics

to

refle

ct c

usto

mer

ent

erin

g AT

M.

-

Add

1 to

Tot

al P

roce

ssed

.

- R

ecor

d T

ime

in Q

ueue

of 0

for

t i-

Arr

ival

Tim

e an

d up

date

C

umul

ativ

e.•

Upd

ate

Tim

e-W

eigh

ted

Num

ber

of E

ntiti

es in

Que

ue s

tatis

tic.

-

Rec

ord

valu

e of

0 fo

r

(ti–

t i–

1)N

Qi–

1 a

nd u

pdat

e

C

umul

ativ

e.

• S

tore

cur

rent

cus

tom

er

entit

y’s

Arr

ival

Tim

e in

last

posi

tion

of E

ntity

Attr

ibut

e

Arr

ay to

ref

lect

cus

tom

er

jo

inin

g th

e qu

eue.

• A

dd 1

to N

Qi,

Num

ber

of

E

ntiti

es in

Que

ue.

• U

pdat

e T

ime-

Wei

ghte

d

Num

ber

of E

ntiti

es in

Que

ue

st

atis

tic.

-

Com

pute

val

ue fo

r

(t

i–t i

– 1)

NQ

i– 1

and

upda

te C

umul

ativ

e.

• U

pdat

e E

ntity

Attr

ibut

e A

rray

by

dele

ting

depa

rted

cus

tom

er e

ntity

from

firs

t pos

ition

in th

e ar

ray

and

shift

ing

wai

ting

cust

omer

s up

.•

Sub

trac

t 1 fr

om N

Qi,

Num

ber

of

E

ntiti

es in

Que

ue.

• S

ched

ule

depa

rtur

e ev

ent f

or

cu

stom

er e

ntity

ent

erin

g th

e AT

M

to

occ

ur a

t tim

e t i

+ E

(2.4

).•

Upd

ate

Ent

ities

Pro

cess

ed

thro

ugh

Que

ue s

tatis

tics

to r

efle

ct

cu

stom

er e

nter

ing

ATM

.-

Add

1 to

Tot

al P

roce

ssed

.-

Com

pute

Tim

e in

Que

ue

valu

e fo

r t i

- A

rriv

al T

ime

and

up

date

Cum

ulat

ive.

• U

pdat

e T

ime-

Wei

ghte

d N

umbe

r of

Ent

ities

in Q

ueue

sta

tistic

.

- C

ompu

te v

alue

for

(ti–

t i–

1)N

Qi–

1

an

d up

date

Cum

ulat

ive.

• U

pdat

e E

ntity

Attr

ibut

e

Arr

ay b

y de

letin

g de

part

ed

cu

stom

er e

ntity

from

firs

t

posi

tion

of th

e ar

ray.

• C

hang

e AT

M S

tatu

s ito

Idle

.

Sch

edul

e ar

rival

eve

ntfo

r ne

xt c

usto

mer

ent

ityto

occ

ur a

t tim

e t i

+ E

(3).

FIG

UR

E4.

5D

iscr

ete-

even

t sim

ulat

ion

logi

c di

agra

m fo

r A

TM

sys

tem

.

82




83

TAB

LE

4.1

Man

ual D

iscr

ete-

Eve

nt S

imul

atio

n of

AT

M S

yste

m

Eve

nt C

alen

dar

Pro

cess

ed E

vent

Syst

em S

tate

Stat

isti

cal A

ccum

ulat

ors

Sche

dule

d F

utur

e E

vent

s

Ent

ity

Att

ribu

te

Arr

ay (

Ent

ity

Tim

e-W

eigh

ted

Num

ber,

Arr

ival

E

ntit

ies

Pro

cess

ed

Num

ber

of E

ntit

ies

Tim

e)th

roug

h Q

ueue

in Q

ueue

i 0—

0—

—*(

)0

Idle

0—

0—

0(1

, Arr

ive,

2

.18)

( )

(_, E

nd,

22

.00)

1(1

, Arr

ive,

2.18

)2.

181

Arr

ive

*(1,

2.1

8)

↑B

usy

10

00

0(2

, Arr

ival

, 7

.91)

(_, E

nd,

2

2.00

)(

)(1

, Dep

art,

2.

28)

2(1

, Dep

art,

2.28

)2.

281

Dep

art

*( )

↑Id

le—

—0

—0

(2, A

rriv

e,7.

91)

( )

No

new

eve

nts

(_, E

nd,

22

.00)

3(2

, Arr

ive,

7.

91)

7.91

2A

rriv

e*(

2, 7

.91)

↑B

usy

20

00

0(3

, Arr

ive,

15

.00)

(_, E

nd,

22

.00)

( )

(2, D

epar

t,12

.37)

4(2

, Dep

art,

12.3

7)12

.37

2D

epar

t*(

)↑

Idle

——

0—

0(3

, Arr

ive,

15.0

0)(

)N

o ne

w e

vent

s(_

, End

,

22.0

0)5

(3, A

rriv

e,15

.00)

15.0

03

Arr

ive

*(3,

15.

00)

↑B

usy

30

00

0(4

, Arr

ive,

15

.17)

(_, E

nd,

22.0

0)(

)(3

, Dep

art,

18.2

5)6

(4, A

rriv

e,15

.17)

15.1

74

Arr

ive

*(3,

15.

00)

1↑

——

00

0(5

, Arr

ive,

15

.74)

(3, D

epar

t,18

.25)

(4, 1

5.17

)(_

, End

, 22

.00)

7(5

, A

rriv

e,15

.74)

15.7

45

Arr

ive

*(3,

15.

00)

2↑

——

00.

570.

57(6

, Arr

ive,

18

.75)

(3, D

epar

t,18

.25)

(4, 1

5.17

)(_

, End

,22

.00)

(5, 1

5.74

)8

(3, D

epar

t,18

.25)

18.2

53

Dep

art

*(4,

15.

17)

1↑

43.

083.

085.

025.

59(4

, Dep

art,

20.

50)

(6, A

rriv

e,18

.75)

(5, 1

5.74

)(_

, End

,

22.0

0)9

(6, A

rriv

e,18

.75)

18.7

56

Arr

ive

*(4,

15.

17)

2↑

——

3.08

0.50

6.09

(7, A

rriv

e,

19.8

8)(4

, Dep

art,

20.5

0)(5

, 15.

74)

(_, E

nd,

22.0

0)(6

, 18.

75)

10(7

, Arr

ive,

19.8

8)19

.88

7A

rriv

e*(

4, 1

5.17

)3

↑—

—3.

082.

268.

35(8

, Arr

ive,

22

.53)

(4, D

epar

t,20

.50)

(5, 1

5.74

)(_

, End

, 22

.00)

(6, 1

8.75

)(7

, 19.

88)

11(4

, Dep

art,

20.5

0)20

.50

4D

epar

t*(

5, 1

5.74

)2

↑5

4.76

7.84

1.86

10.2

1(5

, Dep

art,

24.6

2)(_

, End

,

22.0

0)(6

, 18.

75)

(8, A

rriv

e,22

.53)

(7, 1

9.88

)12

(_, E

nd,

22.0

0)22

.00

End

—↑

↑5

—7.

843.

0013

.21

—(8

, Arr

ive,

22.5

3)(5

, Dep

art,

24.6

2)

(Entity Number, Event, Time)

Clock, ti

Entity Number

Event

*Entity Using ATM, array position 1

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

Number of Entities in Queue, NQi

ATM Statusi

Total Processed

Time in Queue,ti–Arrival Time

Cumulative,∑(ti–Arrival Time)

(ti−ti−1)NQi−1

Cumulative,∑(ti−ti−1)NQi−1

(Entity Number, Event, Time)




customer departs, or the simulation ends. Time is the future time that theevent is to occur. The event “(1, Arrive, 2.18)” under the Scheduled FutureEvents column prescribes that the first customer entity is scheduled to arriveat time 2.18 minutes. The arrival time was generated using the equationt0 + E(3.0). To obtain the value returned from the function E(3), we wentto Table 3.2, read the first random variate from the Interarrival Time column(a value of 2.18 minutes), and added it to the current value of the simulationclock, t0 = 0. The simulation is to be terminated after 22 minutes. Note the“(__, End, 22.00)” under the Scheduled Future Events column. For thetermination event, no value is assigned to Entity Number because it is notrelevant.

i = 1, t1 = 2.18. After the initialization step, the list of scheduled futureevents is added to the event calendar in chronological order in preparationfor the next simulation time step i = 1. The simulation clock is fast forwardedto the time that the next event is scheduled to occur, which is t1 = 2.18(the arrival time of the first customer to the ATM queue), and then the eventis processed. Following the simulation logic diagram, arrival events areprocessed by first scheduling the future arrival event for the next customerentity using the equation t1 + E(3.0) = 2.18 + 5.73 = 7.91 minutes. Notethe value of 5.73 returned by the function E(3.0) is the second randomvariate listed under the Interarrival Time column of Table 3.2. This futureevent 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 previoussimulation time step reveals that the ATM is idle (ATM Status0 � “Idle”).Therefore, the arriving customer entity immediately flows through thequeue to the ATM to conduct its transaction. The future departure event ofthis 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 ScheduledFuture Events column, denoting that the first customer entity is scheduled todepart the ATM at time 2.28 minutes. Note that the value of 0.10 returnedby the function E(2.4) is the first random variate listed under the ServiceTime column of Table 3.2. The arriving customer entity’s arrival time isthen stored in the first position of the Entity Attribute Array to signify that itis being served by the ATM. The ATM Status1 is set to “Busy,” and thestatistical accumulators for Entities Processed through Queue are updated.Add 1 to Total Processed and since this entity entered the queue andimmediately advanced to the idle ATM for processing, record zero minutesin the Time in Queue, t1 − Arrival Time, subcolumn and update thisstatistic’s cumulative value. The statistical accumulators for Time-WeightedNumber of Entities in the Queue are updated next. Record zero for(t1 − t0)NQ0 since there were no entities in queue during the previous timestep, NQ0 = 0, and update this statistic’s cumulative value. Note the arrow“↑” entered under the Number of Entities in Queue, NQ1 column. Recallthat the arrow is placed there to signify that the number of entities waitingin the queue has not changed from its previous value.






i = 2, t2 = 2.28. Following the loop back around to the top of the simulationlogic diagram, we place the two new future events onto the event calendarin chronological order in preparation for the next simulation time stepi = 2. The simulation clock is fast forwarded to t2 = 2.28, and thedeparture event for the first customer entity arriving to the system isprocessed. Given that there are no customers in the queue from the previoustime step, NQ1 = 0 (follow the arrows up to get this value), we simplyremove the departed customer from the first position of the Entity AttributeArray and change the status of the ATM to idle, ATM Status2 � “Idle”.The statistical accumulators do not require updating because there are nocustomer entities waiting in the queue or leaving the queue. The dashes (—)entered under the statistical accumulator columns indicate that updates arenot 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 thearrival of the second customer entity to the ATM queue is processed. Complete theprocessing of this event and continue the manual simulation until the terminationevent “(__, End, 22.00)” reaches the top of the event calendar.

As you work through the simulation logic diagram to complete the manualsimulation, you will see that the fourth customer arriving to the system requiresthat you use logic from a different path in the diagram. When the fourth customerentity arrives to the ATM queue, simulation time step i = 6, the ATM is busy(see ATM Status5) processing customer entity 3’s transaction. Therefore, thefourth customer entity joins the queue and waits to use the ATM. (Don’t forgetthat it invoked the creation of the fifth customer’s arrival event.) The fourth en-tity’s arrival time of 15.17 minutes is stored in the last position of the Entity At-tribute Array in keeping with the first-in, first-out (FIFO) rule. The Number ofEntities in Queue, NQ6 , is incremented to 1. Further, the Time-Weighted Numberof Entities in the Queue statistical accumulators are updated by first computing(t6 − t5)NQ5 = (15.17 − 15.00)0 = 0 and then recording the result. Next, thisstatistic’s cumulative value is updated. Customers 5, 6, and 7 also arrive to thesystem finding the ATM busy and therefore take their place in the queue to waitfor the ATM.

The fourth customer waited a total of 3.08 minutes in the queue (see theti − Arrival Time subcolumn) before it gained access to the ATM in time stepi = 8 as the third customer departed. The value of 3.08 minutes in the queue forthe 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 fourthcustomer arrived to the queue, and that the value is stored in the Entity AttributeArray.

At time t12 = 22.00 minutes the simulation terminates and tallies the finalvalues for the statistical accumulators, indicating that a total of five customerentities were processed through the queue. The total amount of time that these five





customers waited in the queue is 7.84 minutes. The final cumulative value forTime-Weighted Number of Entities in the Queue is 13.21 minutes. Note that at theend of the simulation, two customers are in the queue (customers 6 and 7) and oneis at the ATM (customer 5). A few quick observations are worth consideringbefore 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 tofollow. But imagine a system with dozens of processes and dozens of factors in-fluencing behavior such as downtimes, mixed routings, resource contention, andothers. You can see how essential computers are for performing a simulation ofany magnitude. Computers have no difficulty tracking the many relationships andupdating the numerous statistics that are present in most simulations. Equally asimportant, computers are not error prone and can perform millions of instructionsper second with absolute accuracy. We also want to point out that the simulationlogic diagram (Figure 4.5) and Table 4.1 were designed to convey the essence ofwhat happens inside a discrete-event simulation program. When you view a tracereport of a ProModel simulation in Lab Chapter 8 you will see the simularitiesbetween the trace report and Table 4.1. Although the basic process presented issound, its efficiency could be improved. For example, there is no need to keepboth a “scheduled future events” list and an “event calendar.” Instead, futureevents are inserted directly onto the event calendar as they are created. We sepa-rated them to facilitate our describing the flow of information in the discrete-eventframework.

4.4.4 Calculating Results

When a simulation terminates, statistics that summarize the model’s behavior arecalculated and displayed in an output report. Many of the statistics reported in asimulation output report consist of average values, although most software reportsa multitude of statistics including the maximum and minimum values observedduring the simulation. Average values may be either simple averages or timeaverages.

Simple-Average StatisticA simple-average statistic is calculated by dividing the sum of all observation val-ues of a response variable by the number of observations:

Simple average =∑n

i=1 xi

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 specificlocation, 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.





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

Average time in queue =∑5

i=1 xi

5= 0 + 0 + 0 + 3.08 + 4.76

5

= 7.84 minutes

5= 1.57 minutes

The values necessary for computing this average are accumulated under theEntities Processed through Queue columns of the manual simulation table (see thelast row of Table 4.1 for the cumulative value

∑(ti − Arrival Time) = 7.84 and

Total Processed = 5).

Time-Average StatisticA time-average statistic, sometimes called a time-weighted average, reports theaverage value of a response variable weighted by the time duration for eachobserved value of the variable:

Time average =∑n

i=1(Ti xi )

T

where xi denotes the value of the i th observation, Ti denotes the time duration ofthe i th observation (the weighting factor), and T denotes the total duration overwhich the observations were collected. Example time-average statistics includethe 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-weightedresponse variable in ProModel is computed as a time average.

The average number of customer entities waiting in the queue location fortheir 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 themanual 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). Thatis, Ti = ti − ti−1 for i = 1, 2, 3, . . . , 12. The xi denotes the queue’s contents(number of customer entities in the queue) during each Ti time interval. There-fore, xi = NQi−1 for i = 1, 2, 3, . . . , 12 (recall that in Table 4.1, NQi−1 denotesthe number of customer entities in the queue from ti−1 to ti ). The time-average




88

0

01234

1

T1

� 2

.18

Number of customers in queue

T3

� 7

.91

� 2

.28

� 5

.63

T4

� 1

2.37

� 7

.91

� 4

.46

T5

� 2

.63

T8

� 2

.51

T6

� 0

.17

t 0t 1

t 2t 3

t 4t 5

t 6t 7

t 8t 1

1t 1

2

T7

� 0

.57

T12

� 1

.50

23

45

67

89

1011

1213

1415

1617

1819

2021

22

T2

� 0

.1

…

Sim

ulat

ion

time,

T�

22

FIG

UR

E4.

6N

umbe

r of

cus

tom

ers

in th

e qu

eue

duri

ng th

e m

anua

l sim

ulat

ion.





number of customer entities in the queue (let’s call it Average NQ) is

Average NQ =∑12

i=1(Ti xi )

T=

∑12i=1(ti − ti−1)NQi−1

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

22= 0.60 customers

You may recognize that the numerator of this equation (∑12

i=1(ti − ti−1)NQi−1)

calculates the area under the plot of the queue’s contents during the simulation(Figure 4.6). The values necessary for computing this area are accumulated underthe Time-Weighted Number of Entities in Queue column of Table 4.1 (see theCumulative value of 13.21 in the table’s last row).

4.4.5 Issues

Even though this example is a simple and somewhat crude simulation, it providesa 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 canbias 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 withcustomers already in the system. Second, note that we ran the simulation for only22 minutes before calculating the results. Had we ran longer, it is very likely thatthe long-run average time in the queue would have been somewhat different (mostlikely greater) than the time from the short run because the simulation did nothave a chance to reach a steady state.

These are the kinds of issues that should be addressed whenever running asimulation. The modeler must carefully analyze the output and understand the sig-nificance of the results that are given. This example also points to the need forconsidering beforehand just how long a simulation should be run. These issues areaddressed in Chapters 9 and 10.

4.5 Commercial Simulation SoftwareWhile a simulation model may be programmed using any development languagesuch as C++ or Java, most models are built using commercial simulation softwaresuch as ProModel. Commercial simulation software consists of several modulesfor performing different functions during simulation modeling. Typical modulesare shown in Figure 4.7.

4.5.1 Modeling Interface Module

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





entering and editing model information. External files used in the simulation arespecified 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 files that are used as input data, and creates a simula-tion database. This involves data translation and possibly language compilation.This data conversion is performed because the model database and external filesare generally in a format that cannot be used efficiently by the simulation proces-sor during the simulation. Some simulation languages are interpretive, meaningthat the simulation works with the input data the way they were entered. This al-lows 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 createdfor use during simulation, including statistical counters and state variables. Statis-tical counters are used to log statistical information during the simulation such asthe cumulative number of entries into the system or the cumulative activity timeat a workstation.

4.5.3 Simulation Interface Module

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

Modelinginterface

Modelingprocessor

Modeldata

Simulationdata

Simulationprocessor

Simulationprocessor

Outputdata

Outputprocessor

Simulationinterface

Outputinterface

FIGURE 4.7Typical components ofsimulation software.





request snapshot reports, pan or zoom the layout, and so forth. If visual interactivecapability is provided, the user is even permitted to make changes dynamically tomodel variables with immediate visual feedback of the effects of such changes.

The animation speed can be adjusted and animation can even be disabled bythe user during the simulation. When unconstrained, a simulation is capable ofrunning as fast as the computer can process all of the events that occur within thesimulated 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 isnecessary for processing the event logic. This is how simulation is able to run incompressed time. It is also the reason why large models with millions of eventstake so long to simulate. Ironically, in real life activities take time while eventstake no time. In simulation, events take time while activities take no time. To slowdown a simulation, delay loops or system timers are used to create pauses betweenevents. These techniques give the appearance of elapsing time in an animation. Insome applications, it may even be desirable to run a simulation at the same rate asa real clock. These real-time simulations are achieved by synchronizing the simu-lation clock with the computer’s internal system clock. Human-in-the-loop (suchas operator training simulators) and hardware-in-the-loop (testing of new equip-ment and control systems) are examples of real-time simulations.

4.5.4 Simulation Processor

The simulation processor processes the simulated events and updates the statisti-cal accumulators and state variables. A typical simulation processor consists ofthe following basic components:

• Clock variable—a variable used to keep track of the elapsed time duringthe simulation.

• Event calendar—a list of scheduled events arranged chronologicallyaccording to the time at which they are to occur.

• Event dispatch manager—the internal logic used to update the clock andmanage the execution of events as they occur.

• Event logic—algorithms that describe the logic to be executed andstatistics to be gathered when an event occurs.

• Waiting lists—one or more lists (arrays) containing events waiting for aresource or other condition to be satisfied before continuing processing.

• Random number generator—an algorithm for generating one or morestreams of pseudo-random numbers between 0 and 1.

• Random variate generators—routines for generating random variatesfrom specified probability distributions.

4.5.5 Animation Processor

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





displayed during the simulation itself, although some simulation products createan animation file that can be played back at the end of the simulation. In additionto animated figures, dynamic graphs and history plots can be displayed during thesimulation.

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 animationto simple animated flowcharts. Often, the only output from the simulation that is ofinterest 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 inadvance to make the best use of them. While insufficient animation can weakenthe message, excessive use of graphics can distract from the central point to bemade. It is always good to dress up the simulation graphics for the final presenta-tion; however, such embellishments should be deferred at least until after themodel has been debugged.

For most simulations where statistical analysis is required, animation is nosubstitute for the postsimulation summary, which gives a quantitative overview ofthe entire system performance. Basing decisions on the animation alone reflectsshallow thinking and can even result in unwarranted conclusions.

4.5.6 Output Processor

The output processor summarizes the statistical data collected during the simula-tion run and creates an output database. Statistics are reported on such perfor-mance measures as

• Resource utilization.

• Queue sizes.

• Waiting times.

• Processing rates.

In addition to standard output reporting, most simulation software provides theability to write user-specified data out to external files.

4.5.7 Output Interface Module

The output interface module provides a user interface for displaying the outputresults from the simulation. Output results may be displayed in the form of reportsor charts (bar charts, pie charts, or the like). Output data analysis capabilities suchas correlation analysis and confidence interval calculations also are often pro-vided. Some simulation products even point out potential problem areas such asbottlenecks.




4.6 Simulation Using ProModelProModel is a powerful, yet easy-to-use, commercial simulation package that isdesigned to effectively model any discrete-event processing system. It also hascontinuous modeling capabilities for modeling flow in and out of tanks and othervessels. The online tutorial in ProModel describes the building, running, andoutput analysis of simulation models. A brief overview of how ProModel works ispresented here. The labs in this book provide a more detailed, hands-on approachfor actually building and running simulations using ProModel.

4.6.1 Building a Model

A model is defined in ProModel using simple graphical tools, data entry tables,and fill-in-the-blank dialog boxes. In ProModel, a model consists of entities (theitems being processed), locations (the places where processing occurs), resources(agents used to process and move entities), and paths (aisles and pathways alongwhich entities and resources traverse). Dialogs are associated with each of thesemodeling elements for defining operational behavior such as entity arrivals andprocessing logic. Schedules, downtimes, and other attributes can also be definedfor entities, resources, and locations.

Most of the system elements are defined graphically in ProModel (seeFigure 4.8). A graphic representing a location, for example, is placed on the layoutto create a new location in the model (see Figure 4.9). Information about thislocation can then be entered such as its name, capacity, and so on. Default valuesare provided to help simplify this process. Defining objects graphically provides ahighly intuitive and visual approach to model building. The use of graphics isoptional, and a model can even be defined without using any graphics. In additionto graphic objects provided by the modeling software, import capability is avail-able to bring in graphics from other packages. This includes complete facilitylayouts 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 orcompiled to create the simulation database. The animation in ProModel isdisplayed concurrently with the simulation. Animation graphics are classified aseither static or dynamic. Static graphics include walls, aisles, machines, screen text,and others. Static graphics provide the background against which the animation


FIGURE 4.8Sample of ProModelgraphic objects.





takes place. This background might be a CAD layout imported into the model. Thedynamic animation objects that move around on the background during the simu-lation include entities (parts, customers, and so on) and resources (people, forktrucks, 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 statisticson key performance measures. Simulation results are presented in the form of re-ports, plots, histograms, pie charts, and others. Output data analysis capabilitiessuch as confidence interval estimation are provided for more precise analysis.Outputs from multiple replications and multiple scenarios can also be summa-rized and compared. Averaging performance across replications and showingmultiple scenario output side-by-side make the results much easier to interpret.

Summary ReportsSummary 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.

FIGURE 4.9ProModel animation provides useful feedback.





FIGURE 4.10Summary report of simulation activity.

--------------------------------------------------------------------------------General ReportOutput from C:\ProMod4\models\demos\Mfg_cost.mod [Manufacturing Costing Optimization]Date: Feb/27/2003 Time: 06:50:05 PM--------------------------------------------------------------------------------Scenario : Model ParametersReplication : 1 of 1Warmup Time : 5 hrSimulation Time : 15 hr--------------------------------------------------------------------------------

LOCATIONS

AverageLocation Scheduled Total Minutes Average Maximum CurrentName 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 1NC Lathe 2 10 1 57 9.8918 0.939725 1 1Degrease 10 2 114 10.1889 1.9359 2 2Inspect 10 1 113 4.6900 0.883293 1 1Bearing Que 10 100 90 34.5174 5.17762 13 11Loc1 10 5 117 25.6410 5 5 5

RESOURCES

Average Average AverageNumber Minutes Minutes Minutes

Resource Scheduled Of Times Per Travel Travel % BlockedName Units Hours Used Usage To Use To Park In Travel % Util-------- ----- --------- -------- -------- -------- -------- --------- ------CellOp.1 1 10 122 2.7376 0.1038 0.0000 0.00 57.76CellOp.2 1 10 118 2.7265 0.1062 0.0000 0.00 55.71CellOp.3 1 10 115 2.5416 0.1020 0.0000 0.00 50.67CellOp 3 30 355 2.6704 0.1040 0.0000 0.00 54.71

ENTITY ACTIVITY

Average Average Average Average AverageCurrent Minutes Minutes Minutes Minutes Minutes

Entity Total Quantity In Moving Wait for In Blocked Name Exits In System System Res, etc. Operation------- ----- --------- --------- -------- --------- --------- ---------Pallet 19 2 63.1657 0.0000 31.6055 1.0000 30.5602Blank 0 7 - - - - -Cog 79 3 52.5925 0.8492 3.2269 33.5332 14.9831Reject 33 0 49.5600 0.8536 2.4885 33.0656 13.1522Bearing 78 12 42.1855 0.0500 35.5899 0.0000 6.5455





FIGURE 4.11Time-series graphshowing changes inqueue size over time.

FIGURE 4.12Histogram of queuecontents.




Time Series Plots and HistogramsSometimes a summary report is too general to capture the information beingsought. Fluctuations in model behavior over time can be viewed using a timeseries report. In ProModel, time series output data are displayed graphically sothat patterns can be identified easily. Time series plots can show how inventorylevels fluctuate throughout the simulation or how changes in workload affect re-source utilization. Figure 4.11 is a time series graph showing how the length of aqueue fluctuates over time.

Once collected, time series data can be grouped in different ways to show pat-terns or trends. One common way of showing patterns is using a histogram. Thehistogram in Figure 4.12 breaks down contents in a queue to show the percentageof time different quantities were in that queue.

As depicted in Figure 4.12, over 95 percent of the time, there were fewer than12 items in the queue. This is more meaningful than simply knowing what theaverage length of the queue was.

4.7 Languages versus SimulatorsA distinction is frequently made between simulation languages and simulators.Simulation languages are often considered more general purpose and have fewerpredefined constructs for modeling specific types of systems. Simulators, on theother hand, are designed to handle specific problems—for example, a job shop sim-ulator or a clinic simulator. The first simulators that appeared provided little, if any,programming capability, just as the first simulation languages provided few, if any,special modeling constructs to facilitate modeling. Consequently, simulators ac-quired the reputation of being easy to use but inflexible, while simulation languageswere branded as being very flexible but difficult to use (see Figure 4.13).

Over time, the distinction between simulation languages and simulators hasbecome blurred as specialized modeling constructs have been added to general-purpose simulation languages, making them easier to use. During the same period,general programming extensions have been added to simulators, making themmore flexible. The most popular simulation tools today combine powerful industry-specific constructs with flexible programming capabilities, all accessible from anintuitive graphical user interface (Bowden 1998). Some tools are even config-urable, allowing the software to be adapted to specific applications yet still retain-ing programming capability. Rather than put languages and simulators on oppositeends of the same spectrum as though flexibility and ease of use were mutually ex-clusive, it is more appropriate to measure the flexibility and ease of use for allsimulation software along two separate axes (Figure 4.14).


Simulators

Ease of use

Languages

Flexibility

FIGURE 4.13Old paradigm thatpolarized ease of useand flexibility.




4.8 Future of SimulationSimulation products have evolved to provide more than simply stand-alone simu-lation capability. Modern simulation products have open architectures based oncomponent technology and standard data access methods (like SQL) to provideinterfacing capability with other applications such as CAD programs and enter-prise planning tools. Surveys reported annually in Industrial Engineering Solu-tions show that most simulation products have the following features:

• Input data analysis for distribution fitting.

• 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 technolo-gies improve and more time is devoted to the development of the software. Prod-ucts will become easier to use with more intelligence being incorporated into thesoftware itself. Evidence of this trend can already be seen by optimization andother time-saving utilities that are appearing in simulation products. Animationand other graphical visualization techniques will continue to play an importantrole in simulation. As 3-D and other graphic technologies advance, these featureswill also be incorporated into simulation products.


Eas

e o

f u

se

Eas

yH

ard

Low

Flexibility

High

Earlysimulators

Earlylanguages

Current best-of-breedproducts

FIGURE 4.14New paradigm thatviews ease of use andflexibility asindependentcharacteristics.




Simulation products targeted at vertical markets are on the rise. This trend isdriven by efforts to make simulation easier to use and more solution oriented.Specific areas where dedicated simulators have been developed include call cen-ter management, supply chain management, and high-speed processing. At thesame time many simulation applications are becoming more narrowly focused,others are becoming more global and look at the entire enterprise or value chainin 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 hasbeen viewed as a stand-alone, project-based technology. Simulation models werebuilt to support an analysis project, to predict the performance of complexsystems, and to select the best alternative from a few well-defined alternatives.Typically these projects were time-consuming and expensive, and relied heavilyon the expertise of a simulation analyst or consultant. The models produced weregenerally “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 interfacesare making such models more accessible to decision makers. In these flexible sim-ulation models, controlled changes can be made to models throughout the systemlife cycle. This trend is growing to include dynamic links to databases and otherdata sources, enabling entire models actually to be built and run in the backgroundusing data already available from other enterprise applications.

The trend to integrate simulation as an embedded component in enterpriseapplications is part of a larger development of software components that can bedistributed over the Internet. This movement is being fueled by three emerginginformation technologies: (1) component technology that delivers true objectorientation; (2) the Internet or World Wide Web, which connects business com-munities and industries; and (3) Web service technologies such as JZEE andMicrosoft’s .NET (“DOTNET”). These technologies promise to enable paralleland 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 SummaryMost 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 orcondition-triggered, and are therefore processed either chronologically or when asatisfying condition has been met.

Simulation models are generally defined using commercial simulation soft-ware that provides convenient modeling constructs and analysis tools. Simulation





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

4.10 Review Questions1. Give an example of a discrete-change state variable and a continuous-

change state variable.

2. In simulation, the completion of an activity time that is random must beknown at the start of the activity. Why is this necessary?

3. Give an example of an activity whose completion is a scheduled eventand one whose completion is a conditional event.

4. For the first 10 customers processed completely through the ATMspreadsheet simulation presented in Table 3.2 of Chapter 3, construct atable similar to Table 4.1 as you carry out a manual discrete-eventsimulation of the ATM system toa. Compute the average amount of time the first 10 customers spent in

the system. Hint: Add time in system and corresponding cumulativecolumns to the table.

b. Compute the average amount of time the first 10 customers spent inthe queue.

c. Plot the number of customers in the queue over the course of thesimulation and compute the average number of customers in thequeue for the simulation.

d. Compute the utilization of the ATM. Hint: Define a utilizationvariable that is equal to zero when the ATM is idle and is equal to 1when the ATM is busy. At the end of the simulation, compute a time-weighted average of the utilization variable.

5. Identify whether each of the following output statistics would becomputed 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 bemore useful than just seeing an average value.

7. In real life, activities take time and events take no time. During asimulation, activities take no time and events take all of the time.Explain this paradox.





8. What are the main components of simulation software?

9. Look up a simulation product on the Internet or in a trade journal anddescribe two promotional features of the product being advertised.

10. For each of the following simulation applications identify one discrete-and 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 traffic intersection.

ReferencesBowden, Royce. “The Spectrum of Simulation Software.” IIE Solutions, May 1998,

pp. 44–46.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. Instituteof Electric and Electronics Engineers, Piscataway, NJ, 1997. pp. 100–109.

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 ManufacturingSystems.” Industrial Engineering, July 1986, p. 98.

Harrell, Charles R., and Don Hicks. “Simulation Software Component Architecture forSimulation-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. 1717–21.


harrell ghosh bowden cap1

Documents

discreteevent simulation

restaurant simulation

discreteevent simulation

thespreadsheet simulation

simulation languages

acontinuous simulation

typeof simulation

deterministic discreteevent