Factory Acceptance Testing for Plant Controls: The Complete Guide

An illustrative scenario, typical of a first FAT rather than a description of any one project.

An engineering manager landed in a Midwestern integrator shop on a Monday morning with her commissioning lead and a controls engineer from the end-user plant. The panel was built. The skid was wired. A Rockwell ControlLogix chassis sat staged next to a Siemens S7-1500 on the same bench because the project included two OEM-supplied subsystems. The integrator’s project lead handed her a factory acceptance test protocol document and a punch-list template. She had four days to decide whether the shipment left on Friday.

The reader of this post is typically in that same position: named on a capital project, a FAT date on the calendar, and no single resource that walks through the activity end to end. Vendor pages frame FAT as a sales offering. Validation guides frame it as a pharmaceutical requirement. Glossary entries define it in a sentence. This guide covers the nine topics an engineering manager actually needs: definition and purpose, why FAT matters, preparation, the distinction between FAT, SAT, and commissioning, a day-by-day execution rhythm, defect classification and sign-off, handoff deliverables, common failure modes, and travel logistics when FAT is held at the supplier’s shop.

What Is a Factory Acceptance Test for Plant Controls

A factory acceptance test for plant controls is the witnessed verification that a control system built and staged at an integrator or OEM shop meets the functional, performance, and documentation requirements specified in the purchase order before the equipment ships to the end-user plant. It covers hardware inspection, control logic, operator HMI, alarms, network integration within the delivered scope, and the documentation package, typically with simulated or partial I/O. Both the end user and the supplier witness the tests and sign off test by test.

The purpose is concrete. A defect caught at the supplier’s shop is cheaper and faster to fix than the same defect caught at the plant. The integrator still has every tool, every bench, and every software engineer on hand. Spare components sit on the shelf. A change to a ladder routine and a re-verification cost hours of bench time, not a flight and a shutdown. A disciplined FAT catches build errors, logic errors, HMI inconsistencies, alarm misclassifications, and documentation gaps at the point of lowest intervention cost.

FAT has a second purpose that matters more than most sales pages acknowledge: it gives the end user a structured opportunity to learn the system before it arrives. The operator SME who runs every alarm test at FAT, watches every permissive fire, and walks through every HMI screen arrives at the plant site acceptance test with operational fluency the system would otherwise earn only through production experience. This reduces site acceptance test duration, reduces commissioning training hours, and improves the quality of operator feedback during startup.

The stakeholders on a controls FAT are specific. From the end user: an engineering manager or commissioning lead, a controls engineer, and an operator or maintenance subject matter expert. From the supplier: a controls engineer and a project lead, with a software engineer on call when logic questions arise. In regulated industries (pharmaceutical manufacturing, biotech, food under federal oversight), a QA or validation witness attends, because the FAT contributes to validation evidence downstream. On first-time integration with a new integrator or on safety-related scope, an independent commissioning consultant is often added to the end-user team.

Scope boundaries are worth naming early, because confusion about them is a common reason FATs run long. FAT covers the industrial control systems hardware, software logic, HMI, network integration within the delivered scope, simulated I/O, and documentation. FAT does not cover field installation at the plant, integration with existing plant systems that are not present at the shop, or full production-rate operation with real process. Those activities belong to site acceptance testing and commissioning, which are sequential and cumulative with FAT rather than substitutes for it.

The international reference for the discipline is IEC 62381, which formalizes the structure of acceptance-test procedures in the process industry. For regulated manufacturers, ISPE GAMP 5 guidance in its second edition positions FAT within a risk-based validation lifecycle. A FAT protocol that aligns with both references is defensible across non-regulated capital projects and regulated validation audits without significant restructuring.

Why Factory Acceptance Testing Matters to the Capital Project

Factory acceptance testing is a capital-project risk-control activity, and the economics favor running a disciplined FAT even when schedule pressure tempts a shortcut. The cost-of-defect curve in controls projects is steep. A defect caught at FAT typically takes one unit of engineering effort to resolve, using resources already on site. The same defect caught at SAT takes three to five units, because someone has to travel, parts have to ship, and the plant commissioning window has to absorb the delay. The same defect caught during commissioning or startup takes ten to twenty units and can delay production. Practitioner commentary in Control Engineering and ISA Interchange puts the FAT investment at three to eight percent of total controls project cost, and projects that skip or shortcut FAT commonly see commissioning duration expand two to five times over baseline.

