Factory acceptance testing (FAT) is a structured evidence-gathering exercise conducted before a material handling system leaves the supplier’s integration facility. For a warehouse operator, the FAT is the first point where the gap between a design intent and an installed reality becomes measurable. It is not a demonstration, a courtesy tour, or a checklist to be signed under schedule pressure. It is the commissioning stage where the system’s configured behavior, program logic, and physical interactions are tested against the agreed functional specification. This article provides a commissioning-oriented FAT checklist, explains what evidence matters, identifies common interpretation errors, and clarifies where the FAT ends and site acceptance begins.
The FAT in the Commissioning Lifecycle #
The FAT sits between design freeze and site installation. It is typically performed at the supplier’s facility, often on a partial or full replication of the intended layout. The operating context differs from the live warehouse in several ways: the physical environment is cleaner and less congested, the SKU mix may be simulated, and the surrounding infrastructure such as dock doors, WMS interfaces, and fire systems is absent. That context does not invalidate the FAT; it defines its limits. The FAT verifies that the material handling system, as built and programmed, can execute the functions it was designed for under controlled conditions.
Component interactions are the core of the FAT. A conveyor motor that spins on its own is trivial; a conveyor motor that spins only when the upstream photo-eye confirms no queued carton, while the downstream accumulator signals availability, starts to represent real behavior. The FAT should test these interactions at multiple levels: sensor-to-controller, controller-to-drive, drive-to-mechanical, and system-to-emulated host. Each level reveals a different failure class. Sensor-to-controller failures are wiring and addressing errors. Controller-to-drive failures are parameter and safety-circuit issues. Drive-to-mechanical failures are alignment, tension, and tolerance issues. System-to-emulated-host failures are data-model and interface logic issues.
Warehouse operators often treat the FAT as a “dry run” of the site acceptance test. That is a reasonable mental model, but it understates the FAT’s value. The FAT is where the supplier’s integration team, the operator’s maintenance group, and the controls engineers align on behavior expectations. It is also the last opportunity to identify design errors while the cost of correction is still relatively low. Moving a photo-eye after installation may require structural modification, new cable routing, and reprogramming; moving it at the FAT requires a bracket adjustment and a test repetition.
Scope Definition and Baseline Documentation #
A FAT only has meaning if its scope is bounded by a written reference. The most important baseline documents are the functional specification, the material flow diagram, the I/O list, the sequence of operations, and the performance criteria agreed at the commercial stage. If any of these documents is outdated or ambiguous, the FAT will default to dispute rather than verification. Prior to the test, the operator should confirm that the supplied bill of materials matches the tested configuration. Conveyor lengths, drive locations, curve angles, and safety device placement should be visually checked against the layout drawing. The FAT is not the time to discover that an infeed conveyor was designed 2 meters short of the dock interface.
Baseline conditions also include software revision levels. The PLC program, HMI screens, drive parameter files, and any vision-system configuration should be recorded with version identifiers and timestamps. This establishes a traceable starting point for the commissioning phase. If a fault appears on site, the site team needs to know whether the installed software is exactly what was tested. Without revision control, troubleshooting becomes an archaeology exercise.
One practical baseline action is to photograph and record machine nameplate data for every major component. Motor power, gearbox ratio, belt type, and sensor family all affect spare parts planning. The FAT provides close access to these components while they are still in the integration bay. On a live site, the same data collection may require platform lifts, working-at-height permits, and disruption to operations.
Test Protocol Design and Evidence Collection #
A test protocol is a sequence of scripted actions, expected results, and pass/fail criteria. It should not be written by the supplier alone. The operator’s controls and maintenance teams should review the protocol before the FAT date. The review catches two common problems: tests that only exercise happy paths, and tests that are so equipment-centric that they ignore operational sequences. A good protocol includes normal operation, degraded operation, recovery, and security-related checks such as whether an unauthorized user can change a critical parameter without a log entry.
Evidence collection is the discipline that separates a FAT from a tour. For every test step, the operator should record:
- Start and end time of the step
- Software and hardware revision under test
- Actual result, not the expected result
- The person operating the system and the person witnessing the test
- Photographs, video, or trend plots of significant events
- The exception report number and the agreed corrective action
Photographs are particularly valuable for intermittent faults. A momentary sensor misalignment may appear and disappear within seconds. A high-resolution photograph taken while the system is stopped can show a bracket that flexes under load. Trend plots from the PLC are the definitive evidence for timing-related issues. If the protocol does not already include data logging, request that the supplier enable it. The same trend data will be needed during ramp-up on the live site.
Throughput Evidence and Ramp-Up Logic #
Throughput claims are the most contested part of a FAT. The commercial specification may state a nominal rate, such as 1,200 cartons per hour. A FAT that runs one hour at nominal speed and records 1,200 cartons has not demonstrated throughput; it has demonstrated that the system can move one carton every three seconds under continuous feed. Real throughput includes gaps, SKU changes, barcode read failures, and downstream jams. Therefore, the test protocol should separate steady-state capacity from sustained throughput.
A practical method is to run three test blocks: a short burst at maximum speed with ideal spacing, a longer run over two to four hours with realistic gap distribution, and a mixed-SKU run that includes changeovers and rejects. The evidence that matters is not the peak rate observed in the burst, but the sustained rate over the long run. Ramp-up logic is also tested here. The system should be able to start from a cold condition, incrementally increase to full rate, recover from a pause, and then restart without losing tracking data. If the controls architecture was designed as a series of sequential zones, the ramp-up behavior will reveal whether the release logic properly throttles the infeed.
Failure Injection and Recovery Testing #
The most revealing FAT tests are those that deliberately inject failures. Failing a photo-eye, jamming a diverter, removing a carton from a lift, or interrupting the emulated host connection will expose how the system behaves under abnormal conditions. The operator should observe several things: does the system alarm with a useful message, does the downstream equipment stop in a safe and correct sequence, and does the recovery procedure restore normal operation without manual intervention at every zone?
Recovery testing is especially important for autonomous or semi-autonomous equipment such as shuttles, AGVs, and robotic arms. An unexpected stop mid-cycle can place a load in an indeterminate state. The recovery procedure must allow a technician to resume the cycle without risking collision or misidentification. This is also where competent engineering judgment is most needed. The FAT is not a place to accept a recovery procedure that requires operators to push loads by hand while the system is partially energized. Site procedures, lockout requirements, and OEM documentation take priority over any test convenience.
Component Interactions and Subsystem Boundaries #
A warehouse material handling system is a federation of subsystems: conveyors, sorters, lifts, goods-to-person stations, robotic cells, and the warehouse control system (WCS). Each subsystem may have its own controller, its own safety logic, and its own diagnostic interface. The FAT must define the boundaries between these subsystems and test how messages flow across them. A common failure pattern is an electromechanical subsystem that works correctly in isolation but misbehaves when the WCS sends an unexpected command sequence. For example, a lift may handle a single destination command without issue, but if the WCS queues three destination commands in rapid succession, the lift controller may reset or fail to confirm the destination.
Testing these boundaries requires the supplier to provide a simulated host or a communications gateway. The operator should inspect the data model: message formats, field lengths, timeout values, and error handling. A timeout value that is too short will generate false errors when the WCS is slow; a timeout value that is too long will create silent gaps in tracking. These parameters are often hidden in configuration files rather than in the HMI, and the FAT is the time to document them.
Mechanical and electrical interfaces also merit boundary testing. The connection between a conveyor and an adjacent palletizer may span a gap that opens when one structure flexes under load. The FAT layout should replicate the interface dimensions as closely as possible, and the test should include full-load passes across the joint. Similarly, the electrical interface between the main control panel and a remote I/O cabinet can produce intermittent signal issues if cable routing and grounding are incorrect. These issues are difficult to diagnose on site because the building’s grounding environment masks or amplifies the problem.
Practical Diagnostic Table: FAT Symptom Patterns #
The following table summarizes common FAT observation patterns, the possible interpretations, the evidence that should be collected, and the decision boundary. It is not a substitute for the supplier’s fault tree or OEM documentation; it is a starting point for investigation.
| Observed Symptom | Possible Interpretations | Evidence to Collect | Decision Boundary |
|---|---|---|---|
| Throughput falls below nominal during a two-hour run, though the burst test passed. | Infeed release logic is throttled by downstream queues; sensor timing on a merge is marginal; the control loop is not recovering from short jams. | Trend plots of zone occupancy, jam counters, conveyor start/stop counts, and run timeline with pause events. | Fail if sustained throughput is below the commercial requirement after two repeats at realistic gap distribution. |
| Intermittent photo-eye failure that cannot be reproduced on demand. | Loose mounting bracket with harmonic vibration; marginal sensing range under ambient lighting; contamination on the lens; intermittent wiring connection. | High-resolution photos of mounting, voltage measurements at the sensor, PLC input status history, and vibration readings if available. | Fail if the sensor repeatability does not meet the OEM specification over 100 test cycles. |
| Sorter divert position drifts during a mixed-SKU run. | Mechanical linkage wear is accelerated by side force; pneumatic cushioning is misadjusted; the divert timing is based on a fixed position instead of a measured gap. | Video of consecutive diverts, position error trend from the sorter controller, and pressure readings on the pneumatic circuit. | Conditional accept if the drift is within tolerable bounds and the supplier provides a documented adjustment interval. |
| Controller restart loses order-to-load tracking data. | Data is held only in volatile memory; tracking is not acknowledged by the WCS; the sequence of operations does not include a restart reconciliation. | Recovery procedure log, stored data locations, WCS transaction logs before and after restart. | Fail if the system cannot reconcile tracking after an unplanned restart without manual recount. |
| Safety circuit trips during a normal load transfer at a lift gate. | Safety sensor timing is too aggressive relative to the load position; interlock contact is bouncing; load profile is different from the design specification. | Safety relay input status, interlock contact waveforms, and load position photos at the trip moment. | Fail if the trip is caused by a design mismatch. Do not attempt to bypass or adjust the safety device. Follow OEM documentation. |
Common Interpretation Errors #
One of the most frequent interpretation errors at a FAT is treating a single successful cycle as proof of correct operation. A system that completes one pallet build, one case pickup, or one induction sequence may still fail on the fourth repetition when a sensor accumulates a small amount of drift or a stack height changes. The protocol should require a minimum number of repetitions for each sequence, and the operator should be suspicious of a test that only shows one clean cycle.
A second error is comparing the FAT result to the requested throughput rather than to the agreed operating profile. Most warehouses do not run at a constant rate for eight hours. They experience bursts, gaps, empty zones, and changes in SKU mix. A system that achieves 95% of nominal throughput in the FAT but cannot handle a gap in the infeed without losing tracking will produce more operational pain than one that runs at 80% rate but recovers cleanly from gaps. The FAT should therefore prioritize recovery and robustness over raw peak rate.
A third error is confusing a delayed case with a jam. A product that arrives late at a downstream position is not always jammed. It may be delayed because the upstream conveyor speed profile is not matched, or because the release logic from the WCS inserted an intentional gap for spacing. The observer should note whether the delay is consistent and structured, or random and sticky. Structured delays indicate a control scheduling issue; random delays indicate a mechanical or sensor problem.
A fourth error is accepting a remote diagnosis without local evidence. If the supplier’s engineer changes a PLC parameter while the test is running, the operator should ask for the prior value, the new value, and the reason. Uncontrolled parameter changes during the FAT make it impossible to reproduce the exact configuration on site. Every parameter change should be logged and included in the as-built documentation.
Maintenance Implications and Lifecycle Planning #
The FAT produces more than a pass/fail decision; it produces the first real maintenance data set for the system. Watch the system closely during the test for signs of wear, vibration, or unusual noise. A drive chain that is noisy at the FAT will become a source of persistent downtime after six months of operation. Record which components show visible heat, how frequently jams occur, and which zones require operator intervention. This data informs the spare parts holding strategy and the preventive maintenance schedule.
Ramp-up on the live site is usually more painful than the FAT because the system must integrate with real WMS transactions, live operators, and building services. The FAT can reduce this pain by confirming that the system can tolerate input variation. A system that only works with perfectly packed cartons at the FAT will fail dramatically when a real operator puts an overfilled carton on the infeed. The acceptance checklist should include deliberately imperfect loads: a slightly tilted carton, a torn label, a load that is narrower than the conveyor, and a box that is heavier at one end. These variations simulate the real distribution of operator behavior.
Lifecycle planning also begins at the FAT. The operator should collect the full list of component suppliers, part numbers, and recommended spares. Calibration procedures, such as sorter timing adjustment or lift position offsets, should be requested in writing. The FAT is also the time to confirm that the maintenance team has read-and-understood access to the HMI and that diagnostic messages are useful to a technician. A system that alarms with a generic code while the root cause requires opening the control cabinet is a maintenance liability, and the FAT is the right place to raise that concern.
Change control is part of lifecycle planning. The FAT establishes a baseline configuration. After the FAT, the supplier may ship the system, and during installation the software may be updated to fix a bug discovered in a sister project. The operator should establish that any change after the FAT is documented, reviewed, and, if significant, retested. Without this discipline, the site acceptance test will be performed on a system that no longer matches the FAT evidence.
Decision Boundaries: Accept, Conditionally Accept, or Reject #
The FAT concludes with one of three decisions. An accept means that all critical and major observations are resolved or are formally risk-accepted in writing with the rationale attached. The system is released for shipment and site installation. A conditional accept means that the system is functionally sound but has a defined list of outstanding items, each with an agreed corrective date and a verification method. Conditional acceptance is appropriate for items that do not affect the safety, fundamental performance, or core functionality of the system. A reject is appropriate when the system fails to meet a critical requirement, when there is a safety defect, or when the performance gap is so large that correcting it after shipment would be less efficient than continuing work at the supplier’s facility.
The operator should insist that the decision be tied to the evidence rather than to the calendar. If the test protocol has not been completed, or if the trend data does not support the pass claim, the decision should be delayed. It is the supplier’s responsibility to provide the means of testing, but it is the operator’s responsibility to witness and verify. Both parties should sign the FAT report only after the evidence is reviewed.
Finally, the FAT does not replace the site acceptance test. The live system will be installed in a different physical environment, connected to the real building network, and operated by personnel who were not present at the FAT. The FAT is the reference point, not the final proof. This is why the evidence collection and documentation standards of the FAT must be high. The site acceptance test will be evaluated against the same functional specification, and the FAT report is the baseline for that comparison.
Key Takeaways #
- The FAT is an evidence-gathering event, not a demonstration. Every test step should produce a recorded result that can be
Related Pearl Gateway Guides #
