Discrete Rate vs Discrete Event Simulation.
Two simulation paradigms. Same family. Very different answers when your line runs faster than a few units per minute. This is the head-to-head comparison — what each does well, where each breaks down, and why Andrew Siprelle created Discrete Rate Simulation in 1990 when classical Discrete Event Simulation couldn't model the lines he was working on.
The fundamental difference
Discrete Event Simulation (DES) models the system as a sequence of discrete events involving individual entities. Each unit moving through the system is an event the simulator schedules, executes, and cleans up. The model advances time by jumping from one event to the next.
Discrete Rate Simulation (DRS) models flow as a rate. Between rate-changing events — failures, changeovers, blocking, starvation — the rate is constant and the buffers evolve linearly. The simulator does no work until something actually changes.
Both methods are event-based. The difference is in what counts as an event. DES says: each unit is an event. DRS says: each rate-change is an event, and the units between events flow through the system as a continuous stream.
Side by side
| Aspect | Discrete Event Simulation | Discrete Rate Simulation |
|---|---|---|
| Unit of analysis | Each entity is an individual event | Flow is modeled as a rate |
| Computational complexity | Scales with throughput rate — faster line, more events, longer run | Independent of throughput rate — one event per rate change |
| Micro-stoppages | Often averaged into a single downtime factor | Each interrupt explicit, with its own TTF and TTR distributions |
| Blocking and starvation | Approximated through entity-level events | Computed exactly via flow propagation in closed form |
| Buffer dynamics | Modeled through entity queueing and dequeueing | Buffer levels evolve linearly between events; fill/empty events fire in closed form |
| Validation at full speed | Models often validate at low speeds, drift at scale | Independently validated within 1% OEE on real production lines (WSC 2020) |
| Best fit for | Low-volume systems, individual-unit logistics, queueing networks where unit identity matters | High-speed bulk flow, continuous-process manufacturing, rate-based flow systems |
When DES is the right tool
Don't write off Discrete Event Simulation. It's the right paradigm for any system where unit identity matters — queueing networks where you care about specific customers and their wait times; supply-chain models where individual orders need tracking; call-center modeling where each interaction is its own event with attributes; baggage-handling systems where individual bags route through scanners and conveyors. Andy himself uses DES where it's appropriate; the point isn't to replace DES, it's to extend the family with a paradigm that handles rate-based systems where DES breaks down.
When DES breaks down
Three failure modes show up in classical DES models of high-speed production:
1. Computational cost scales with throughput
A bottling line running 1,200 cans per minute produces 1,200 events per minute in a DES model. A six-station line at the same rate produces ~7,200 events per minute. A shift produces millions of events. Real-line micro-interrupts — three-second jams, label misreads, sensor faults — multiply that further. The model can't finish a shift's worth of simulation in less than an afternoon, and you can't make decisions in days from a model that takes overnight to run.
2. Cascade effects get averaged away
The standard escape valve is to model the system at a coarser time scale — aggregate micro-stoppages into a single "downtime" parameter, treat the line as a single composite constraint with a derated rate. This buys you speed at the cost of dynamics. You lose the cascade effects: how a two-minute downstream stop on station four shows up as a six-minute starvation at station two thirty seconds later. Those cascade effects often dominate real-line OEE. Average them away and the model validates at low speeds but drifts 10–15% at scale.
3. Blocking and starvation are approximated, not computed
Classical DES models blocking and starvation through entity-level logic: an entity exits a station, can't enter the next station, returns to a queue. The mechanics work, but the propagation timing is approximated. Discrete rate computes blocking and starvation by flow propagation through the buffer network — the answer is exact, not approximated.
The validation evidence
The 2020 Winter Simulation Conference paper High Accuracy Discrete Rate and Reliability Modeling to Drive Improvement of Plant OEE and Throughput (Lange, Fischel, and Siprelle) reported independent validation of discrete rate models within 1% OEE on real production lines. The paper's co-author Tom Lange spent 36 years at Procter & Gamble, where he retired as Director of Modeling & Simulation in Corporate R&D.
One percent. On lines where conventional discrete event models routinely come in 10–15% off. That's the size of the gap between the two paradigms at scale.
Choosing between them
Use Discrete Event Simulation when:
- Individual entity identity matters (specific orders, customers, parts)
- Throughput is low enough that per-unit events are computationally cheap
- You're modeling queueing networks, call centers, baggage handling, ride-share dispatch
- You need to track unit-level attributes through the system
Use Discrete Rate Simulation when:
- Flow rate matters more than individual unit identity
- High-speed lines (hundreds or thousands of units per minute) where DES becomes impractical
- Continuous-process or bulk-flow systems — chemical, food and beverage, paper, pipeline
- Cascade effects from micro-stoppages drive system performance
- Buffer-design and decoupling questions are central to the analysis
- Real-line OEE validation accuracy matters
What it looks like in code
Conceptually, the two paradigms make different choices about the simulator's main loop.
A DES simulator maintains a priority queue of events ordered by time. The main loop pops the next event, processes it (which may schedule further events), and advances the clock. Every unit transit is its own event.
A DRS simulator maintains the current rate of every flow in the system, plus a priority queue of predicted rate-change events: when will this buffer fill? when will this interrupt fire? when does this scheduled changeover begin? The main loop pops the next predicted event, recomputes the affected rates and buffer levels in closed form, and predicts the new next event. Between events, the simulator does nothing — the math is closed-form because rate is constant and buffers evolve linearly.
Read more
The three primitives of Discrete Rate Simulation
— constraints, buffers, interrupts. The building blocks Andy introduced in 1990.
The history of Discrete Rate Simulation
— how Andy created the technique in 1990, originally as bulk flow simulation, and how
the paradigm spread.
DRS FAQ
— quick answers to common questions.
ReliaSim
— the manufacturing-deep discrete rate simulator built on this paradigm, validated within
1% OEE.