FAT is also where the integrator’s work is judged against specification at the one moment the integrator still has full accountability. After sign-off and shipment, the conversation shifts. A defect discovered at SAT becomes a question of who caused it: the integrator during build, the rigger during shipping, the electrician during installation, or the end-user team during pre-energization. Before shipment, accountability is unambiguous. FAT is the last point at which the end user can reject the work at the supplier’s cost.

The “we trust our integrator” objection surfaces at almost every pre-FAT kickoff, and it deserves a direct answer. Trust is not a reason to skip FAT. Trust is a reason to run FAT efficiently. A disciplined FAT with a trusted integrator runs faster because fewer defects surface, not because fewer tests are executed. The protocol still runs, the witnesses still sign, and the documentation still gets reviewed. The value of trust is that the FAT completes in four days rather than seven, not that it completes in zero.

Integrator accountability is one of the reasons systems integrator selection is a parallel discipline to FAT. An integrator who resists FAT discipline at the contract stage is an integrator who will resist it at execution, and the end user will end up paying for the internal testing the integrator should have completed before the witness team arrived. The contract language that governs FAT scope, entry criteria, witness requirements, and defect disposition is drafted long before anyone boards a flight.

The budget framing is useful for engineering managers who have to defend the FAT line item during capital review. A three-day controls FAT with an end-user team of three traveling to an integrator within the continental United States typically runs $30,000 to $60,000 in fully-loaded cost, including team time, travel, and per diem. A commissioning window extended by two weeks because FAT was skipped typically runs $200,000 to $600,000 in production-delay cost, rework, and consultant fees. The math survives every budget review; the political cost of defending the FAT line item rarely does not.

Preparing the Factory Acceptance Test: Protocol, Documentation, and Punch List

Sixty percent of a successful FAT happens before anyone boards a flight. Preparation determines whether the on-site days run smoothly or chaotically. Three preparation artifacts matter most: the FAT protocol, the documentation package, and the punch-list template.

The FAT protocol is the binding test plan. Aligned with IEC 62381, the protocol contains a cover page, scope statement, responsibilities, test environment description, prerequisites, test categories with procedures and expected results, acceptance criteria, deviation handling rules, and signed sign-off pages. A typical controls FAT protocol for a mid-complexity skid runs 80 to 150 pages. Batch or recipe-heavy projects under ISA-TR88.00.04 run longer because each recipe phase and each equipment module carries its own test set. Plant-scale or MES-integrated FATs can exceed 300 pages.

The test categories the protocol must cover include:

• Hardware inspection: panel build quality, wiring dress, termination torque, label legibility, ground continuity.
• Power-up and fault clearing: cold-start behavior, fault-clearing sequence, power-interruption recovery.
• I/O loop checks: forced and simulated I/O verified to each field signal’s expected range and engineering units.
• Control logic verification: sequence tests, interlock verification, permissive logic, PID loop review with simulated process response.
• Operator HMI verification: screen-by-screen navigation, control element behavior, trend display, historian data flow.
• Alarm verification: every alarm triggered, every classification verified, every operator response confirmed.
• Network and communication verification: Ethernet topology, industrial protocol handshakes, controller-to-controller messaging.
• Failure and recovery tests: emergency stop, loss-of-power, network fault, communication timeout, safe-state transitions.
• Safety-related function verification: where a safety instrumented system is in scope, each safety function is verified to its target SIL with pre-use response-time measurement.
• Documentation review: every document in the package is opened, cross-checked against the build, and signed.

The documentation package must be in place before FAT starts, not during. Required documents include P&IDs, control narrative, I/O list, network diagram, panel general arrangement and schematic drawings, bill of materials, software and firmware version list, HMI screen inventory, alarm list, the test protocol itself, and signed design review minutes. A FAT that begins with a missing control narrative is a FAT that will stall on day two when a tester asks what behavior is actually required.

