Vous êtes sur la page 1sur 31
 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

CHAPTER

4

DISCRETE-EVENT

SIMULATION

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

—Abraham Maslow

4.1 Introduction

Building on the foundation provided by Chapter 3 on how random numbers and

random variates are used to simulate stochastic systems, the focus of this chapter

is on discrete-event simulation, which is the main topic of this book. A discrete-

event simulation is one in which changes in the state of the simulation model

occur at discrete points in time as triggered by events. The events in the automatic teller machine (ATM) simulation example of Chapter 3 that occur at discrete points in time are the arrivals of customers to the ATM queue and the completion

of their transactions at the ATM. However, you will learn in this chapter that the

spreadsheet simulation of the ATM system in Chapter 3 was not technically exe- cuted as a discrete-event simulation. This chapter ﬁrst deﬁnes what a discrete-event simulation is compared to a continuous simulation. Next the chapter summarizes the basic technical issues re- lated to discrete-event simulation to facilitate your understanding of how to effec- tively use the tool. Questions that will be answered include these:

• How does discrete-event simulation work?

• What do commercial simulation software packages provide?

• What are the differences between simulation languages and simulators?

• What is the future of simulation technology?

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

system from Chapter 3 is given to further illustrate what goes on inside this type

of simulation.

71

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

72

Part I

Study Chapters

4.2 Discrete-Event versus Continuous Simulation

Commonly, simulations are classiﬁed according to the following characteristics:

• Static or dynamic

• Stochastic or deterministic

• Discrete-event or continuous

In Chapter 3 we discussed the differences between the ﬁrst two sets of 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 discrete points in time as triggered by events. Typical simulation events might include

• The arrival of an entity to a workstation.

• The failure of a resource.

• The completion of an activity.

• The end of a shift.

State changes in a model occur when some event happens. The state of the model becomes the collective state of all the elements in the model at a particular point in time. State variables in a discrete-event simulation are referred to as discrete- change 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 discrete- event simulation. In continuous simulation, state variables change continuously with respect to time 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 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
1
Time
Start
Event 1
Event 2
Event 3
Simulation
(customer
(customer
(customer
arrives)
arrives)
departs)
 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

FIGURE 4.2

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

Chapter 4
Discrete-Event Simulation
Continuous-change
state variable
Value
Discrete-change
state variable

Time

73

Continuous simulation products use either differential equations or differ- ence equations to deﬁne the rates of change in state variables over time.

4.2.1 Differential Equations

The change that occurs in some continuous-change state variables is expressed in terms of the derivatives of the state variables. Equations involving derivatives of a state variable are referred to as differential equations. The state variable v, for example, might change as a function of both v and time t:

dv(t)

dt

= v 2 (t) + t 2

We then need a second equation to deﬁne the initial condition of v:

v(0) = K

On a computer, numerical integration is used to calculate the change in a particular response variable over time. Numerical integration is performed at the end of successive small time increments referred to as steps. Numerical analysis techniques, such as Runge-Kutta integration, are used to integrate the differential equations numerically for each incremental time step. One or more threshold values for each continuous-change state variable are usually deﬁned that determine when some action is to be triggered, such as shutting off a valve or turning on a pump.

4.2.2 Difference Equations

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

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

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

74

Part I

Study Chapters

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

4.2.3 Combined Continuous and Discrete Simulation

Many simulation software products provide both discrete-event and continuous simulation capabilities. This enables systems that have both discrete-event and continuous characteristics to be modeled, resulting in a hybrid simulation. Most processing systems that have continuous-change state variables also have discrete- change state variables. For example, a truck or tanker arrives at a ﬁll station (a discrete event) and begins ﬁlling a tank (a continuous process). Four basic interactions occur between discrete- and continuous-change variables:

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

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

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

4. An initiation or interruption of change in a continuous variable may occur as the result of a discrete event (the replenishment or depletion of inventory initiates or terminates a continuous change of the continuous variable).

4.3 How Discrete-Event Simulation Works

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

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

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

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

76

FIGURE 4.3

Logic diagram of how discrete-event simulation works.

Part I

Study Chapters

Start

Create simulation database and schedule initial events.

Advance clock to next event time.

 Yes Update statistics and generate output report.

Stop

Termination

event?

No

Process event and

schedule any new

events.

Update statistics,

state variables,

and animation.

Yes

Any conditional

