Discrete Event Simulation: Modeling Processes and System Flows

Last Updated June 6, 2026

Discrete event simulation is a computational modeling method for analyzing systems in which state changes occur at identifiable moments in time. Instead of representing change as a continuous flow, discrete event simulation models a system as an ordered sequence of events: arrivals, departures, service starts, service completions, breakdowns, repairs, transfers, inspections, handoffs, routing decisions, and other state-changing occurrences.

This event-driven structure makes discrete event simulation, often abbreviated as DES, especially useful for systems organized around workflows, queues, constrained resources, process stages, and operational timing. Hospitals, airports, ports, warehouses, factories, call centers, rail yards, emergency response systems, data centers, maintenance systems, and logistics networks all depend on when entities arrive, how long service takes, which resources are available, how queues form, and how delays propagate through process chains.

DES is one of the major paradigms in systems modeling because it represents operational complexity with a level of timing and sequencing detail that aggregate models often cannot capture. Where system dynamics emphasizes stocks, flows, feedback loops, and delays, and agent-based modeling emphasizes heterogeneous agents and local interaction, discrete event simulation emphasizes process logic, event calendars, queue behavior, resource contention, and performance under variability.

This article explains discrete event simulation as a major paradigm within systems modeling. It covers conceptual foundations, event calendars, entities, resources, queues, bottlenecks, stochastic timing, performance metrics, validation, software tools, infrastructure and sustainability applications, mathematical foundations, professional workflows, Python and R examples, strengths, limitations, and responsible use.

What Is Discrete Event Simulation?

Discrete event simulation is a modeling approach in which a system changes state only when specific events occur. Between events, the system is assumed to remain unchanged. Time advances from one scheduled event to the next, rather than being updated continuously at every instant.

This makes DES especially appropriate for systems whose behavior depends on operational sequence. A patient arrives. A triage nurse becomes available. A diagnostic test begins. A machine breaks down. A repair crew is dispatched. A vehicle enters a loading bay. A customer joins a queue. A server completes a task. Each event changes the system state, and the next state depends on the timing and ordering of events before it.

In a DES model, the analyst defines entities, resources, queues, routing rules, processing times, event logic, priority rules, capacity constraints, and performance measures. The model then simulates how entities move through the system under stochastic arrivals, variable service times, limited resources, and operational rules.

DES is therefore a method for turning operational logic into an executable model. It is most valuable when timing, sequencing, capacity, and variability determine system performance.

Back to top ↑

Why Discrete Event Simulation Matters

Discrete event simulation matters because many systems fail or perform poorly not because total capacity is obviously inadequate, but because timing, variability, routing, and resource constraints interact in ways that are difficult to see from averages alone.

A hospital may appear to have enough average daily capacity, yet experience severe waiting during peak arrival periods. A warehouse may have enough workers overall, yet bottlenecks may form at packing or loading stations. An airport may process passengers efficiently under normal conditions but collapse under delayed arrivals, staffing shortages, or security-screening disruptions. A manufacturing line may be designed for high throughput but lose performance because of machine downtime, rework, changeovers, and blocking between stages.

DES helps analysts ask operational questions that aggregate models often miss:

• Where do queues form, and when?
• Which resource becomes the bottleneck under stress?
• How does variability affect waiting time?
• How does priority routing change service equity?
• How much capacity is idle, and how much is overloaded?
• How does maintenance timing affect reliability?
• How does changing staffing, layout, scheduling, or routing affect performance?
• How does a shock propagate through a process chain?

The importance of DES lies in its ability to represent process reality. Many operational systems do not fail smoothly. They fail through queues, blocking, starvation, overload, missed connections, cascading delays, and resource contention.

Back to top ↑

Conceptual Foundations

Discrete event simulation developed within operations research, industrial engineering, systems engineering, computer simulation, and management science. It became a core method for analyzing systems where performance depends on event timing, queue dynamics, process flow, and limited resources.

The conceptual foundation of DES is simple but powerful: a system has a state; events occur at specific times; events change the state; and a future-event list determines the next event to process. The model does not need to update continuously between events because nothing relevant changes until an event occurs.

