Factory Acceptance Testing (FAT) Best Practices

Factory Acceptance Testing (FAT) Best Practices

Factory Acceptance Testing, or FAT, is the point where design intent is verified against a real, assembled system before shipment to site. For electrical panels, MCCs, PLC/SCADA skids, automation cabinets, and packaged process systems, FAT is the most cost-effective opportunity to detect wiring errors, configuration defects, interface mismatches, documentation gaps, and cybersecurity weaknesses while the equipment is still in the factory. In contracting practice, FAT is not just a quality event; it is a risk-control gate that protects schedule, reduces site rework, and supports compliance with CE marking, the EU Machinery Directive, and applicable IEC/EN requirements.

1. Define FAT objectives before you write the test script

A strong FAT starts with clear objectives tied to the contract, functional design specification, and applicable standards. The test should prove that the delivered system:

• Matches approved drawings, BOM, and software version.
• Performs all specified control and safety functions.
• Has correct wiring, terminaling, labeling, and protection settings.
• Interfaces correctly with field devices, networks, and third-party systems.
• Meets documentation, traceability, and cybersecurity requirements.

For machinery control panels and electrical equipment assemblies, relevant references commonly include IEC 60204-1 for electrical equipment of machines, IEC 61439 for low-voltage switchgear and controlgear assemblies, IEC 61131-3 for PLC programming structure, and IEC 62443 for industrial automation and control system cybersecurity. In European projects, FAT evidence often supports the technical file for CE marking and demonstrates conformity with the Machinery Directive 2006/42/EC and, where applicable, the Low Voltage Directive and EMC Directive.

2. Build the FAT plan from contract requirements, not from habit

The most common FAT failure is a generic checklist that does not reflect the project’s actual risks. A good FAT plan should be derived from:

• Customer specifications and deviations.
• Functional Design Specification (FDS) and Cause & Effect matrix.
• P&IDs, GA drawings, wiring diagrams, loop diagrams, and network architecture.
• Safety requirements specification for any safety-related control functions.
• Applicable standards and local regulatory requirements.

For safety-related control systems, the FAT must verify the implemented safety functions against the safety requirements specification. If the project uses IEC 61508 or ISO 13849 concepts, the test evidence should reflect the required diagnostic coverage, category, or SIL/PL target. For machinery control, IEC 60204-1 Clause 18 addresses verification, including continuity of protective bonding, insulation resistance, and functional checks. IEC 61439 requires verification of design and routine tests for assemblies, including dielectric properties, temperature rise considerations, and protective circuit effectiveness.

3. Separate routine tests from functional tests

Contracting teams often blur routine factory tests with operational FAT. They are related but not identical.

Test type	Purpose	Typical examples	Primary reference
Routine test	Confirms the built assembly is electrically sound	Continuity, insulation resistance, dielectric withstand, polarity, torque checks	IEC 61439 routine verification; IEC 60204-1 Clause 18
Functional FAT	Confirms the system performs the intended control logic	I/O simulation, sequence testing, alarms, interlocks, communications	Project FDS; IEC 61131-3; IEC 60204-1 functional verification
Safety validation	Confirms safety functions achieve required performance	E-stop, guard interlock, STO, safety relay logic, safe state behavior	ISO 13849-2, IEC 62061, IEC 61508 as applicable
Cybersecurity verification	Confirms access control and secure configuration	Password policy, account roles, patch baseline, port hardening, backups	IEC 62443 series; project cybersecurity requirements

Keeping these categories separate improves traceability and avoids disputes about whether a failed point is a workmanship issue, a software defect, or a design change.

4. Use a traceable FAT matrix

The best FAT packages use a requirements traceability matrix that maps each test to a contractual or standards-based requirement. This prevents “nice-to-have” tests from displacing critical ones and helps close out punch items efficiently.

A practical matrix should include:

• Requirement ID.
• Source document and clause reference.
• Test method.
• Acceptance criteria.
• Actual result.
• Pass/fail status.
• Witness sign-off.

For example, if the system has a motor feeder, the matrix might link overload setting verification to the approved motor data sheet, short-circuit protection coordination to the design study, and the control sequence to the FDS. For the assembly itself, IEC 61439 routine verification records should be archived with the FAT dossier.

5. Verify hardware first, then software, then interfaces

FAT execution should follow the physical and logical stack of the system:

1. Hardware inspection: cabinet build quality, gland plates, earthing, segregation, clearances, torque marking, labeling, device ratings, and spare terminals.
2. Electrical routine testing: continuity, insulation resistance, dielectric withstand where specified, phase rotation, polarity, and protective circuit checks.
3. Software verification: PLC code version, HMI screens, alarm text, recipe logic, interlocks, permissives, and fallback behavior.
4. Interface testing: fieldbus, OPC UA, Modbus TCP, hardwired signals, time sync, historian links, and remote access paths.
5. Integrated scenario testing: start-up, shutdown, fault recovery, loss of comms, power failure, and safe restart.

This sequence reduces ambiguity. A software fault found before basic hardware integrity is established can waste time; similarly, interface testing before the control core is stable usually creates false failures.

