Why discrete-event sim beats continuous for AMR planning

If you have ever sized an AMR fleet by looking at a fluid-flow chart of “average robots per pick station” and “average travel time,” you already know the trick the chart played on you. It told you about the mean. It said nothing about the moment a station queue built up, the moment two robots arrived at the same node in the same tick, or the moment an order’s due time slid past while the dispatcher kept assigning to the busy half of the floor. Fleet sizing decisions are tail decisions. Continuous-time models do not give you tails honestly.

This is the argument for discrete-event simulation (DES) as the right level of detail for warehouse robotics planning, written for someone who has done both kinds of modeling and is wondering whether the upgrade is worth it. WareMax is a DES; this post is about why.

What a continuous model is actually doing

A continuous-time model of a Robotic Mobile Fulfillment System (RMFS) typically reduces the floor to a small set of coupled ODEs or a fluid network: orders enter at rate λ, get serviced at rate μ per station, robots cycle at rate 1/τ through travel + pickup + queue + service. Many such models are useful for the question they were built for — back-of-envelope steady-state throughput, the equilibrium fleet size at which the system is neither starved nor saturated.

But four things happen on a real RMFS floor that those models smooth over:

1. Service-time distributions are not exponential. Pick-station service times are well-modeled as lognormal; in WareMax, that is the default (distribution: lognormal, base: 12.0, per_item: 3.0). The tail of a lognormal distribution is heavier than what a steady-state fluid model implicitly assumes, and the tail is where SLA breaches live.

2. Arrivals are bursty, not paced. Order arrivals follow a Poisson process; lines per order follow a negative binomial; SKU popularity follows a Zipf law (the WareMax defaults again). The interaction of these three is what makes the same hour feel like idle one minute and overloaded the next. A continuous model with rate λ does not see those minutes.

3. Decisions are discrete and they happen at events, not at clock ticks. A dispatcher chooses a robot when a task arrives and when a robot becomes free, not every second. If your model advances time on a fixed timestep, you are either over-deciding (assigning every Δt and then ignoring the assignment) or under-deciding (missing the moment a faster robot would have been the better pick). Event-driven advancement matches what the controller actually does.

4. The thing you most want to measure is a deadline-related count, not a mean. Operations cares about p95 lateness, fraction of orders on-time, and worst-station queue depth in the hour. Each is a tail statistic that requires counting individual orders, individual robots, individual events. A fluid model cannot count them; it can only report rate.

What DES actually models

A discrete-event simulator advances time only to the next scheduled event — an arrival, a travel-end, a station-service-end, an enqueue. Between events, nothing happens; there is no integration step, no time tick. WareMax’s waremax-core kernel is exactly that: a priority queue keyed on SimTime, a single-threaded loop, and a set of typed event handlers.

This buys you four things that matter for AMR planning:

A. Honest queueing. When robot R3 arrives at station S1 and there is already one robot ahead, the wait is service_time_remaining(robot_ahead) + max(0, queue_position_factor). The DES kernel records that wait as a real number on a real event, not as a flux through a queue node. When you sweep robots.count from 8 to 16, you can plot the actual distribution of station-queue waits, not its mean.

B. Causal decomposition you can use. Because every event is typed, you can decompose the cycle time of a single task into causal buckets — assignment wait, travel, station queue, congestion, service — and the buckets sum to the cycle time exactly. WareMax exposes this as waremax-analysis and uses it directly as a reward signal in two of its RL reward modes (attribution, routed). A continuous model gives you a number; a DES gives you a number plus a why.

C. Decisions you can intervene on. The lever you actually care about — which robot handles which task — is a discrete choice triggered by a discrete event. In a DES, swapping the dispatching policy means swapping a function called at one event type. In WareMax that function implements a one-method TaskAllocationPolicy trait, and the policy factory in waremax-sim/src/policy_factory.rs is a one-arm change. In a fluid model the “policy” is an assumption baked into the rate equations; you cannot swap it without rewriting the model.

D. Reproducibility, if you build for it. This is the one most people get wrong, including most DES implementations. Determinism is not a free property of event-driven time advancement; it is a property of every randomized choice (RNG sequence, hash iteration order, tie-breaking) being canonical. WareMax enforces this: ChaCha8 RNG seeded from a u64, id-based tie-breaking everywhere, and tests in waremax-rl/tests/determinism.rs that fail if (seed, action sequence) does not produce a byte-identical trajectory. It is also, frankly, the property that exposed several HashMap-iteration bugs in the simulator core that had previously made supposedly-seeded results silently irreproducible.

What you give up by going DES

Honesty requires that we list these.

• Cost. DES is slower per simulated second than a fluid model. WareMax mitigates this with a Rust event-driven core and mimalloc; on a laptop CPU it can train thousands of episodes. But “fast for DES” is not “as fast as one ODE solve.”

• Calibration burden. A DES needs distributions, not just rates: service-time distribution, arrival distribution, SKU popularity. Each one is a question you have to answer from data. A fluid model only needs λ and μ. (Counter-argument: the answers were always being assumed; DES makes them explicit.)

• Output volume. A DES produces per-event logs and per-task records, not a single steady-state number. WareMax persists CSVs (runs.csv) and rebuilds a tables.md per grid; consumers must be ready to read tables, not single scalars.

When DES is the wrong tool

We will not insult you by claiming DES is universal. Two regimes where continuous models are the right call:

• Very early sizing, when you are arguing about whether the right fleet is 10 robots or 100. A back-of-envelope queueing model is faster and at that resolution, accurate enough.

• Steady-state limit analysis, when you want to know the asymptotic throughput of a topology under uniform load. DES will give the same answer with more work.

For everything in between — comparing dispatching policies, sizing for SLA attainment under bursty load, training an RL agent on a reproducible benchmark, decomposing where in the cycle the time is being lost — DES is the level of detail the question is actually asked at.

What this looks like in WareMax

A 60-minute scenario with 10 robots, two pick stations, Poisson arrivals at 1 order/min, and the routed task-allocation policy runs to completion in well under a second on a laptop. It produces a results/ directory with the event log, the per-task delay attribution CSV, the per-policy A/B comparison if you ran waremax compare, and an HTML report. Run it again with the same seed and same scenario and you get a byte-identical trajectory. Run it across eight seeds and you get a confidence interval on every reported metric, computed with waremax-testing’s Welch’s t machinery.

That is the value proposition: not “DES is better than continuous” in the abstract, but for the specific questions warehouse-robotics planning asks, DES is the level of detail at which those questions become answerable, and once you are at that level of detail, reproducibility is achievable and worth enforcing.

If you have been sizing AMR fleets with fluid models, the next time you size one, run the same scenario in WareMax against a heuristic baseline and look at the p95 of station-queue wait, not the mean. That is the number that will most surprise you.

← All posts