How to Conduct FAT for Automation Systems: Factory Acceptance Testing

Factory Acceptance Testing is where projects are won or lost long before a crate ever arrives at your dock. As a systems integrator who has stood beside panels, skids, and consoles through countless runoffs, my goal here is to show you how to run a FAT that prevents onsite surprises, speeds commissioning, and gives every stakeholder confidence that the system you ship is the system you can safely start. The practical approach below blends hands‑on lessons with established guidance from sources like ATC Automation, Control Engineering, ISA InTech, ControlDesign, SafetyCulture, University of Minnesota, and AQI Service.

What FAT Is—and What It Is Not

A Factory Acceptance Test is a witnessed, pre‑shipment verification at the builder’s facility that demonstrates the system meets contractual requirements, safety expectations, and functional performance. The strongest protocols tie each user requirement and design intent to objective pass or fail criteria and capture evidence with traceable data and sign‑offs. This is not a site‑integration exercise, and it is not a substitute for Site Acceptance Testing. FAT proves the machine or control system is built correctly; SAT proves it works correctly in your real environment. Control Engineering and ATC Automation emphasize this distinction because pushing plant‑specific utilities, materials, and network dependencies into FAT creates false confidence and drains time at the wrong phase.

FAT enables safe, low‑cost defect discovery. Fixing a miswired input, a bad alarm mapping, or a flawed switchover routine on the vendor floor is faster and cheaper than unraveling it during startup while electricians, mechanics, and operators wait. ISA InTech characterizes FAT as both hardware testing and software testing under controlled conditions, with results captured and approved before shipment.

When to Plan FAT

The best FATs are designed alongside the system, not after it. ATC Automation advises aligning on scope, performance targets, variants, and standards early, supported by a protocol meeting to finalize acceptance criteria. In practice, I treat the FAT protocol as a living document that matures with the design, and I include a builder’s pre‑FAT dry run to resolve obvious gaps before witnesses arrive. Scheduling and parts logistics matter more than people expect; when production parts are limited, agree on surrogate materials and how long the runoff must run to prove repeatability without gaming the result.

Building a Risk‑Focused FAT Protocol

AQI Service and ControlDesign both stress coverage that is broad yet risk‑based. Start with a complete, traceable mapping between the user requirement specification or functional design specification and the specific FAT step that verifies it. Favor quantifiable thresholds over subjective judgments. Include normal operation, edge conditions, and negative scenarios along with operator safety interlocks, e‑stops, and safe states. If you operate under regulation, align with the applicable standards: for example, IEC electrical safety and alarm expectations, ISA/IEC 62443 for cybersecurity posture, or GxP validation traceability practices in life sciences.

Set explicit pass, fail, and concession criteria. Agree on the handling of nonconformances before testing begins to avoid in‑the‑moment debate. Document each deviation with owners and deadlines, and retest to closure.

Preparing the Floor and the People

Good FATs begin with realistic simulation and the right team in the room. Champion Technology Services describes high‑fidelity simulation of vendor control hardware, I/O, and operator workstations to mirror site conditions; that level of preparation consistently finds integration and logic defects early. On the people side, include engineering, quality or validation, operations, maintenance, and safety representatives with clear decision authority. When travel is constrained, Precision For Medicine shows that virtual FATs work if you finalize design earlier, schedule persistent video sessions with breakout capability, designate a coordinator for conferencing logistics, and provide remote control tools so SMEs can exercise the system directly. Poor planning, limited visibility, or missing decision‑makers will stretch what should be a few days into weeks and damage relationships.

Executing the FAT: A Practical Walkthrough

Treat day one as a kickoff and a safety check. Verify that nameplates are legible, emergency stops are accessible, guarding and interlocks function, and documented risk assessments are current. Confirm grounding continuity and insulation where applicable; ISA InTech highlights the value of hardware FAT checks such as ground bonding and protection against short circuits.

Power up in a controlled fashion. RealPars recommends de‑energizing safely and being mindful that the line side of a main breaker remains live; after powering, proceed through digital and analog I/O checkout with simulated signals when field devices are not present. Command outputs, validate feedbacks, and watch for scaling errors on 4–20 mA loops and thermocouples. Exercise fault handling: remove a sensor, drop a network link, or simulate a power supply switchover to validate redundant behavior and alarm annunciation. MAVERICK Technologies, writing in Control Engineering, notes that FATs using simulators do not replicate a full plant; mitigate that limitation with explicit checks of signal ranges, addressing, fail positions for discrete I/O, controller loading, and protocol configuration.

Once functional checks pass, demonstrate performance under representative load. Run for a sustained interval to prove thermal stability, cycle time, and repeatability. If your acceptance criteria call for a sustained eight‑hour run, do not compress it. Automation NTH calls this a runoff, and on many programs an eight‑hour single‑shift run across variants is the minimum proof that a system is production‑worthy. Capture raw data in real time with timestamps and calibrated instruments; AQI Service frames these records as a quality passport that supports traceability and future troubleshooting.

