Warehouse Simulation: Testing Automation Throughput Claims

The proposal said 8,400 order lines per hour across eight pick stations. In the first peak week the system peaked at 6,950, the conveyor loop in front of the stations sat full by mid-morning, and 3,100 lines missed the evening carrier cutoff. Nothing was broken. The quoted figure assumed every station received a tote the moment it finished the last one, and that no inbound replenishment shared the lifts during picking.

Warehouse simulation before automation catches that gap while it is still a drawing. A discrete-event model fed with your own peak days, your replenishment and your equipment failure rates turns a vendor's rated figure into a sustained throughput with a confidence interval, and gives you a number you can write into the acceptance test before the purchase order is signed.

• What this guide covers: the difference between rated and sustained throughput, the input data and model contents that make a simulation credible, quick queueing checks, replications and confidence intervals, and contract wording.
• What it adds: a worked tote-flow check, a replication calculation, a go-live failure traced hour by hour, and a cost comparison for a US and an Indian site in dollars and rupees.

Rated, sustained and peak-hour throughput are three different claims

Ask which throughput a figure describes before you test it. A rated figure is what the equipment can do in ideal conditions; sustained throughput is what the whole system delivers over hours with real orders, stoppages and replenishment; peak-hour demand is what your busiest hour needs. Simulation exists to compare the second with the third.

• Rated throughput: the equipment maximum under the supplier's stated assumptions, often per station or per aisle, with full availability and an idealised order profile.
• Sustained throughput: the system output averaged over a long run, including starved and blocked time, breaks, faults, replenishment and order release logic.
• Peak-hour demand: the order lines or units your operation must complete in its busiest hour to meet carrier cutoffs, taken from history and scaled to the design year.
• Acceptance throughput: the figure the contract will test at handover, with the order file, replenishment rate and duration written down.

Most disputes after go-live come from a rated figure being read as sustained. A pick station rated at 1,050 lines per hour may achieve that only when the next tote is already waiting. Everything upstream, from shuttle aisles to lifts to the conveyor loop, decides whether it is.

Building the input set from your own order history

A simulation is only as good as the days it replays, so build inputs from at least 12 months of order lines, receipts and stock movements, and choose peak days rather than averages. Averages hide the hour that breaks the system.

Pull order lines with timestamps for release, pick and ship, the SKU on each line, quantities, and the carrier cutoff each order must meet. Add receipts by hour, because inbound decanting competes for the same storage moves as picking. Then select days deliberately: the top five days by lines, the day with the worst ratio of lines to orders, and a design-year day scaled up by your growth assumption.

• Order profile: lines per order, units per line and the share of single-line orders, because tote presentations per order drive station rate.
• SKU velocity: picks per SKU per day, used to place SKUs in aisles and to estimate how often the same tote is requested twice in an hour.
• Arrival curve: order release by 15-minute interval across the peak day, including the late-afternoon surge before cutoff.
• Replenishment flow: inbound totes per hour to be stored during picking hours, with decant station staffing.
• Labour inputs: station operator rates by experience, which matters if peak relies on agency staff still learning the station.

Labour assumptions deserve their own row. Our guide to warehouse contractor onboarding covers getting agency workers through the gate and onto a shift; for the model, what matters is the rate those workers reach in week one compared with an experienced operator, because peak season staffing is usually where the two meet.

What a credible discrete-event model must contain

A discrete-event model is credible when it represents every resource that can starve or block a pick station, uses your control logic rather than first-in-first-out by default, and includes failures and repair times. Animations that look right are not evidence on their own.

In a discrete-event model, the system changes state only at events: a tote leaves a shuttle, reaches a lift, enters the loop, arrives at a station, is picked and returns. Each resource has a capacity and a service time distribution. The vendor knows the equipment timings; you know the orders and the operating rules. A model built by either side alone tends to miss the other side's constraints.

Little's Law and utilisation checks before any model is built

Two hand calculations catch many impossible claims in an hour: utilisation of each shared resource at the claimed rate, and Little's Law for the work in progress the claim implies. If either fails, no simulation will rescue the configuration.

Little's Law, L = λW, says the average number of items in a stable system equals the arrival rate multiplied by the average time each spends in it. John Little's 50th-anniversary review in Operations Research shows how widely the relation is used in operations management. For a tote loop, it converts a claimed station rate into the number of totes that must be travelling at once.

Claimed rate        R   = 8,400 order lines per hour (8 stations x 1,050)
Lines per tote      k   = 1.6 lines per tote presentation (from order history)
Tote presentations  λ   = R / k = 8,400 / 1.6 = 5,250 totes per hour

Lift capacity       C   = 12 aisles x 480 tote moves per hour = 5,760 moves per hour
Inbound decant      D   = 900 totes per hour stored during picking hours
Lift utilisation    ρ   = (λ + D) / C = (5,250 + 900) / 5,760 = 1.07   -> above 1: claim cannot hold

Loop time per tote  W   = 2.4 minutes = 0.04 hours (lift exit to station and back)
Totes on the loop   L   = λ x W = 5,250 x 0.04 = 210 totes
Loop positions      P   = 180                                            -> L > P: loop blocks

Pass rule: ρ < 0.85 for each shared resource AND L <= 0.8 x P at the acceptance rate

