Discrete Event Simulation in AnyLogic: A Practical Introduction

A new production line, a redesigned emergency department, a busier warehouse - before any of these get built or changed in reality, there's a cheaper question worth asking: what happens to queues, wait times and resource use if this process runs the way we're planning? Discrete event simulation (DES) answers that by modelling entities - patients, parts, orders, customers - as they flow through a sequence of steps, queues and resources over simulated time. AnyLogic is one of the most widely used platforms for building these models, and this is a practical starting point for understanding how.

Key takeaways

• DES models entities moving through queues, resources and processing steps - it's a natural fit for manufacturing, logistics, healthcare and service operations.
• AnyLogic's Process Modeling Library provides pre-built blocks (Source, Queue, Seize, Delay, Release, Sink) that map directly onto real process steps.
• A model is only useful once validated against real historical data - build first, then confirm it behaves like the real system before trusting its predictions.
• AnyLogic can combine DES with agent-based and system dynamics modelling in one model when a system genuinely needs more than one modelling paradigm.

Table of Contents

• 1What Is Discrete Event Simulation?
• 2Why AnyLogic for DES
• 3Core Building Blocks
• 4How a DES Model Is Built
• 5Common Use Cases
• 6DES vs Agent-Based vs System Dynamics
• 7Common Mistakes
• 8FAQ

What Is Discrete Event Simulation?

Discrete event simulation models a system as a sequence of distinct events happening at specific points in simulated time - an entity arrives, joins a queue, seizes a resource, gets processed, releases the resource, and exits. Between events, nothing about the system state changes, which is what makes DES computationally efficient even for systems running over long simulated periods.

ⓘ

Why this maps so naturally to real operations: Most manufacturing, logistics, healthcare and service processes already look like this in reality - arrivals, waiting lines, shared staff or equipment, processing time, departure. DES doesn't force an abstraction onto the process; it mirrors the structure that's usually already there.

Why AnyLogic for DES

AnyLogic provides a dedicated Process Modeling Library with pre-built blocks representing the standard elements of a process flow - queues, resource pools, delays, branching logic - so models can be assembled visually rather than coded from scratch. It also supports combining DES with agent-based and system dynamics modelling in a single model, which matters when a system genuinely has both a process-flow component and an individual-behaviour or feedback-loop component.

Core Building Blocks

Block	Represents
Source	Where entities enter the system - customer arrivals, incoming orders, patient check-ins
Queue	A waiting line formed when entities arrive faster than they can be processed
Seize	An entity claims a unit of a shared resource - staff, a machine, a bay
Delay	Time spent being processed - a service time, a machining cycle, a consultation
Release	The entity gives up the resource it was using, freeing it for the next entity
Sink	Where entities exit the system once their process is complete

✎

Start with the simplest version. A first model built with just these six blocks, reflecting the real process sequence, is usually more valuable than a highly detailed model built too early. Add complexity - branching logic, multiple resource types, breakdowns - once the basic flow is validated.

How a DES Model Is Built

Map the process → Build the block diagram → Configure resources & queues → Add statistics → Validate → Run experiments

1. Map the real process flow: document the actual sequence of arrivals, queues, processing steps, resource use and exit points before opening AnyLogic.
2. Build the block diagram: reconstruct the process using Process Modeling Library blocks connected in the same sequence.
3. Configure resources and queues: define resource pools and queue capacities to reflect real constraints, with realistic arrival rates and service time distributions.
4. Add statistics collection: attach data collectors for queue length, waiting time, resource utilisation and throughput.
5. Validate against real data: compare model output to actual historical performance before trusting its predictions.
6. Run experiments: use parameter variation, sensitivity analysis or optimisation to compare scenarios.

Common Use Cases

Industry	Typical application
Manufacturing	Production line throughput, bottleneck identification, buffer sizing
Logistics & warehousing	Order fulfilment flow, dock scheduling, staffing levels
Healthcare	Emergency department flow, appointment scheduling, bed capacity planning
Service operations	Call centre staffing, bank branch queueing, retail checkout design

DES vs Agent-Based vs System Dynamics

Approach	Best suited for
Discrete event simulation	Process flows with queues, resources and processing steps
Agent-based simulation	Individual, autonomous behaviour and interactions - customers, vehicles, competitors
System dynamics	Aggregate feedback loops and stocks/flows over time - inventory levels, population trends

⚠

These aren't mutually exclusive in AnyLogic. A hospital model might use DES for patient flow through departments, agent-based logic for individual staff decision-making, and system dynamics for long-term bed demand trends - all combined in one model when the system genuinely needs that mix.

Common Mistakes

• Building complexity before validating the basics. A detailed model built on an unvalidated process flow just produces detailed wrong answers.
• Using average values instead of distributions. Real arrival and service times vary; modelling them as fixed averages understates queueing and congestion effects.
• Skipping validation against real data. A model that's never checked against actual historical performance offers no real confidence in its predictions.
• Ignoring the warm-up period. Statistics collected before the model reaches steady state can bias results, especially for utilisation and queue length metrics.
• Treating the model as a one-time deliverable. The most value often comes from running many scenarios after the base model is built, not from the base model alone.

Related reading: explore our Simulation & Analytics Services, see our article on How Data Analytics Helps Businesses Reduce Costs, or contact our simulation team to discuss a project.

Frequently Asked Questions

What is AnyLogic used for?

AnyLogic is a simulation modelling platform that supports discrete event, agent-based and system dynamics modelling, either separately or combined in a single model. It's widely used for manufacturing and logistics, healthcare operations, supply chain planning, and process improvement projects where the goal is to test changes virtually before implementing them in reality.

What is the difference between discrete event and agent-based simulation?

Discrete event simulation models a process as entities flowing through a sequence of steps - queues, resources, delays - and is well suited to process flows like manufacturing lines or service operations. Agent-based simulation models individual, autonomous agents with their own behaviour and decision rules, better suited to modelling scenarios where interactions between individuals, such as customers or vehicles, drive the system's behaviour. AnyLogic supports both, and can combine them in one model when a system genuinely needs both perspectives.

Is discrete event simulation the right approach for my process?

DES is generally a strong fit when a process can be described as entities moving through a sequence of steps involving queues, shared resources and processing times - common in manufacturing, logistics, healthcare and service operations. If the system's behaviour depends more on individual, independent decision-making or spatial interaction, an agent-based or hybrid approach may be more appropriate.

How do you validate a discrete event simulation model?

Validation typically involves comparing model outputs - throughput, wait times, utilisation - against real historical data from the actual system over a comparable period, checking that the model's baseline behaviour reasonably matches reality before using it to test hypothetical scenarios. Sensitivity analysis on key assumptions also helps confirm the model responds to changes in a believable way.

Conclusion

Discrete event simulation gives you a way to ask "what happens if" about a real process - a busier shift, a new resource allocation, a redesigned layout - without disrupting the actual operation to find out. AnyLogic's Process Modeling Library makes the core building blocks accessible without requiring every model to be built from raw code, while still leaving room to add agent-based or system dynamics elements when a system genuinely calls for them.

Start with the simplest version of your real process, validate it against what's actually happening today, and only then start testing the changes you actually care about. That order - map, build, validate, experiment - is what turns a simulation from an interesting diagram into a decision-making tool.

---

For more simulation and analytics insights, explore HyperCurve. If this article helped you, please share it with your colleagues.