This “next-event” time progression distinguishes DES from fixed-step simulations that update every minute, hour, or day regardless of whether anything happens. In a DES model, time jumps directly to the next scheduled event. This makes DES efficient and conceptually aligned with systems where change is event-driven.

DES belongs to systems modeling because it shows how system performance can emerge from process structure. It is not merely a scheduling technique. It is a formal representation of operational dynamics under constraint and variability.

Back to top ↑

Entities, Resources, Events, and Queues

Most DES models are built from a small number of core components. These components can be combined into complex workflows that represent hospitals, factories, ports, warehouses, transit systems, call centers, maintenance systems, or service operations.

Entities are the objects that move through the system. They may arrive, wait, receive service, change state, split into sub-processes, combine with other entities, or depart. Resources are limited-capacity assets needed to process entities. Events are state changes. Queues form when entities require resources that are unavailable.

DES models also include routing logic. After one process step, an entity may go to another station, leave the system, return for rework, wait for inspection, or be prioritized based on urgency. Routing rules make DES useful for real operational systems where entities do not all follow the same path.

These components make DES flexible. A simple queue can be modeled with one entity class and one server. A hospital, airport, or logistics hub may require multiple entity classes, resource pools, routing rules, priorities, and exception events.

Back to top ↑

Event Calendars and Next-Event Time Advance

The event calendar, also called the future-event list, is one of the defining mechanisms of DES. It stores events scheduled to occur in the future. At each step, the simulation selects the next event in chronological order, advances the simulation clock to that event time, updates the system state, and schedules any new events generated by that state change.

For example, an arrival event may add an entity to a queue. If a server is idle, the arrival may immediately trigger a service-start event and schedule a future service-completion event. A service-completion event may release a resource, route the entity onward, start service for the next queued entity, or schedule a departure. A failure event may reduce resource capacity and schedule a repair event.

This mechanism allows DES to represent complex operational timing without forcing the model to update at arbitrary fixed intervals. It is one reason DES is efficient for systems with many periods of inactivity punctuated by meaningful events.

Back to top ↑

Queuing and Process Dynamics

Queues are central to discrete event simulation because they reveal the consequences of limited resources under variable demand. A queue forms when entities arrive faster than they can be processed, or when resources are temporarily unavailable because of service, failure, maintenance, setup, priority rules, or downstream blocking.

Queue behavior is often nonlinear. As utilization approaches full capacity, waiting times can increase sharply. Small increases in arrival rate or service-time variability can produce disproportionate increases in waiting. A system that appears adequate under average conditions may become unstable under peak loads or high variability.

DES is useful because it captures the timing structure behind queue formation. It can distinguish a system with steady arrivals from one with clustered arrivals. It can distinguish a resource with predictable service times from one with high service-time variability. It can represent priority queues, balking, reneging, batch processing, setup times, breakdowns, and rework loops.

DES helps analysts see that queues are not only a sign of insufficient capacity. They are also consequences of variability, timing, sequencing, routing, and resource coordination.

Back to top ↑

Resource Contention and Bottlenecks

Resource contention occurs when multiple entities require the same limited resource. Bottlenecks occur when a resource, station, process, or rule constrains system throughput. DES is especially strong for identifying bottlenecks because it can trace how entities compete for capacity over time.

A bottleneck may be obvious, such as a single machine in a production line. But it may also be dynamic. A station may become a bottleneck only during peak arrivals. A resource may become constrained only after a failure. A nurse, technician, gate, forklift, inspection step, or information handoff may become the limiting factor even when nominal capacity appears adequate.

DES allows analysts to test whether adding capacity at one step improves the whole system or merely shifts the bottleneck elsewhere. This is crucial for operational decision-making. Buying another machine, adding another staff member, or opening another service line may not improve performance if the true constraint lies downstream.

DES is often used not simply to find the busiest resource, but to determine which resource limits system-level performance under realistic variability.

Back to top ↑

Stochastic Arrivals, Service Times, and Variability

Many DES models are stochastic. Arrival times, service times, travel times, failure times, repair times, routing decisions, and demand levels may be represented as random variables. This is important because operational systems often perform differently under variability than they do under average assumptions.