The punch-list template is the instrument that turns observations into trackable defects. The template fields include defect number, date, discovered by, test reference, description, affected component, severity class (Critical / Major / Minor), resolution owner, required-before-ship flag, resolution date, and verification signature. A verbal “we’ll fix that before ship” understanding is the primary way defects are forgotten. The punch list is the remedy, and discipline about entering every observation, including minor cosmetic issues, is what separates a FAT that catches what it should catch from one that does not.

Entry criteria determine whether FAT starts on the planned day. The panel build must be complete, the software must be loaded at the production version, the simulation or stimulus rigs must be connected, every cited document must be present and issued at the signed revision, and the integrator’s internal dry-run must be documented as complete. If entry criteria fail on the morning of day one, FAT pauses. Negotiating entry criteria under schedule pressure is the most expensive decision an engineering manager makes at FAT, because every subsequent problem on days two, three, and four traces back to it.

The end-user team brings its own preparation artifacts: highlighted P&IDs flagging areas of operational focus, an operator-SME question list, specific scenarios the plant has historically struggled with and wants verified (a particular alarm flood, a specific changeover sequence, a known recipe edge case), and the punch-list template. Preparation on the end-user side is not the integrator’s responsibility. An end-user team that arrives without preparation witnesses the integrator’s testing; an end-user team that arrives prepared directs the testing toward the plant’s real operational risks.

FAT vs SAT vs Commissioning: What Each Actually Covers

The most common question engineering managers ask before their first FAT is where the boundaries lie between FAT, site acceptance testing, and commissioning. The three activities are sequential, cumulative, and each has its own protocol, punch list, and sign-off. A pass at one does not dismiss the next.

The comparison below captures the essential differences.

	FAT	SAT	Commissioning
Location	integrator or OEM shop	end-user plant	end-user plant, live process
Timing	before shipment, after integrator internal dry-run	after installation, before production tie-in	after SAT, during plant start-up or restart
Primary focus	build quality, logic correctness against purchase order, documentation completeness	installation quality, field device integration, verification that nothing was damaged or misconnected during shipping or install	bringing the system into production service, verifying performance guarantees, training operators on live equipment, integrating with existing plant systems and business processes
I/O	simulated or partial; stimulus rigs substitute for field devices	real field devices connected; process usually not running	real field devices, real process, full production rates once cleared
Typical duration	3 to 5 days for a skid or packaging line, 2 to 3 weeks for plant-scale scope	3 to 7 days for a skid or line, 2 to 4 weeks for plant-scale scope	2 to 12 weeks depending on scope and production type; batch manufacturing typically runs longer than continuous
Key output	signed FAT report, updated documentation package, software archive, open punch list, action list for SAT	signed SAT report, field-device calibration records, updated as-installed documentation, pre-commissioning readiness	signed commissioning report, performance test run, operator training certification, final acceptance against contractual guarantees, handover to operations

IEC 62381 also recognizes a Site Integration Test (SIT) in some process-industry contexts, which sits between SAT and commissioning. SIT is the activity where a newly commissioned subsystem is integrated with the rest of the plant’s control architecture and tested under simulated load before real process is introduced. SIT matters for brownfield projects where the new system has to coexist with existing PLC, SCADA, and MES layers.

Where the boundaries blur is worth naming. Some end users combine SAT with early commissioning under a single protocol. Some integrators propose a combined FAT plus pre-commissioning at the shop for projects where the shop is close to the plant. Regulated-industry projects often require a separate validation lifecycle (Installation Qualification, Operational Qualification, Performance Qualification) layered on top of FAT, SAT, and commissioning. The post’s recommendation is to keep FAT, SAT, and commissioning as distinct gates even when the paperwork overlaps, because collapsing the gates compresses the chances to catch defects at the point of lowest intervention cost.

For readers whose FAT work pushes them deeper into the full commissioning discipline, Joltek’s commissioning support carries the detail on SAT, commissioning protocols, performance testing, and final acceptance.

Executing the FAT: A Day-by-Day Run

A four-day controls FAT is the most common engagement pattern for mid-complexity skid or packaging-line scope. The rhythm changes each day, and knowing what to expect on each day helps the end-user team pace itself, ask the right questions, and avoid the cognitive overload that derails first-time attendees.

