A clinic can be quiet at 9:00, overwhelmed at 10:15 and quiet again at noon even when its average arrival rate has not changed. A warehouse can have enough total labour and still miss dispatch because several tasks compete for the same people at the wrong moments. A factory can have high-capacity machines and still lose output to blocking, starvation, failures and repair delays.

Discrete-event simulation models systems whose state changes at identifiable events: an arrival, service completion, breakdown, repair, departure, replenishment or another occurrence that changes what the system can do next. Instead of advancing time in equal tiny steps, the simulation clock usually jumps from one scheduled event to the next.

The method is useful when queues, resource competition, variability and sequencing make simple averages inadequate. It is not a substitute for real evidence. A detailed simulation can reproduce the assumptions of its designer with extraordinary precision and still misrepresent the world.

Examples below are constructed for explanation. They do not describe actual eduKate operations, medical workflows or commercial performance.

1. Discrete-event simulation represents change as events

In a queueing system, nothing relevant may happen between 10:00:12 and 10:00:39. At 10:00:39 a service completes, freeing a resource and perhaps starting service for the next entity. The event changes state; the intervening seconds do not need to be simulated individually.

This event-driven architecture can make large operational systems computationally manageable.

2. Entities are the things that move through the process

Entities might be customers, jobs, parts, documents, vehicles or requests. They can carry attributes such as priority, due time, destination or required service type.

The entity definition should match the decision. A warehouse simulation concerned with cartons may not need item-level detail; a picking simulation may.

3. Resources constrain simultaneous activity

Servers, machines, staff, docks, vehicles and rooms are resources. A task can begin only when its required resources are available.

Resource calendars matter. Two identical workers are not equivalent if one is available only during a different shift or lacks a required qualification.

4. Queues store work that cannot yet proceed

When an entity needs a busy resource, it waits. The queue may follow first-in-first-out, priority, due-date or another discipline.

The queue rule can materially change outcomes even when average capacity is unchanged.

5. The event calendar is the simulation’s future agenda

The engine maintains a list of scheduled future events. It removes the earliest event, advances the clock to that time, updates state and schedules any new events caused by the change.

This loop continues until a stopping condition such as simulated closing time, completion of a fixed number of entities or another horizon is reached.

6. A minimal event loop

INITIALISE STATE
SCHEDULE INITIAL EVENTS
WHILE stopping condition not met:
    take earliest event
    move clock to event time
    update system state
    collect relevant statistics
    schedule consequences
END
SUMMARISE REPLICATION

The simplicity of the loop hides the hard work: defining valid events, state transitions, distributions, priorities and dependencies.

7. A constructed one-server example

Suppose four fictional requests arrive at times 0, 1, 4 and 5 minutes. Their service times are 3, 4, 2 and 1 minutes, and service is first-in-first-out.

Constructed deterministic event trace

Request	Arrival	Service starts	Service ends	Waiting time
A	0	0	3	0
B	1	3	7	2
C	4	7	9	3
D	5	9	10	4

The average waiting time is 2.25 minutes. The trace shows why: congestion propagates forward because later entities inherit the backlog created earlier.

8. Average rates can hide event-level congestion

If arrivals and service were spread perfectly evenly, a system could look comfortable. Random clustering can create queues even when long-run average capacity exceeds average demand.

This is the bridge to Queueing Theory and Waiting Lines. Queueing theory provides powerful analytical results; discrete-event simulation handles richer rules and interactions when exact analysis becomes difficult.

9. Random inputs should represent evidence, not convenience

Arrival times, service durations, failures and repairs are often stochastic. The distribution selected for each input should be justified by data, mechanism or a clearly labelled scenario.

Choosing an exponential distribution because a software menu offers it is not evidence that the real process is exponential.

10. Empirical distributions can preserve observed shape

When sufficient data exist, resampling from observed values or fitting a distribution can preserve skewness and variability better than substituting a single average.

Dependence matters too. Service time may be longer for certain job types or at certain hours. Independent sampling can erase structure the real system carries.

11. Correlation can create bottlenecks that independent inputs miss

If several resources become busy together because the same event drives demand, modelling them independently may understate peaks. Conversely, negative dependence can reduce congestion.

A simulation should represent important joint behaviour, not merely match each variable’s marginal histogram.

12. Warm-up removes artificial starting conditions

A steady-state simulation often begins empty because initialization is easy, but the real system may normally contain work in progress. Early observations then reflect the empty start rather than ordinary operation.

A warm-up period can be excluded from steady-state statistics, provided the choice is justified rather than tuned after seeing a preferred result.

13. Terminating and steady-state simulations answer different questions

A school-day simulation, emergency evacuation or one production shift may have a natural beginning and end. A round-the-clock network may instead be analysed for long-run behaviour.

The statistical treatment differs because a finite operational episode and an indefinitely continuing process are different estimands.

14. One simulation run is one stochastic realisation

If random inputs are used, rerunning with a different random stream produces another path. A single run can be unusually favourable or unfavourable.

