A Quick Beginner's Guide to Discete-Event Simulation
Author: Descreye Solutions
What is discrete-event simulation?
Discrete-event simulation is a model of a system where all changes to the system happen at timed events. It can usually be used to represent systems where distinct products, people, or entities move through the system experiencing defined delays (usually in the form of processes).
Why use discrete-event simulation?
Discrete-event simulation is usually used in systems that have some form of variability in the defined delays that the entities (products, people, etc.) experience. This variability can be represented in the simulation model and then the effects can be observed. Often simulations are used to determine how a change to the current system would affect various processes without the need to physically implement the change. This is usually done by creating a current state, or baseline, simulation model and then making the desired changes and observing the effect that occurs when the new model is run.
How does a discrete-event simulator work?
In the most basic terms a discrete-event simulator consists of a log of events that will occur and a current time that the model is at. The log consists of a time that the event will occur and then information that tells the model what to do at that time. The simulator starts with the next event in the log and performs the action that it suggests. That action often adds additional future events to the event log. Once the event has been processed the simulator moves to the next time event in the log. By doing this the simulator does not need to model each second of the system, because it is inherent that nothing occurs in the system between events. This makes it possible to run the simulation at much faster than real-time.
What is the process for simulating?
To simulate a system, the following steps are taken: data gathering, model building, model validation, and experimenting.
The first step in creating a simulation is gathering the data that will define the system in the simulation.
Types of data
The first information that is needed to build a system simulation is system flow data. This is usually done by creating a process flow chart diagram to show how the entities move through the system. In defining the process flow it is important to define any decisions that are made in the flow, as these will also need to be input into the simulation.
Once the system flow is defined it is necessary to define each step in that flow. The first thing that needs to be defined is often referred to as arrivals. This means it is necessary to define how often entities enter the system for every start object in the process flow diagram. Once this is done it is necessary to define how many objects at a time can be in each step in the system. This is often referred to as content. Then it is necessary to define how long each process step takes in the system. Inevitable some steps merely wait for availability. These steps are called buffers or queues and do not require a defined process length, as they are merely waiting for availability. If any of the steps split or combine entities the amount that they do this also needs to be noted.
This is some of the basic data that is needed for simulating a model. However, the goals of your model often define the type of information that is needed. Additionally, some simulation packages would require additional information to be gathered in order to build a model.
Inevitably processes in the system do not always take the same amount of time. For instance, we could, on average, get an order that needs to be processed every 10 min. But in reality we might get an order, 5 minutes later another order, and then 15 minutes later another order, etc. This variability would not be captured if we merely used the average to define the system. Additionally, discrete-event simulation can replicate this variability and show how it affects the rest of the system.
In discrete-event simulation this variability is replicated by using a statistical distribution. Many people are familiar with a normal distribution, or bell-curve. This is one of dozens of distributions that can be used to define the variability in a process. Other distributions can be seen in this image of various statistical distributions. A simulation uses these statistical distributions by sampling from them to get random numbers.
For instance, one statistical distribution is the uniform distribution. You are likely more familiar with this one than you think. Whenever someone says, “Pick a number between 1 and 10,” that could be interpreted in statistical talk as, “Sample a number from the uniform distribution defined with a minimum of 1 and a maximum of 10.” They are essentially asking you to sample for a statistical distribution. The same thing occurs when simulations are running with defined sampling distributions. They are randomly choosing a number that is from the defined statistical distribution.
With the dozens of statistical distributions to choose from it would be difficult to know which one fits the data for a given process. Fortunately, most simulation software packages have a tool that does the complex math for you. These tools do distribution fitting. Basically you give the tool the raw data from a group of samples of the process, like in our example above 10, 5, and 15, and then the tool suggests a distribution to use in your simulation. OPS has a slightly different distribution fitting tool. It allows the user to put in the raw data. The simulation then fits the data to the histogramic-6 distribution. Whichever way the tool fits the data to a distribution, distribution fitting makes it possible to include the randomness inherent in the system in the simulation model.
Once the data is gathered, the next step is using the simulation software to build the model. Simulation software may differ on the way that a model is built, but usually the following steps are used.
Creating system steps
The first thing that is done is to translate the system flow data that was gathered into the simulation. This is usually done by adding the various steps to the simulation. Often simulation software has objects that can help to define steps. In OPS, these objects are start, end, process, buffer, split, and merge. These objects are used to define some basic characteristics of the process step. For instance, if the step is a buffer, then it will have no processing time, because it is merely waiting for the next step to have capacity for any entity it contains.
Once all the steps have been added to the model, the steps are then connected to show how the entities flow through the steps. Finally, the decisions are defined in the model. Depending on the software the decisions could be defined in the step where the decision is made or by creating a separate object that represents the decision.
Defining system steps
Once the system steps are added and the flow is defined it is necessary to add the defining characteristics of each step. This includes the information regarding the maximum number of objects that can be in each step at each time, or content. It also includes adding the processing time, or fitted statistical distribution, to represent the amount of time an entity is delayed in the step. Other information is also sometimes defined like the split or merge amount, or other characteristics that are specific to certain types of system steps.
Once the model is built it is important to validate that it is an accurate representation of the system that it is replicating. This is done by running the model and making sure that the output is expected. Additionally, it is important to validate that changes to aspects of the model would have a similar effect if the changes were made in the real-world system. There are many ways to do model validation, and often the depth of model validation depends on the accuracy required for gaining the desired insight.
When the model has been created and validated, it is then appropriate to test scenarios in the model. The model was likely created to gain insight into the system. This can be done by running experiments. Experiments would change certain values in the model, and then record the output data for each scenario. If statistical distributions are used to get random numbers, then it is important to run multiple replications of each scenario. This is necessary, because we usually want to see the range of performance of the system, and not just one random day’s performance. Once multiple replications of the simulation are run for each scenario it is possible to observe how changes will affect the system.
Creating simulation models can be difficult. Many people have spent hours creating models only to scrap them because they weren't getting any useful insight from them. The following 4 mistakes are common for people when they start creating simulation models. Avoiding them is an important part of becoming an experienced discrete-event simulation modeler.
Wikipedia Discrete Event Simulation
Wikipedia list of discrete event simulation software
Wikipedia sampling distribution
Wikipedia probability distribution fitting
← Back to blog