events?

No

event that cannot be satisﬁed 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 deﬁned for it and, in the case of an entity, exits the system. As an object is being processed, any resources that are freed or other entities that might have been cre- ated as byproducts are placed in an action list and are processed one at a time in a similar fashion after the current object reaches a stopping point. To deliberately

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

77

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

4.4 A Manual Discrete-Event Simulation Example

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

4.4.1 Simulation Model Assumptions

We did not list our assumptions for simulating the ATM system back in Chapter 3 although it would have been a good idea to have done so. In any simulation,

FIGURE 4.4

Entity ﬂow diagram for example automatic teller machine (ATM) system.

Arriving customers

(entities)

8

7

6

ATM queue

(FIFO)

5 4

3

ATM server

(resource)

2

Departing

customers

(entities)

1

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

78

Part I

Study Chapters

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 and the ATM is idle.

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

• Customers are processed from the queue on a ﬁrst-in, ﬁrst-out (FIFO) basis.

• The ATM never experiences failures.

4.4.2 Setting Up the Simulation

A discrete-event simulation does not generate all of the events in advance as was

done in the spreadsheet simulation of Chapter 3. Instead the simulation schedules the arrival of customer entities to the ATM queue and the departure of customer entities from the ATM as they occur over time. That is, the simulation calls a

function to obtain an exponentially distributed interarrival time value only when

a new customer entity needs to be scheduled to arrive to the ATM queue. Like-

wise, the simulation calls a function to obtain an exponentially distributed service time value at the ATM only after a customer entity has gained access (entry) to the ATM and the entity’s future departure time from the ATM is needed. An event calendar is maintained to coordinate the processing of the customer arrival and customer departure events. As arrival and departure event times are created, they are placed on the event calendar in chronological order. As these events get processed, state variables (like the contents of a queue) get changed and statistical accumulators (like the cumulative time in the queue) are updated. With this overview, let’s list the structured components needed to conduct the

manual simulation.

Simulation Clock As the simulation transitions from one discrete-event to the next, the simulation

clock is fast forwarded to the time that the next event is scheduled to occur. There

is no need for the clock to tick seconds away until reaching the time at which the

next event in the list is scheduled to occur because nothing will happen that changes the state of the system until the next event occurs. Instead, the simulation clock advances through a series of time steps. Let t i 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 t 0 = 0. Using this nomenclature, t 1 denotes the value

of the simulation clock when the ﬁrst discrete event in the list is processed, t 2 de-

notes the value of the simulation clock when the second discrete-event in the list

is processed, and so on.

Entity Attributes

To capture some statistics about the entities being processed through the system,

a discrete-event simulation maintains an array of entity attribute values. Entity

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

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 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 the Arrival Time attribute. The simulation program computes how long each cus- tomer entity waited in the queue by subtracting the time that the customer entity arrived to the queue from the value of the simulation clock when the customer en- tity gained access to the ATM.

State Variables Two discrete-change state variables are needed to track how the status (state) of the system changes as customer entities arrive in and depart from the ATM system.

• Number of Entities in Queue at time step i, NQ i .

• ATM Status i to denote if the ATM is busy or idle at time step i.

Statistical Accumulators The objective of the example manual simulation is to estimate the expected amount of time customers wait in the queue and the expected number of cus- tomers waiting in the queue. The average time customers wait in queue is a simple average. Computing this requires that we record how many customers passed through the queue and the amount of time each customer waited in the queue. The average number of customers in the queue is a time-weighted average, which is usually called a time average in simulation. Computing this requires that we not only observe the queue’s 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. Here’s 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, t i Arrival Time. Time-average number of customers in the queue.

• For the duration of the last time step, which is t i t i1 , and the number of customer entities in the queue during the last time step, which is NQ i1 , record the product of t i t i1 and NQ i1 . Call the product (t i t i1 )NQ i1 the Time-Weighted Number of Entities in the Queue.

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

80

Part I

Study Chapters

Events There are two types of recurring scheduled events that change the state of the sys- tem: arrival events and departure events. An arrival event occurs when a customer entity arrives to the queue. A departure event occurs when a customer entity com- pletes its transaction at the ATM. Each processing of a customer entity’s arrival to the queue includes scheduling the future arrival of the next customer entity to the ATM queue. Each time an entity gains access to the ATM, its future departure from the system is scheduled based on its expected service time at the ATM. We