Integration and communications deserve a dedicated pass. Confirm PLC code revisions and software versions, SCADA point mapping, alarm routing, historian tags, and role‑based access controls. Verify time synchronization and disable unnecessary remote services; ControlDesign and Control Engineering both flag cyber hygiene during FAT as a proven risk reducer later.

Close with a structured review, a clear punch list, and an acceptance package. When all items are closed, issue a certificate of conformity or equivalent acceptance certificate before shipment as a shipment exit criterion.

Documentation and Handover That Withstands Scrutiny

Demand complete and accurate documentation at FAT exit. That means as‑built drawings and wiring schematics, bills of material, software source and version manifests, backups, calibration certificates, manuals, labeling to applicable standards, and the full FAT report with raw data, deviations, dispositions, and signatures. ControlDesign recommends a traceability matrix that links requirements to test steps and outcomes. In regulated industries, ISPE guidance expects data integrity controls and qualified test methods; only leverage vendor data after verifying integrity and outcomes and applying stage‑gate decisions.

Practical Benchmarks and Examples

Benchmarks clarify expectations and reduce debate during execution. The following examples, adapted from AQI Service and related notes, illustrate objective criteria across different domains. They are directional and must be adapted to your equipment and standards.

A case inspection on a mobile substation cited by AQI Service on March 22, 2025, documented grounding continuity at or below 0.1 Ω, verified accurate remote signals into SCADA, and closed with an accepted report and calibrated instruments. Examples like this show how objective measurements, photos, and witnessed sign‑offs cut through disagreements later.

Tools and Software That Strengthen FAT

Modern FATs benefit from software that automates steps, acquires data from diverse sensors, and applies pass or fail criteria in real time. The University of Minnesota overview of FAT software emphasizes automation of procedures, broad DAQ support across thermocouples, pressure transducers, accelerometers, and digital I/O, plus strong configuration control so test scripts, calibrations, and hardware mappings are versioned and repeatable. Real‑time dashboards with alarms help teams stop, diagnose, and correct rather than discovering issues after the fact in reports.

Teams that also build significant application software into their control systems can borrow proven concepts from agile acceptance testing in the software world. Sources such as QualiZeal and BrowserStack describe layered test strategies that quickly deliver a verdict by running the right tests at the right stage, which is both compatible with and helpful to automation controller and HMI software modules. When applying these ideas to industrial systems, be explicit that test environments mirror production behavior closely enough to be meaningful and constrain automated checks to non‑invasive scenarios during FAT.

Pros and Cons of a Rigorous FAT

A strong FAT reduces total project cost, compresses onsite startup time, and hardens safety and cybersecurity posture before first energization. It enables structured operator training and builds trust with concrete, signed evidence. The limitations are also real. Simulators and hard‑wired loops cannot fully replicate plant dynamics; control loops may behave differently once real process responses and utility conditions apply. There is a schedule and travel cost to a thorough, witnessed FAT, and some teams over‑specify FAT scope and then feel pressure to rush through it. Precision For Medicine notes that virtual FATs can cut travel costs that often approach about $40,000.00 on large programs and raise participation if you invest in design finality, careful scheduling, and remote control and visualization tools. The tradeoff is an increased risk of shipping a system that has not been observed under sufficient scrutiny, unless you compensate with rigorous documentation and active, real‑time collaboration.

Buying and Care Tips When You Contract for FAT

Select an integrator or OEM that treats FAT as an engineering activity rather than a ceremonial checklist. Ask to see a sample protocol that includes a requirement‑to‑test traceability matrix, objective pass or fail thresholds, and a defined deviation process. Require a pre‑FAT dry run and reserve the right to adjust the focus based on early findings without expanding scope unbounded. Insist that firmware and software versions, configuration databases, and code repositories be baselined and backed up as part of acceptance, with recovery instructions verified.

Simulate your site conditions wherever reasonable. Provide parts, materials, and recipes in time for debug and runoff, as advised by ATC Automation and Automation NTH, and align the acceptance run duration with how you will actually run the line. Validate cybersecurity basics during FAT by confirming roles, password policies, logging, time sync, network addressing, and that unnecessary remote access is disabled by default, as ControlDesign recommends. For virtual FATs, plan communications like you would plan I/O: establish persistent rooms for each workstream, publish access information in the schedule, and assign a facilitator to keep disciplines synchronized.

When you evaluate FAT software, look for robust automation of procedures, broad sensor and DAQ support, configurable real‑time pass or fail criteria, synchronized multi‑signal logging, and audit‑grade reporting with templates you can tailor to your sector. Configuration management matters; the University of Minnesota article calls it critical in regulated environments where repeatability, traceability, and root‑cause analysis are mandatory.

Common Pitfalls and How to Avoid Them

