Performance Baselines: Commissioning and Acceptance Checklist

A performance baseline is a documented, reproducible snapshot of how an automated warehouse system behaves under defined conditions, captured during commissioning and used for the rest of its working life. It is not a design target, a vendor brochure figure, or a single speed reading. It is an evidence-based reference that supports acceptance decisions, ramp-up planning, troubleshooting, change control, and lifecycle maintenance. This article describes a practical commissioning and acceptance checklist for establishing performance baselines, with emphasis on operating context, component interactions, evidence collection, and the common mistakes made when interpreting the numbers.

Purpose of a Performance Baseline #

Commissioning confirms that equipment is installed correctly, control software is configured, and safety functions operate as intended. A performance baseline goes one step further: it answers the question, “Under a defined set of operating conditions, at what rate, latency, and availability does this system actually work?” The value of that answer is not limited to sign-off on the day of commissioning. It becomes the yardstick for later decisions such as whether a software upgrade has degraded throughput, whether a worn conveyor is causing growing delays, or whether a newly introduced SKU mix requires a new baseline entirely.

Without an agreed baseline, every future performance complaint becomes a dispute about what “normal” means. With a baseline, operators, maintenance engineers, and controls teams can compare today’s observed behavior against a fixed, documented reference point. The baseline also exposes where system capacity truly lies. It identifies the bottleneck at a given configuration and shows how much reserve exists before the system becomes unstable. That information is essential for planning seasonal peaks and for deciding whether a change in software parameters or physical hardware will actually increase output.

Operating Context and Component Interactions #

An automated warehouse is not a collection of independent machines. It is a coupled network of mechanical, electrical, and software elements whose combined behavior determines throughput. Conveyors feed induction stations, which feed sorters, which divert to spurs, which feed palletizers or put-wall workstations. Shuttles and cranes move totes between storage buffers and pick stations. The warehouse control system (WCS) or warehouse execution system (WES) releases orders and coordinates traffic, while programmable logic controllers (PLCs) handle interlocking and fine-grained timing.

Each component has a rated speed, but system throughput is not the minimum of those rated speeds. It is the result of how the components interact under load. For example, a sorter rated at 180 cartons per minute will never reach that figure if induction conveyors have insufficient spacing or if the order-release logic sends bursts of totes that create gaps at the merge point. Similarly, a shuttle system with high vertical speed can appear fast in isolation but deliver poor overall performance if the WCS queues requests poorly and empty travel distances grow.

Component interactions also appear in subtler forms:

• Scanner read rates affect the spacing decisions made by upstream conveyors.
• Buffer fullness downstream of a merge creates back-pressure that propagates to the induction area.
• Pick-station cycle times influence the release logic that feeds the sorter.
• Recovery sequences after a jam or e-stop determine how quickly lost time is regained.

Performance testing must therefore be designed around the system as a whole, not around individual equipment certificates. A baseline that only records each motor’s speed does not tell you what the warehouse can actually ship. It is the sustained flow from order release to the final dock, with all interactions active, that matters.

Baseline Metrics and Their Meaning #

Three metric families form the core of most performance baselines: throughput, latency, and availability. Each must be defined precisely before any test begins. A metric that is not tied to a clear boundary, a defined time window, and a specific condition is open to misinterpretation later.

Throughput #

Throughput is typically expressed as units per hour, but the unit of measure can be cartons, totes, orders, or pieces, and the counting point must be unambiguous. Common counting points include induction, sorter divert, put-wall completion, or pallet wrap. The baseline should record three values: the sustained throughput maintained over a full test window, the peak throughput achieved over a short interval, and the average throughput including all exception events. Confusing these three values is a frequent source of disputes. A sorter that handles 200 units during one minute is not a 12,000-unit-per-hour system if it cannot hold that rate for an hour without jams and backups.

Latency #

Latency measures the time a unit or order spends in a defined segment of the system. Useful latency baselines include order release time to first scan, scan to induction, induction to divert, and request time to delivery for shuttle or crane transactions. Latency reveals inefficiencies that throughput alone hides. A system may maintain target throughput but carry abnormally long end-to-end lead times because units queue in buffer lanes. Establish a small set of latency points that correspond to the physical layout and support future problem investigation.

Availability #

Availability is the fraction of the test window during which the system is actually processing, excluding planned breaks but including unplanned stops such as jams, sensor faults, and software hiccups. Availability should be tracked separately from throughput because a system can recover from a jam and still meet average throughput for the hour, masking the disruption. The baseline should also record the number and duration of unplanned stops so that later changes in jam frequency or recovery time can be compared directly.

Pre-Commissioning Review #

Before running performance tests, the team must confirm that the system is in a state that makes the resulting baseline meaningful. A thorough review covers configuration status, documentation, and physical readiness.

• Record software versions for the WCS, PLCs, and any subsystem controllers. A baseline captured before a software change is valid only for that exact version.
• Confirm that all mechanical adjustments, tensioning, and alignment work is complete and signed off by the responsible parties.
• Review alarm logs from earlier installation testing to identify recurring faults that have not been fully resolved.
• Verify that sensors, encoders, and scanners are within calibration and that the control system sees signals consistent with the physical layout.
• Confirm that the system is in the correct operating mode. A test run in manual or semi-automatic mode does not represent normal production behavior.
• Check that test loads are available in the required variety and quantity, and that their dimensions, weight, and surface characteristics match the intended operational SKU profile.
• Identify which personnel will execute the test, and verify that they have been trained on the control interfaces and are aware of the test schedule.

Site procedures, lockout requirements, and OEM documentation take priority over any test plan. No performance test should be run in a way that compromises safety or requires disabling safety devices. If a test must simulate a fault condition, the simulation must follow approved procedures and must never bypass a safety function.

Controlled Test Execution #

A performance baseline should be built through staged, controlled tests rather than by simply running the system and writing down numbers. Staging allows the team to observe how the system transitions from one load level to the next and to identify the first component that begins to degrade.

Ramp-Up Protocol #

A typical ramp-up sequence begins with a dry run without product to verify that conveyors, sorters, and control software respond normally. The next stage introduces a low product rate, well below expected capacity, to confirm that scans, diverts, and order tracking work correctly. From there, the team increases the rate in controlled steps, holding each level long enough for the system to reach steady state. A short burst at a high rate is not a valid baseline unless the system maintains that rate across the full duration. Agree on the length of the steady-state window before testing begins; 30 minutes is a practical minimum for most conveyor-based operations, but longer windows are appropriate where processes have significant natural variability.

Mixed Load and SKU Mix #

Testing with a single SKU or a single box size produces an optimistic baseline that cannot be compared to day-to-day operations. The test load should reflect the real SKU mix, including variations in carton dimensions, weight, tote type, and order structure. Mixed loads force the system to exercise dimensional detection, spacing logic, and diverts under representative conditions. If the operation is expected to handle waves of same-SKU orders during peak seasons, run a separate test block for that pattern as well. Document the exact mix used for each block so that a later comparison is made against the same conditions.

Throughout all tests, appoint observers to stand at known bottleneck points such as merges, induction stations, and sorter exits. Their role is to record what the system logs may not capture, including the physical causes of jams, the location of queue build-up, and the time taken for manual clearing. This observation data is invaluable when interpreting the automated logs.

Practical Diagnostic Table #

The following table lists common symptoms observed during performance baseline testing and how to interpret them. It is a diagnostic aid, not a substitution for OEM documentation or competent engineering judgment.