This preview shows pages 1–8. Sign up to view the full content.
This preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full DocumentThis preview has intentionally blurred sections. Sign up to view the full version.
View Full Document
Unformatted text preview: Introduction to DiscreteEvent Simulation Our purpose here is to introduce the primary discreteevent simulation concepts by using a
singleserver queueing system as an example. For our singleserver queueing system, we assume
that there is inﬁnite capacity in the waiting room, the queue discipline is ﬁrst—come—ﬁrst—serve
(FCFS), the interarrival times are i.i.d. random variables generated from the cumulative
distribution function (c.d.f.) FAL), the service times are i.i.d. random variables generated
from the c.d.f. F3(), and the interarrival and service times are independent. 1. Commonalities of DiscreteEvent Simulation Models
All discrete—event simulation models share a number of important building blocks. The simulation clock — The dynamic nature of most discreteevent simulation models
means that it is necessary to keep track of the simulated time. The variable in a simulation
model that keeps track of the simulated time is called the simulation clock. There are basically two methods for advancing the simulation clock: Fixed—increment
time advance and next—event time advance. Fixed—increment time advance is typically used
in applications of a. continuous nature. For example, the clock may increase in 5—second
increments in a simulation model built for estimating the outcomes of America’s Cup yacht
match races. The ﬁxed—increment time advance may be viewed as a special case of next—event time advance, and so will not be treated in detail. System state ﬂ The ﬁrst step in building a discrete—event simulation model is to deﬁne the
system state. System state isa collection of variables necessary to describe the status of the
system at a particular point in time. In the single—server queue, the number of customers in
the system (queue and service area) is the state variable. However, if there are two servers,
then the state of the system would be the number of customers in the system and which
servers are busy. For the single—server queue, we let X (t) be the number of customers in the system at time t. Events * An event is an instantaneous occurrence that modiﬁes the state of the system.
In the single—server queue, customers arrive to the system, increasing the value of X The
customers complete service and depart from the system, decreasing the value of X So, the set of possible events are {arrival, departure}. (Future) event list i A discrete—event simulation model keeps and updates an event list
that contains the events that will occur in the future. For example, at time t, we may have the event list
(A,t+5). (B,£+7), (0,t+10), which indicates that at time t + 5 event A is scheduled to occur, at time t + 7 event B is
scheduled to occur and at time t + 10 event 0’ is scheduled to occur. There are several approaches to generating the events in an event list. For example, one
could pre—generate the arrival times of all customers and store all the necessary arrival events
in the event list. However, this approach is extremely storage—intensive and time consuming. 75 Instead, What is typically done is that events are generated as needed. This approach
keeps the size of the event list down, reducing memory and computational requirements. In
the singleserver queue, the event corresponding to the arrival of the n + 1—st customer is
generated and added to the event list only when the n—th customer arrives. Timing and eventhandling — Associated with each event in the event list, there is an
occurrence time, which is a time stamp showing when the event is to occur. Clearly, if the
simulation clock shows that the current simulated time is t, then the occurrence time of all
the events in the event list should be greater—than—or—equal to t. The timing routine selects the earliest event in the event list and advances the simulation
clock to the time of this event. The event is then “processed” by the event handler. The
event handler contains the “logic” of the simulation. It updates the system state to reﬂect
the changes induced by the event and (maybe) generates new events. These new events are then added to the event list.
In the single—server queue, when an arrival event occurs,
1. We add one to the number of customers in the system, 2. We generate the next customer arrival event, 3. If the server was previously idle, then the newly arriving customer immediately starts to
receive service and we generate the service completion event for this customer. When a service completion event occurs,
1. We reduce the number of customers in the system by one, 2. If there are other customers in the system, then the ﬁrst customer in the queue immediately
starts to receive service and we schedule the service completion event for this customer. Other components of a simulation model — The above components of a simulation
model are enough to describe the evolution of the system over time. However, there are
several other components that are almost always a part of the simulation. 1. Statistical counters store information about the system performance. For example, we may
maintain a variable that stores the amount of time during which there have been N or more customers in the system. 2. Library routines are used to generate samples of the random variables that define the input
sequences. In the single—server queue, the library routines generate the interarrival and service times. 3. Reporting routines report information at the end of (and maybe during) the simulation
run. For debugging purposes, we may output the nature and time of each event, along with
the system state. For ﬁnal reporting purposes, we may report the statistical counters, along with confidence intervals. 76 2. The Overall Algorithm A general algorithm for discrete—event simulation can be described as follows:  Set the clock to 0.
 Initialize the system state.
I Initialize the event list.
 Initialize the statistical counters.  Determine the imminent event.