For example, two systems may have the same average arrival rate and average service time but different variability. The system with more clustered arrivals or more variable service times may experience longer waits, higher peak queues, and more frequent overload. DES can represent these differences directly.

Stochastic simulation requires experimental discipline. A single run is not enough. Analysts usually run multiple replications with different random seeds, then summarize mean performance, confidence intervals, percentiles, tail risks, and worst-case scenarios. This helps distinguish structural behavior from random variation.

Variability is not noise to be ignored. In DES, variability is often one of the primary drivers of system behavior.

Back to top ↑

Performance Metrics

DES models are typically evaluated through operational performance metrics. These metrics describe how well the system processes entities, uses resources, absorbs variability, and maintains service quality.

Common metrics include waiting time, queue length, time in system, throughput, utilization, cycle time, service level, abandonment, blocked time, idle time, failure frequency, recovery time, and cost. The right metrics depend on the purpose of the model. A hospital model may focus on patient waiting time and bed utilization. A manufacturing model may focus on throughput and work-in-process. A warehouse model may focus on order cycle time and dock utilization.

DES analysis should avoid optimizing one metric in isolation. Higher utilization may increase waiting. Lower waiting may require more idle capacity. Higher throughput may reduce resilience. The value of DES lies in making these tradeoffs visible.

Back to top ↑

Simulation Experiments and Decision Support

Discrete event simulation is widely used for decision support because it allows analysts to test operational alternatives before implementing them in real systems. A DES model can compare staffing levels, schedules, layouts, routing rules, priority policies, maintenance strategies, inventory buffers, automation investments, and surge-response plans.

The goal is not always to find one mathematically optimal solution. Often the goal is to learn how the system behaves under competing assumptions. DES can reveal which intervention reduces waiting, which intervention shifts the bottleneck, which intervention improves throughput at the cost of equity, or which intervention works only under certain arrival patterns.

Because DES can compare operational futures under uncertainty, it connects directly to scenario modeling, decision science, and resilience analysis.

Back to top ↑

Relationship to Other Systems Modeling Methods

Discrete event simulation is one of several major systems modeling paradigms. It is most useful when the system is process-based, event-driven, and resource-constrained.

System dynamics modeling represents aggregate behavior through stocks, flows, feedback loops, and delays. Agent-based modeling represents systems through interacting agents with heterogeneous rules. Network models represent structural interdependence through nodes and edges. DES represents processes through events, queues, resources, and operational logic.

In practice, these approaches can be combined. A hospital model may use DES for patient flow, ABM for patient behavior, system dynamics for staffing feedback, and network models for referral pathways. A logistics model may use DES for terminal operations, network modeling for routes, and system dynamics for inventory accumulation. A digital twin may combine DES with real-time sensor data and predictive maintenance models.

DES is therefore not a replacement for other systems modeling methods. It is a specialized and powerful tool for systems whose behavior depends on event timing and operational flow.

Back to top ↑

Calibration, Validation, and Credibility

Because DES models often influence real operational decisions, calibration and validation are critical. A DES model may appear precise because it produces numerical outputs, but those outputs are only as credible as the process logic, data, assumptions, and validation behind them.

Calibration may involve estimating arrival distributions, service-time distributions, routing probabilities, resource availability, failure rates, repair times, priority rules, and schedule patterns. Validation evaluates whether the model is credible for its intended purpose. A teaching model, exploratory design model, operational planning model, and high-stakes policy model require different evidence standards.

Validation should include both structural and behavioral checks. Does the process flow match the real system? Are resources represented correctly? Are queues and priority rules accurate? Do simulated waiting times and throughput resemble observed data? Do outputs respond plausibly under extreme conditions?

DES should be treated as an experimental tool, not an oracle. Its credibility depends on disciplined assumptions, reproducible workflows, transparent documentation, and careful interpretation.

Back to top ↑

Software Tools for Discrete Event Simulation

Discrete event simulation can be implemented in specialized commercial tools, open-source libraries, general-purpose programming languages, and hybrid simulation platforms. The right choice depends on model scale, stakeholder needs, visualization requirements, reproducibility, licensing, integration, and performance.

