FAT and SAT for Control Panels

The panel is on the shop floor, the owner's engineer is flying in Thursday, and somebody just asked where the approved test procedure is. There isn't one. So the witness spends the day testing whatever occurs to them, the exceptions go into a notebook, and three weeks later at site nobody can say which of those items were fixed before the panel shipped. The panel was fine. The test was a mess, and the test is what the owner remembers.

Acceptance testing goes well when it is treated as a document exchange that happens to involve a powered panel. This article covers the procedure, what gets witnessed, the I/O checkout, the punch items it produces, and the record that closes it, with a filled set of test sheet rows.

FAT, SAT, and what each one proves

The factory acceptance test happens at the panel shop before shipment. It proves the panel was built to the approved drawings and that the program does what the sequence says, with the field simulated at the terminals. The site acceptance test happens after installation. It proves the panel, the field wiring, and the real devices work together in place. Some specs add a site integration test for the handoff to a plant SCADA or BAS head end, and IEC 62381 describes this FAT, SAT, and SIT split for process automation if you want the formal version.

The two tests catch different failures, which is why a good FAT does not replace a SAT. FAT finds wrong wire numbers, swapped terminals, a mis-scaled analog, and logic that does not match the narrative. SAT finds the transmitter ranged differently than the instrument index, the motor wired for the wrong rotation, and the comm cable run next to a VFD output. Write both procedures knowing which failures each one is there to catch.

The procedure is a submittal first

Most process and BAS specs require the test procedure to be submitted and reviewed before the test. The lead time varies, so check your spec, and add the review cycle to the schedule as its own line. A procedure that comes back revise and resubmit the week of the FAT moves the FAT.

A procedure that survives review carries:

• Scope. Which panels, which programs, which revision of the drawings and the sequence of operations the test is run against.
• Prerequisites. Approved shop drawings, program loaded and version recorded, panel QC complete, test equipment calibrated.
• Roles. Who operates, who witnesses, who signs. Name the owner's and engineer's witnesses if known.
• Test equipment. Loop calibrator, meter, simulator, laptop, each with its calibration date or serial.
• Steps and acceptance criteria. Every step says what is done, what should happen, and what counts as a pass, including the tolerance for analog checks.
• Test sheets. The blank forms you will fill in, attached, so the reviewer approves the forms as well as the prose.
• Deficiency handling. How a failed step is recorded, who owns the fix, and whether it must be retested before shipment or can carry to site.

That last item avoids the worst argument of the day. Agree in writing, before the test, that a cosmetic item can ship open and a failed interlock cannot.

What gets witnessed

The witness does not need to watch every terminal get checked. Agree on hold points instead: the steps the witness must see in person, and the steps your own tech can perform and document beforehand for spot checking. A typical FAT covers:

1. Visual and mechanical inspection against the drawings: layout, nameplates, wire labels, terminal numbering, the UL 508A label if the spec requires one, spacing, and the bill of materials against what is actually mounted.
2. Power-up: supply voltages, grounding, UPS transfer if fitted, power-loss restart behavior.
3. I/O checkout: every point, end to end, covered below.
4. Logic and sequence tests: each mode of the sequence driven with simulated inputs, permissives and interlocks verified, alarm setpoints tripped.
5. HMI: screens against the approved graphics, alarm text and priority, operator controls, security levels.
6. Communications: network addresses, protocol points to the head end or SCADA, and behavior on comm loss.

SAT repeats a subset with real field devices, plus the parts only the site can show: rotation, actual process response, and the integration points the FAT could only simulate.

I/O checkout, point by point

The I/O checkout is the bulk of the test and the part most worth doing carefully. Each point is exercised from the terminal or the field device through to the controller and the HMI, and each output is commanded and confirmed at the device or the terminal.

For a discrete input, apply the signal and confirm the controller bit and the HMI indication. For an analog input, inject at least three values across the range, commonly 4, 12, and 20 mA, and confirm the scaled engineering value against the stated tolerance. For an output, command it from the HMI and confirm it at the terminal or the device, and confirm it drops on command too. At FAT the signal is simulated at the panel terminals. At SAT the same check is run from the field device, which is the loop check, and the instrument index and loop drawings described in I/O lists, instrument indexes, and loop drawings are what the sheets get checked against.

A filled set of rows from a lift station panel FAT, run against drawing set E01 to E07 Rev 1 and program version 1.4:

Two details carry the record. The failed step keeps its row and points to an exception number, and the retest gets its own row with the new program version. Overwriting step 4.13 with "Pass" would erase the only proof that the program changed during the test.

The punch items it produces

Every failed step and every observation the witness raises becomes an exception: a numbered item with a description, the step it came from, an owner, and a disposition. Most of them are punch items in the ordinary sense, tracked to closure the same way as the substantial completion list. The mechanics of owners, rounds, and closure are in punch list to retainage.

Sort the exceptions before anyone leaves the room:

• Fix and retest before shipment. Failed interlocks, wrong safety logic, anything the witness needs to see work.
• Fix before shipment, verify by record. Wrong nameplate, missing wire label. A photo and your tech's initials close it.
• Carry to site. Items that can only be resolved with field devices, or that the owner agrees can wait.

Write the disposition beside each exception and have the witness initial the list. An exception list nobody signed is a list the owner can expand later.

The signed record that closes it

A test is closed by a report, not by the witness flying home. The report is what goes to the engineer, gets filed with the project, and eventually lands in the O&M manual's test records chapter. It carries:

• A cover sheet with project, panel tags, test type, dates, and the signatures of the operator, the witness, and the owner's representative.
• The procedure revision the test was run against.
• Every completed test sheet, failed rows included.
• The exception list with disposition and closure date for each item.
• The as-tested program version, ideally with a file checksum, and the drawing revision.
• Test equipment serials and calibration dates.

Submit the FAT report before the panel ships if the spec makes acceptance a condition of shipment, which many process specs do. The SAT report goes in after startup and feeds directly into substantial completion. Both are cheap to produce on test day and expensive to reconstruct from a truck laptop later.

How Submittal Kit handles this

The pain here is test-day exceptions that live in a notebook and resurface at site with no history. In Submittal Kit, each exception becomes an item on the project's punch list, numbered per panel, with its source, severity, owner, and a round history when an item comes back. At FAT acceptance you issue a Punch List for Record, which freezes every item and the percent complete exactly as they stood that day and exports to XLSX for the witness. At turnover, the signed report goes into the Testing & Commissioning section that an O&M manual carries by default, one of the section roles in configure sections. There is no test sheet editor; the sheets stay in your own template.

Disclosure: I build Submittal Kit. The procedure, the sheets, and the signed report work the same in any tool.