Discrete-Event System Simulation — Arena / AnyLogic Style
Also known as: DES, discrete event simulation, Kesikli Sistem Simülasyonu (Arena / AnyLogic tarzı)
Discrete-event system simulation (DES) is a computational modelling technique in which the state of a system changes only at discrete points in time — called events — such as a customer arriving, a machine starting, or a job completing. Formalised through foundational texts by Kelton, Sadowski, and Zupick (2014) and Law (2015), DES represents processes as networks of resources, queues, and activities, allowing analysts to test capacity and policy changes on a virtual model before touching the real system.
Key highlights
- Captures the stochastic, time-dependent dynamics of complex real-world processes that analytical queuing formulas cannot handle.
- Allows risk-free what-if experimentation — staffing levels, layout changes, or policy rules can be tested on the model without disrupting the live system.
- Scales from small single-station models to enterprise-wide supply chains, and handles arbitrary routing logic, priorities, and breakdowns.
- Output confidence intervals from replications give decision-makers a probabilistic view of performance, not just a single-point estimate.
Intuition
This section is available to Pro members. Upgrade to Pro
How it works
This section is available to Pro members. Upgrade to Pro
When to use it
Discrete-event simulation is appropriate when a system's behaviour is driven by discrete, asynchronous events — arrivals, completions, failures — rather than by continuously evolving equations. It suits capacity planning, bottleneck identification, and what-if scenario analysis for manufacturing lines, service counters, hospital wards, and supply chains. The method requires a complete process map with well-defined resources and routing rules, and enough historical data to fit arrival and service-time distributions. It imposes no sample-size floor, but poorly specified process maps or poorly fitted distributions will yield misleading results regardless of run length.
Strengths & limitations
- Captures the stochastic, time-dependent dynamics of complex real-world processes that analytical queuing formulas cannot handle.
- Allows risk-free what-if experimentation — staffing levels, layout changes, or policy rules can be tested on the model without disrupting the live system.
- Scales from small single-station models to enterprise-wide supply chains, and handles arbitrary routing logic, priorities, and breakdowns.
- Output confidence intervals from replications give decision-makers a probabilistic view of performance, not just a single-point estimate.
- Building and validating a credible model requires detailed process knowledge and sufficient historical data for distribution fitting.
- Simulation results are stochastic estimates, not exact answers; adequate replication counts and warm-up periods are needed for valid inference.
- The method describes how a system performs under given assumptions but does not directly optimise those assumptions — optimisation requires coupling the simulation with a search algorithm.
- Large, high-fidelity models can be computationally expensive to run for long simulation horizons or extensive scenario sets.
Common pitfalls
This section is available to Pro members. Upgrade to Pro
Applications
This section is available to Pro members. Upgrade to Pro
Frequently asked
How many replications do I need?
The required number depends on the variance of the output metric and the precision you need. A common approach is to run a pilot of 10–20 replications, estimate the variance, and then calculate the additional replications needed to achieve a target confidence-interval half-width. For most practical studies, 30–100 replications are sufficient, but high-variance outputs or tight precision requirements may demand more.
How long should the warm-up period be?
The warm-up period must be long enough for the system to reach its typical operating state before statistics are collected. A practical approach is to plot a running mean of a key output (e.g., queue length) over time across pilot replications and identify where it stabilises. Welch's graphical method is a standard procedure for this determination.
What is the difference between discrete-event simulation and system dynamics?
Discrete-event simulation tracks individual entities (jobs, patients, vehicles) moving through a system and updates state only at discrete event times, making it well suited to capacity and flow analysis at the operational level. System dynamics uses aggregate stock-and-flow equations that evolve continuously, and is better suited to strategic, macro-level analysis of feedback structures. The right choice depends on whether individual entity behaviour and queuing details matter.
Can discrete-event simulation find the optimal solution?
Simulation alone does not optimise — it evaluates. To find optimal configurations (staffing levels, buffer sizes, routing priorities), the simulation must be coupled with an optimisation algorithm such as a genetic algorithm or OptQuest-style search that systematically explores the design space and uses simulation to evaluate each candidate.
Sources
- 1.Kelton, W.D., Sadowski, R.P. & Zupick, N.B. (2014). Simulation with Arena (6th ed.). McGraw-Hill.ISBN 978-0073401317
- 2.Law, A.M. (2015). Simulation Modeling and Analysis (5th ed.). McGraw-Hill.ISBN 978-0073401324
You have read it. What now?
Cite this page
ScholarGate. (2026, June 1). Discrete-Event System Simulation. ScholarGate. https://scholargate.app/simulation/discrete-system-simulation