Direct answer #
Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT) are the formal gates that prove a warehouse automation system meets its specified requirements before financial and operational handover. This guide defines a rigorous, evidence-based methodology: every test must trace to a requirement, use a defined method, capture objective evidence, and pass a measurable acceptance criterion. The owner of each test must be named, and the disposition of every failure—whether re-test, waiver, or deviation—must be documented. The process is not a final demonstration; it is a structured verification and validation activity. This reference provides the editorial framework, templates, and worked calculations to plan, execute, and close out FAT and SAT phases, with explicit attention to safety boundaries, traceability, and the operational realities of conveyor, sortation, and robotic systems.
Key takeaways #
- Traceability is the backbone: Each test case must link to a specific requirement ID, and each requirement must link to a design element or contract clause. Without this bidirectional traceability, a passed test proves nothing about system compliance.
- Evidence is objective and time-stamped: Evidence includes raw data logs, video recordings, signed checklists, and instrument calibration certificates. Subjective observations like “ran smoothly” are not acceptable evidence.
- Acceptance criteria are numeric and pre-defined: Criteria such as throughput (units/hour), read rate (%), jam frequency (jams/10,000 cycles), and recovery time (seconds) must be written before testing begins, not interpreted after results are known.
- Exit criteria are non-negotiable: A phase is not complete until all critical tests pass, all major defects are closed or have an approved disposition, and all evidence is archived in the project repository.
- Safety is a boundary condition, not a test item: Lockout/tagout procedures [S3] and machine guarding [S4] are legal requirements that constrain how tests are performed, not optional test criteria.
- Statistical rigor prevents false confidence: Sample sizes for tests like read-rate verification must be calculated to achieve a stated confidence level, not chosen arbitrarily [S2].
- Disposition is a decision, not a default: Every failed test requires a formal disposition: re-test after fix, approved deviation, or waiver with documented risk. The decision owner must be named.
Scope and objectives of FAT and SAT #
Factory Acceptance Testing (FAT) is performed at the supplier’s or integrator’s facility, typically before equipment is shipped. Its purpose is to verify that the manufactured or integrated system meets the design specifications and functional requirements in a controlled environment. Site Acceptance Testing (SAT) is performed at the final operating location after installation and commissioning. SAT verifies that the system operates correctly in its intended environment, including interactions with site infrastructure, utilities, and existing networks.
The objectives are distinct but complementary. FAT reduces the risk of shipping defective or non-conforming equipment. SAT validates the installation, integration, and environmental readiness. Both phases must be planned with the same rigor: a test plan, a schedule, named participants, and a documented decision process. The systems engineering principle of verification and validation applies directly: FAT is primarily verification (did we build it right?), while SAT is primarily validation (did we build the right thing?) [S1].
This guide treats FAT and SAT as two phases of a single acceptance process. The test architecture—requirements, methods, evidence, criteria—is identical; only the environment and some specific test cases differ. A common mistake is treating SAT as a repeat of FAT with the same scripts. SAT must include site-specific tests: power quality, network latency, physical clearances, and integration with the warehouse management system (WMS) or warehouse execution system (WES) as installed.
Requirements traceability matrix (RTM) #
The Requirements Traceability Matrix (RTM) is the controlling document for the entire acceptance process. It is a table that maps every requirement to one or more test cases, and every test case to a requirement. The RTM is created during the design phase and updated throughout the project. It is not a post-test summary; it is a planning tool that ensures no requirement is untested and no test is orphaned.
Each requirement must have a unique identifier (e.g., REQ-001), a source (e.g., contract clause, design document, regulatory standard), and a verification method. The verification method is one of four types: Test (execution of a procedure), Analysis (calculation or simulation), Inspection (visual or dimensional check), or Demonstration (operational show without formal measurement). The RTM must also record the phase (FAT or SAT) where the verification occurs.
An illustrative example: REQ-014 states “The sortation system shall achieve a throughput of 6,000 units per hour (uph) for cartons within the specified size range.” The verification method is Test. The FAT test case TC-014-01 runs the system at nominal speed for 60 minutes and measures output. The SAT test case TC-014-02 repeats the measurement with the installed conveyor layout and site power. Both test cases are linked to REQ-014 in the RTM.
The RTM is also the primary audit trail. During the final acceptance review, the project manager, quality engineer, and customer representative walk through the RTM line by line. Any requirement without a passing test, or any test without a linked requirement, is a blocker to sign-off. The RTM should be maintained in a shared repository with version control, and changes must be approved by the change control board.
Test case design: method, evidence, and acceptance criteria #
Each test case is a standalone document that defines five mandatory elements: the requirement ID, the test method, the evidence to be captured, the acceptance criterion, and the test owner. Without all five, the test is not executable. The test method must be detailed enough for a competent technician to execute without prior knowledge of the system. It includes setup conditions, input parameters, step-by-step actions, and the duration of the test.
Evidence is the objective record that the test was performed and the result was achieved. Evidence types include: time-stamped system logs, video recordings with visible timestamps, signed and dated checklists, screenshots of HMI screens, and output from calibrated instruments. For automated systems, the preferred evidence is raw data logs exported from the control system, not manual tallies. Manual tallies are acceptable only when no automated data source exists, and they must be countersigned by two people.
Acceptance criteria must be numeric and measurable. Phrases like “system shall operate reliably” are not acceptable. A correct criterion is “the system shall operate for 60 continuous minutes with zero unplanned stops attributable to the control system.” The criterion must also define the pass/fail boundary. For example, if the criterion is a read rate of 99.5%, the test must specify how many reads are required to demonstrate this with statistical confidence (see the Worked example section).
The test owner is the single person accountable for executing the test and reporting the result. The owner is typically the supplier’s test engineer during FAT and the site commissioning engineer during SAT. The customer’s witness is not the owner; the witness has the authority to observe and challenge, but not to execute. The owner signs the test record, and the witness signs to confirm observation.
Test execution protocol and witnessing #
Test execution follows a strict protocol to ensure consistency and to protect personnel. Before any test begins, a pre-test briefing is held. The briefing covers: the test objective, the safety hazards, the emergency stop procedure, the roles of all participants, and the exact sequence of actions. The briefing is documented with a sign-in sheet. No test proceeds without a completed briefing.
Witnessing is a critical control. The customer or their authorized representative has the right to witness any test. The witness’s role is to confirm that the test was executed as written and that the evidence is authentic. The witness does not operate equipment unless explicitly trained and authorized. If the witness disagrees with the result, they can record a formal observation, which is logged and resolved before the test is closed.
During execution, the test owner records the start time, end time, and any deviations from the written method. Deviations are not failures; they are events that must be documented. For example, if a test requires a conveyor speed of 1.5 m/s but the VFD is set to 1.45 m/s, this is a deviation. The deviation is recorded, and the test result is evaluated in the context of the deviation. If the deviation affects the validity of the test, the test is re-run.
Safety boundaries are absolute. Tests are paused or aborted if any unsafe condition is observed. The authority to abort a test rests with any participant, not just the test owner or safety officer. This is consistent with the principle that safety is a boundary condition, not a test item [S3][S4]. After an abort, the test cannot be restarted without a new briefing and a root cause investigation.
Evidence management and data integrity #
Evidence is the currency of acceptance testing. Without credible evidence, a test result is an assertion, not a fact. Evidence management begins before the test with a defined naming convention and storage location. The convention includes the project ID, test case ID, date, and a sequence number. For example: PRJ-2024-001_TC-014-01_2024-11-15_001.log.
Data integrity requires that evidence cannot be altered after the test. This is achieved through controlled storage, access permissions, and, where practical, cryptographic hashing. The project repository should be on a server with access controls, not on a local laptop. For critical tests, a hash of the raw data file is recorded in the test record. If the file is later challenged, the hash is recomputed and compared.
Video evidence is powerful but must be managed carefully. The recording must show the test setup, the equipment under test, and the timestamp. A camera angle that only shows the HMI screen is insufficient; it must show the physical equipment operating. For long-duration tests, a time-lapse recording is acceptable if the timestamp is visible and the recording is continuous.
Calibration certificates for all measurement instruments are part of the evidence package. A stopwatch used to measure cycle time must have a calibration certificate traceable to a national standard. The certificate must be current (within the calibration interval) and must cover the range of measurements taken. If an instrument is out of calibration, all tests using that instrument are invalid and must be re-run.
FAT-specific test categories #
FAT focuses on verifying that the equipment as built meets the design specification. The test categories are: mechanical inspection, electrical verification, functional testing, and performance testing. Mechanical inspection verifies dimensions, clearances, and assembly quality. Electrical verification checks wiring continuity, insulation resistance, and proper termination. Functional testing exercises each control function, such as start/stop, emergency stop, and mode selection. Performance testing measures throughput, speed, and accuracy under controlled conditions.
An illustrative FAT test for a conveyor system: the test verifies that the conveyor achieves a linear speed of 1.2 m/s with a load of 25 kg per meter. The method is to set the VFD frequency, load the conveyor with test cartons, and measure the time for a marked carton to travel a known distance. The acceptance criterion is a measured speed of 1.2 m/s ± 2% (i.e., 1.176 to 1.224 m/s). The evidence is the time measurement, the distance measurement, and the VFD setpoint log.
FAT also includes software verification. The control logic is tested against the functional specification using a hardware-in-the-loop (HIL) simulator or the actual PLC with simulated field devices. Each input and output is exercised, and the logic response is verified. This is particularly important for safety functions, such as light curtains and emergency stops, which must be tested for correct response time and fail-safe behavior.
The FAT environment is not the final environment. Therefore, FAT results are indicative, not conclusive, for site-specific issues like network latency or power quality. A common error is to accept a FAT result as proof of SAT performance. The RTM must clearly distinguish which tests are FAT-only, which are SAT-only, and which are repeated in both phases.
SAT-specific test categories #
SAT verifies the system in its final installed configuration. The test categories are: installation verification, site integration, environmental testing, and operational readiness. Installation verification checks that equipment is mounted correctly, aligned, and connected to site utilities. Site integration tests the interface with the WMS/WES, the network infrastructure, and any third-party equipment such as label printers or scales.
Environmental testing is a key differentiator between FAT and SAT. The system must operate correctly within the site’s temperature, humidity, and power quality ranges. An illustrative test: the system is operated for 8 hours while the site’s incoming power is monitored. The acceptance criterion is that the system experiences zero unplanned stops and that the power quality (voltage, frequency, harmonics) remains within the equipment manufacturer’s specified range throughout the test.
Network integration testing is critical in modern warehouses. The control network (e.g., EtherNet/IP) must be verified for latency, packet loss, and bandwidth utilization. The test method is to generate a known traffic load and measure the response time of a control command. The acceptance criterion is a maximum round-trip time of 50 ms for a control message, measured at the application layer. This test is performed with the site’s managed switches and network configuration, not the lab setup [S5].
Operational readiness testing includes the first full production run. This is often called a “soak test” or “endurance test.” The system runs at a defined percentage of nominal throughput for a defined duration. An illustrative criterion: the system runs at 85% of nominal throughput for 72 hours with no more than 3 minor stops and zero major stops. A minor stop is defined as a stop that is cleared in under 5 minutes; a major stop requires more than 5 minutes or a maintenance intervention.
Performance metrics and acceptance thresholds #
The table below defines the core performance metrics used in FAT and SAT for typical unit-handling automation. The thresholds shown are illustrative assumptions for a medium-complexity sortation system and must be replaced with contractually agreed values. The definitions are the editorial standard for this guide.
| Metric | Definition | Unit | Illustrative FAT Threshold | Illustrative SAT Threshold |
|---|---|---|---|---|
| Throughput | Units processed per hour at nominal speed | units/hour (uph) | 6,000 uph sustained for 60 min | 5,700 uph sustained for 8 hours |
| Read rate | Successful barcode reads / total read attempts × 100 | % | 99.5% (n=2,000 reads) | 99.0% (n=10,000 reads) |
| Jam rate | Jams per 10,000 cartons processed | jams/10,000 | ≤ 5 jams/10,000 | ≤ 8 jams/10,000 |
| Recovery time | Time from stop signal to system ready for auto-restart | seconds (s) | ≤ 30 s | ≤ 45 s |
| Sortation accuracy | Correctly diverted units / total diverted units × 100 | % | 99.9% (n=5,000) | 99.8% (n=20,000) |
| MTBF (observed) | Total operating time / number of stops (excluding planned stops) | hours (h) | ≥ 120 h | ≥ 72 h |
| MTTR (observed) | Total downtime / number of stops | minutes (min) | ≤ 10 min | ≤ 15 min |
The distinction between FAT and SAT thresholds reflects the reality that the site environment is less controlled. The FAT threshold is typically tighter because the test is performed under ideal conditions. The SAT threshold accounts for site-specific variables such as existing conveyor interfaces, operator experience, and power quality. Both thresholds must be defined in the contract or the test plan; they cannot be negotiated after the test.
Statistical sample size determination #
Many acceptance criteria are rates or percentages, such as read rate or sortation accuracy. To verify these with confidence, the test must include a sufficient number of observations. The required sample size depends on the desired confidence level, the acceptable error margin, and the expected rate. The NIST Engineering Statistics Handbook provides the standard methodology for this calculation [S2].
For a proportion (e.g., read rate), the sample size n is calculated using the formula:
n = ( Z² × p × (1 − p) ) / E²
Where:
- n = required sample size (unitless, number of observations)
- Z = Z-score for the desired confidence level (unitless). For 95% confidence, Z = 1.96.
- p = expected proportion (unitless, expressed as a decimal). For an expected read rate of 99.5%, p = 0.995.
- E = acceptable margin of error (unitless, expressed as a decimal). For a margin of ±0.5%, E = 0.005.
This formula is derived from the normal approximation to the binomial distribution, which is valid when n × p and n × (1 − p) are both greater than 5. For high rates (close to 1.0), the normal approximation can be inaccurate, and an exact binomial method is preferred. The NIST handbook provides tables and software for exact methods [S2].
The formula is used in the worked example below. It is critical to note that the sample size is calculated before the test, not after. If the test uses a smaller sample than calculated, the result does not achieve the stated confidence level, and the test is invalid for acceptance purposes.
Worked example #
This example demonstrates the calculation of a sample size for a read-rate verification test. All numbers are illustrative assumptions and must be replaced with project-specific values.
Inputs:
- Expected read rate (p): 99.5% (0.995 as a decimal). This is the supplier’s claimed performance.
- Desired confidence level: 95%. The corresponding Z-score (Z) is 1.96.
- Acceptable margin of error (E): ±0.5% (0.005 as a decimal). This means the test result must be within 0.5% of the true rate.
Intermediate calculation:
Using the formula n = ( Z² × p × (1 − p) ) / E²:
n = (1.96² × 0.995 × (1 − 0.995)) / 0.005²
n = (3.8416 × 0.995 × 0.005) / 0.000025
n = (3.8416 × 0.004975) / 0.000025
n = 0.019112 / 0.000025
n = 764.5
Result:
The required sample size is 765 reads (rounded up from 764.5). The test must attempt at least 765 barcode reads to verify a read rate of 99.5% with 95% confidence and a margin of error of ±0.5%. If the test uses 765 reads and achieves 762 successful reads, the observed rate is 762/765 = 99.61%, which is within the margin of error and passes the criterion.
Sensitivity:
The sample size is highly sensitive to the margin of error. If the margin is relaxed to ±1.0% (0.01), the required sample size drops to n = (3.8416 × 0.004975) / 0.0001 = 191.2, or 192 reads. Conversely, tightening the margin to ±0.25% (0.0025) increases the sample size to n = (3.8416 × 0.004975) / 0.00000625 = 3,058 reads. The sample size is also sensitive to the expected rate; as p approaches 1.0, the term p × (1 − p) approaches zero, which can lead to an unrealistically small sample size. This is why the normal approximation is not recommended for rates above 99.9%.
Limitations:
This calculation assumes that each read is independent and that the read rate is constant throughout the test. In practice, read rate can vary with carton condition, label quality, and conveyor speed. The test should be designed to include a representative mix of these conditions. Additionally, the calculation provides the sample size for a single test; if the test is repeated, the total sample size is the sum of the individual samples, and the confidence level for the combined result is higher than 95%.
Defect management and disposition #
Defects are classified by severity, which determines the disposition path. The classification is defined in the test plan and agreed by both parties. A typical classification is: Critical (system unsafe or cannot operate), Major (system operates but does not meet a key requirement), Minor (system operates and meets requirements but has a cosmetic or non-critical issue). The table below defines the disposition options.
| Severity | Definition | Disposition Options | Decision Owner |
|---|---|---|---|
| Critical | Safety hazard or total system failure | Fix and re-test only. No waiver or deviation permitted. | Project Manager + Safety Officer |
| Major | Requirement not met; system degraded | Fix and re-test, or approved deviation with documented impact. | Project Manager + Customer Representative |
| Minor | Requirement met; non-critical issue | Fix now, or fix within a defined period after handover (punch list). | Test Owner + Customer Representative |
A deviation is a formal agreement that the system will be accepted even though a requirement is not fully met. A deviation must include: the requirement ID, the measured result, the required result, the reason for the deviation, the operational impact, and a mitigation plan. A waiver is a similar agreement but typically applies to a requirement that is not applicable or is superseded. Both require sign-off from the decision owner and must be archived with the test records.
Re-testing after a fix is not automatic. The re-test must cover the failed test case and any related test cases that could be affected by the fix. For example, if a jam recovery fix changes the control logic, the re-test must include not only the jam recovery test but also the throughput test, because the logic change could affect cycle time. The scope of the re-test is determined by the test owner and approved by the customer representative.
All defects, regardless of severity, are logged in a defect tracking system with a unique ID, the date, the test case ID, the severity, and the disposition. The log is reviewed daily during the test campaign. The final acceptance report includes the complete defect log and the disposition of every item.
Exit criteria for FAT and SAT phases #
Exit criteria are the formal conditions that must be met before the phase is declared complete. They are defined in the test plan and are not subject to informal relaxation. The exit criteria for FAT are: (1) all Critical and Major defects are closed with a passing re-test, (2) all Minor defects have an approved disposition (fix now or punch list), (3) the RTM shows 100% of requirements verified, (4) all evidence is archived in the project repository, and (5) the FAT report is signed by the test owner and the customer representative.
The exit criteria for SAT are similar but include site-specific conditions: (1) all FAT exit criteria are met, (2) all site integration tests pass, (3) the endurance test is completed with results within the acceptance thresholds, (4) all site-specific defects are closed or have an approved disposition, (5) the as-built documentation (drawings, manuals, spare parts lists) is delivered and accepted, and (6) the SAT report is signed.
A phase cannot be exited with open Critical defects. This is a hard boundary. If a Critical defect is found during SAT, the phase is paused, and the defect must be fixed and re-tested before the phase can be considered for closure. The only exception is a safety-related defect that requires a fundamental redesign; in that case, the project is escalated to the change control board, and the acceptance process is suspended until a resolution is approved.
The exit criteria are also the gate for payment milestones. The contract should link a percentage of payment to the successful completion of FAT and SAT. This creates a financial incentive for both parties to complete the process rigorously. The payment release is triggered by the signed exit criteria checklist, not by a verbal agreement.
Safety boundaries and lockout/tagout #
Safety is not a test criterion; it is a boundary condition that governs how all tests are performed. The OSHA standard for the control of hazardous energy (lockout/tagout) [S3] and the general requirements for machine guarding [S4] are mandatory references. They are not optional best practices. The test plan must include a section on safety that references these standards and defines the specific procedures for the equipment under test.
Lockout/tagout (LOTO) applies whenever a test requires personnel to enter a hazard zone or to remove a guard. The procedure is: identify all energy sources (electrical, pneumatic, hydraulic, gravitational), isolate them, lock them out, tag them, and verify zero energy state. The verification step is critical; it is not sufficient to press the stop button. The test plan must specify which tests require LOTO and who is authorized to perform it.
Machine guarding [S4] must be in place during all tests that involve moving parts. Guards are not removed for testing unless the test specifically requires access, and in that case, a risk assessment must be completed, and additional controls (e.g., reduced speed, two-person rule) must be in place. The removal of a guard for a test is a deviation that must be documented and approved.
Emergency stop (E-stop) testing is a mandatory test in both FAT and SAT. The test verifies that the E-stop stops the system within a specified time and that the system cannot be restarted without a deliberate reset action. The acceptance criterion is a stop time of less than 500 ms from actuation to zero motion, measured at the fastest-moving element. This is an illustrative assumption; the actual criterion is defined by the risk assessment.
Network and cybersecurity verification #
Modern warehouse automation is heavily networked, and the acceptance process must include verification of the network infrastructure and cybersecurity controls. The NIST Guide to Operational Technology Security [S5] provides the framework for OT security, and the acceptance tests must verify that the implemented controls match the design.
Network tests verify connectivity, latency, and bandwidth. An illustrative test: the test injects a known traffic pattern and measures the round-trip time for a control message between the PLC and a remote I/O module. The acceptance criterion is a maximum latency of 20 ms for 99.9% of messages, measured over a 15-minute test period. This test is performed on the installed network with the site’s managed switches [S5].
Cybersecurity tests verify that the system is configured securely. This includes: default passwords are changed, unused ports are disabled, firmware is up to date, and network segmentation is in place. The test method is a configuration audit against the security baseline. The acceptance criterion is 100% compliance with the baseline. Any deviation is a Major defect and must be fixed before SAT exit.
The test plan must also include a procedure for verifying that the system can be safely patched and updated. This is a lifecycle consideration; the acceptance test is the first opportunity to validate the update process. An illustrative test: a firmware update is applied to a non-critical controller, and the system is verified to operate correctly after the update. This test is performed during FAT, not SAT, to avoid disrupting site operations.
Documentation deliverables and as-built records #
The acceptance process produces a defined set of documents. The test plan is the controlling document; it is approved before testing begins. The test records are the individual results for each test case. The defect log is the complete list of defects and dispositions. The RTM is the traceability matrix. The final acceptance report summarizes the entire campaign and includes the signed exit criteria checklist.
As-built documentation is a deliverable of SAT. It includes: updated electrical schematics, mechanical drawings, PLC programs (with comments), network diagrams, and spare parts lists. The as-built documentation must reflect the system as actually installed, not the design as originally drawn. The acceptance of the as-built documentation is a formal step; the customer representative signs to confirm that the documentation is accurate and complete.
The spare parts list is a critical deliverable. It must include the manufacturer, part number, description, quantity, and recommended stock level for each item. The list is used to set up the initial spare parts inventory. The lifecycle strategy for spare parts, including obsolescence management, is a separate planning activity that should be initiated during the acceptance phase, not after handover.
All documentation is archived in the project repository with version control. The archive is the legal record of the acceptance process. It must be retained for the life of the system plus a defined period (typically 10 years). The archive is the first place to look when a dispute arises about whether a requirement was tested or a defect was resolved.
Roles, responsibilities, and authority matrix #
The acceptance process requires clear roles and a defined authority matrix. The test owner executes the test and records the result. The witness observes and confirms. The decision owner approves dispositions and signs the exit criteria. The safety officer has the authority to stop any test. The project manager is accountable for the overall process.
The authority matrix defines who can make decisions at each stage. For example, the test owner can decide to re-run a test that failed due to a test setup error, but cannot approve a deviation. The decision owner (typically the customer representative for SAT) approves deviations and waivers. The project manager approves changes to the test plan. The safety officer can stop any test without needing approval from anyone.
It is a common error to conflate the roles of test owner and witness. The test owner is from the party performing the work (supplier or integrator). The witness is from the party accepting the work (customer or their consultant). The witness does not execute tests. If the witness operates equipment, they become the test owner, and the test is compromised. This separation is a control that ensures the test is performed by a competent person and observed by an independent person.
The authority matrix must be agreed before the test campaign begins. It is part of the test plan. Disputes during the campaign are resolved by escalating to the next level of authority. The escalation path is defined in the matrix. For example, if the test owner and witness disagree on a test result, the issue is escalated to the project manager and the customer’s project sponsor.
When this guidance does not apply #
This guidance is written for unit-handling automation systems: conveyors, sorters, palletizers, and robotic workstations. It does not apply to bulk material handling systems (e.g., grain silos, mining conveyors) where the test methodology and metrics are fundamentally different. It also does not apply to purely software systems (e.g., a WMS without physical automation) where the acceptance process is governed by software testing standards, not physical FAT/SAT.
The statistical methods described are valid for high-volume, repetitive operations. They are not appropriate for low-volume, high-variability operations where the sample sizes would be impractically large. For a system that processes 100 units per day, a sample size of 765 reads (from the worked example) would take over a week to collect, which is not practical. In such cases, a different acceptance approach, such as a time-boxed demonstration with defined coverage, is more appropriate.
This guidance assumes a greenfield or major retrofit project with a formal contract. It does not apply to minor modifications or troubleshooting activities where a full FAT/SAT process is disproportionate. For a small change, such as replacing a sensor, a simplified verification checklist is sufficient. The decision to apply the full process is based on risk and contract value, and it is made by the project manager.
Finally, this guidance does not apply to safety-critical systems that are governed by specific industry regulations (e.g., pharmaceutical manufacturing, food processing with HACCP). Those industries have their own validation requirements (e.g., GAMP, 21 CFR Part 11) that supersede this generic guidance. The reader must determine the applicable regulatory framework before using this guide.
Integration with lifecycle and maintenance planning #
The acceptance process is not the end of the system’s life; it is the beginning of the operational phase. The data collected during FAT and SAT is the baseline for future performance monitoring. The throughput, read rate, and jam rate measured during SAT become the reference values for ongoing condition monitoring. The acceptance report should include a section that defines these baseline values and the method for comparing future performance.
Maintenance planning is initiated during the acceptance phase. The as-built documentation and spare parts list are the inputs to the maintenance plan. The test results identify weak points that may require more frequent inspection. For example, if the jam rate is higher at a specific transfer point, that point is flagged for preventive maintenance. The maintenance mode controls and commissioning checklist is a relevant reference for defining how the system is safely taken out of service and returned to service [S3].
The acceptance process also validates the diagnostic capabilities of the system. The tests should include fault injection to verify that the system detects and reports faults correctly. For example, a sensor is disconnected, and the system must generate an alarm within a defined time. This test verifies the diagnostic chain from sensor to HMI. The results are the baseline for the technician diagnostic checklists used during operations.
Spare parts strategy is informed by the FAT/SAT results. Components that failed during testing are candidates for higher stock levels. Components that performed flawlessly may be candidates for lower stock levels. The critical spare parts lifecycle strategy should be reviewed after the acceptance campaign to incorporate the test findings. This is a continuous improvement loop that starts with the acceptance data.
Common failure modes in FAT/SAT execution #
Several recurring failure modes undermine the effectiveness of FAT/SAT campaigns. The first is inadequate preparation: the test plan is written but not reviewed, the equipment is not ready, and the participants are not briefed. This leads to a chaotic campaign where tests are skipped or improvised. The mitigation is a formal readiness review before the campaign begins, with a checklist that confirms the test plan is approved, the equipment is ready, and the participants are trained.
The second failure mode is the “demo effect”: the supplier optimizes the system for the test conditions, masking real-world performance. For example, the test uses perfectly sized and labeled cartons, while the actual operation has a mix of sizes and label qualities. The mitigation is to define the test conditions in the test plan, including the range of inputs, and to use a random or representative sample rather than a hand-picked one.
The third failure mode is the “green pen” syndrome: the witness signs off on a test without actually observing it. This is a governance failure. The mitigation is a rule that the witness must be physically present for the entire test and must sign the test record at the time of completion, not later. The witness must also be empowered to challenge the result and to record a formal observation if they have any doubt.
The fourth failure mode is the “scope creep” of the punch list. Minor defects are deferred to the punch list, and the punch list grows until it becomes a second project. The mitigation is a limit on the number of punch list items, defined in the contract. If the punch list exceeds the limit, the SAT phase is not closed, and the project remains in the acceptance phase until the list is reduced.
Revision and editorial note #
This article was prepared by the Pearl Gateway Editorial Team. It was reviewed against the listed sources [S1]–[S5] and the internal Pearl Gateway documentation library. The guidance is educational and is intended to support the planning and execution of FAT and SAT campaigns for warehouse automation systems. It does not constitute legal advice, and it does not replace site-specific risk assessments or contractual requirements. All illustrative assumptions are explicitly labeled as such and must be validated for each project. The editorial team welcomes feedback on this reference to improve its clarity and utility for the automation community.
Sources and standards #
- NASA — NASA Systems Engineering Handbook. In “Warehouse Automation FAT and SAT Master Guide: Evidence, Traceability and Exit Criteria”, source [S1] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.
- NIST — Engineering Statistics Handbook. In “Warehouse Automation FAT and SAT Master Guide: Evidence, Traceability and Exit Criteria”, source [S2] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.
- OSHA — The Control of Hazardous Energy (Lockout/Tagout), 29 CFR 1910.147. In “Warehouse Automation FAT and SAT Master Guide: Evidence, Traceability and Exit Criteria”, source [S3] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.
- OSHA — General Requirements for Machine Guarding, 29 CFR 1910.212. In “Warehouse Automation FAT and SAT Master Guide: Evidence, Traceability and Exit Criteria”, source [S4] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.
- NIST — Guide to Operational Technology Security, SP 800-82 Rev. 3. In “Warehouse Automation FAT and SAT Master Guide: Evidence, Traceability and Exit Criteria”, source [S5] supports the attributed terminology or boundary; the warehouse-specific synthesis remains Pearl Gateway editorial analysis.
Revision and editorial note #
The Pearl Gateway Editorial Team prepared “Warehouse Automation FAT and SAT Master Guide: Evidence, Traceability and Exit Criteria” from the five linked source records. The published guide remains educational and requires site evidence before application.
