Discrete Event Simulation

The majority of modern computer simulation tools (simulators) implement a

paradigm, called discrete-event simulation (DES). This paradigm is so general and
powerful that it provides an implementation framework for most simulation languages,
regardless of the user worldview supported by them. Because this paradigm is so
pervasive, we will review and explain in this session its working in some detail.

1. ELEMENTS OF DISCRETE EVENT SIMULATION

In the DES paradigm, the simulation model possesses a state S (possibly vector valued)
at any point in time. A system state is a set of data that captures the salient variables of
the system and allows us to describe system evolution over time. In a computer
simulation program, the state is stored in one or more program variables that represent
various data structures (e.g., the number of customers in a queue, or their exact sequence
in the queue). Thus, the state can be defined in various ways, depending on particular
modeling needs, and the requisite level of detail is incorporated into the model. As an
example, consider a machine, fed by a raw-material storage of jobs. A “coarse” state of
the system is the number jobs in the storage; note, however, that this state definition does
not permit the computation of waiting times, because the identity of individual jobs is
not maintained. On the other hand, the more “refined” state consisting of customer
identities in a queue and associated data (such as customer arrival times) does permit the
computation of waiting times. In practice, the state definition of a system should be
determined based on its modeling needs, particularly the statistics to be computed.
The state trajectory over time, S(t), is abstracted as a step function, whose jumps
(discontinuities) are triggered by discrete events, which induce state transactions
(changes in the system state) at particular points in time. Although computer
implementation of events varies among DES simulators, they are all conceptually similar:
An event is a data structure that always has a field containing its time of occurrence, and
any number of other fields. Furthermore, the “occurrence” of an event in a DES simulator
is implemented as the execution of a corresponding procedure (computer code) at the
scheduled event occurrence time. When that procedure is run, we say that the event is
processed or executed.
Event List Head
Event 1
Time: 7.25
Event 2
Time: 11.2
Event 3
Time: 22.13
Event 4
Time: 22.11
Event List Tail
Other fields

Figure 1 Structure of a DES event list.

The evolution of any DES model is governed by a clock and a chronologically ordered
event list. That is, events are linked in the event list according to their scheduled order of
occurrence (Figure 1). The event at the head of the list is called the most imminent event
for obvious reasons. Scheduling an event means that the event is linked chronologically
into the event list. The occurrence of an event means that the event is unlinked from the
event list and executed. The execution of an event can change state variables and possibly
schedule other events in the event list.
An essential feature of the DES paradigm is that “nothing” changes the state unless an
event occurs, at which point the model typically undergoes a state transition. More
precisely, every event execution can change the state (although on rare occasions the state
remains intact), but every state change is effected by some event. Between events, the
state of the DES is considered constant, even though the system is engaged in some
activity. For example, consider a machine on the factory floor that packages beer cans
into six-packs, such that the next six-pack is loaded for processing only when the previous
one has been completely processed. Suppose that the state tracks the number of six-packs
waiting to be processed at any given time. Then during the processing time of a six-pack,
the DES state remains unchanged, even though the machine may, in fact, be processing
six beer cans individually. The DES state will only be updated when the entire six-pack
is processed; this state change will be triggered by a “six-pack completion” event. Note
again that the definition of the state is up to the modeler, and that models can be refined
by adding new types of events that introduce additional types of state transitions.
At the highest level of generalization, a DES simulator executes the following
algorithm:
1. Set the simulation clock to an initial time (usually 0), and then generate one or more
initial events and schedule them.
2. If the event list is empty, terminate the simulation run. Otherwise, find the most
imminent event and unlink it from the event list.
3. Advance the simulation clock to the time of the most imminent event, and execute it
(the event may stop the simulation).
4. Loop back to Step 2.
This beguilingly simple algorithm (essentially an infinite loop) is extremely general. Its
complexity is hidden in the routines that implement event execution and the data
structures used by them. The power and versatility of the DES simulation algorithm stem
from the fact that the DES paradigm naturally scales to collections of interacting
subsystems: one can build hierarchies of increasingly complex systems from subsystem
components. In addition, the processing of any event can be as intricate as desired. Thus,
both large systems as well as complex ones can be represented in the DES paradigm. (For
more details, see Fishman 1973, Banks et al. 1999, and Law and Kelton 2000.)
2. EXAMPLES OF DES MODELS
In this section the power and generality of DES models are illustrated through several
examples of elementary systems. The examples illustrate how progressively complex
DES models can be constructed from simpler ones, either by introducing new modeling
wrinkles that increase component complexity, or by adding components to create larger
DES models.
2.1. SINGLE MACHINE

2.2. SINGLE MACHINE WITH FAILURES

 Figure 3 A single FIFO machine with failures.

2.3. SINGLE MACHINE WITH AN INSPECTION STATION AND ASSOCIATED

INVENTORY
3. MONTE CARLO SAMPLING AND HISTORIES
3.1. EXAMPLE: WORK STATION SUBJECT TO FAILURES AND INVENTORY
CONTROL
Sample History
Sample Statistics