Commercial tools such as Arena, AnyLogic, SIMUL8, FlexSim, and Simio are often used in operations, manufacturing, logistics, healthcare, and engineering contexts. Programming frameworks such as SimPy support reproducible DES workflows in Python. Custom DES implementations may be appropriate when the model needs to integrate with domain data pipelines, optimization systems, digital twins, or high-performance simulation infrastructure.

Software does not determine model quality. A strong DES model depends on clear process logic, valid inputs, disciplined experimentation, and responsible interpretation.

Back to top ↑

Applications Across Complex Systems

Across these domains, DES helps analysts understand how operational details combine into system-level performance.

Back to top ↑

Applications in Sustainability and Infrastructure

Discrete event simulation is increasingly relevant for sustainability and infrastructure because many sustainability challenges are operational as well as strategic. Energy-efficient logistics, low-emission transit operations, hospital surge capacity, resilient maintenance systems, water utility repairs, port congestion, emergency response, and circular-economy operations all involve event timing and constrained resources.

DES can help planners evaluate how operational changes reduce waste, energy use, waiting, idle time, emissions, and service disruption. For example, a warehouse DES model can test whether different picking strategies reduce travel time and energy use. A transit DES model can test how bus dispatching affects passenger waits and fleet utilization. A water utility DES model can test how repair-crew allocation affects service restoration after failures.

DES complements broader sustainability modeling by revealing whether operational designs can actually deliver intended outcomes under real timing, capacity, and variability constraints.

Back to top ↑

Mathematical Lens: Event Scheduling, Queues, and Service Rates

In a basic event-driven queue, let \(N(t)\) represent the number of entities in the system at time \(t\). The state changes only when an event occurs. An arrival at time \(t_a\) updates the state as:

A departure or service completion at time \(t_d\) updates the state as:

If interarrival times are \(A_i\), arrival times can be constructed recursively:

For a single-server queue, service for entity \(i\) begins at:

The departure time is:

Waiting time is:

Utilization in a simple queue is often summarized as:

When utilization approaches full capacity, waiting times often rise sharply. This is one of the reasons DES is powerful: it shows how queues emerge from timing, variability, and constrained service capacity.

Back to top ↑

Back to top ↑

Strengths and Limitations

Discrete event simulation is powerful because it represents process flow with operational detail. It can capture queues, bottlenecks, resource contention, stochastic arrivals, service-time variability, routing logic, downtime, maintenance, priorities, blocking, and surge conditions. It is especially useful when the performance of the system depends on timing rather than only on aggregate levels.

DES also has limitations. Detailed models may require extensive data. They can become complex, opaque, and difficult to maintain. They may focus on operational mechanics while missing broader feedback, behavior, institutional incentives, or long-term structural change. Results can appear precise even when input assumptions are uncertain.

The strongest DES models are not necessarily the most detailed. They are the ones whose level of detail fits the decision, whose assumptions are validated, and whose outputs are interpreted with appropriate caution.

Back to top ↑

Python Workflow: Event Calendar, Queue Pressure, and Utilization

The Python workflow below uses only the standard library. It implements a simple event-calendar DES for a single-server queue, then compares scenarios with different arrival rates, service rates, server counts, and random seeds. It records waiting time, queue length, utilization, time in system, and service-level diagnostics.

# discrete_event_simulation_workflow.py
# Dependency-light DES workflow:
# event calendar, queue pressure, utilization, and scenario comparison.
#
# Suggested repository placement:
# articles/discrete-event-simulation/python/discrete_event_simulation_workflow.py

from __future__ import annotations

from dataclasses import dataclass
from heapq import heappop, heappush
from pathlib import Path
import csv
import random
from statistics import mean


ARTICLE_ROOT = Path(__file__).resolve().parents[1]
TABLES = ARTICLE_ROOT / "outputs" / "tables"


@dataclass(frozen=True)
class Scenario:
    name: str
    arrival_rate: float
    service_rate: float
    servers: int
    simulation_horizon: float
    seed: int
    service_level_target: float = 12.0


def write_csv(path: Path, rows: list[dict[str, object]]) -> None:
    path.parent.mkdir(parents=True, exist_ok=True)
    if not rows:
        raise ValueError(f"No rows to write: {path}")

    with path.open("w", newline="", encoding="utf-8") as handle:
        writer = csv.DictWriter(handle, fieldnames=list(rows[0].keys()))
        writer.writeheader()
        writer.writerows(rows)


