FAT vs SAT for Robot Projects: What Buyers Should Test Before Shipment and After Installation

Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT) are two distinct verification stages in a robot project. FAT is conducted at the supplier’s facility before the equipment ships. SAT is conducted at the buyer’s site after installation. They solve different problems, verify different parameters, and carry different risks. Treating them as a single “testing phase” is a common mistake in robot procurement. This article explains what each test should cover, what FAT cannot verify, and how to handle the gap between factory performance and real-world performance.

FAT and SAT Solve Different Risks

FAT answers the question: “Does the equipment meet the agreed specifications before it leaves the factory?” It is a contractual checkpoint that protects the buyer from accepting non-conforming equipment and the supplier from shipping equipment that will be rejected on site.

SAT answers a different question: “Does the equipment perform as required in the actual operating environment?” It verifies that the robot, once installed at the buyer’s site, can perform the task under real conditions—real layout, real parts, real operators, real network, real interfaces.

The distinction matters because a robot can pass FAT and fail SAT without either party being at fault. The robot meets its specifications in the controlled factory environment, but the buyer’s site introduces variables that the factory cannot replicate: dynamic obstacles, network coverage gaps, elevator integration, real production loads, multi-robot traffic, and operator behavior.

Whether both tests are necessary depends on the contract and project risk. Many engineered projects use both, but the scope and depth of each should be defined by the contract—not assumed as a universal requirement for all robot projects.

What Should Be Verified During Factory Acceptance Testing (FAT)

FAT should be structured as a series of tests that verify the robot and its configuration before shipment. The specific test items depend on the robot type and project scope.

Basic Function Tests

• Robot motion: all axes move through their full range without error
• Jog and teach mode: pendant control functions correctly
• Program execution: sample programs run without fault
• Emergency stop: E-stop triggers immediate halt and safe state
• Safety functions: collision detection, speed monitoring, safe stop (if applicable to the robot type)

Performance Tests

• Repeatability: measure position variation over a defined number of cycles at a defined point, using a laser tracker or equivalent measurement device. ISO 9283:1998 provides performance criteria and test methods for industrial manipulating robots. If referencing ISO 9283, follow its applicable scope and test procedures—do not specify a fixed cycle count without verifying against the standard’s actual test requirements.
• Payload verification: robot moves the rated payload through the required trajectory without position error or fault
• Speed verification: TCP speed measured at a defined point in the trajectory
• Cycle time: complete cycle timed under controlled conditions

Configuration Verification

• Software version: confirm the installed software version matches the agreed specification
• Parameter file: confirm that the robot parameters match the project configuration
• I/O configuration: verify that digital and analog I/O are configured and responding
• Communication: verify that the robot communicates with the controller and any test PLC or HMI

Interface Tests (Simulated)

• Gripper or end-effector: verify that the gripper opens, closes, and holds the sample part
• Vision system (if applicable): verify that the vision system recognizes the sample part in the test cell lighting
• Conveyor tracking (if applicable): verify that the robot tracks a moving conveyor at test speed
• Safety interface: verify that the safety PLC or safety relay receives and responds to robot safety signals

Documentation Review

• Confirm that operation manuals, maintenance manuals, electrical drawings, and software documentation are included and match the shipped configuration
• Confirm that the risk assessment (if provided by the supplier) covers the test cell configuration
• Confirm that the spare parts list matches the equipment being shipped

What Cannot Be Proven at FAT Because the Buyer Site Is Missing

FAT has inherent limitations. The supplier’s factory is not the buyer’s production environment, and certain performance characteristics can only be verified on site.

Actual Site Navigation (for Mobile Robots)

AMRs and AGVs rely on site-specific maps, real obstacle configurations, and dynamic traffic patterns. FAT for a mobile robot typically uses a test area at the supplier’s facility, which may have different floor conditions, lighting, and obstacle layouts than the buyer’s site.

Illustrative failure scenario: a robot that navigated flawlessly on the supplier’s polished concrete test floor encountered LiDAR interference from glass walls in the buyer’s lobby, causing repeated localization failures.

Integration with Real Building Systems

Elevators, automatic doors, fire alarm systems, and building management systems cannot be tested at FAT because they exist only at the buyer’s site. The supplier may test the interface protocol using a simulator, but the actual elevator controller, door controller, and fire alarm system may behave differently.

Illustrative failure scenario: the elevator controller protocol tested fine in simulation, but the actual controller added a delay between call and door open that the robot’s timeout did not account for.

Multi-Robot Traffic Management

If the project involves multiple robots, FAT typically tests one robot at a time. Multi-robot traffic management can only be verified when multiple robots operate in the actual environment simultaneously.

Real Production Loads and Cycle Times

FAT uses sample parts or mock-ups. Real production parts may have different dimensions, surface conditions, or weight distributions that affect gripper performance, vision recognition, or cycle time.

Illustrative failure scenario: the sample boxes used at FAT had smooth surfaces; the production boxes have a glossy finish that causes the vacuum gripper to slip at speeds above the FAT-tested rate.

Thermal and Battery Performance Under Real Conditions

A robot that runs in a controlled factory may behave differently in a warehouse at high temperature or in a cold storage facility. Battery life depends on load, speed, ambient temperature, and charge cycle—none of which are fully replicated at FAT.

What Should Be Verified During Site Acceptance Testing (SAT)