actually need a third event to end the simulation. This event is usually called the termination event. To schedule the time at which the next entity arrives to the system, the simu- lation needs to generate an interarrival time and add it to the current simulation clock time, t i . The interarrival time is exponentially distributed with a mean of

3.0 minutes for our example ATM system. Assume that the function E(3.0) re-

turns an exponentially distributed random variate with a mean of 3.0 minutes. The future arrival time of the next customer entity can then be scheduled by using the equation t i + 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 t i + 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, t i , equal to the time at which the event is scheduled to occur, and processing the event.

4.4.3 Running the Simulation

To run the manual simulation, we need a way to generate exponentially distributed

random variates for interarrival times [the function E(3.0)] and service times [the function E(2.4)]. Rather than using our calculators to generate a random number and transform it into an exponentially distributed random variate each time one is needed for the simulation, let’s take advantage of the work we did to build the spreadsheet simulation of the ATM system in Chapter 3. In Table 3.2 of Chapter 3, we generated 25 exponentially distributed interarrival times with a mean of

 3 minutes and 25 exponentially distributed service times with a mean of 2.4 minutes in advance of running the spreadsheet simulation. So when we need a

service time or an interarrival time for our manual simulation, let’s use the values from the Service Time and Interarrival Time columns of Table 3.2 rather than computing them by hand. Note, however, that we do not need to generate all random variates in advance for our manual discrete-event simulation (that’s one of its advantages over spreadsheet simulation). We are just using Table 3.2 to

make our manual simulation a little less tedious, and it will be instructive to

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

81

compare the results of the manual simulation with those produced by the spread- sheet simulation. Notice that Table 3.2 contains a subscript i in the leftmost column. This sub- script denotes the customer entity number as opposed to the simulation time step. We wanted to point this out to avoid any confusion because of the different uses of the subscript. In fact, you can ignore the subscript in Table 3.2 as you pick val- ues from the Service Time and Interarrival Time columns. A discrete-event simulation logic diagram for the ATM system is shown in Figure 4.5 to help us carry out the manual simulation. Table 4.1 presents the re- sults of the manual simulation after processing 12 events using the simulation logic diagram presented in Figure 4.5. The table tracks the creation and schedul- ing of events on the event calendar as well as how the state of the system changes and how the values of the statistical accumulators change as events are processed from the event calendar. Although Table 4.1 is completely ﬁlled in, it was initially blank until the instructions presented in the simulation logic diagram were exe- cuted. As you work through the simulation logic diagram, you should process the information in Table 4.1 from the ﬁrst row down to the last row, one row at a time (completely ﬁlling in a row before going down to the next row). A dash (—) in a cell in Table 4.1 signiﬁes 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 signiﬁes that the simulation logic diagram does not require you to update that cell at the current time step. However, the arrows serve as a re- minder to look up one or more rows above your current position in the table to de- termine the state of the ATM system. Arrows appear under the Number of Entities in Queue, NQ i column, and ATM Status i column. The only exception to the use of dashes or arrows is that we keep a running total in the two Cumulative sub- columns in the table for each time step. Let’s get the manual simulation started.

i = 0, t 0 = 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, t 0 = 0. The system state variables are set to ATM Status 0 “Idle”; Number of Entities in Queue, NQ 0 = 0; and the Entity Attribute Array is cleared. This reﬂects 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 t i Arrival Time, and the other to accumulate the values of the time-weighted number of entities in the queue, (t i t i1 )NQ i1 . Recall that t i Arrival Time is the amount of time that entities, which gained access to the ATM, waited in queue. Both Cumulative variables (t i Arrival Time) and (t i t i1 )NQ i1 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