The most frequent failure is incomplete coverage because nobody mapped requirements to tests. Close that gap with a short pre‑test review cycle where engineering and operations read the protocol against the design and agree on appearance limits and quantitative thresholds. The second failure mode is weak customer participation. Mandate a witness presence or deliver reliable remote streaming with live data and instrument views so decisions can be made in the moment. A third pitfall is ambiguous criteria that lead to inconsistent calls; bring numbers to subjective areas so discussions about quality become discussions about thresholds and methods. Finally, delays compound when nonconformities linger after shipment; set deadlines and retest to closure before signing acceptance, including cybersecurity and change‑control checks.

MAVERICK Technologies’ checklist of I/O ranges, fail positions, addressing, and controller loading is a useful supplement when your FAT relies heavily on simulation. RealPars’ methodical I/O checkout and analog scaling verification is a practical model for panel FATs that many teams skip at their peril.

FAT vs. SAT: Two Stages That Complement Each Other

FAT keeps the factory honest to the spec and gets the machine or system ready for shipment. SAT ensures the system integrates into your utilities and production environment and validates inter‑system interfaces. It is helpful to frame them as partners rather than substitutes. The handover from FAT to SAT is smoother when you export your FAT tag list, test limits, and alarm definitions into site commissioning plans, then repeat the most critical FAT items in situ while adding site‑specific tests for interfaces, utilities, and environmental conditions.

Takeaway

A great FAT is not an event; it is a disciplined, collaborative process that starts in design, uses risk to focus effort, executes with realism and rigor, and concludes with evidence that will stand up to the pressures of commissioning. If you invest in traceability, objective criteria, calibrated data, and engaged witnesses, you will recover far more time and money at startup than you spend preparing and running the test. Keep the scope true to what a factory can prove, and hand cleanly to SAT with the people and knowledge already aligned.

FAQ

How early should we define FAT acceptance criteria?

The strongest programs define criteria during requirements and design, not weeks before shipment. Locking thresholds, methods, and documentation expectations early allows the builder to design for testability, run a pre‑FAT dry run, and avoid protocol churn that burns schedule near the finish line. This guidance aligns with ATC Automation’s emphasis on early protocol alignment.

What belongs in a FAT acceptance package at shipment?

Expect a signed FAT report with raw data and timestamps, a closed deviation list, a requirement‑to‑test traceability matrix, as‑built drawings, software source and version manifests, backups, calibration certificates, label and nameplate verification, and a certificate of conformity. ControlDesign and Control Engineering both elevate the certificate of conformity as a shipment exit criterion.

When does a virtual FAT make sense, and what are the risks?

Virtual FATs can increase participation and cut travel costs that often approach about $40,000.00 on large programs. Precision For Medicine’s case studies show they work when designs are finalized, roles and schedules are explicit, persistent video is used, and remote control of equipment is enabled. The risk is lower fidelity of observation, so compensate with meticulous documentation and active, real‑time collaboration.

How long should the performance run last during FAT?

Run long enough to demonstrate stability and repeatability that resembles your real operations. Many discrete manufacturing programs use an eight‑hour run across variants as a minimum, as shared by Automation NTH. Process systems may require longer soaks or endurance tests based on thermal and control dynamics. If you shorten this phase, be explicit about the risk you are accepting.

What if production parts are unavailable for FAT?

Agree on representative surrogates and what data will be accepted as evidence, and document any concessions. ATC Automation recommends aligning on samples and debug runs early so you do not repeat FAT later. Capture enough objective performance to justify shipment while understanding the added scope that will shift to SAT.

Which FAT software features are most valuable in practice?

Automation of test steps with clear pass or fail criteria, synchronized multi‑signal logging across diverse DAQ devices, real‑time visualization and alarms, configurable reporting templates, and strong configuration management are the features that pay back. The University of Minnesota resource highlights these capabilities for traceability and repeatability, especially in regulated contexts.

References

ATC Automation; AQI Service; Control Engineering; ISA InTech; ControlDesign; SafetyCulture; University of Minnesota; Automation NTH; RealPars; Precision For Medicine; MAVERICK Technologies.

1. https://www.academia.edu/93196016/Factory_Acceptance_Testing_Site_Acceptance_Testing_Commissioning_Activities_Oh_My_
2. https://ddg.wcroc.umn.edu/factory-acceptance-test-software/
3. https://www.sei.cmu.edu/documents/5645/2017_018_100_503518.pdf
4. https://digital.library.unt.edu/ark:/67531/metadc739187/
5. https://do-server1.sfs.uwm.edu/link/_A29109B208/edu/A91820B/industrial+process+automation+systems+design+and+implementation.pdf
6. https://www.isa.org/intech-home/2017/march-april/columns/bypassing-the-factory-acceptance-test
7. https://aqiservice.com/factory-acceptance-test-fat-guide/
8. https://www.automationnth.com/steps-to-automation-step-8-runoff-&-factory-acceptance-test-at-supplier/
9. https://www.browserstack.com/guide/acceptance-testing
10. https://www.champtechnology.com/fats-a-critical-step/