def exponential_time(rng: random.Random, rate: float) -> float:
    if rate <= 0:
        raise ValueError("Rate must be positive.")
    return rng.expovariate(rate)


def simulate_queue(scenario: Scenario) -> tuple[list[dict[str, object]], dict[str, object]]:
    rng = random.Random(scenario.seed)

    event_calendar: list[tuple[float, int, str, int | None]] = []
    event_counter = 0

    queue: list[tuple[int, float]] = []
    busy_servers = 0
    entity_id = 0

    entity_records: dict[int, dict[str, float]] = {}
    event_trace: list[dict[str, object]] = []

    busy_time_area = 0.0
    queue_time_area = 0.0
    last_event_time = 0.0

    def schedule(time: float, event_type: str, entity: int | None = None) -> None:
        nonlocal event_counter
        event_counter += 1
        heappush(event_calendar, (time, event_counter, event_type, entity))

    schedule(0.0, "arrival", None)

    while event_calendar:
        current_time, _, event_type, event_entity = heappop(event_calendar)

        if current_time > scenario.simulation_horizon:
            break

        elapsed = current_time - last_event_time
        busy_time_area += busy_servers * elapsed
        queue_time_area += len(queue) * elapsed
        last_event_time = current_time

        if event_type == "arrival":
            entity_id += 1
            entity_records[entity_id] = {
                "arrival_time": current_time,
                "service_start": -1.0,
                "departure_time": -1.0,
                "service_time": -1.0,
            }

            schedule(current_time + exponential_time(rng, scenario.arrival_rate), "arrival", None)

            if busy_servers < scenario.servers:
                busy_servers += 1
                service_time = exponential_time(rng, scenario.service_rate)
                entity_records[entity_id]["service_start"] = current_time
                entity_records[entity_id]["service_time"] = service_time
                schedule(current_time + service_time, "departure", entity_id)
            else:
                queue.append((entity_id, current_time))

        elif event_type == "departure":
            if event_entity is None:
                raise ValueError("Departure event missing entity id.")

            entity_records[event_entity]["departure_time"] = current_time

            if queue:
                next_entity, _arrival_time = queue.pop(0)
                service_time = exponential_time(rng, scenario.service_rate)
                entity_records[next_entity]["service_start"] = current_time
                entity_records[next_entity]["service_time"] = service_time
                schedule(current_time + service_time, "departure", next_entity)
            else:
                busy_servers -= 1

        event_trace.append({
            "scenario": scenario.name,
            "time": round(current_time, 6),
            "event_type": event_type,
            "entity_id": event_entity if event_entity is not None else entity_id,
            "queue_length": len(queue),
            "busy_servers": busy_servers,
        })

    completed_rows: list[dict[str, object]] = []

    for entity, record in sorted(entity_records.items()):
        if record["departure_time"] < 0 or record["service_start"] < 0:
            continue

        waiting_time = record["service_start"] - record["arrival_time"]
        time_in_system = record["departure_time"] - record["arrival_time"]

        completed_rows.append({
            "scenario": scenario.name,
            "entity_id": entity,
            "arrival_time": round(record["arrival_time"], 6),
            "service_start": round(record["service_start"], 6),
            "departure_time": round(record["departure_time"], 6),
            "service_time": round(record["service_time"], 6),
            "waiting_time": round(waiting_time, 6),
            "time_in_system": round(time_in_system, 6),
            "met_service_level": waiting_time <= scenario.service_level_target,
        })

    waiting_times = [float(row["waiting_time"]) for row in completed_rows]
    time_in_system = [float(row["time_in_system"]) for row in completed_rows]

    summary = {
        "scenario": scenario.name,
        "completed_entities": len(completed_rows),
        "average_waiting_time": round(mean(waiting_times), 6) if waiting_times else 0,
        "maximum_waiting_time": round(max(waiting_times), 6) if waiting_times else 0,
        "average_time_in_system": round(mean(time_in_system), 6) if time_in_system else 0,
        "maximum_time_in_system": round(max(time_in_system), 6) if time_in_system else 0,
        "average_queue_length_time_weighted": round(queue_time_area / max(last_event_time, 1e-9), 6),
        "utilization": round(busy_time_area / max(last_event_time * scenario.servers, 1e-9), 6),
        "service_level_share": round(
            sum(1 for row in completed_rows if row["met_service_level"]) / max(1, len(completed_rows)),
            6
        ),
        "diagnostic": "high waiting pressure" if waiting_times and mean(waiting_times) > scenario.service_level_target else "contained waiting under current assumptions",
    }

    return completed_rows + event_trace, summary