Day one begins with entry-criteria verification. The end-user team confirms that the integrator’s internal dry-run is documented, the protocol on the bench is the signed revision, the documentation package is present at the cited revisions, and the physical build matches the general arrangement drawings. If any entry criterion fails, the FAT pauses. This sounds theoretical until the first time the team arrives to find that the software loaded on the controller is one revision behind what was tested internally, at which point every subsequent test is suspect.

The rest of day one covers hardware inspection, power-up, communication verification, HMI cold-start and navigation, and I/O loop checks on a representative sample. The goal is to establish baseline confidence. Large defect counts on day one predict a schedule slip and often indicate that the integrator’s internal dry-run was incomplete. A useful rule of thumb: more than ten open Major or Critical defects at end of day one is a signal to convene a schedule conversation with the integrator’s project lead rather than pushing harder into day two.

Day two covers control-logic verification by subsystem. Sequence tests, interlock verification, permissive logic, and PID loop review with simulated process signals. This is the day the operator or maintenance SME earns her seat at the table. Questions like “what happens when this permissive is false while this sequence is step three” surface logic bugs that a controls engineer alone would not catch because the controls engineer is thinking about the code, not about the plant scenario. Operator-SME participation is heaviest on day two, and the end-user team that sent only a project manager is on day two realizing the under-staffing cost.

Day three covers alarm verification, failure-mode and recovery tests, network-fault tests, and emergency-stop or safety-function verification when safety instrumented system scope is present. These are the tests that surface the defects the integrator never saw during internal testing, because internal testing rarely exercises the full failure surface. A typical day three produces the highest rate of new Major defects, which is why the end-user team must hold day four in reserve for re-verification rather than booking return flights.

Day four is re-verification, documentation review, open-punch-list review, and sign-off negotiation. Every defect logged on days one through three is re-tested after fix. Documentation is reviewed cross-document (the alarm list matches the HMI screens, the I/O list matches the wiring schedule, the control narrative matches the logic). The sign-off meeting is a formal review of the punch list, category by category, with written disposition for each Critical and Major defect. The meeting is paced; a rushed sign-off is a sign-off that becomes a SAT problem.

Defect logging discipline during the run matters more than any individual test procedure. Every observation goes into the punch list immediately, even minor cosmetic issues. Verbal understandings between the end-user team and the integrator are the primary way defects are forgotten. A useful rhythm: at the end of each test day, the end-user team and the integrator’s project lead review the day’s punch-list entries together, agree on classification, and assign resolution owners. The review takes thirty minutes and prevents the day-four scramble that otherwise dominates sign-off.

The witness convention is specific. The end user witnesses each test step, the integrator executes, and both sign the test step as passed, failed, or deviated. Remote or hybrid witnessing has grown since 2021, and it has a place for low-complexity subsystems or repeat builds with trusted integrators. For first-time integration with a new integrator, for safety-related scope, and for complex HMI review, in-person attendance produces outcomes that remote witnessing does not. The travel cost is small compared to the cost of the defect the remote witness did not catch.

Classifying Defects and Defining What “Pass” Means

The discipline that separates a rigorous FAT from a theater FAT is defect classification. The classification matrix and the sign-off criteria that follow from it are where most engineering managers make the mistakes that come back to haunt them at SAT and commissioning.

Three defect classes cover almost every observation:

• Critical. A defect that prevents core function, creates a safety hazard, violates a regulatory or purchase-order requirement, or introduces data integrity risk. Critical defects must be resolved and the failing test procedure must be re-verified before shipment. No exceptions, no deviations, no “we’ll fix it at the plant.” A safety-function failure, a permissive that does not prevent the hazard it was designed to prevent, a batch record that cannot be reconstructed, an alarm that does not trigger when its condition is met: all Critical.
• Major. A defect that does not prevent core function but significantly impairs usability, reliability, or planned operation. Major defects must be resolved before shipment, or the parties must sign a written deviation with a compensating action and a firm resolution date scheduled within the commissioning window. A PID tuning that is acceptable for initial start-up but requires refinement with real process, an HMI screen with navigation awkwardness that slows operator response, a recipe phase that works but takes longer than specified: all Major.
• Minor. A cosmetic, documentation, or convenience issue that does not affect function. Minor defects can be resolved after shipment and are tracked on the punch list through commissioning. A panel label misaligned, a documentation page number out of sequence, an HMI color that is not the plant’s preferred shade: all Minor.

