Discrete rate vs. discrete event on a 1,000-a-minute line

The problem with counting every container

Picture a bottling line moving 1,000 containers a minute. In a conventional discrete event model, each container is its own item. It is created, moved, queued, filled, capped, labeled and packed, and every one of those steps is an event the computer has to schedule and process. The event count grows with every container the line makes.

Most of those events tell you nothing new. While the line runs smoothly, container 40,001 behaves exactly like container 40,000. What you care about is when smooth running stops, and how far the stop spreads up and down the line.

Others have written about this cost for a long time. Sturrock and Drake (WSC 1996) explained why modeling every item slows high-speed line models down, and offered two ways around it: continuous equations and aggregation.

What changes when you model rates

Discrete rate simulation treats what flows through the model as a rate. A filler runs at a rate. A conveyor carries a rate. A buffer fills at the difference between the rate coming in and the rate going out. The model only does work when a rate changes: a machine stops, a buffer fills, a tank runs dry, a changeover starts, a shift ends. At each of those moments it works out the new rates and the time of the next change.

For a high-speed system, that can cut the events in a stretch of simulation from 40,000 steps to 2. The events grow with the number of changes, not the number of containers.

Andy Siprelle created the method in 1990 as bulk flow simulation, and it was later renamed discrete rate simulation. The first paper, "Modeling a Bulk Manufacturing System Using Extend," by Siprelle and Parsons, was presented at the 1995 Winter Simulation Conference. Discrete rate libraries or extensions are now part of the major commercial packages, including ExtendSim, AnyLogic and Siemens Plant Simulation.

Why run speed changes the answer

Fast models are not just a convenience. They change what you can learn. Line questions are rarely answered by one run. A buffer study needs many buffer sizes. Each size needs several failure scenarios. Each scenario needs replications, because stops are random. And before anyone trusts the results, the model has to be checked against the line's own history.

When one run takes a long time, teams cut corners. They test a handful of cases and pick the best of those. When a run takes seconds, they can test the whole range and ask "what would happen if" as many times as the decision needs. On our buffer tradeoff experiment, dozens of failure scenarios across many buffer sizes ran in practical time for exactly this reason.

Speed does not have to cost accuracy on the things a high-speed line cares about: stops, starves, blocks and accumulation. Fischel and Lange (WSC 2020) described a discrete rate and reliability model of a salad dressing plant that matched actual OEE within 1% and found improvements the team did not expect.

When discrete rate fits

• High-speed packaging lines. Filling, capping, labeling, case packing and palletizing lines that run fast and stop often, where short stops add up and accumulation decides whether a stop stays local.
• Bulk material. Powder, grain and liquid have no natural "item." Forcing them into items means inventing a lot size and living with the error.
• Tanks, bins and silos. A rate model knows exactly when storage will fill or empty, so it shows when the upstream end will block and the packer will starve.
• Make-store-pack plants. Where the bottleneck moves with the package size or schedule.
• Supply chains. Product moving between plants, warehouses and customers can be modeled as flows, so months of operation run in minutes.

When discrete event fits

• Items with their own identity. Assembly where each unit carries its own options, or routing where each order takes its own path.
• Job shops and low-volume lines. When items are few and each one matters, there is little to gain from aggregating them.
• Questions about one specific item. Where did this pallet go, how long did this order wait, which unit missed its slot.

Neither method is better in general. Researchers have built the same system both ways to compare them. Zabawa and Radosiński (2016) compared discrete rate and discrete event models on method and run time. Gleye, Reggelin and Lang (2017) built one automotive production line both ways and compared effort, speed and accuracy. Our own 2002 paper, "Non-Item Based Discrete-Event Simulation Tools," used a bottling line to compare modeling with items, with flow and with pure data, and showed where the item approach falls short. They are all on our papers page.

Most plants need both

A real plant is rarely all one thing. The packing line moves hundreds of containers a minute through accumulation conveyors. At the end of it, individual pallets go to a warehouse, each with its own destination. A good discrete rate tool lets you mix the two: rate flow on the high-speed line, individual items for the pallets that come off the end.

The right split follows the questions. If the decision is about conveyor length, buffer size, which stops to fix or what a faster filler will add, model the line as flow. If the decision is about which truck a pallet goes on, give the pallets their own identity.

A quick way to choose

Ask	If yes, lean toward
Does the line run hundreds of units a minute or more?	Discrete rate
Is the material bulk, liquid or powder?	Discrete rate
Do the answers depend on stops, buffers and accumulation?	Discrete rate
Will you run many scenarios and replications?	Discrete rate
Does each unit carry its own options or route?	Discrete event
Is the question about one specific item or order?	Discrete event

If you answer yes on both sides, you probably need a mixed model. For more on the method, see our discrete rate simulation guide. For how we apply it to real lines, see packaging line simulation and the chemical packaging case. We build these models in ExtendSim, Plant Simulation or the tool your team already uses.