SAT is the buyer’s opportunity to verify that the robot performs in its actual operating environment before the project is accepted as complete. The SAT protocol should be defined before installation begins.

Navigation and Movement

• Robot reaches all required positions in the installed layout
• For mobile robots: navigation map is accurate, routes are clear of obstacles, charging station docking works
• For articulated robots: all positions in the work envelope are reachable with the installed end-effector and fixtures
• Robot moves at the required speed in the production environment

Integration with Real Systems

• WMS/MES/ERP interface: orders are received, tasks are executed, status is reported
• Machine interface: robot loads/unloads the target machine correctly
• Elevator interface (mobile robots): robot calls the elevator, enters, rides, and exits at the correct floor
• Door interface: automatic doors open and close in coordination with robot movement
• Safety system: light curtains, area scanners, and safety PLC respond correctly to robot presence

Throughput Under Real Conditions

• Measure actual cycle time or throughput over a representative production period (not a single cycle)
• Compare measured throughput to the FAT result and to the project requirement
• Document any gap and investigate the cause

Safety in the Real Environment

• Risk assessment is updated for the installed configuration
• Safety zones and speed reduction areas are configured for the actual layout
• Emergency stop is accessible and functional from all operator positions
• Operator training has been completed and documented

Network and Communication

• Robot communicates with the fleet platform and/or WMS over the production network
• Network coverage is adequate across all robot routes
• Network failover or offline recovery behavior is tested

Operator and Process Validation

• Operators can start, stop, and recover the robot using the trained procedures
• Exception handling follows the documented SOP
• Production records and error logs are being generated and stored correctly

Acceptance Criteria: Define Before Testing, Not After

Acceptance criteria must be defined before testing begins—not negotiated after the test results are in. The criteria should be specific, measurable, and tied to the project requirements.

The acceptance criteria should include a tolerance band. The specific tolerance is buyer/supplier agreed before the test—not a generic industry threshold. A robot that achieves slightly below the specified throughput at SAT may be acceptable if the gap is explained by a known process bottleneck that can be addressed. A robot that falls significantly below the specified throughput requires root-cause analysis.

How to Record Test Conditions and Exceptions

Test documentation is not just a formality. It is the record that protects both parties if a dispute arises later.

Test Record

• Date, location, and participants (buyer and supplier representatives)
• Robot serial number, software version, and parameter file version
• Test equipment used (laser tracker, stopwatch, scale, multimeter)
• Environmental conditions (temperature, humidity, lighting)
• Test procedure reference (which test, which step)
• Measured results (actual values, not just pass/fail)
• Pass/fail determination for each criterion

Exception Log

• Any deviation from the planned test procedure
• Any test that could not be completed (and why)
• Any anomaly observed during testing
• Any temporary fix applied during testing
• Any item deferred to SAT (for FAT) or to post-acceptance (for SAT)

Sign-Off

• Buyer representative signature (accepting or conditionally accepting the test results)
• Supplier representative signature (confirming the test was conducted as documented)
• List of open items with assigned responsibility and target resolution date

What Happens When FAT Passes but SAT Fails

This is one of the most stressful moments in a robot project. The equipment was accepted at the factory, shipped, installed, and now it does not perform at the site. The first step is to understand why.

Common causes of FAT-pass-but-SAT-fail:

The resolution depends on the contract terms. Allocation of responsibility depends on the contract, documented site assumptions, change control, and root-cause determination—not on a universal default. The contract should define:

• The process for root-cause analysis (joint investigation, third-party assessment)
• The timeline for resolution
• The conditions under which the buyer can reject the equipment

Even when FAT and SAT both pass, the project team should establish a post-go-live observation period (buyer-defined stabilization period) to monitor performance under full production conditions. Some issues—intermittent faults, thermal drift, battery degradation—only appear after sustained operation.

FAT/SAT Checklist for Industrial Arms, AMRs, Delivery and Cleaning Robots

The FAT and SAT scope differs by robot type. Below is a checklist that highlights the most critical test items for each category.

This checklist is a framework. The actual test plan for each project should be defined in the contract, agreed by both parties before FAT begins, and updated if the project scope changes. For pilot design and acceptance criteria (pre-purchase validation), see our Robot Pilot guide. For multi-site rollout planning, see our Pilot to Multi-Site Rollout guide.

Research Sources Used

1. Source / organization: IEEE (FAT/SAT verification methodology for SCADA and automation systems) | URL: https://ieeexplore.ieee.org/ | Version/date: as cited in report_batch_c
2. Source / organization: IEEE (transformer failure case study: FAT/SAT pass but post-commissioning failure) | URL: https://ieeexplore.ieee.org/ | Version/date: as cited in report_batch_c
3. Source / organization: ISO (ISO 9283:1998 performance criteria for manipulating industrial robots) | URL: https://www.iso.org/ | Version/date: 1998
4. Source / organization: ISO (ISO 10218-1:2025, ISO 10218-2:2025) | URL: https://www.iso.org/ | Version/date: 2025
5. Source / organization: ANSI/A3 (R15.06-2025) | URL: https://www.a3automate.org/ | Version/date: 2025
6. Source / organization: ISO (ISO/TS 15066:2016, ISO 3691-4:2023) | URL: https://www.iso.org/ | Version/date: as applicable

Internal product/material source: report_batch_c (batch C research report) [TO VERIFY]: none