6. Include cybersecurity checks in every modern FAT

For SCADA systems, PLC networks, and remote service gateways, cybersecurity should be part of FAT by default. IEC 62443-2-4 and IEC 62443-3-3 are especially relevant for security capabilities and operational requirements. FAT should confirm, at minimum:

• Unique user accounts and role-based access control.
• Default passwords removed or changed.
• Backups created and restoration tested.
• Remote access is controlled, logged, and approved.
• Unused services, ports, and accounts are disabled.
• Firmware and software versions are recorded.
• Security event logging is enabled where required.

For European projects, this is increasingly important because contracting teams must demonstrate reasonable technical and organizational measures, especially where systems support critical operations. FAT is the ideal place to capture this evidence before the asset leaves the factory.

7. Worked example: FAT planning for a 24-way MCC section

Consider a 24-way motor control center section with 18 direct-on-line starters, 4 VFDs, and 2 spare feeders. The project schedule allows 2 FAT days with one customer witness. The panel builder estimates the following test durations:

• Visual and mechanical inspection: 3 hours
• Continuity and torque verification: 2 hours
• Insulation resistance tests: 1.5 hours
• PLC/HMI functional simulation: 5 hours
• Motor starter and VFD sequence tests: 4 hours
• Alarm, trip, and interlock testing: 3 hours
• Documentation review and punch closeout: 2.5 hours

Total estimated FAT time:

$$T = 3 + 2 + 1.5 + 5 + 4 + 3 + 2.5 = 21 \text{ hours}$$

If the FAT day is 8 working hours, then two days provide 16 hours. The schedule is short by:

$$21 - 16 = 5 \text{ hours}$$

That means the FAT is underplanned by more than half a day. The contracting team has three options: extend the FAT to 3 days, reduce scope by pre-approving certain routine evidence, or run parallel test stations with additional technicians. If labor costs are $95/hour and one extra 8-hour day is added, the incremental factory cost is:

$$8 \times 95 = 760 \text{ USD}$$

That is usually far less than the cost of a failed site commissioning day, where travel, delay, and rework can easily exceed several thousand dollars. The example shows why FAT planning should be based on realistic test effort, not on optimistic assumptions.

From a quality perspective, the same project should also define acceptance criteria. For example, the insulation resistance test might require values above the manufacturer’s minimum and project specification, and the VFD communication test should show stable polling with no dropped frames over a defined period. If the project has a safety function, the test record should include the exact simulated fault, the expected safe response, and the measured response time.

8. Manage witnesses, hold points, and change control

In international contracting, FAT is often a witness point or hold point. That means the customer, consultant, or third-party inspector may need formal notice and access to evidence. Good practice includes:

• Issuing the FAT schedule early with named test windows.
• Providing a pre-FAT document pack at least several days in advance.
• Defining hold points for safety, software, and final sign-off.
• Recording deviations, concessions, and temporary workarounds.
• Freezing software and hardware versions before testing begins.

Any late change should go through formal change control. Even a small PLC logic change can invalidate prior test evidence if it affects sequence, alarm thresholds, or safety behavior. Good FAT discipline preserves the integrity of the acceptance record.

9. FAT acceptance criteria should be binary and measurable

Ambiguous criteria create disputes. “Looks good” is not acceptable. Every test point should have a clear pass/fail definition, such as:

• All devices match approved part numbers and ratings.
• All cables are terminated and labeled per drawing.
• All analog inputs scale correctly within the specified tolerance.
• All alarms are displayed with correct text and priority.
• All safety functions achieve the defined safe state.
• All backups are restorable to a verified test environment.

Where timing matters, define the allowable range. Where a threshold matters, define the exact threshold. Where a sequence matters, define the expected order. This is especially important for process skids, batch systems, and any equipment with interdependent permissives.

10. Close FAT with a disciplined dossier

The FAT dossier should be treated as a controlled project deliverable. At minimum, it should include:

• Approved FAT procedure and checklist.
• Traceability matrix.
• Calibration certificates for test instruments where needed.
• Signed test sheets and witness sheets.
• Redlined drawings and final as-built documents.
• Software version list and backup media identification.
• Punch list with closure evidence.

For IEC 61439 assemblies and IEC 60204-1 machine panels, keeping the test dossier complete is not just a commercial issue; it supports conformity assessment, future troubleshooting, and maintenance handover. For SCADA and networked control systems, the dossier should also include security configuration baselines and backup validation records.

Conclusion: common FAT mistakes and how to avoid them

The most common FAT mistakes are predictable: vague acceptance criteria, incomplete traceability, missing customer witnesses, software changes during testing, poor simulation of field devices, and treating cybersecurity as an afterthought. Another frequent problem is overreliance on visual inspection while skipping realistic functional scenarios such as power loss, communications failure, alarm flooding, or safe restart. These errors are avoidable if the FAT is planned from the contract documents, aligned with IEC/EN requirements, and executed with strict version control and measurable criteria. In practice, the best FATs are not the longest; they are the most disciplined, the most traceable, and the most representative of real operating conditions.