def main() -> None:
    scenarios = [
        Scenario("baseline_single_server", arrival_rate=0.18, service_rate=0.22, servers=1, simulation_horizon=600, seed=42),
        Scenario("higher_arrival_pressure", arrival_rate=0.21, service_rate=0.22, servers=1, simulation_horizon=600, seed=43),
        Scenario("two_servers", arrival_rate=0.30, service_rate=0.22, servers=2, simulation_horizon=600, seed=44),
        Scenario("faster_service", arrival_rate=0.18, service_rate=0.30, servers=1, simulation_horizon=600, seed=45),
        Scenario("stress_surge", arrival_rate=0.25, service_rate=0.22, servers=1, simulation_horizon=600, seed=46),
    ]

    all_rows: list[dict[str, object]] = []
    summaries: list[dict[str, object]] = []

    for scenario in scenarios:
        rows, summary = simulate_queue(scenario)
        all_rows.extend(rows)
        summaries.append(summary)

    write_csv(TABLES / "python_des_event_and_entity_trace.csv", all_rows)
    write_csv(TABLES / "python_des_queue_summary.csv", summaries)

    print("Discrete event simulation workflow complete.")
    print(TABLES / "python_des_queue_summary.csv")


if __name__ == "__main__":
    main()

This workflow demonstrates the core DES logic. Events are scheduled in an event calendar, the simulation clock jumps to the next event, resources are seized and released, queues form when capacity is unavailable, and performance is measured from completed entity records.

Back to top ↑

R Workflow: Single-Server Queue with Stochastic Arrivals

The R workflow below uses base R. It simulates a single-server queue using stochastic interarrival and service times, then generates entity-level and summary-level diagnostics.

# discrete_event_simulation_diagnostics.R
# Base R workflow:
# single-server queue with stochastic arrivals, service times, and diagnostics.
#
# Suggested repository placement:
# articles/discrete-event-simulation/r/discrete_event_simulation_diagnostics.R

args <- commandArgs(trailingOnly = FALSE)
file_arg <- grep("^--file=", args, value = TRUE)

if (length(file_arg) > 0) {
  script_path <- normalizePath(sub("^--file=", "", file_arg[1]), mustWork = TRUE)
  article_root <- normalizePath(file.path(dirname(script_path), ".."), mustWork = TRUE)
} else {
  article_root <- normalizePath(getwd(), mustWork = TRUE)
}

tables_dir <- file.path(article_root, "outputs", "tables")
figures_dir <- file.path(article_root, "outputs", "figures")

dir.create(tables_dir, recursive = TRUE, showWarnings = FALSE)
dir.create(figures_dir, recursive = TRUE, showWarnings = FALSE)