Harrell−Ghosh−Bowden:
I. Study Chapters
4. Discrete−Event
Simulation Using
ProModel, Second Edition
Simulation
Companies, 2004
Start
i = 0
Initialize variables and schedule initial arrival event and termination event (Scheduled Future Events).
i = i + 1
i = i + 1
Update Event Calendar: Insert Scheduled Future Events in chronological order.
Advance Clock, t i , to the Time of the first event on the calendar and process the event.
i = i + 1
Schedule arrival event
Arrive
Event
Depart
for next customer entity
type?
to occur at time t i + E(3).
End
Update statistics and generate output report.
Any
Yes
Is ATM
No
Yes
No
customers
idle?
in queue?
End
Schedule departure event for
current customer entity entering
ATM to occur at time t i + E(2.4).
Store current customer’s
Arrival Time in first position of
Entity Attribute Array.
Change ATM Status i to Busy.
Update Entities Processed
through Queue statistics to
reflect customer entering ATM.
Record Time in Queue of 0 for
t i - Arrival Time and update
Cumulative.
Update Entity Attribute
Array by deleting departed
customer entity from first
position of the array.
Change ATM Status i to Idle.
Store current customer
entity’s Arrival Time in last
position of Entity Attribute
Array to reflect customer
joining the queue.
Add 1 to NQ i , Number of
Entities in Queue.
Update Time-Weighted
Number of Entities in Queue
statistic.
-
-
Compute value for
(t i – t i – 1 )NQ i – 1 and
update Cumulative.
Update Entity Attribute Array by
deleting departed customer entity
from first position in the array and
shifting waiting customers up.
Subtract 1 from NQ i , Number of
Entities in Queue.
Schedule departure event for
customer entity entering the ATM
to occur at time t i + E(2.4).
Update Entities Processed
through Queue statistics to reflect
customer entering ATM.
-
-
-
Update Time-Weighted Number
of Entities in Queue statistic.
Record value of 0 for
(t i – t i – 1 )NQ i – 1 and update
Cumulative.
Compute Time in Queue
value for t i - Arrival Time and
update Cumulative.
-
Update Time-Weighted Number of
Entities in Queue statistic.
-
Compute
for (t i – t i – 1 )NQ i –1
and
update value
Cumulative.
FIGURE 4.5
Discrete-event simulation logic diagram for ATM system.

