Machine Design #42: FAT/SAT for Automated Machines — “It Runs Fine” Is Not Acceptance
“The machine runs fine” is a feeling, not an acceptance method. It does not say which requirement was tested, under which condition, with which sample, or what evidence proves the result. When handover and payment arrive, the missing detail becomes a dispute.
Factory Acceptance Testing (FAT) and Site Acceptance Testing (SAT) work when they form a traceable chain: requirement → test case → measurable criterion → observed result → evidence → disposition. The chain must include normal production, abnormal conditions, recovery, integration, safety, documentation, and the as-installed machine.
This article is a conceptual framework. It does not replace contractual requirements, risk assessment, safety validation, local regulations, or the customer’s formal acceptance procedure.
1. Separate FAT, FIT, SAT, SIT, and commissioning
FAT checks the supplier’s assembled machine in a controlled factory environment. FIT checks how units or functions fit together. SIT checks system integration across stations, utilities, software, and interfaces. SAT checks the installed machine at the customer site. Commissioning prepares, adjusts, and proves operation; it is not automatically the same as acceptance.
Write the purpose, environment, responsible parties, entry criteria, exit criteria, and evidence for each activity. A successful FAT cannot prove site utilities, installation, operator access, or integration behavior that was not present in the factory.
2. Start with requirement traceability
Every acceptance item should trace to a stable requirement ID. The requirement may cover cycle time, accuracy, capacity, noise, utility consumption, changeover, safety function, data logging, maintainability, or document delivery.
Create a matrix showing requirement, design reference, test case, criterion, result, evidence, deviation, owner, and disposition. If a line has no requirement, ask why it is being tested. If a requirement has no test route, acceptance is not yet defined.
3. Acceptance criteria must be measurable
“Stable operation,” “good quality,” and “easy maintenance” are useful intentions but weak criteria. Define sample, setup, duration, speed, load, tolerance, measurement method, instrument accuracy, number of repetitions, and pass/fail boundary.
For example: “At 23 ± 3 °C and 0.50 ± 0.02 MPa, the machine produces 120 accepted parts in 60 minutes, with cycle time ≤ 30 s for 95% of cycles and zero safety-function failures.” The exact values depend on the contract; the principle is that two parties should reach the same result from the same protocol.
4. What fields does one test case need?
A useful test case includes ID, requirement, objective, equipment and software revision, preconditions, sample and recipe, instruments, steps, expected result, acceptance criterion, actual result, evidence link, tester, date, deviation, and final disposition.
Record enough context to reproduce the result. A photograph without recipe, load, or timestamp is rarely enough. A screenshot should identify the state and data source. A measurement should include instrument ID and calibration status where accuracy matters.
5. Preconditions matter as much as results
Before a test, confirm machine build, guarding, utilities, software, recipe, tooling, sample, environment, network, safety configuration, and instrument calibration. If a precondition is missing, record the test as not ready rather than silently changing the protocol.
Many acceptance disputes are actually precondition disputes: the supplier tested at a different pressure, with a better part, with an engineer manually assisting, or with a temporary software force. Make those conditions visible.
6. What belongs in FAT?
FAT should cover functional sequence, cycle and throughput under defined conditions, quality result, changeover, alarms and recovery, utility behavior, data and traceability, maintainability access, documentation, spare parts, and agreed safety-function tests.
Run representative normal and abnormal cases. Demonstrate how a jam, missing part, utility loss, sensor failure, and restart are handled. Record evidence that the machine returns to a known state and does not bypass a safety condition.
7. What FAT cannot prove
FAT cannot prove site installation, foundation stiffness, actual exhaust and air quality, customer network, upstream and downstream integration, local operator behavior, production shift duration, or the exact as-installed safety boundary.
List these as SAT or commissioning items. Do not mark them “passed at FAT” because a similar condition worked in the factory. The gap between factory and site is a requirement for planning, not an exception to traceability.
8. Close the delivery baseline before shipment
Freeze the machine configuration tested at FAT: mechanical drawings, PLC and robot programs, HMI, recipes, parameters, safety configuration, electrical drawings, firmware, network map, calibration records, and open deviations.
Give every item a revision and checksum or equivalent identity where practical. Record what is installed, what is packed, what is temporary, and what will change during installation. A USB containing “latest files” is not a baseline.
9. SAT starts from the as-installed condition
At site, document foundation, level, guards, utilities, cable routing, network, interfaces, tooling, sample, environment, and software revisions before testing. Confirm that the machine matches the FAT baseline or list each difference.
Repeat the tests affected by installation and integration. Verify recovery after power and air loss, operator access, safety zones, material flow, data handoff, and sustained production under the agreed site conditions.
10. Site performance needs common conditions
Supplier and customer must agree on sample quality, material supply, utilities, shift schedule, staffing, upstream/downstream state, measurement method, and allowed adjustments. Define who pays for a repeat caused by a failed precondition and how evidence is recorded.
Do not compare a factory result from perfect samples with a site result from mixed incoming quality. Either control the sample or separate machine capability from process capability.
11. FIT and SIT expose ownership gaps
FIT may reveal that a robot, conveyor, fixture, or machine meets its local interface while the combined handshake fails. SIT tests the complete exchange of requests, permissions, part identity, timing, fault, and recovery.
Assign an owner for each interface and define which side supplies evidence. “The other machine did not respond” is a symptom; the protocol should show request, acknowledgement, timeout, state, and recovery responsibility.
12. Safety validation is not one FAT line
Safety-function validation requires its own specification, test method, fault conditions, reset and restart behavior, stopping performance, and evidence. A checkbox saying “safety passed” cannot replace validation of guards, interlocks, emergency stops, energy isolation boundaries, safe motion, and foreseeable faults.
Coordinate safety validation with FAT/SAT, but keep its technical ownership and acceptance evidence explicit.
13. Manage deviations; do not let “PASS with note” live forever
A deviation should state requirement, actual condition, risk and impact, temporary measure, owner, due date, disposition, and closure evidence. Classify it as accepted, corrected, deferred with approval, or rejected.
“Pass with note” is not a permanent state. A time-limited deviation needs a review date and a clear condition for closure. If the condition changes the tested baseline, determine which tests must be repeated.
14. Retest according to impact
Retest is not always “run the whole FAT again,” and it is not always “repeat one button press.” Assess the changed failure path, affected requirements, interfaces, safety functions, recipes, and data.
Define regression scope: targeted test, related sequence, complete station, integrated line, or safety revalidation. Record why the scope is sufficient and link the new evidence to the deviation and revision.
15. Golden samples and test data need revision
Identify golden samples, fixtures, reference measurements, recipes, software, and data sets. A test may pass simply because the sample was changed or the instrument was adjusted.
Store sample identity, condition, measurement method, and acceptance version. When the product or process changes, review whether the golden sample still represents the requirement.
16. Handover is more than delivering a USB
Handover includes an approved baseline, drawings, source and executable versions, parameter exports, safety documents, manuals, maintenance plan, spare parts, calibration, alarm list, training record, open-deviation register, backup and restore procedure, and ownership for future changes.
Demonstrate that the customer can identify what is running, restore a known-good version, recover from a fault, and find the evidence behind acceptance. Delivery is complete when the capability to operate and recover is transferred.
17. FAT/SAT protocol checklist
- [ ] FAT, FIT, SIT, SAT, and commissioning purposes are separated.
- [ ] Every test traces to a stable requirement.
- [ ] Criteria define condition, measurement, repetitions, tolerance, and pass/fail boundary.
- [ ] Preconditions and instrument status are recorded.
- [ ] Normal, abnormal, recovery, integration, and safety cases are included.
- [ ] FAT limits and SAT responsibilities are explicit.
- [ ] Tested configuration is baselined before shipment.
- [ ] As-installed differences are identified before SAT.
- [ ] Deviations have owners, dates, risk disposition, and closure evidence.
- [ ] Retest scope follows impact and is traceable.
- [ ] Safety validation has independent technical evidence.
- [ ] Handover transfers operation, maintenance, backup, restore, and change capability.
Conclusion
Acceptance is not a feeling that the machine runs. It is evidence that defined requirements are met under defined conditions, with deviations controlled and the tested configuration traceable.
Build the chain from requirement to criterion, result, evidence, and disposition. Separate factory proof from site proof, make integration ownership explicit, validate safety functions independently, and close the handover baseline.
When FAT and SAT are designed this way, they reduce arguments instead of moving them to the payment meeting. They give the owner a machine that can be operated, maintained, recovered, and changed with confidence.
Public references
View all MINATA technical articles