Jump to content
  • 0

Discrete Event Simulation

Go to solution Solved by Sourabh Nandi,

Discrete Event Simulation (DES) models the operation of a system as a (discrete) sequence of events in time. Each event occurs at a particular instant in time and it marks a change in the state. It is assumed that there is no change in the system between consecutive events. It is commonly used to simulate real life events or systems.


An application-oriented question on the topic along with responses can be seen below. The best answer was provided by Sourabh Nandi on 2nd Jan 2021.


Q 327. What is discrete event simulation? Explain its applications. How does a discrete event simulation reach the steady state distribution that it is supposed to represent?


Note for website visitors - Two questions are asked every week on this platform. One on Tuesday and the other on Friday.

Link to post
Share on other sites

3 answers to this question

Recommended Posts

  • 0
  • Solution


Business processes are commonly modeled as computer-based, dynamic, stochastic, and discrete simulation models. The most popular way to represent these models within the computer is using Discrete-Event Simulation (DES). In simplistic terms, DES defines how a system with discrete flow units or jobs evolves. Technically, this implies that the computer tracks how and when state variables such as queue lengths and resource availabilities improve over time—the state-variables change due to an event (or discrete event) occurring in the system. A characteristic is that discrete-event models focus only on the time cases when these discrete events occur. This feature allows for vital time compression because it makes it possible to skip through all time segments within events when the system's state remains unchanged. Therefore, the computer can simulate many situations epistolizing to a long real-time span in a short period.


To demonstrate the mechanics of a DES model, consider an information desk within an individual server. Suppose that the objective of the simulation is to evaluate the typical delay of a customer. This simulation then must have the following state variables.

  • The status of the server (active or idle).
  • The number of shoppers in the queue.
  • Time of arrival of each shopper in the queue.

While the simulation runs, two events can change these state variables' value: the arrival of a customer or service completion.


A customer's approach either changes the server's status from idle to busy or increases the number of customers in the queue. On the other hand, the completion of service either changes the server's status from active to idle or minimizes the number of customers in the line.


However, the state variables evolve when an event occurs. A discrete-event simulation model analyzes the system's dynamics from one event to the next. The simulation prompts the "simulation clock" from one event to the next and considers that the system does not improve in any way between two consecutive events. 

For example, suppose a single customer is waiting in line at a grocery store. The subsequent event is the completion of service of the consumer who is currently paying for his groceries. In that case, the discrete-event simulation does not keep track of how the consumer in the line spends the waiting time. Hence, the simulation keeps track of when each event occurs but assumes that nothing occurs during the elapsed time between two consecutive events. 


The below figure reviews the steps associated with a discrete-event simulation. The simulation begins with initializing the current state of the system and an event list. The primary state of the system, for example, might include some jobs in multiple queues as specified by the analyst. It also could determine the availability of some resources in the process. The most apparent initial state is to consider that no jobs are in the process and that all supplies are currently available. The event list shows the time when the next event will occur. For instance, the event list initially might incorporate the time of the first arrival to the process. Other events might be scheduled originally, as defined by the analyst.


Once the initialization move is completed, the clock is advanced to the next phase in the event list. The next event is then performed. The execution of an event triggers three activities. First, the current state of the system is changed. For instance, the executed event might be a job landing in the process. If all the servers are occupied, then the state change consists of adding the arriving job to a queue. Other state changes might expect deleting a job from a queue or making a server occupied. 



FIGURE: Discrete-Event Simulation [Source: Business Process Modeling, Simulation, and Design by Manuel Laguna] 


The execution of an event might induce the cancellation of other events. For instance, if the completed event consists of a machine breakdown, this event forces removing the processing of jobs waiting for the machine. Ultimately, the execution of an event may prompt the scheduling of future events. For instance, if a job arrives and is added to a queue, a future event is also added to the event list, indicating that the job will commence processing.


During an event is executed, the event is eliminated from the event list. Then the termination rule is checked. If the rule indicates that the end of the simulation has been reached, then raw data & summary statistics are available to the analyst. However, if the termination rule indicates that the simulation has not finished (for instance, because more events remain in the event list), the clock is moved ahead to the next event.

Link to post
Share on other sites
This topic is now closed to further replies.
  • Create New...