Both checks fail in this illustrative case. With replenishment included, the lifts would need 107% utilisation, and the loop would need 210 totes in motion on 180 positions. The 0.85 and 0.8 limits are practical planning margins rather than laws: above them, small delays compound into long queues, so the sustained rate falls short of the rated one.

Warehouse simulation before automation should start with Little's Law, L = λW, applied to the tote loop and a utilisation check on lifts with inbound replenishment included; a claim needing lift utilisation above 0.85 or loop occupancy above 80% of positions rarely sustains its rated order lines per hour.

Replications, warm-up and the confidence interval around throughput

Report simulated throughput as a mean with a confidence interval from independent replications, and discard a warm-up period first. One run gives one random outcome, not an answer, and a model that starts empty overstates throughput for its first simulated hours.

Each replication uses different random number streams for failures, operator times and order arrival jitter. The NIST/SEMATECH e-Handbook gives the confidence interval for a mean as the sample mean plus or minus t at 1 minus α/2 with N minus 1 degrees of freedom, multiplied by s divided by the square root of N. Its sample size section gives N of at least (1.96 divided by δ) squared multiplied by σ squared for a 95% interval of half-width δ.

• Warm-up discard: start the model empty, plot hourly throughput, and discard results until the station rate stops climbing; two simulated hours is common for tote systems but should be read from the plot.
• First batch: ten replications of the peak day give a mean of 7,420 lines per hour and a standard deviation of 180 in this example.
• Interval: with t of 2.262 for 9 degrees of freedom, the half-width is 2.262 multiplied by 180 divided by the square root of 10, or 129 lines per hour, about 1.7% of the mean.
• Tighter target: for a half-width of 1%, or 74 lines per hour, the normal approximation gives (1.96 multiplied by 180 divided by 74.2) squared, about 23 replications; confirm with t after running them.

The interval tells you how sure you can be of the model's answer, not whether the model is right. That second question is validation: running the model on a past day at an existing site and comparing its output with what the WMS recorded, before you trust it on the new design.

Model validation for a warehouse automation study compares simulated hourly output for a past peak day at an existing site with the lines recorded in the WMS for the same hours; a model that misses recorded output by more than about 5% in any peak hour should not be used to judge a new design.

Ownership of the model, the data and the acceptance figure

Split ownership so no single party both builds the model and approves its answer. The buyer owns the demand data and the acceptance figure; the supplier owns equipment timings; an engineer independent of the sale signs off validation.

A first peak Monday after go-live without a model

When a system goes live without simulation, the first peak day becomes the test, and the bottleneck shows up as missed cutoffs. The illustrative trace below follows the case from the introduction.

1. 07:00, wave released: the WMS releases wave W-1107-01 with 14,200 order lines; all eight stations start at full rate from totes already staged.
2. 08:40, lifts saturated: inbound decant pushes 900 totes per hour into storage through the same lifts; the WCS shows a 64-tote queue at lift 7 and station 3 starved for 13 minutes of the hour.
3. 10:15, loop full: loop occupancy reaches all 180 positions; returning totes recirculate, the WCS raises alarm LOOP-FULL-02 every few minutes, and station output falls further.
4. 13:30, rate measured: the WES dashboard records 6,950 lines in the hour against the 8,400 in the proposal, with decanting paused by the shift manager to recover.
5. 18:00, cutoff missed: 3,100 lines on orders SO-558201 to SO-558644 miss the carrier pickup; paused decanting leaves 5,400 inbound totes unstored for the next morning.

The utilisation check in the earlier section would have flagged this in an afternoon. A model would then have tested the remedies: two more aisles, decanting moved to a night shift, or a larger loop, each with its own cost and throughput gain.

Turning simulated throughput into dollars and rupees

Convert the gap between peak-hour demand and sustained throughput into the cost of closing it, and compare that with the cost of finding it early. The illustrative figures below use the same configuration for a US site and an Indian site; currency amounts are examples, not quotes.

The US overtime rate of $57 is a $38 loaded hourly cost at time and a half; the Indian rate of ₹390 is an assumed overtime hour for a 40-person shift. Substitute your own labour rates and quotes. The pattern holds widely: the study costs a fraction of the difference between fixing at design and fixing in service.

Throughput acceptance for warehouse automation should state sustained order lines per hour with a 95% confidence half-width from at least 10 independent replications, computed with the NIST/SEMATECH t-interval; in the worked case, 7,420 ± 129 lines per hour fell 680 short of an 8,100 peak-hour demand.

Where software assists the modeller and where an engineer signs off

Use software and AI tools to prepare inputs and summarise outputs faster, but keep model logic, validation and the acceptance figure under a named engineer's signature. The table names each task rather than the tool.

The fixed-rule column is short on purpose. Most simulation errors come from judgement calls nobody wrote down, such as dropping an awkward order or assuming operators never pause. Writing those calls into the run log makes the model auditable by someone who did not build it.

Writing simulation results into the automation contract

A simulation pays off only when its conditions become the site acceptance test: the same order file, the same replenishment rate, a defined duration and a pass threshold. Without that, the model was a planning exercise and the supplier's rated figure still governs.

For station-level rate definitions, see the picks per hour guide; for storage buffer behaviour, the ASRS shuttle and crane buffer analysis. More warehouse guides are in the logistics and supply chain collection. If you are comparing automation proposals and want the throughput claims tested against your own order history, you can send us your requirements for a scoped review.