Independent replications help estimate the expected performance and uncertainty of the simulation output.

15. Replication error is not model uncertainty

Running the same model ten thousand times can reduce Monte Carlo error. It does not prove that the arrival distribution, resource rules or behavioural assumptions are correct.

This distinction is developed in Monte Carlo and Simulation-Based Inference.

16. Common random numbers can improve comparisons

When comparing two designs, using coordinated random streams can make both face similar simulated demand, allowing differences to reflect the design more clearly rather than unrelated random luck.

This variance-reduction technique must be implemented carefully so the intended correlation structure is preserved.

17. Verification asks whether the simulation was implemented correctly

Check event ordering, queue discipline, resource release, counters, units, time calendars and boundary conditions. Use tiny cases whose answers can be calculated by hand, like the four-request trace above.

A complex animation is not verification.

18. Validation asks whether the model is adequate for its use

Compare simulated behaviour with relevant observations: throughput, queue lengths, utilisation, waiting distributions, downtime, routing frequencies and known responses to interventions.

NIST’s requirements analysis for discrete-event simulation and its current Simantha manufacturing simulation software page provide public examples of discrete-event modelling in manufacturing contexts.

19. Face validity is useful but weak

Domain experts may notice impossible behaviour quickly. Their review is valuable. But a model can look plausible while producing systematically wrong quantitative results.

Use visual plausibility as one check among several, not the final proof.

20. Bottlenecks are dynamic, not merely the slowest machine

A nominally fast resource can become a bottleneck because many routes converge on it. A slow resource may rarely constrain output if demand is low or buffers decouple it.

Simulation reveals bottlenecks through the interaction of timing, routing and capacity.

21. Blocking and starvation matter in production systems

A machine is blocked when it cannot release completed work because downstream space is unavailable. It is starved when it has capacity but no input to process.

Both can reduce throughput without any machine being mechanically slow.

22. Failures and repairs create state-dependent capacity

Equipment can fail while busy or idle, require technicians, wait for parts and return in degraded condition. Discrete-event simulation can represent these dependencies explicitly.

The model should distinguish evidence-supported failure behaviour from hypothetical stress scenarios.

23. Priorities create winners and losers

A priority rule can reduce delay for urgent entities while increasing it for others. Average waiting time may improve or worsen depending on the workload.

Report distributional effects, not only the overall mean, when different receiver groups matter.

24. Resource pooling can reduce idle fragmentation

Two dedicated servers can leave one idle while the other’s queue grows. A pooled resource may use capacity more flexibly, but cross-training, travel and handoff costs can offset the benefit.

Simulation is useful precisely because these competing mechanisms can be represented together.

25. Scenario analysis should not masquerade as probability

A stress case with double demand can be useful even if nobody has assigned a probability to that event. Label it as a stress case. Do not average several scenarios as though they were equally likely unless that probability model is justified.

See Strategic Foresight and Scenario Planning.

26. Simulation optimisation adds a search layer

An optimiser can vary staffing, buffer sizes, schedules or routing rules and use simulation output to evaluate candidates. NIST’s Simantha page explicitly notes simulation-based optimisation and planning applications.

Optimisation can exploit model errors, so unusual “optimal” solutions deserve especially careful validation.

27. Experimental design still matters inside simulation

Changing one factor at a time can miss interactions. Factorial designs, response surfaces and carefully planned comparisons can extract more information from expensive simulation runs.

Relevant routes include Factorial Experiments and Interaction Effects and Sensitivity Analysis and Robustness Checks.

28. A digital twin is not automatically a validated simulation

Connecting a model to live data can keep its state current, but the transition logic, sensor coverage and decision rules still require validation.

Real-time data can update a wrong model very efficiently.

29. A practical DES audit

• Define the decision job and system boundary.
• List entities, resources, queues and events.
• Document routing and priority rules.
• Source arrival, service, failure and repair inputs.
• Represent important dependence and calendars.
• Verify event logic with hand-checkable cases.
• Validate output against relevant real observations.
• Choose terminating or steady-state analysis deliberately.
• Use enough independent replications for the required precision.
• Separate Monte Carlo error from structural uncertainty.
• Test sensitivity and stress cases.
• Record the model version, data period and random-stream policy.

30. The deepest lesson

Discrete-event simulation teaches that systems fail and succeed in sequence, not only in averages. Timing, competition for resources and accumulated queues can create behaviour that no static capacity total reveals.

The simulation is valuable when it makes those interactions inspectable and testable. It becomes dangerous when a moving animation makes assumptions look like observations.

Sources and further reading

• NIST — Simantha: Simulation for Manufacturing, discrete-event simulation software and dataset.
• NIST — Production Systems Engineering: Requirements Analysis for Discrete-Event Simulation.
• eduKateSingapore — How Models and Simulations Work.

Continue through eduKate: Queueing Theory and Waiting Lines → Monte Carlo and Simulation-Based Inference → Linear Programming and Mathematical Optimization → Research Collections Directory.