ELEMENTS OF DISCRETE EVENT SIMULATION

2.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 occur- rence time. When that procedure is run, we say that the event is processed or executed.

12 Discrete Event Simulation Event 1

Event List Head Time: 7.25 Event 2

Time: 11.2 Event 3 Time: 22.13

Event 4 Time: 22.11

Other fields Event List Tail

Figure 2.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 2.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 comple- tion” 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

Discrete Event Simulation 13 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.)