simulate_single_server <- function(
  scenario,
  n_entities = 240,
  arrival_rate = 0.18,
  service_rate = 0.22,
  service_level_target = 12,
  seed = 42
) {
  set.seed(seed)

  interarrival <- rexp(n_entities, rate = arrival_rate)
  service_time <- rexp(n_entities, rate = service_rate)

  arrival_time <- cumsum(interarrival)
  service_start <- numeric(n_entities)
  departure_time <- numeric(n_entities)
  waiting_time <- numeric(n_entities)

  service_start[1] <- arrival_time[1]
  departure_time[1] <- service_start[1] + service_time[1]
  waiting_time[1] <- 0

  for (i in 2:n_entities) {
    service_start[i] <- max(arrival_time[i], departure_time[i - 1])
    departure_time[i] <- service_start[i] + service_time[i]
    waiting_time[i] <- service_start[i] - arrival_time[i]
  }

  entity_df <- data.frame(
    scenario = scenario,
    entity = seq_len(n_entities),
    arrival_time = arrival_time,
    service_time = service_time,
    service_start = service_start,
    departure_time = departure_time,
    waiting_time = waiting_time,
    time_in_system = departure_time - arrival_time,
    met_service_level = waiting_time <= service_level_target
  )

  summary_df <- data.frame(
    scenario = scenario,
    arrival_rate = arrival_rate,
    service_rate = service_rate,
    implied_utilization = arrival_rate / service_rate,
    completed_entities = n_entities,
    average_waiting_time = mean(waiting_time),
    maximum_waiting_time = max(waiting_time),
    average_time_in_system = mean(entity_df$time_in_system),
    maximum_time_in_system = max(entity_df$time_in_system),
    service_level_share = mean(entity_df$met_service_level),
    diagnostic = ifelse(
      mean(waiting_time) > service_level_target,
      "high waiting pressure",
      "contained waiting under current assumptions"
    )
  )

  list(entity = entity_df, summary = summary_df)
}

scenarios <- list(
  simulate_single_server("baseline_single_server", arrival_rate = 0.18, service_rate = 0.22, seed = 42),
  simulate_single_server("higher_arrival_pressure", arrival_rate = 0.21, service_rate = 0.22, seed = 43),
  simulate_single_server("faster_service", arrival_rate = 0.18, service_rate = 0.30, seed = 44),
  simulate_single_server("stress_surge", arrival_rate = 0.25, service_rate = 0.22, seed = 45)
)

entity_rows <- do.call(rbind, lapply(scenarios, function(x) x$entity))
summary_rows <- do.call(rbind, lapply(scenarios, function(x) x$summary))

write.csv(entity_rows, file.path(tables_dir, "r_des_entity_trace.csv"), row.names = FALSE)
write.csv(summary_rows, file.path(tables_dir, "r_des_queue_summary.csv"), row.names = FALSE)

png(file.path(figures_dir, "r_des_waiting_time_by_entity.png"), width = 1200, height = 700)
plot(
  entity_rows$entity[entity_rows$scenario == "baseline_single_server"],
  entity_rows$waiting_time[entity_rows$scenario == "baseline_single_server"],
  type = "l",
  lwd = 2,
  xlab = "Entity",
  ylab = "Waiting Time",
  main = "Waiting Time Across Entities in Baseline DES Queue"
)
grid()
dev.off()

png(file.path(figures_dir, "r_des_average_waiting_by_scenario.png"), width = 1200, height = 700)
barplot(
  summary_rows$average_waiting_time,
  names.arg = summary_rows$scenario,
  las = 2,
  ylab = "Average Waiting Time",
  main = "Average Waiting Time by DES Scenario"
)
grid()
dev.off()

print(summary_rows)
cat("R discrete event simulation diagnostics complete.\n")

This R workflow shows why DES is useful for operational analysis. Even small changes in arrival pressure or service rate can produce large differences in waiting time, utilization, and service level.

Back to top ↑

GitHub Repository

Back to top ↑

Ethics and Responsible Use

Discrete event simulation can influence staffing, scheduling, resource allocation, facility design, service priorities, and investment decisions. That makes DES ethically important. A model that minimizes average waiting time may increase waiting for vulnerable groups. A model that maximizes utilization may create unsafe working conditions. A model that improves throughput may reduce service quality, increase burnout, or hide distributional harm.

DES is often used in settings involving people: patients, passengers, workers, customers, emergency callers, residents, and service users. Responsible modeling requires attention to equity, safety, labor conditions, privacy, uncertainty, and the lived consequences of operational decisions.

A responsible DES model should improve operational judgment while making tradeoffs explicit. It should not hide human consequences behind efficiency metrics.

Back to top ↑

Common Pitfalls

Discrete event simulation can fail when operational detail is added without modeling discipline. A large DES model may still be weak if its data, assumptions, or event logic are poorly specified.

Good DES practice requires verification, validation, experimental design, replication, and humility about what the model can support.

Back to top ↑

Conclusion

Discrete event simulation is one of the most important methods in systems modeling because it makes operational complexity analyzable. It represents systems as ordered sequences of events, queues, resources, and state transitions, allowing analysts to examine how timing, variability, capacity, and process design shape performance.

