Discrete-event simulation (DES) is a powerful framework used in modern computer simulation tools, where the system state evolves over time through discrete events that trigger state changes. The simulation operates on an event list, executing events in chronological order, and the state remains constant between events. The document also discusses the general algorithm for DES and illustrates its application through various examples of DES models.
Discrete-event simulation (DES) is a powerful framework used in modern computer simulation tools, where the system state evolves over time through discrete events that trigger state changes. The simulation operates on an event list, executing events in chronological order, and the state remains constant between events. The document also discusses the general algorithm for DES and illustrates its application through various examples of DES models.
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