Sign-off criteria follow directly from the matrix. Zero Critical defects are open at sign-off. Zero Major defects are open at sign-off, or every open Major defect has a signed written deviation with a compensating action and a firm resolution date. Minor defects are documented on the punch list with resolution owner and date; the count of open Minor defects is disclosed but does not block shipment in most contracts.

What “pass” actually means deserves explicit statement, because the word carries different interpretations in different shops. “Pass” does not mean “no defects found.” A FAT that finds no defects is almost always a FAT that did not look hard enough. “Pass” means the control system has been witnessed to function per the purchase-order specification across the full protocol, defects have been classified and either resolved or properly deviated, documentation matches the as-tested build, and both parties have signed the FAT report. “Pass” is the integrated outcome of the test program, not the absence of findings.

Common sign-off traps to avoid include:

• Accepting a Major defect as Minor because the shipment date is next week. The commercial pressure is real. The engineering cost of misclassification is larger. A Major defect reclassified as Minor does not become less impactful in the field; it becomes harder to resolve because accountability has shifted.
• Signing a deviation without a compensating action and a firm resolution date. A deviation is not a free pass; it is an explicit acknowledgment that a defect exists with a specific plan to address it. A deviation without a plan is a documentation failure.
• Agreeing to a verbal fix without re-verifying the failing test. “We fixed it overnight, trust me” followed by a single-case demonstration is not re-verification. The full failing test procedure must run to completion.
• Allowing the integrator to demonstrate a fix without running the test steps that originally failed. Demonstrations are framing; test procedures are evidence.

For regulated-industry readers, the defect log feeds validation evidence, and defect classification directly affects Installation Qualification and Operational Qualification downstream under the GAMP 5 framework. Manufacturers, the validation team, and the auditor each read the FAT log. Sloppy classification invites audit findings that are easier to avoid at FAT than to defend months later.

Handoff Deliverables: What Gets Signed Before Shipment

Most project managers know the FAT report is a deliverable. Fewer track the full package of artifacts that must be signed before the equipment leaves the supplier’s floor. A thin handoff package creates problems at SAT that a complete handoff would have prevented.

The signed FAT report itself includes a cover sheet, a summary of testing, the defect log with classifications and dispositions, the signed protocol pages, the list of deviations and compensating actions, photographs of the as-built panel, and signatures from the end-user lead, the integrator’s project lead, and any independent witness. The report is the primary evidence that FAT occurred and reached a defined outcome.

The updated documentation package must reflect the as-tested state, not the as-designed state. P&IDs, the control narrative, the I/O list, the HMI screen inventory, the alarm list, the software version log, and the bill of materials are all updated with any changes made during FAT. Redlined markups made during testing are transferred to controlled drawings. A FAT that passed against specification but whose documentation still reflects the pre-FAT design is a handoff with a latent defect: the plant will read the wrong drawings during the first maintenance call.

The software and configuration archive is the exact version tested at FAT, checksummed and stored in a controlled repository. The end-user team should leave the shop with a copy. The archive is the version of software that arrives at the plant; any later change, whether by the integrator during shipping or by the end user during install, is a change-management event and is treated as such. A checksummed archive is the difference between “we tested version X and installed version X” and a dispute.

A training record is a handoff deliverable that reduces SAT and commissioning training pressure. Operator and maintenance SMEs who attended FAT have completed a preliminary training session on the live system. A signed training record documents who attended, what was covered, and what the trainee can demonstrate. The record accelerates later training by identifying which topics are already covered and which require repetition.

Packing and shipping documentation is easy to overlook and expensive when missed. Preservation notes (dry nitrogen purge where required, desiccant packs, temperature and humidity limits), shipping-shock monitor records for fragile equipment, lifting instructions, and uncrate instructions all travel with the shipment. A FAT-passed system that arrives at the plant damaged during shipping becomes a SAT problem and an insurance claim. A twenty-minute packing-standard conversation before the equipment leaves the shop avoids a six-week shipping-damage dispute.

