Lecture 30: Discrete Event Simulation#
Note
In this lecture, we will establish the foundations of Discrete Event Simulation by understanding the central concepts of state and event through examples from everday life including those from civil engineering and more specifically, transportation engineering. In addition, this lecture will also establish the mechanisms of Discrete Event Simulation, describing the
Introduction#
Discrete-event simulation models how a system evolves over time by representing changes in its state at distinct, separate points known as events. Note, the state of a system refers to the collection of variables needed to describe the system at a given moment, while an event is defined as an instantaneous occurrence that may alter the state of the system.
Examples#
Bank Teller: Consider a bank with a single teller. Customers arrive at random times, wait in line if the teller is busy, eventually served one at a time.
System State: number of customers in the bank and whether the teller is busy or idle
Events: customer arrival, start of service, and completion of service
Dynamics: when a customer arrives (event), the queue length increases (system state); when customer service being (event), the queue length decreases and the teller becomes busy (system state); when a customer is served (event), the teller becomes free (system state), allowing next customer to be served
Construction Site: Consider the operations of a concrete mixer truck supplying concrete for a building project. The truck arrives at the site, waits if the pump or crew is busy, and unloads when ready.
System State: number of mixer trucks waiting on-site, whether the pump/crew is busy or free, and the unloading status of the current truck
Events: arrival of a truck, start of unloading, and completion of unloading
Dynamics: when a truck arrives (event), the queue length increases (system state); when unloading begins (event), the queue length decreases and the pump/crew becomes busy (system state); when unloading is completed (event), the pump/crew becomes free (system state), allowing the next truck to be served
Highway Toll Plaza: Consider the operations of a toll plaza. Vehicles arrive at random times, wait in the line if the booth is busy, eventually served one at a time (per booth)
System State: availability of booth and number of vehiclls in queue of each booth
Events: vehicle arrival, start of toll payment, and completion of toll payment
Dynamics: when a vehicle arrives (event), the queue length increases (system state); when toll payment begins (event), the queue length decreases and the booth becomes busy (system state); when toll payment is completed (event), the booth becomes free (system state), allowing the next vehicle in line to be served
Simulation Mechanism#
Due to the dynamic nature of discrete-event simulation models, we must keep track of the current value of simulated time as the simulation proceeds, and we also need a mechanism to advance simulated time from one value to another. We call the variable in a simulation model that gives the current value of simulated time the simulation clock. Note, there is generally no relationship between simulated time and the time needed to run a simulation on the computer.
Historically, two principal approaches have been suggested for advancing the simulation clock: next-event timing routine and fixed-increment timing routine.
With the next-event time-advance approach, the simulation clock is initialized to zero and the times of occurrence of future events are determined. The simulation clock is then advanced to the time of occurrence of the most imminent (first) of these future events, at which point the state of the system is updated to account for the fact that an event has occurred, and our knowledge of the times of occurrence of future events is also updated. Then the simulation clock is advanced to the time of the (new) most imminent event, the state of the system is updated, and future event times are determined, etc. This process of advancing the simulation clock from one event time to another is continued until eventually some prespecified stopping condition is satisfied. Since all state changes occur only at event times for a discrete-event simulation model, periods of inactivity are skipped over by jumping the clock from event time to event time.
Alternatively, fixed-increment timing routine does not skip over these inactive periods. Instead, the simulation clock is advanced in fixed increments of time (say, one second, one minute, or one hour, depending on the application), and at each clock tick the model checks whether any events occur during that interval. If so, the event is processed; if not, the simulation clock still moves forward. While this approach is simpler to implement conceptually, it can consume substantial computer time if increments are small and many periods of inactivity are checked unnecessarily.
All Discrete Event Simulation models share the following components, logically organized as follows:
System State: the collection of state variables necessary to describe the system at a particular time
Simulation Clock: a variable giving the current value of simulated time
Event List: a list containing the next time when each type of event will occur (for next-event timing routine)
Event Check: at each clock tick, the system is checked to determine whether any events occur within the current interval (for fixed-increment timing routine)
Statistical Counters: variables used for storing statistical information about system performance
Initialization Routine: a subprogram to initialize the simulation model at time 0
Timing Routine: a subprogram that determines the next event from the event list and then advances the simulation clock to the time when that event is to occur (for next-event timing routine); a subprogram that that advances the simulation clock by Δt and invokes the event check (for fixed-increment timing routine)
Event Routine: a subprogram that updates the system state when a particular type of event occurs (there is one event routine for each event type)
Library Routines: a set of subprograms used to generate random observations from probability distributions that were determined as part of the simulation model
Report Generator: a subprogram that computes estimates (from the statistical counters) of the desired measures of performance and produces a report when the simulation ends
Main program: a subprogram that invokes the timing routine to determine the next event and then transfers control to the corresponding event routine to update the system state appropriately. The main program may also check for termination and invoke the report generator when the simulation is over.
This organization allows robust programming, easy debugging, and future proofing to changes in the simulation model.
Note
In the next lecture, we will explore single-server queueing systems to understand how discrete event simulation can be applied to model waiting lines. We will study how customers arrive, wait if the server is busy, and receive service one at a time. This will allow us to connect the abstract concepts of system state, events, and simulation mechanism to a practical queueing framework that forms the foundation for many real-world applications in transportation, logistics, and service systems.