Factory Acceptance Testing (FAT) is a structured verification event performed before a system leaves the supplier environment, yet its results echo far beyond the test bay. In warehouse automation, a FAT is not a simple demonstration of a machine moving a box; it is the first controlled opportunity to confirm that the system, as designed and assembled, behaves according to the agreed functional specification under conditions that approximate real operation. This article explains the operating principles that make a FAT meaningful, defines the system boundaries that separate factory validation from site acceptance, and offers practical guidance for warehouse operators, maintenance engineers, and controls teams who must interpret FAT evidence without overstating its predictive power.
The Purpose and Timing of a Factory Acceptance Test #
A FAT exists to reduce risk before capital equipment is physically moved, reinstalled, and integrated into a live facility. It is the point at which the supplier demonstrates that the hardware, software, and control logic work together as an assembled system, rather than as individual components. For the buyer, the FAT is the last opportunity to observe the system in a controlled environment with relatively low cost of change. Once the system is on its way to the warehouse, corrections become more expensive, schedule pressure increases, and the operational environment introduces variables that are difficult to isolate.
The timing of a FAT is equally important. It should occur after component testing and after the integration of the complete unit, but before the system is prepared for shipment. A well-structured FAT leaves enough time for corrective action without delaying the overall project plan. If a FAT is rushed or scheduled too late, it becomes a ceremonial formality rather than a genuine verification milestone. Operators and engineers should treat the FAT as a test of the system, not a test of the observers’ patience.
Operating Context: What the FAT Can and Cannot Simulate #
Every warehouse automation system operates within a broader material flow ecosystem. Conveyors interact with sorters, palletizers interface with stretch wrappers, and automated storage and retrieval systems exchange loads with automated guided vehicles. A FAT typically addresses one major system subassembly, not the entire warehouse. Consequently, the operating context of a FAT is deliberately simplified. The test simulates load conditions, sequence timing, and control messages, but it cannot reproduce the full dynamics of a live facility.
This is not a weakness if understood correctly. The FAT verifies that the system can execute its defined functions under representative conditions. It tests the logic, the mechanical motion, the sensor response, and the interface behavior. What it cannot verify is how the system will perform under unplanned traffic congestion, degraded operator behavior, or infrastructure anomalies such as fluctuating power quality or building network latency. These conditions belong to site acceptance testing, and operators who expect the FAT to prove site-level performance will misread the evidence.
Core Component Interactions Under Test #
A warehouse automation system is governed by several interacting layers: the mechanical structure, the motor and drive systems, the sensing network, the programmable logic controller, and the higher-level warehouse control system. The FAT is the first time these layers are intentionally exercised as a unified whole. Each layer presents distinct failure modes and observable behaviors.
Mechanical and Drive Systems #
Mechanical verification includes checking that moving elements travel within expected bounds, that end stops are correctly positioned, and that alignment tolerances are met. But the FAT goes deeper: it verifies that the drive systems respond to commands with appropriate acceleration and deceleration, that homing sequences are repeatable, and that mechanical binding does not occur after multiple cycles. Motor currents, travel time, and positioning accuracy are all observable parameters that indicate whether the electromechanical pair is well matched.
Sensing and Control Logic #
The sensing network is the nervous system of the equipment. Photoelectric sensors, limit switches, encoders, and safety interlocks must all report states to the controller in the correct order. The FAT validates that the control logic interprets these signals correctly under both normal and deliberately induced fault conditions. For example, a sorter should reject a product that fails to arrive within a prescribed window, and a transfer shuttle should not move if the destination is not clear. The sequence logic is especially important; subtle race conditions often do not appear until multiple signals change state nearly simultaneously.
Warehouse Control System Interface #
Modern automation systems do not operate as islands. They receive transport orders, confirm job completion, and report status to a warehouse control system or warehouse management system. The FAT should include a simulated interface test, where synthetic orders are injected and the system’s response is compared to the expected message structure. This is a common point of misunderstanding: a system may appear functional mechanically but fail the FAT because of message handshaking issues that will cause disruption during commissioning.
Observable Symptoms and Acceptance Criteria #
Acceptance criteria are the reference points against which the FAT is judged. These criteria should be quantitative, written, and agreed in advance. Observable symptoms are not just pass or fail events; they are patterns that reveal the health of the system. A table of symptom patterns helps test observers move from a vague impression of “it worked” to a structured diagnosis of subsystem performance.
| Observed Symptom | Likely Involved Subsystem | Evidence to Collect | Typical Boundary Question |
|---|---|---|---|
| Repetitive cycle time drift beyond specified tolerance | Drive tuning, motor thermal limits, or mechanical drag | Cycle time stamps, motor current logs, temperature readings | Is the drift a function of load weight, ambient temperature, or accumulated wear? |
| Intermittent sensor false triggers | Sensor alignment, reflective surfaces, or electrical noise | Sensor state capture, waveform traces, event timestamps | Does the trigger occur at the same mechanical position or at the same point in the PLC scan? |
| Positioning error increases with speed | Encoder resolution, controller gain, or mechanical backlash | Position deviation records, axis speed profiles, repeatability measurements | Is the error consistent with a lag error, a deadband error, or a mechanical slip? |
| Order sequence executes correctly in manual mode but fails in automatic mode | Warehouse control system logic, message timing, or handshake protocol | Interface message logs, PLC trace, order completion records | Does the failure follow a data content issue or a timing/sequence issue? |
| Safety interlock interrupts motion unexpectedly during a non-hazardous phase | Guard switch adjustment, circuit wiring, or logic misconfiguration | Interlock event log, physical guard position inspection, schematic review | Is the interrupt caused by a real guard movement or by a false signal from a damaged component? |
| Settling time increases after repeated cycles | Mechanical wear, thermal expansion, or lubricant degradation | Bearing temperatures, vibration measurements, cycle count records | Is the system approaching a maintenance limit during the FAT, or is it a setup issue? |
The table above is a diagnostic guide, not a substitute for the supplier’s test documentation. Every parameter in the acceptance criteria must be measured with an instrument that is calibrated and traceable. Subjective assessments such as “looks smooth” are insufficient. A reliable FAT produces numerical evidence, including timestamps, counts, and deviations, that can be reviewed later during commissioning.
Evidence Collection During a FAT #
Evidence collection is the discipline that turns a FAT from a demonstration into a traceable record. The buyer’s team should bring a structured test script derived from the functional specification. Each test case should have a unique identifier, a clear objective, a described procedure, and a pass condition that is measurable. During the execution, the team records results, observations, and deviations. This record becomes part of the project documentation and is referenced during site acceptance and future audits.
It is not enough to record that a test passed. The team must capture the conditions under which the test was executed. Ambient temperature, input voltage, load weight, and software version all affect performance. If the software changes after the FAT, the evidence from the original test may no longer be valid for the new revision. The same applies for hardware modifications. For this reason, the evidence log should include the exact software revision and hardware revision numbers, along with the calibration date of any measurement instruments used.
Photographs and video recordings are valuable supplementary evidence, but they must be annotated. A video clip of a conveyor running is of limited use unless the timestamp, cycle count, and corresponding test case identifier are recorded in the same frame. Practical evidence collection also includes capturing the state of the human-machine interface, alarm history, and any configuration parameters that were changed during the test. These records support later troubleshooting by the maintenance team.
Common Interpretation Errors #
Misreading FAT results is a frequent source of project friction. One common error is treating a pass as a promise of site performance. A FAT conducted in the supplier’s facility cannot account for floor flatness, building heating cycles, dusty environments, or the behavior of operators from the customer’s crew. Passing a FAT means the system met the specification in that environment at that time, not that it will meet operational targets indefinitely.
A second interpretation error is confusing the FAT with a stress test. If the acceptance criteria specify a throughput of four hundred cycles per hour, a FAT that runs at three hundred cycles per hour without failure does not prove the higher rate. The evidence only supports the rate that was actually tested. To gain confidence at the higher rate, the test must be executed at that rate for a meaningful duration. A two-minute burst is never evidence of sustained throughput. Fatiguing bearings, overheating drives, and accumulating software errors all take time to manifest.
A third error is dismissing warning signs as “factory quirks” that will disappear at site. A sensor that intermittently triggers during the FAT will likely be a chronic nuisance in the field. A PLC that loses communication during a long run is a genuine defect. These issues must be resolved before shipment, because the cost of debugging them at site is considerably higher, and the evidence collected there will be contaminated by a hundred other variables.
Finally, teams often overlook the difference between a failure and a deviation. A failure is a clear violation of an acceptance criterion. A deviation is a behavior that does not satisfy the strict criterion but is judged to be acceptable for the time being. Every deviation should be documented, acknowledged by both parties, and assigned a corrective action. Unadjudicated deviations are a common source of disputes later, particularly when the site acceptance test reveals the same deviation again.
Maintenance Implications of FAT Results #
For the maintenance team, the FAT is a preview of the equipment’s normal operating envelope, and the observations made during it inform spare parts planning, lubrication schedules, and inspection intervals. If the FAT reveals, for example, that a particular drive runs hot under nominal load, the maintenance plan should include more frequent infrared checks for that drive. The FAT data serve as a baseline for trend analysis; comparing future motor currents and cycle times against the FAT baseline helps identify degradation before it causes a failure.
The FAT also provides an opportunity to validate the accessibility of maintenance points. While the equipment is in the factory, it is relatively easy to ask for additional clearance spaces or to document the location of grease fittings. Once the equipment is installed in a dense warehouse layout, such changes are more intrusive. Maintenance engineers should review the FAT from the perspective of reachability, tool requirements, and the time needed to replace a component. If replacing a sensor requires the removal of a guard and a structural bracket, that information should be captured in the maintenance planning documents.
Another maintenance implication concerns software backup. The FAT is the point at which the verified control software configuration can be archived with confidence. After the FAT, the maintenance team should have a secure copy of the PLC program, the human-machine interface project, the drive parameters, and the system documentation. This archive is essential for fault recovery. The FAT also verifies that the equipment can be started, stopped, and reset in a controlled manner, and these procedures should be recorded in the maintenance manual.
Decision Boundaries and Handover Logic #
The FAT sits at a decision gate: the boundary between the supplier’s factory and the customer’s site. It is essential to define, before the FAT begins, what authority the observers have to stop the test or to request changes. A balanced protocol distinguishes between critical defects, which must be corrected before shipment, and minor observations, which may be deferred as long as they are documented and do not compromise safety or operability.
A critical defect typically includes any safety interlock malfunction, any failure to meet a stated cycle time under nominal load, any software bug that causes an uncontrolled motion, and any unexplained loss of communication between the control layers. Minor observations might include cosmetic paint damage, labels that are not legible from the intended viewing distance, or a preference for a different display layout on the human-machine interface. These are not reasons to delay shipment, but they should be tracked through resolution.
The decision to pass or fail should be explicitly recorded by both parties. If a test fails, the responsible team investigates, applies corrective action, and re-runs the test. It is not adequate to fix one symptom and assume the entire procedure is validated; the relevant test must be repeated under the same documented conditions. The decision gate should also include a clear rule for partial shipment. If a system consists of multiple conveyors delivered in separate loads, the FAT ideally validates the interconnected operation on the factory floor before disassembly. If a partial FAT is necessary, the scope should be clearly limited so that no observer assumes the entire system was tested.
Handover logic also applies to documentation. A FAT is not complete until the test records, deviation list, backup software, as-built drawings, and maintenance recommendations are handed over in a structured format. These documents accompany the equipment to the site and form the foundation for the site acceptance test. Without these records, the site team is forced to rediscover the system’s behavior, which wastes time and increases commissioning risk.
Safety and Authorization Boundaries #
No discussion of testing is complete without a clear statement on safety. During a FAT, observers may be tempted to reach toward a moving conveyor, to defeat a guard switch, or to override an interlock in order to “see what happens.” These actions are never acceptable. Site procedures, lockout requirements, OEM documentation, and the competent judgment of the authorized engineering team always take priority over any test objective. Observers should be instructed on the emergency stop locations, access boundaries, and the communication protocol before the test begins. A FAT that compromises safety, even if it produces passing data, is a failed event in every meaningful sense.
Key Takeaways #
- A FAT verifies integrated function under representative conditions; it is not a guarantee of all site-level performance outcomes.
- Acceptance criteria must be quantitative, written, and agreed before the test begins; subjective observations are not evidence.
- Diagnostic evidence should include timestamps, software revisions, instrument calibration, and the exact test conditions to remain valid for later reference.
- Throughput claims are only supported when the equipment runs at the claimed rate for a sufficient, sustained duration; short bursts prove little.
- Deviations and failures must be documented separately, and every deviation should have an assigned owner and completion date.
- FAT baseline data, including motor currents, cycle times, and temperatures, form the foundation for future predictive maintenance.
- Maintenance teams should use the FAT to assess component accessibility and to archive verified software and parameter backups.
- The FAT decision gate must specify which defects block shipment, which observations are deferred, and how the records are handed over for site acceptance testing.
- Safety protocols, lockout requirements, and OEM guidance always supersede test expedience; no observer is authorized to bypass a safety device.