The action list for SAT is the list of items that must be verified again at SAT because they could not be fully verified at FAT. This includes all real-world field I/O integration, field-device-specific tests, and any test that required the actual plant environment. The action list lives as an appendix to the FAT report and becomes the SAT test plan’s starting skeleton. A clear action list reduces SAT duration because the end-user team arrives at the plant with a pre-agreed set of tests that close the FAT-to-SAT gap.

The open punch list is the signed, agreed list of Minor items that travel with the equipment. It becomes the commissioning punch list’s starting point. The list names each item, assigns an owner, sets a resolution date, and captures the classification signed by both parties. An open punch list at shipment is not a FAT failure; it is the transparent record of what remains and who owns each item.

Common Failure Modes in Factory Acceptance Testing

Several mistakes recur across controls FAT engagements. Naming them ahead of a first FAT is faster and cheaper than encountering them in person.

Skipping entry-criteria verification. The team has flown in, the integrator’s schedule is tight, and the panel is 80 percent built. The temptation is to start anyway and cover the remaining 20 percent in parallel with the protocol. The reality is that the 20 percent surfaces defects that would have been caught in the integrator’s dry-run, and the end-user team pays for internal testing that should have completed before the witnesses arrived. Entry criteria exist to protect the end user’s time.

Accepting protocol deviations informally. The protocol calls for one behavior, the integrator demonstrates something close, the end-user team nods because the alternative works. Every deviation must be documented, assessed against specification, and agreed in writing. Informal deviations become documentation gaps at SAT and audit findings in regulated industries. If the deviation is acceptable, it is acceptable in writing.

Under-staffing the end-user witness team. Sending the project manager alone is the most common version of this mistake. A disciplined FAT requires at least three end-user roles: a controls engineer who can read the logic and spot errors, an operator or maintenance SME who understands how the system will actually be used, and a manager-level role who can negotiate disposition and sign off. Each role catches defects the others do not. Under-staffing means defects that an operator SME would catch are missed entirely, and the plant discovers them during commissioning.

Accepting verbal fixes without re-verification. “We fixed it overnight” followed by a demonstration of the single passing case is not evidence. The original failing test must run to completion. An integrator who resists re-verification is an integrator who is guessing at the fix, and the end-user team is better off insisting on the test even when the conversation is uncomfortable.

Reclassifying Critical or Major defects for schedule reasons. The commercial pressure at sign-off is real. The cost of pushing a Critical defect to Major or a Major to Minor to clear a shipment date compounds at commissioning. A defect that a reasonable independent witness would call Critical remains Critical regardless of what the signing parties want it to be. The label does not change the underlying behavior; it only changes who pays when the behavior surfaces at the plant.

Weak documentation review. The functional protocol passes and the test team moves to sign-off, but the documentation does not match the as-tested build. The plant receives a system whose as-built drawings are wrong, and every subsequent troubleshooting call costs more than it should because the maintenance technician is chasing a wiring path that exists only on paper. Documentation review is a formal step, not a formality.

Assuming remote FAT matches in-person FAT. Remote or hybrid witnessing has a place for low-complexity subsystems, repeat builds with trusted integrators, and stakeholders who cannot attend the full protocol. It does not replace in-person attendance for the primary witness team on first-time integrations, safety-related scope, or complex HMI review. The travel cost is bounded; the cost of a missed defect that propagates to SAT and commissioning is not.

Travel Logistics When FAT Is Held at the Integrator or OEM Shop

The practical reality most FAT guides omit is that a controls FAT is frequently a week of the end-user team’s time at a facility hundreds or thousands of miles from the plant, and the logistics affect the quality of the test. A short, practical section on travel discipline pays back quickly.

Time-zone reality matters. If the integrator is overseas or on the opposite coast, plan for a day of travel on each side and expect the first morning on site to be low-productivity. Build the protocol so day one is inspection, power-up, and low-cognitive-demand verification rather than the logic tests that require full attention. A controls engineer who flew red-eye and is reviewing sequence logic at nine in the morning is not catching the defects she would catch at two in the afternoon on day two.

Team composition on site for a typical controls FAT includes a controls engineer, an operator or maintenance SME, and a project or engineering manager. In regulated projects, add a QA or validation witness. For first-time integration with a new integrator, add an independent commissioning or controls consultant. The budget line for an outside consultant is small compared to the cost of defects an under-staffed team misses.