' Advance the clock to the imminent
event’s occurrence time. new 1011 [lemmings  Update the system state.
0 Update the statistical counters.
' Generate the future events triggered
by the current event and add them
to the event list. Execute the event Simulation over.  Compute the estimates of
the performance measures.
0 Report the results. 3. Hand Simulation of the SingleServer Queue Recall that our state variable for the single—server queue is X (the number of customers in
the system at time 15). Suppose that there are no customers in the system at time 0. Therefore, the initialization of the simulation entails setting generating the ﬁrst interarrival time from the c.d.f. FA()
A1 = 2 and initializing the event list as (14,?) If we would like to end the simulation at a predeﬁned time point, then we can also schedule
another event to occur at the desired ending time of the simulation. (A, 2) (E,120) Notice that 1. We proceed from event to event, updating the simulation clock.
2. The clock does not always increase by the same amount. 3. The event list, simulation clock (it) and state (X completely determine the future
evolution of the simulation. We never need to look back at past behavior. 4. We made no mention of how the statistics are accumulated. The average number of customers in the system over the time interval (0, T] can be com—
puted by noting X10 U I ["T" E 13'le Emu AVT The integral appearing in this expression can be computed as the simulation proceeds. L (m. i (Tu~17..) XCTH) Em
4 78 where T, is the time of the i—th event. On the other hand, the average time spent in the system by each customer can be com— puted by
\N to Nit) where W(t) is the total time spent in the system by the customers that have departed by
time t and N (t) is the number of customers served by time t. We now need an array that
keeps track of when each customer joins the queue. The single—server queue is a simple discrete—event system. In general, at a particular point
in time, the number of events in the event list could be large. For example, consider an
assembly line where jobs arrive, are processed at a sequence of stations, and ﬁnally, depart
from the end of the assembly line. We need to keep track of the events corresponding to the
next job completion at each station (assuming FCFS) and the next job arrival. If there are d stations, then we may have as many as d + 1 events in the event list. As another example, take the single—server queue with processor—sharing discipline (a good
model of most web servers). Here, we assume that each customer (job) arrives with a given
amount of processing time. The server serves at unit rate, but splits its effort equally amongst
all the jobs that are present. So, if there are k: jobs present, then the work requirement of
each job decreases at rate 1 / it. For this model, we need to keep track of as many events as the
number of jobs in the system (plus one more event for the arrival of the next job). Thus, the
number of events in the event list could be very large. Hence, we need efﬁcient list—managing techniques for the event list. 4. World Views Our discussion so far suggests one approach for implementing a simulation model, namely
that of identifying the relevant events and their effects on the system state and event list. This is only one way to describe a simulation (one “world view”). There are, in fact, three
world views. Each world view corresponds to a different way to think about discrete—event simulation. Event scheduling — This is the world view we have focused on so far. In this approach, we
identify the set of events that can change the system state, and then carefully describe the effect of each event. Process interaction — This is the world view that is used by the user interface of the
modern simulation software. In this view, one specifies the entities in a system, along with
the processes they follow as they go through the system. These processes may include being
delayed at a particular location or waiting for the use of a scarce resource. In general, there
will be many active processes at a given time point in the simulation. For example, in the mm
of the single—server queue, the entitiesare customers. They arrive, possibly queue for service 79 at the server, receive service and depart. Even if the simulation software uses a process interaction world view, there is still an event
list buried within the software. In other words, the software user uses a process interaction
world view when deﬁning the model, but the software converts this description of the model
into an event scheduling world View (see T.J. Schriber and D. T. Brunner, Inside discrete
event simulation software: How it works and why it matters, Proceedings of the 2000 Winter Simulation Conference). ProModel employs a process interaction view. Activity scanning — Here the user builds a simulation model by providing a list of activities
that occur within the simulation. For each activity, a set of conditions is provided that must
hold in order for the activity to take place. The clock is advanced in small steps, each time
checking to see if any of the activities can be performed. For example, in the single server
queue, the activities are to serve a customer and to wait until another customer arrives. 5. Alternative Methods for Simulation Implementation Development of simulation models has beneﬁted greatly from the advent of modern software
engineering methodologies. Parallel and distributed simulation — The execution of the basic event handling simu—
lation algorithm is inherently sequential in the sense that the events have to occur according
to the order of their occurrence times. If we want to speed up this sequential algorithm, one
approach is to implement more efﬁcient event list handling procedures and data structures. Another approach that shows considerable promise is to exploit the processing power on a
collection of linked computers. The idea is that with multiple computers (think of workers),
the simulation algorithm (the job at hand) can be divided, and therefore, be completed in a
shorter period of time. The performance of parallel and distributed simulation largely depends
on the model being simulated. Some models are more easily parallelized than others. For
example, in simulating a supply chain, if the operations of one factory are almost completely
decoupled from those of another (except perhaps during material transfers), then the model might be broken down. Object—oriented simulation e In a small simulation project, it is usually quite straight—
forward to develop and test the model. However, as simulation models get more complex,
the design and implementation become more difﬁcult. One way of managing this difﬁculty is
to use an object—oriented design. In this approach, one speciﬁes a simulation as a collection
of interacting objects. Each object is developed separately. Every object keeps information
about itself and the operations it can perform. For example, in an ambulance simulation, each
ambulance is an object. The necessary information about an ambulance could be its home
base (static information) and its destination (dynamic information). Object—oriented methodology can take a while to learn and can lead to slower model
execution. But, it does have several important advantages over more traditional software development methods. 1. It is relatively easy to reuse objects, because they are speciﬁcally designed to be “self— 80 contained.” 2. The model implementation can be broken down into implementation of each object, so
that multiple programmers can code the model simultaneously. 3. It allows one to break down the complex problem into a collection of smaller and more
easily managed problems. Webbased Simulation e Given the power and appeal of the world—wide—web, researchers
are beginning to investigate how it can be exploited in a simulation context. It is fair to say
that this work is in its infancy and it is not yet clear how it will evolve. 81 A M
I a.) V f...—
.._a mmfg k3 /"\
f\ ,q
31 l 7:
M y H... '_'
U U A
v,
__;'
H:
u._/ /—~.
2}“
,
rd
cr AN“ pm: 33m .a.‘ qu.no.ﬂ
,_ I
3 1m 4
77;; &nmm
33595 IO pd m
aka/plop»;
maxi
TEE/K 82 ...
View
Full
Document
This note was uploaded on 03/08/2012 for the course ORIE 4580 at Cornell University (Engineering School).
 '08
 TOPALOGLU

Click to edit the document details