20111101_190721 - Introduction to Discrete-Event Simulation...

Info iconThis preview shows pages 1–8. Sign up to view the full content.

View Full Document Right Arrow Icon
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 2
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 4
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 6
Background image of page 7

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
Background image of page 8
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Introduction to Discrete-Event Simulation Our purpose here is to introduce the primary discrete-event simulation concepts by using a single-server queueing system as an example. For our single-server queueing system, we assume that there is infinite capacity in the waiting room, the queue discipline is first—come—first—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 Discrete-Event Simulation Models All discrete—event simulation models share a number of important building blocks. The simulation clock — The dynamic nature of most discrete-event 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 fixed—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 fl The first step in building a discrete—event simulation model is to define 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 modifies 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 single-server 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 event-handling — 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 reflect 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 first 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 final 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 Single-Server 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 first 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 predefined 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 finally, 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 efficient 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 defining 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 benefited 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 efficient 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 difficult. One way of managing this difficulty is to use an object—oriented design. In this approach, one specifies 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 specifically 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. Web-based 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 c-r AN“ pm: 33m .a.‘ qu.no.fl ,_ 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).

Page1 / 8

20111101_190721 - Introduction to Discrete-Event Simulation...

This preview shows document pages 1 - 8. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online