1. Chapter 3 General Principles Banks, Carson, Nelson & Nicol Discrete-Event System Simulation

2. 2 Concepts in Discrete-Event Simulation System: collection of entities interacting together to accomplish a goal Model: an abstract representation of a system structural / logical / mathematical relationships describe system in terms of state, entities, attributes, processes, events, activities System state: collection of variables to describe a system at any time Entity: object or component in the system Attributes: properties of entities List: collection of entities ordered by first come first serve

3. 3 Concepts in Discrete-Event Simulation (contd) Events: instantaneous occurrence changing the state of a system Event notices: record of events to occur Event lists: list of event notices ordered by time of occurrence FEL: Future Events List Activity: duration of time of specific length e.g. interarrival / service times duration may be deterministic, statistical, a function of system variables and / or entity attributes Delay: duration of time of unspecific length, which is not known until it ends. Eg: customer’s delay in a LIFO waiting line. Clock: variable representing simulated time

4. 4 Concepts in Discrete-Event Simulation (contd) An activity’s duration may be specified in no. of ways :  Deterministic (exactly 5 mins)  Statistical (random draw from among 2, 5, 7 with equal prob)  A function depending on system variables and/or entity attributes (loading time of an iron ore ship – function of ship’s allowed cargo weight and the loading rate in tons) A Delay’s duration may not be specified by the modeler ahead of time. A delay ends when some set of logical conditions become true or an event occurs. A delay is sometimes called a conditional wait, and an activity and unconditional wait. The completion of an activity is a primary event, that is managed by placing an event on the FEL.

5. 5 Example: The A– B Call Center Problem - Components System state -  LQ(t): no of caller waiting for service at time t  LA(t): A is idle/busy at time t (0/1)  LB(t): B is idle/busy at time t (0/1) Entities - Callers and servers need not be represented explicitly. Can be represented in terms of state variables Events - Arrival of a call, service completion by A and service completion by B Activities - interarrival time of calls, service time by A and service time by B (as defined in the tables) Delays - caller’s wait in the queue until A or B is free.

6. 6 Discrete event simulation - modeling over time of a system whose state changes occur at discrete points in time. It produces a sequence of snapshots of system evolving over time A given snapshot includes:  system state at time t  FEL of all the activities in progress  values of cumulative statistics and counters

7. 7 Event Scheduling Event scheduling is a mechanism for advancing simulation time and guaranteeing that all events occur in the correct chronological order based on the FEL. FEL contains all event notices for events that have been scheduled to occur at a future time. Scheduling a future event –  at start of activity  duration determined or as drawn from a statistical distribution.  end-activity event and its time determined all placed on FEL At any given time, FEL contains all previously scheduled future events and their associated event times.

8. 8 Event Scheduling (contd) FEL is ordered by event times, meaning, the events are arranged in the chronological order. i.e., event times satisfy t <= t1 <= t2 <= t3 <= … tn Where t is the clock, t1 is the imminent event i.e., the next event that will occur. After the system snapshot at time clock time t, the clock is advanced to t1. The imminent event is removed from the FEL and the event is executed. Execution of the imminent event means that a new snapshot is taken at time t1. At time t1, if there are any future events, they are scheduled by creating events and placing them at proper positions on the FEL. The process is repeated until the simulation is completed.

9. 9 Event Scheduling (contd) sequence of actions a simulator / program performs to advance the clock and to build a new system snapshot is called the event-scheduling / time-advance algorithm The length an content of FEL is constantly changing as the simulation progresses. Thus the FEL has to be efficiently managed if the software pgm doing the simulation should be efficient. Management of lists (FELs) is called List Processing. Operations of the lists are  Addition of an event to the lists  Deletion of an event from the list  searching the list. (hence chronological ordering of lists is imp.)

10. 10 Event-Scheduling / Time-Advance Algorithm step 1: remove event notice for imminent event from future events list (FEL) step 2: advance CLOCK to imminent event time step 3: execute imminent event: update system state, change entity attributes step 4: generate future events (if necessary) and place the event notices on FEL, ranked by event time step 5: update cumulative statistics and counters

11. 11 Event-Scheduling / Time-Advance Algorithm - Examples Exogenous event – happens outside the system that impinges on the system. Example 1 - Arrival to a queuing system.  Interarrival time is an activity. We generate the next event by adding the IA time to the current time. This method of generating the next time is called bootstrapping.  Bootstrapping is illustrated in fig 3.3 below.

12. 12 Event-Scheduling / Time-Advance Algorithm - Examples Example 2 – service completion event in queuing system.  Service time is also an example of an activity.  When a customer completes service and if the next customer is present, a new service time s* will be generated for the next customer.  The next service completion event is scheduled at t* = t + s*  Service completion is an example of a primary event.  Only primary events occur on the FEL.

13. 13 Event-Scheduling / Time-Advance Algorithm - Examples Example 3 – runtimes and downtimes of a machine subject to breakdowns.  At first a runtime is generated and an end-of-runtime event is scheduled.  Whenever an end-of-runtime event occurs, a downtime will be generated and an end-of-downtime event is scheduled and is placed on the FEL.  When the clock hits end-of-downtime, a runtime event is generated and an end-of-runtime event is placed on the FEL.  In this way runtimes and downtimes alternate through the simulation.  Every simulation must have a stopping event, here called E, which defines how long the simulation will run.

14. 14 World Views When developing a model, a modeler adopts a world view or orientation to develop a model. Most prevalent ones are  event-scheduling world view  process-interaction world view  activity-scanning world view When using the event-scheduling approach, the simulation analyst concentrates on events and their effects on system state. These are illustrated using manual simulations in the next section.

