The building blocks

The three primitives of Discrete Rate Simulation.

Any rate-based system — a high-speed bottling line, a continuous-process chemical plant, a hospital patient flow, a power generation facility — can be modeled with just three building blocks. Andrew Siprelle introduced this decomposition in 1990 as the foundation of what was originally called bulk flow simulation and is today known as discrete rate simulation.

Why three?

Classical discrete event simulation models a production system as thousands of individual units flowing through stations — one event per unit, per station, per stop, per release. Computational cost scales with throughput. On a slow line that's fine. On a real line running 1,200 units per minute, it isn't.

The discrete rate decomposition asks a different question: what's the smallest set of abstractions that can faithfully represent any rate-based system? The answer turns out to be three. Every constraint, every accumulator, every interruption you'd find in a real plant maps onto one of these three primitives. There are no fourth or fifth primitives. The decomposition is complete.

Between events involving these primitives, the system needs no recalculation — the rate is constant and the buffers evolve linearly. The simulator does work only when something actually changes. That's why discrete rate models scale independently of throughput.

Primitive 1. Constraints

A constraint is a point in the system that limits the rate of flow. Constraints are the units of capacity in a discrete rate model — they define how fast the system can move.

Every constraint has a maximum rate that may vary over time. Between rate-changing events, it runs at its nominal rate. When an interrupt fires (a failure, a changeover, a scheduled stop), its rate changes — potentially to zero. When the buffer downstream fills, it may be blocked. When the buffer upstream empties, it may be starved.

Examples in real systems: a high-speed filler at 1,200 cans/min · a labeling station at 850 bottles/min · a chemical reactor at 12 m³/hr · a pipeline compressor at 800 MMcf/day · an ED triage station at 8 patients/hr · a forklift loading bay at 22 pallets/hr.

Primitive 2. Buffers

A buffer is an accumulator between constraints — the decoupler. Buffers absorb mismatches between upstream and downstream rates: when upstream is faster than downstream, the buffer fills; when downstream is faster, it drains.

Buffers are why production systems don't immediately seize when one station hiccups. A well-placed buffer between Filler A and Capper B can absorb several minutes of downstream downtime before Filler A is forced to block. A poorly-sized buffer cascades upstream failures into downstream starvation within seconds.

Buffer level evolves continuously between events. The simulator predicts the next event — typically buffer fills or buffer empties — in closed form from the current rate differential. No time stepping. No integration. The buffer just hits its limit and fires an event.

Examples in real systems: product accumulator between filling and labeling · WIP inventory between machining and assembly · holding tank between reactor and distillation column · waiting room between triage and exam room · pipeline line pack between compressor stations · loaded-pallet stack between palletizer and forklift.

Primitive 3. Interrupts

An interrupt is a discrete stochastic event that modifies a constraint's rate. Every disruption you'd find in a real plant — equipment failures, changeovers, quality stops, scheduled maintenance — is an interrupt.

Each interrupt carries its own time-to-failure (TTF) and time-to-repair (TTR) distributions. There's no averaging across interrupt types — a three-second label misread is one distribution, a four-hour belt replacement is another, a twenty-minute changeover is a third. The model fires each independently with its own stochastics.

This is the primitive that classical discrete event models often averages away — rolling twelve different interrupt types into a single "downtime" factor or "availability" number. Discrete rate keeps them separate. That's how you capture the cascade effects that drive real-line throughput.

Examples in real systems: 3-second label misreads · 90-second jam clears · 5-minute changeovers · 4-hour preventive maintenance windows · quality holds awaiting QA release · shift changes · CIP cycles · ED staff turnover at shift change · pipeline compressor trips · weather-induced derating.

The closure property

The three primitives compose. A real plant is a network: constraints connected through buffers, modulated by interrupts. There are no other building blocks needed. Any process you can characterize as rates, accumulators, and disturbances reduces to this decomposition.

That's what makes the discrete rate paradigm general. The same three primitives model a soap manufacturing system (Andy's 1995 foundational paper), a real-line production validation within 1% OEE (Lange / Fischel / Siprelle, 2020 WSC), an emergency department, a fuel pipeline, a distillation column. The domain changes; the primitives don't.

"Every discrete rate model is built from three fundamental block types — first introduced by Andrew Siprelle in 1990 and now used by tens of thousands of practitioners worldwide."

Where to learn more

The history of Discrete Rate Simulation — how Andy created the technique in 1990 and how the paradigm spread.
Discrete Rate Simulation FAQ — quick answers to common questions about how it works and how it differs from discrete event simulation.
ReliaSim — the manufacturing-deep discrete rate simulator built on this paradigm.
Decoupling Buffer Simulator — explore the constraint-buffer-interrupt interaction in your browser, free.

← Back to DiscreteRate