DES is especially valuable for systems where averages are misleading. Hospitals, warehouses, ports, factories, call centers, transit systems, data centers, and maintenance operations all depend on the interaction of arrivals, service times, resource availability, routing rules, and delays. DES provides a disciplined way to test those interactions before changing the real system.

Used well, DES supports better decisions about staffing, scheduling, capacity, routing, resilience, and service quality. But its value depends on careful assumptions, credible data, validation, multiple replications, sensitivity analysis, and responsible interpretation.

A discrete event simulation is not merely a model of a process. It is a structured experiment about how operational systems behave under constraint, uncertainty, and time.

Back to top ↑

Related Articles

• What Is Systems Modeling?
• Systems Thinking vs Systems Modeling
• Why Complex Systems Require Models
• System Dynamics Modeling
• Agent-Based Modeling
• Network Models
• Hybrid Modeling Approaches
• Scenario Modeling and Simulation
• Calibration and Validation of Models
• Stress Testing and Robustness Analysis

Further Reading

• INFORMS. Simulation. Available at: INFORMS Simulation.
• SimPy. Overview. Available at: SimPy Documentation.
• AnyLogic. Discrete-Event Modeling. Available at: AnyLogic Discrete-Event Simulation.
• Rockwell Automation. Arena Simulation Software: Discrete Event Modeling. Available at: Arena Discrete Event Modeling.
• Banks, J., Carson, J.S., Nelson, B.L. and Nicol, D.M. (2010) Discrete-Event System Simulation. Upper Saddle River, NJ: Prentice Hall.
• Cassandras, C.G. and Lafortune, S. (2008) Introduction to Discrete Event Systems. New York: Springer.
• Law, A.M. (2015) Simulation Modeling and Analysis. New York: McGraw-Hill.
• Rossetti, M.D. Simulation Modeling and Arena. Available at: Simulation Modeling and Arena.
• Buss, A.H. (2012) A Tutorial on Discrete-Event Modeling with Simulation Graphs. Available at: Naval Postgraduate School.
• Vázquez-Serrano, J.I., Peimbert-García, R.E. and Cárdenas-Barrón, L.E. (2021) Discrete-Event Simulation Modeling in Healthcare: A Comprehensive Review. Available at: National Library of Medicine.

Back to top ↑

References

• AnyLogic. (n.d.) Discrete-Event Modeling. Available at: https://www.anylogic.com/use-of-simulation/discrete-event-simulation/.
• Banks, J., Carson, J.S., Nelson, B.L. and Nicol, D.M. (2010) Discrete-Event System Simulation. Upper Saddle River, NJ: Prentice Hall.
• Buss, A.H. (2012) A Tutorial on Discrete-Event Modeling with Simulation Graphs. Available at: https://calhoun.nps.edu/server/api/core/bitstreams/c0b1a6ec-36ae-42ce-aa55-c8dfc068aefa/content.
• Cassandras, C.G. and Lafortune, S. (2008) Introduction to Discrete Event Systems. New York: Springer.
• INFORMS. (n.d.) Simulation. Available at: https://www.informs.org/Explore/History-of-O.R.-Excellence/O.R.-Methodologies/Simulation.
• Law, A.M. (2015) Simulation Modeling and Analysis. New York: McGraw-Hill.
• Rockwell Automation. (n.d.) Arena Simulation Software: Discrete Event Modeling. Available at: https://www.rockwellautomation.com/en-us/products/software/arena-simulation/discrete-event-modeling.html.
• Rossetti, M.D. (n.d.) Simulation Modeling and Arena. Available at: https://rossetti.github.io/RossettiArenaBook/.
• SimPy. (n.d.) Overview. Available at: https://simpy.readthedocs.io/.
• Vázquez-Serrano, J.I., Peimbert-García, R.E. and Cárdenas-Barrón, L.E. (2021) ‘Discrete-Event Simulation Modeling in Healthcare: A Comprehensive Review’, International Journal of Environmental Research and Public Health, 18(22), 12262. Available at: https://pmc.ncbi.nlm.nih.gov/articles/PMC8625660/.

Back to top ↑