15. 15 World Views Process interaction approach is popular because the analyst can describe the process flow in terms of high-level block or network constructs, while the interaction among processes is handled automatically. Eg is a customer processes shown in fig 3.4 below. Two interacting customer processes in a single-server queue

16. 16 World Views Activity-Scanning World View Concentrate on  Activities of a model  Conditions that allow an activity to begin At each clock advance conditions for all activities are checked. If conditions true, activities started. This approach is simple and leads to modular models that are easily maintained, understood and modified by other analysts at a later time. But repeated scanning results in slow runtime. Mixed approach called three-phase approach was proposed which combines the features of event scheduling with activity approach but keeps the main advantage of the activity scanning approach.

17. 17 Three-phase approach Activities are divided into B and C type of activities B activities = activities that are bound to occur. All primary and events and unconditional activities. C activities = activities that are conditional. B-type activities can be scheduled ahead of time and C- type activities can be scanned after each advance on clock time. Simulation proceeds in 3 phases –  Phase A = remove the imminent event from FEL and execute it  Phase B = Execute all B-type events removed from FEL  Phase C = Scan the conditions that trigger each C-type activities and activate those whose conditions are met. Rescan until no additional C-type activities can begin.

18. 18 Manual Simulation using Event Simulation Example 3.3 Single Channel Queue, Grocery Store with a single checkout counter with stopping time of 60 minutes. System State : LQ(t) = no of customers in the waiting line and LS(t) = no being served (0 or 1) at time t. Events : Arrival(A), Departure(D), Stopping event(E) at 60 Event Notices : (A,t), (D,t) and (E, 60) Activities : interarrival times (table 2.6) and service times (table 2.7) Delay : time spent by the customer in the queue. Simulation tables for the above pbm is given in table 3.1 and 3.2. The effect of arrival event and departure events are shown in more detail in fig 3.5 and 3.6

19. 19 Initial conditions  Begin service at time 0  Take system snapshot at time 0, with LQ(0) = 0 and LS(0) = 1  Departure even for customer 1 and arrival of customer 2 in FEL. Cummulative statistics collected are :-  S = Sum of customer response times for all customers who have departed by the current time.  F = Total number of customers who spend more than 4 or more minutes at the checkout counter.  ND = total number of departures upto the current simulation time. Statistics  Server utilization = Total server busy time (B) / Total Time (T E )  Maximum Queue Length (MQ)

20. 20 a* and s* are the generated interarrival and service times Table 3.1 does not indicated the arrival, service and departure of customers. Table 3.2  has a column called CHECKOUT LINE, which indicates the customers (c1, c2, c3…) who are being serviced and who are in the queue at any point t.  The event notices on the FEL will be expanded to indicate which customer will be affected.

21. 21 Entities = (Ci,t) represents customer Ci arrived at time t Event Notices =  (A, t, Ci) = Arrival of customer Ci at time t  (D, t, Ci) = Departure of customer Ci at time t For a simulation length of 23 minutes,  The avg response time was S/N D = 35/6 = 5.83 minutes  The proportion of customers who spent 5 or more minutes in the system was F/N D = 5/6 = 0.83

22. The Dump-Truck Problem Six dump trucks are used to haul coal from the entrance of a small mine to the railroad. Figure 3.7 provides a schematic of the dump truck operation. Each truck is loaded by one of two loaders. After loading, a truck immediately moves to the scale, to be weighed as soon as possible. Both the loaders and the scale have a first-come, first-serve waiting line (or queue) for trucks. Travel time from a loader to the scale is considered negligible. After being weighed, a truck begins a travel time (during which time the truck unloads) and then afterward returns to the loader queue. The distributions of loading time, weighing time, and travel time are given in Tables 3.3, 3.4, and 3.5, respectively, together with the random digit assignment. The purpose of the simulation is to estimate the loader and scale utilizations (percentage of time busy).

23. The model has the following components : System State : LQ(t) = no of customers in the loader queue L(t) = no of trucks (0,1,2) being loaded. WQ(t) = no of customers in the weighing queue W(t) = no of trucks (0,1,2) being weighed, all at simulation time t. Entities : Six dump trucks (DT1.. DT6) Event Notices :  (ALQ,t,DTi) : Dump truck i arrives at loader queue (ALQ) at time t  (EL,t,DTi) : Dump truck i ends loading (EL) at time t  (EW,t,DTi) : Dump truck i ends weighing (EW) at time t Activities : loading time, weighing time and travel time Delays : Delay at loader queue and weighing queue Lists : Loader queue and Weighing queue

24. B L = total busy time of both the loaders from time to time t B S = Total busy time of the scale from 0 to t Avg loader utilization = (49/2)/76 = 0.32 Avg scale utilization = 76/76 = 1.0

25. 25 List Processing List processing deals with methods for handling lists of entities and the future event list (FEL). Lists are ranked, so they have a head or top, which indicates the top of the list. In simulation, each record represents one entity or one event notice. An entity identifier and its attributes are the fields of an entity record. The event time, event type and other event related data are fields of the event-notice record. Each record has a field that holds the next pointer, which points to the next record on the list.

26. Operations of the lists are  Addition of an record from the top of the list  Addition of an record from any position in the list  Deletion of an record from the top of the list  Deletion of an record from any position in the list  searching the list. (hence chronological ordering of lists is imp.) Most simulation pkgs use dynamically allocated records and pointers to keep track of list items.