Duration budgeting accounts for the gap between protocol days and calendar days. A four-day FAT protocol commonly runs five to six calendar days on site because re-verification and the sign-off meeting extend beyond the protocol’s planned timeline. Do not book return flights for the planned final day. Book the next day, and accept the extra night in the hotel as cheap insurance against signing off under travel-deadline pressure.

Remote and hybrid witnessing has matured since 2021. Many integrators support remote-witnessing cameras, live screen shares, and recorded test steps. The tooling is useful for stakeholders who cannot attend and for low-complexity subsystems. It is not equivalent to in-person attendance for the primary witness team, and the distinction matters most on the tests that surface the hardest defects.

Shipping logistics are a FAT sign-off activity, not a separate conversation. Before leaving the shop, the end-user team confirms packing standard, shipping method, insurance coverage, delivery date, and rigging requirements. A FAT-passed system damaged during shipping becomes a SAT problem and an insurance claim that is slower than the twenty-minute conversation at the end of day four.

Per-diem and expense policy for long FATs must be established before travel. A commissioning lead who cannot extend by a day without written approval from corporate is a commissioning lead under pressure to sign. An engineering manager who needs to schedule an additional re-verification day but has no authority to approve the extra night is not in a position to run a rigorous FAT. The expense envelope is a quiet but important input to FAT quality.

Frequently Asked Questions About Factory Acceptance Tests

What is a Factory Acceptance Test?

A Factory Acceptance Test is the witnessed verification of a plant control system at the integrator or OEM shop, before shipment, against the purchase-order specification. It covers hardware inspection, control logic, operator HMI, alarms, network integration within the delivered scope, and documentation, typically with simulated or partial I/O. Both the end user and the supplier witness the tests and sign off test by test.

What is the difference between FAT and SAT?

FAT is performed at the supplier’s site with simulated I/O before shipment, focused on build quality and logic correctness against the purchase order. SAT is performed at the end-user plant after installation, with real field I/O connected but before production tie-in, focused on installation quality and field device integration. Both are sequential; a FAT pass does not dismiss SAT, and each has its own protocol, punch list, and sign-off.

Who attends a Factory Acceptance Test?

The end-user team typically includes an engineering manager or commissioning lead, a controls engineer, and an operator or maintenance SME. The integrator provides a controls engineer and a project lead, with a software engineer on call. In regulated industries, a QA or validation witness attends because the FAT contributes to validation evidence. For first-time integration with a new integrator or safety-related scope, an independent commissioning consultant is often added to the end-user team.

How long does a FAT take?

A mid-complexity skid or packaging-line FAT runs 3 to 5 days on site. A full plant or MES-integrated FAT can run 2 to 3 weeks. The protocol drives the duration; scope and defect count drive the variance around that baseline. A practical rule: book return travel for the day after the planned final day, because re-verification and sign-off commonly extend the protocol by half a day to a full day.

What is GAMP 5 and how does it relate to FAT?

GAMP 5 is the ISPE risk-based guidance for validation of computerized systems in pharmaceutical and regulated manufacturing. It positions FAT as a supplier-testing activity that contributes to validation evidence, with risk-based test selection and documented defect disposition. In a GAMP 5 project, the FAT protocol and report feed Installation Qualification and Operational Qualification downstream, and the defect log is reviewed by the validation team and the auditor during the validation lifecycle.

Factory Acceptance Testing Is the Last Cheap Opportunity to Catch a Defect

A factory acceptance test for plant controls is not a formality. It is the last point at which the supplier still has every tool to fix a defect cheaply and the end user still has the leverage to insist on the fix at the supplier’s cost. An engineering manager who walks into her first FAT with the nine-section framework in this guide (definition, why it matters, preparation, the FAT-SAT-commissioning distinction, day-by-day execution, defect classification and sign-off, handoff deliverables, failure modes, and travel logistics) is prepared to run a FAT that actually catches what it is supposed to catch, rather than one that rubber-stamps a shipment.

To run your next FAT from a single page, download the FAT checklist for plant controls (PDF): entry criteria, test categories, the four-day plan, defect classes, the punch-list fields and the handoff package. For an independent FAT witness or a protocol review before execution, Joltek acts as the plant’s owner’s engineer, and our commissioning support carries the same discipline through SAT and start-up.