For who: Controls engineers, OEM integration teams, and procurement/quality leads buying industrial control panels and cabinets.
Short outcome: A copy/paste FAT checklist structure plus an “evidence pack” layout (records + sign-offs) that reduces disputes, rework, and delayed shipments.
Factory Acceptance Test (FAT) for control panels: checklist + records clients expect
A control panel FAT is successful when two things are true: (1) the panel performs the required functions under defined test conditions, and (2) you can prove it with clear records. This guide gives you a practical FAT checklist structure (what to test) and the record pack structure customers typically expect (what to record), including a FAT report template layout and punch list workflow.
If you’re building or buying a cabinet with DIN-rail power supplies, safety circuits, PLC/HMI, and field wiring, the difference between “we tested it” and “it passed FAT” is documentation that is specific, repeatable, and signed.
What a control panel FAT is—and what it is not
A Factory Acceptance Test (FAT) is a structured verification of the control panel or cabinet in a controlled environment before shipment. The goal is to confirm the build matches the drawings and performs agreed functions, using defined test methods and acceptance criteria. FAT is also where you freeze documentation: as-built drawings, settings, labels, and the evidence pack.
FAT vs SAT vs commissioning: avoid scope gaps
FAT is not a full system commissioning. Your panel can “pass FAT” while the machine still fails on-site due to field wiring, sensors, pneumatic/hydraulic timing, or real-world loads. A clean approach is:
- FAT: verify the panel build and core logic with simulation and controlled inputs.
- SAT (Site Acceptance Test): verify integration with the real machine/process on-site.
- Commissioning: tune performance and validate production readiness.
Best practice: write the FAT scope so it’s explicit what is simulated vs what requires real equipment. That one paragraph prevents most “it didn’t work at our site” disputes.
Control panel FAT checklist: what to test
Think in layers: safety first, then power integrity, then I/O and sequences, then communications and HMI, then documentation. Below is a checklist structure you can adapt to most industrial control panels.
Incoming power, protection, and power-up behavior
- Incoming voltage and phase checks (as applicable).
- Main disconnect and protective device verification (ratings, labeling, torque record).
- 24VDC (or other DC bus) power-up: inrush behavior, nuisance trip check, brownout behavior.
- Power supply redundancy/ORing behavior (if used) and alarm contacts.
- Thermal/airflow basics: fans run, filters installed, hot spots noted (if criteria defined).
If your cabinet uses DIN-rail power supplies, define the DC distribution and branch protection tests early. For product selection and integration context, see the DIN-rail power supply collection.
PE/ground bonding and continuity evidence
- Protective earth (PE) continuity: door bonding straps, DIN rail bonding points, backplate bonding.
- Ground lug presence, labeling, and torque record.
- Shield termination approach verified against drawings (single-point vs multi-point as specified).
Customers don’t just want “ground is good.” They want a recorded measurement method, instrument used, and the pass/fail threshold.
I/O simulation and functional sequences
- Digital inputs: simulate sensors and confirm HMI/PLC state and diagnostics.
- Digital outputs: confirm correct device actuation (or simulated loads), including interlocks.
- Analog I/O: simulate 4–20 mA / 0–10 V loops, scaling, alarm thresholds, and failsafe behavior.
- Sequence tests: start/stop, mode select, permissives, fault handling, and reset logic.
Tip: define “functional sequence acceptance” as observable outputs (states, alarms, timing windows) rather than subjective judgment. That makes your records defensible.
E-stops, safety relays, interlocks, and reset logic
- E-stop loop validation: safe state reached, latched state behavior, reset requirements, indicator behavior.
- Guard door / interlock switches: expected behavior and diagnostic messaging.
- Safety relay or safety PLC: test each safety function with documented steps and evidence.
- Restart prevention: verify the system does not auto-restart on power return (unless explicitly designed to).
Network/fieldbus and HMI validation
- IP scheme confirmation, device discovery, and connectivity checks.
- Fieldbus health: node list matches drawings, comm-loss alarms verified.
- HMI screens: navigation, alarms, trends (if applicable), user roles, and key setpoints.
Need FAT-ready cabinets with documented evidence?
If you want the builder to execute FAT with an evidence pack (records, photos, punch list closure, and sign-offs), use the Integration Solutions service as the hub for scope and RFQ alignment, or start from the Services overview.
For projects where EMC and safety validation matter, reference the EMC and Safety Testing Lab during FAT planning so your evidence maps cleanly into later compliance work.
FAT report template: the fields customers expect
Your FAT report should read like a controlled test document: scope, method, results, and approvals. Most customers expect a consistent structure, even if they don’t provide a template.
Recommended FAT report sections (template layout)
- Header: project name, panel ID, revision, date, location, attendees.
- Scope: what’s included/excluded; simulated items; required utilities.
- Documents controlled: drawing list, BOM, software versions, network list.
- Instrumentation: tools used + calibration status/date.
- Test matrix: test IDs, steps, acceptance criteria, pass/fail, evidence reference.
- Deviations: punch list with owner, due date, closure evidence, retest sign-off.
- As-built release: final document set + revision control statement.
- Acceptance: conditional acceptance notes + signatures.
Deviations, punch list, and closure evidence
Treat deviations as normal. The difference between a professional FAT and a messy one is how cleanly you close the punch list: every deviation has (a) impact, (b) fix owner, (c) retest step, and (d) evidence that it’s closed.
Sign-offs and traceability
Include signature blocks for execution and acceptance (or conditional acceptance). Tie signatures to a specific document revision so it’s clear what was actually accepted.
Functional test records: how to make evidence “audit-proof”
The fastest way to lose customer confidence is to record results without context. Your functional test record should make it possible for someone who was not in the room to understand what was tested and why it passed.
Minimum fields that make a functional record usable:
- Test ID + requirement link: ties the test to a drawing note, sequence description, or customer requirement.
- Setup conditions: simulated inputs, jumpers, software mode, and any temporary overrides.
- Step-by-step actions: what the tester did (so the test can be repeated).
- Expected result: observable behavior and acceptance criteria.
- Observed result + evidence reference: photo number, screenshot file name, or meter reading table.
- Pass/fail + retest: if fail, link to punch list line item and retest outcome.
- Sign-off: tester and reviewer (and customer if required).
Standards touchpoints (UL/NFPA/IEC): what customers point to
Even when the customer doesn’t quote a clause number, their expectations often map to common safety and electrical standards. In the US industrial controls world, UL 508A is widely used for industrial control panels, while NFPA 79 covers electrical systems on industrial machinery. :contentReference[oaicite:6]{index=6} For machine electrical equipment and broader international projects, IEC 60204-1 is a common reference point. :contentReference[oaicite:7]{index=7} When the build resembles a low-voltage “assembly,” IEC 61439 concepts around verification and documentation can influence what evidence buyers expect. :contentReference[oaicite:8]{index=8}
Practical takeaway: treat standards as a guide for what to document—especially around safety circuits, protective bonding, labeling, and controlled documentation release.
Authoritative references (external): UL 508A summary (UL Solutions), NFPA 79 overview (NFPA), IEC 60204-1 publication page (IEC), IEC 61439-1 publication page (IEC).
Copy/paste control panel FAT checklist structure (what to test + what to record)
1) Header and scope
- Panel ID / project / revision / date / location / attendees
- Included systems and excluded items (explicit)
- Utilities and test setup requirements
- Software/firmware versions + network/IP list
2) Safety + protective measures
- E-stop test steps + observed safe state + reset logic record
- Interlocks/guards: per-device functional proof
- Safety relay/PLC diagnostics and fault injection results
- Protective bonding/continuity results + instrument used
3) Power system
- Incoming power checks + protective devices + torque log
- DC bus readings at load levels (defined) + alarm contacts
- Redundancy/ORing behavior (if applicable)
- Power-up/power-down behavior + brownout response
4) Controls + I/O
- DI/DO point-to-point verification (with I/O map evidence)
- Analog loop simulation results (scaling + alarms)
- Functional sequences: steps, expected results, observed results, timestamps
- Fault handling: injected fault → alarm → safe state → recovery
5) Communications + HMI
- Device discovery and comms-loss alarms
- HMI navigation + alarm list + critical setpoints protected by roles
- Export key screenshots/logs as evidence references
6) Documentation + labeling
- As-built drawing list (released revision)
- Label list (wire IDs, terminals, devices) + mismatch log if any
- Punch list closure summary + retest sign-off
- Final acceptance signatures
Want examples of documentation-led builds? See: Build-to-print case with traceability, FAT, and documentation and industrial control panels and power supply cabinets case.
Plan FAT early to avoid late rework
The best time to define FAT scope is before the panel is wired. If you align on test points, evidence expectations, and sign-off roles early, FAT becomes a predictable gate instead of a stressful argument at ship time.
Use the Services hub to route internally, or go direct to Contact Us with your panel I/O list, drawings, and acceptance requirements.
FAQs
What should be included in a control panel FAT report?
Scope + revision control, instrumentation list, test matrix with criteria, results + evidence references, deviations/punch list closure, and sign-offs.
Who signs the FAT—customer, OEM, panel shop, or integrator?
Commonly: builder/integrator signs execution; customer/OEM signs acceptance (or conditional acceptance); engineering signs as-built release.
What’s the difference between a FAT checklist and a commissioning checklist?
FAT verifies panel build and simulated functional behavior before shipment; commissioning verifies the real system on-site with actual field wiring and loads.
What test equipment is typically required for a panel FAT?
DMM, clamp meter, I/O simulators (digital/analog), network tools, and—when specified—insulation/continuity/ground-bond test equipment.