82

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event Simulation Using ProModel, Second Edition Simulation © The McGraw−Hill Companies, 2004 Scheduled Future Events 2.18) 22.00) 7.91) 2.28) No new events 15.00) (2, Depart, 12.37) No new events 15.17) 18.25) 15.74) 18.75) (4, Depart, 20.50) 19.88) 22.53) (5, Depart, 24.62) Time)Event,Number,(Entity (1, Arrive, (_, End, (2, Arrival, (1, Depart, (3, Arrive, (4, Arrive, (3, Depart, (5, Arrive, (6, Arrive, (7, Arrive, (8, Arrive, — Time-Weighted of Entities 1−i NQ) 1−i t− i t(∑ 0 0 0 0 0 0 0 0.57 5.59 6.09 8.35 10.21 13.21 in Queue Cumulative, Statistical Accumulators Number 1−i NQ) 1−i t− t( i — 0 — 0 — 0 0 0.57 5.02 0.50 2.26 1.86 3.00 )TimeArrival– i t(∑ 3.08 3.08 3.08 7.84 7.84 Entities Processed through Queue Cumulative, 0 0 0 0 0 0 0 0 TimeArrival– t i — — — — — 3.08 — — 4.76 — Queue,inTime 0 0 0 ProcessedTotal 0 1 — 2 — 3 — — 4 — — 5 5 i StatusATM Idle Busy Idle Busy Idle Busy ↑ ↑ ↑ ↑ ↑ ↑ ↑ i NQQueue,in Manual Discrete-Event Simulation of ATM System TABLE 4.1 System State EntitiesofNumber 0 ↑ ↑ ↑ ↑ ↑ 1 2 1 2 3 2 ↑ Entity Attribute Arrival 3,2,positions Array (Entity arrayQueue, *(1, 2.18) ) ( *(2, 7.91) *(3, 15.00) *(3, 15.00) (4, 15.17) *(3, 15.00) (4, 15.17) (5, 15.74) *(4, 15.17) (5, 15.74) *(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) Time) inWaitingEntities ) ) ) ) ) ) ) ) — Number, ——— *( ( *( ( ( *( ( ( 1positionarray ATM,Using*Entity Processed Event Event — Arrive Depart Arrive Depart Arrive Arrive Arrive Depart Arrive Arrive Depart End NumberEntity — 1 1 2 2 3 4 5 3 6 7 4 tClock, i 0 2.18 2.28 7.91 12.37 15.00 15.17 15.74 18.25 18.75 19.88 20.50 22.00 Event Calendar 2.18) 22.00) 2.28) 7.91) 22.00) 7.91) 22.00) (2, Depart, 12.37) (3, Arrive, 15.00) 22.00) (3, Arrive, 15.00) 22.00) (4, Arrive, 15.17) (3, Depart, 18.25) 22.00) (5, Arrive, 15.74) (3, Depart, 18.25) 22.00) (3, Depart, 18.25) (6, Arrive, 18.75) 22.00) (6, Arrive, 18.75) (4, Depart, 20.50) 22.00) (7, Arrive, 19.88) (4, Depart, 20.50) 22.00) (4, Depart, 20.50) 22.00) 22.53) 22.00) (8, Arrive, 22.53) (5, Depart, 24.62) Time)Event,Number,(Entity — (1, Arrive, (_, End, (1, Depart, (2, Arrive, (_, End, (2, Arrive, (_, End, (_, End, (_, End, (_, End, (_, End, (_, End, (_, End, (_, End, (_, End, (8, Arrive, (_, End, i 0 1 2 3 4 5 6 7 8 9 10 11 12

83

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

84

Part I

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 t 0 + 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, t 0 = 0. The simulation is to be terminated after 22 minutes. Note the

, termination event, no value is assigned to Entity Number because it is not relevant. i = 1, t 1 = 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 t 1 = 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 t 1 + 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 Status 0 “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 t 1 + 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 entity’s 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 Status 1 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, t 1 Arrival Time, subcolumn and update this statistic’s cumulative value. The statistical accumulators for Time-Weighted Number of Entities in the Queue are updated next. Record zero for (t 1 t 0 )NQ 0 since there were no entities in queue during the previous time step, NQ 0 = 0, and update this statistic’s cumulative value. Note the arrow “” entered under the Number of Entities in Queue, NQ 1 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.

End, 22.00)” under the Scheduled Future Events column. For the

“(

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

85

i = 2, t 2 = 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 t 2 = 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, NQ 1 = 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 Status 2 “Idle”. The statistical accumulators do not require updating because there are no customer entities waiting in the queue or leaving the queue. The dashes (—) entered under the statistical accumulator columns indicate that updates are not required. No new future events are scheduled. As before, we follow the loop back to the top of the simulation logic diagram, and place any new events, of which there are none at the end of time step i = 2, onto the event calendar in chronological order in preparation for the next simula-

tion time step i = 3. The simulation clock is fast forwarded to t 3 = 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 “(

, 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 Status 5 ) processing customer entity 3’s transaction. Therefore, the fourth customer entity joins the queue and waits to use the ATM. (Don’t forget that it invoked the creation of the ﬁfth 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 ﬁrst-in, ﬁrst-out (FIFO) rule. The Number of Entities in Queue, NQ 6 , is incremented to 1. Further, the Time-Weighted Number of Entities in the Queue statistical accumulators are updated by ﬁrst computing (t 6 t 5 )NQ 5 = (15.17 15.00)0 = 0 and then recording the result. Next, this statistic’s 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 t i 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 t 8 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 t 12 = 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

End, 22.00)” reaches the top of the event calendar.

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

86

Part I

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 sta- tistics for a simulation output report. This simple and brief (while tedious) manual simulation is relatively easy to follow. But imagine a system with dozens of processes and dozens of factors in- ﬂuencing behavior such as downtimes, mixed routings, resource contention, and others. You can see how essential computers are for performing a simulation of any magnitude. Computers have no difﬁculty 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 efﬁciency could be improved. For example, there is no need to keep both a “scheduled future events” list and an “event calendar.” Instead, future events are inserted directly onto the event calendar as they are created. We sepa- rated them to facilitate our describing the ﬂow of information in the discrete-event framework.

4.4.4 Calculating Results

When a simulation terminates, statistics that summarize the model’s behavior are calculated and displayed in an output report. Many of the statistics reported in a

simulation output report consist of average values, although most software reports

a multitude of statistics including the maximum and minimum values observed

during the simulation. Average values may be either simple averages or time averages.

Simple-Average Statistic

A simple-average statistic is calculated by dividing the sum of all observation val-

ues of a response variable by the number of observations:

Simple average = n

i=1 x i

n

where n is the number of observations and x i 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 speciﬁc location, or the average time per use for a resource. An average of an observation- based response variable in ProModel is computed as a simple average.

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

87

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 x i 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

Average time in queue = 5

5

i=1 x i

= 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 the Entities Processed through Queue columns of the manual simulation table (see the last row of Table 4.1 for the cumulative value (t i 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:

Time average = n

i=1 (T i x i )

T

where x i denotes the value of the i th observation, T i denotes the time duration of the i th observation (the weighting factor), and T denotes the total duration over which the observations were collected. Example time-average statistics include the average number of entities in a system, the average number of entities at a lo- cation, and the average utilization of a resource. An average of a time-weighted response variable in ProModel is computed as a time average. The average number of customer entities waiting in the queue location for their turn on the ATM during the manual simulation is a time-average statistic. Figure 4.6 is a plot of the number of customer entities in the queue during the manual simulation recorded in Table 4.1. The 12 discrete-events manually simu-

lated in Table 4.1 are labeled t 1 , t 2 , t 3 , , t 11 , t 12 on the plot. Recall that t i de-

notes the value of the simulation clock at time step i in Table 4.1, and that its ini- tial value is zero, t 0 = 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 T i denotes the dura-

tion of time step i (distance between adjacent discrete-events in Figure 4.6). That

is, T i = t i t i1 for i = 1, 2, 3, ,

12. The x i denotes the queue’s contents

(number of customer entities in the queue) during each T i time interval. There-

fore, x i = NQ i1 for i = 1, 2, 3, ,

12 (recall that in Table 4.1, NQ i1 denotes

the number of customer entities in the queue from t i1 to t i ). The time-average

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation
queueincustomersofNumber
4
3
2
1
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
T 1 2.18
T 3 7.91 2.28 5.63
T 4 12.37 7.91 4.46
T 5 2.63
T 8 2.51
T 7 0.57
T 12 1.50
T 2 0.1
T 6 0.17
t 0
t 1 t 2
t 3
t 4
t 5 t 6
t 7
t 8
t 11
t 12
Simulation time, T 22
FIGURE 4.6
Number of customers in the queue during the manual simulation.

88

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

89

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

Average NQ =

12

i=1 (T i x i )

=

12

i=1 (t i t i1 )NQ i1

T 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 (

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 under the Time-Weighted Number of Entities in Queue column of Table 4.1 (see the Cumulative value of 13.21 in the table’s last row).

i=1 12 (t i t i1 )NQ i1 )

4.4.5 Issues

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

4.5 Commercial Simulation Software

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

4.5.1 Modeling Interface Module

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

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

90

FIGURE 4.7

Typical components of simulation software.

Part I

Study Chapters

 Modeling Simulation Output interface interface interface Modeling Model Simulation Output Output processor data data data processor Simulation Simulation processor processor

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

4.5.2 Model Processor

When a completed model is run, the model processor takes the model database, and any other external data ﬁles that are used as input data, and creates a simula- tion database. This involves data translation and possibly language compilation. This data conversion is performed because the model database and external ﬁles are generally in a format that cannot be used efﬁciently by the simulation proces- sor during the simulation. Some simulation languages are interpretive, meaning that 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 created for use during simulation, including statistical counters and state variables. Statis- tical counters are used to log statistical information during the simulation such as the cumulative number of entries into the system or the cumulative activity time at a workstation.

4.5.3 Simulation Interface Module

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

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

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 simu- lation clock with the computer’s internal system clock. Human-in-the-loop (such as operator training simulators) and hardware-in-the-loop (testing of new equip- ment and control systems) are examples of real-time simulations.

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 of the following basic components:

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

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

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

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

Waiting lists—one or more lists (arrays) containing events waiting for a resource or other condition to be satisﬁed before continuing processing.

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

Random variate generators—routines for generating random variates from speciﬁed probability distributions.

4.5.5 Animation Processor

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

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

92

Part I

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 rep- resentation of what is happening in the model while the simulation is running. Animation comes in varying degrees of realism from three-dimensional animation to simple animated ﬂowcharts. Often, the only output from the simulation that is of

interest is what is displayed in the animation. This is particularly true when simula- tion is used for facilitating conceptualization or for communication purposes.

A lot can be learned about model behavior by watching the animation (a pic-

ture is worth a thousand words, and an animation is worth a thousand pictures). Animation can be as simple as circles moving from box to box, to detailed, real- istic graphical representations. The strategic use of graphics should be planned in advance to make the best use of them. While insufﬁcient animation can weaken the message, excessive use of graphics can distract from the central point to be made. It is always good to dress up the simulation graphics for the ﬁnal presenta- tion; however, such embellishments should be deferred at least until after the model has been debugged. For most simulations where statistical analysis is required, animation is no substitute for the postsimulation summary, which gives a quantitative overview of the entire system performance. Basing decisions on the animation alone reﬂects shallow 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 the ability to write user-speciﬁed data out to external ﬁles.

4.5.7 Output Interface Module

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

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

4.6 Simulation Using ProModel

93

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

4.6.1 Building a Model

A model is deﬁned in ProModel using simple graphical tools, data entry tables,

and ﬁll-in-the-blank dialog boxes. In ProModel, a model consists of entities (the items being processed), locations (the places where processing occurs), resources (agents used to process and move entities), and paths (aisles and pathways along which entities and resources traverse). Dialogs are associated with each of these modeling elements for deﬁning operational behavior such as entity arrivals and processing logic. Schedules, downtimes, and other attributes can also be deﬁned for entities, resources, and locations. Most of the system elements are deﬁned graphically in ProModel (see

Figure 4.8). A graphic representing a location, for example, is placed on the layout

location can then be entered such as its name, capacity, and so on. Default values

are provided to help simplify this process. Deﬁning objects graphically provides a highly intuitive and visual approach to model building. The use of graphics is optional, and a model can even be deﬁned without using any graphics. In addition

to graphic objects provided by the modeling software, import capability is avail-

able to bring in graphics from other packages. This includes complete facility layouts created using CAD software such as AutoCAD.

4.6.2 Running the Simulation

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

FIGURE 4.8

Sample of ProModel graphic objects.

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

94

Part I

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 simu- lation include entities (parts, customers, and so on) and resources (people, fork trucks, and so forth). Animation also includes dynamically updated counters, indicators, gauges, and graphs that display count, status, and statistical information (see Figure 4.9).

4.6.3 Output Analysis

The output processor in ProModel provides both summary and detailed statistics on key performance measures. Simulation results are presented in the form of re- ports, plots, histograms, pie charts, and others. Output data analysis capabilities such as conﬁdence 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 showing multiple scenario output side-by-side make the results much easier to interpret.

Summary Reports Summary reports show totals, averages, and other overall values of interest. Figure 4.10 shows an output report summary generated from a ProModel simula- tion run.

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

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

95

--------------------------------------------------------------------------------

 Scenario : Model Parameters Replication : 1 of 1 Warmup Time : 5 hr

Simulation Time : 15 hr

--------------------------------------------------------------------------------

 LOCATIONS Average Location Scheduled Total Minutes Average Maximum Current Name Hours Capacity Entries Per Entry Contents Contents Contents

----------- --------- -------- ------- --------- -------- -------- --------

 Receive 10 2 21 57.1428 2 2 2 NC Lathe 1 10 1 57 10.1164 0.961065 1 1 NC Lathe 2 10 1 57 9.8918 0.939725 1 1 Degrease 10 2 114 10.1889 1.9359 2 2 Inspect 10 1 113 4.6900 0.883293 1 1 Bearing Que 10 100 90 34.5174 5.17762 13 11 Loc1 10 5 117 25.6410 5 5 5 RESOURCES Average Average Average Number Minutes Minutes Minutes Resource Scheduled Of Times Per Travel Travel % Blocked Name 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.76 CellOp.2 1 10 118 2.7265 0.1062 0.0000 0.00 55.71 CellOp.3 1 10 115 2.5416 0.1020 0.0000 0.00 50.67 CellOp 3 30 355 2.6704 0.1040 0.0000 0.00 54.71 ENTITY ACTIVITY Average Average Average Average Average Current 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.5602 Blank 0 7 - - - - - Cog 79 3 52.5925 0.8492 3.2269 33.5332 14.9831 Reject 33 0 49.5600 0.8536 2.4885 33.0656 13.1522 Bearing 78 12 42.1855 0.0500 35.5899 0.0000 6.5455
 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation
96
Part I
Study Chapters
FIGURE 4.11
Time-series graph
showing changes in
queue size over time.

FIGURE 4.12

Histogram of queue contents.

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

97

Time Series Plots and Histograms Sometimes a summary report is too general to capture the information being sought. Fluctuations in model behavior over time can be viewed using a time series report. In ProModel, time series output data are displayed graphically so that patterns can be identiﬁed easily. Time series plots can show how inventory levels ﬂuctuate 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 a queue ﬂuctuates 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. The histogram in Figure 4.12 breaks down contents in a queue to show the percentage of time different quantities were in that queue. As depicted in Figure 4.12, over 95 percent of the time, there were fewer than 12 items in the queue. This is more meaningful than simply knowing what the average length of the queue was.

4.7 Languages versus Simulators

A distinction is frequently made between simulation languages and simulators. Simulation languages are often considered more general purpose and have fewer predeﬁned constructs for modeling speciﬁc types of systems. Simulators, on the other hand, are designed to handle speciﬁc problems—for example, a job shop sim- ulator or a clinic simulator. The ﬁrst simulators that appeared provided little, if any, programming capability, just as the ﬁrst simulation languages provided few, if any, special modeling constructs to facilitate modeling. Consequently, simulators ac- quired the reputation of being easy to use but inﬂexible, while simulation languages were branded as being very ﬂexible but difﬁcult to use (see Figure 4.13). Over time, the distinction between simulation languages and simulators has become blurred as specialized modeling constructs have been added to general- purpose simulation languages, making them easier to use. During the same period, general programming extensions have been added to simulators, making them more ﬂexible. The most popular simulation tools today combine powerful industry- speciﬁc constructs with ﬂexible programming capabilities, all accessible from an intuitive graphical user interface (Bowden 1998). Some tools are even conﬁg- urable, allowing the software to be adapted to speciﬁc applications yet still retain- ing programming capability. Rather than put languages and simulators on opposite ends of the same spectrum as though ﬂexibility and ease of use were mutually ex- clusive, it is more appropriate to measure the ﬂexibility and ease of use for all simulation software along two separate axes (Figure 4.14).

FIGURE 4.13

Old paradigm that polarized ease of use and ﬂexibility.

 Simulators Languages Ease of use Flexibility

EasyHard

Ease of use

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation
 98 Part I Study Chapters FIGURE 4.14

New paradigm that views ease of use and ﬂexibility as independent characteristics.

Early

simulators

Low

4.8 Future of Simulation

Current best-of-breed products

Flexibility

Early

languages

High

Simulation products have evolved to provide more than simply stand-alone simu- lation capability. Modern simulation products have open architectures based on component technology and standard data access methods (like SQL) to provide interfacing capability with other applications such as CAD programs and 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 ﬁtting.

• Point-and-click graphical user interface.

• Reusable components and templates.

• Two- (2-D) and three-dimensional (3-D) animation.

• 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 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.

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

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

4.9 Summary

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

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

100

Part I

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 simula- tion is promising and will continue to incorporate exciting new technologies.

4.10 Review Questions

1. Give an example of a discrete-change state variable and a continuous- change state variable.

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

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

4. For the ﬁrst 10 customers processed completely through the ATM spreadsheet simulation presented in Table 3.2 of Chapter 3, construct a table similar to Table 4.1 as you carry out a manual discrete-event simulation of the ATM system to

a. Compute the average amount of time the ﬁrst 10 customers spent in the system. Hint: Add time in system and corresponding cumulative columns to the table.

b. Compute the average amount of time the ﬁrst 10 customers spent in the queue.

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

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

5. Identify whether each of the following output statistics would be computed as a simple or as a time-weighted average value.

a. Average utilization of a resource.

b. Average time entities spend in a queue.

c. Average time entities spend waiting for a resource.

d. Average number of entities waiting for a particular resource.

e. Average repair time for a machine.

6. Give an example of a situation where a time series graph would be more useful than just seeing an average value.

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

 Harrell−Ghosh−Bowden: I. Study Chapters 4. Discrete−Event © The McGraw−Hill Companies, 2004 Simulation Using ProModel, Second Edition Simulation

Chapter 4

Discrete-Event Simulation

101

8. What are the main components of simulation software?

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

10. For each of the following simulation applications identify one 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 trafﬁc intersection.

References

Bowden, 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. Institute of 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 Manufacturing Systems.” Industrial Engineering, July 1986, p. 98. Harrell, Charles R., and Don Hicks. “Simulation Software Component Architecture for Simulation-Based Enterprise Applications.” Proceedings of the 1998 Winter Simula- tion Conference, ed. D. J. Medeiros, E. F. Watson, J. S. Carson, and M. S. Manivannan. Institute of Electrical and Electronics Engineers, Piscataway, New Jersey, 1998, pp. 1717–21.