Factory acceptance test checklist for a PLC control panel

A factory acceptance test proves that the panel does what the functional design specification says, while it is still on the bench, the programmer is in the building and a spare part is a drawer away. The checklist below is written to be copied into a protocol and carried out, section by section, on the witness day and on the internal dry run before it.

The order follows one rule: each stage relies only on what earlier stages have proved. Documents before power, power before I/O, I/O before logic. The difference between FAT and SAT, and where commissioning starts, is covered in the commissioning checklist; this article stays on the FAT itself.

For process automation, IEC 62381:2024, edition 3, is the reference. It covers the FAT, the site acceptance test and the site integration test, adds an optional factory integration test, and replaces the old annex forms with activity checklists for writing project-specific plans.

Before the FAT: entry criteria

The FAT does not start until every line here is true. A FAT started early produces a punch list that is really a build list.

1. Documentation

2. Visual and mechanical inspection

Check V4 against the colour scheme on the drawings, not memory; the wire colour codes article sets out what NFPA 79 and IEC 60204-1 expect.

3. Power-up and electrical tests

Dead tests first, then power in stages. For machine electrical equipment, clause 18 of IEC 60204-1 defines the verification. In the 2016 edition with its 2021 amendment, 18.2 covers protection by automatic disconnection of supply (Test 1, continuity of the protective bonding circuit, and Test 2, fault loop impedance), 18.3 insulation resistance, 18.4 voltage tests, 18.5 protection against residual voltages, 18.6 functional tests and 18.7 retesting after modification.

For reference, the 2005 edition of IEC 60204-1 (as published in JIS B 9960-1:2008) specified a continuity test current between 0.2 A and about 10 A from a source of no more than 24 V, and at least 1 MΩ insulation resistance at 500 V DC between power circuits and the protective bonding circuit. Take the values from the edition your contract names, and record them.

4. I/O check, point by point

Every point on the I/O list, individually. It is the slowest section and the one that saves the most later, because a crossed pair found here costs five minutes. The method, as RealPars describes it, is to simulate at the terminals: a jumper or switch for passive inputs, a signal simulator for active devices, and a calibrator in current mode for 4-20 mA.

Work the expected analog values out before the day, from the I/O list's range, so nobody does arithmetic in front of the witness. The calculation is the 4-20 mA scaling line:

FUNCTION ExpectedEU : REAL
VAR_INPUT
    mA    : REAL;  (* injected by the calibrator *)
    EU_Lo : REAL;  (* engineering value at 4 mA, from the I/O list *)
    EU_Hi : REAL;  (* engineering value at 20 mA *)
END_VAR
ExpectedEU := EU_Lo + (mA - 4.0) * (EU_Hi - EU_Lo) / 16.0;
END_FUNCTION

For FT-101, ranged 0 to 50 m3/h, 12 mA gives 0 + 8 × 50 / 16 = 25.0 m3/h. Record the observed value, not just a tick; a reading of 24.6 against 25.0 is a calibration question, and a tick hides it.

5. Functional tests from the FDS

Every test quotes the FDS clause it proves, so a passed FAT means the FDS is met, and a gap between them is found here.

6. Interlocks, from the cause and effect matrix

The cause and effect matrix is the most testable document on the project: each mark is one FAT test. Test the marks and confirm the blanks, because an effect that happens when it should not is as much a failure as one that does not happen.

Three rows of a matrix:

become these steps:

IL-02 is the one that catches mistakes: a guard switch wired into the same chain as the E-stop passes every mark in its row and fails the blanks.

7. Safety functions

S5 catches the commonest reset fault: a reset that acts on a level rather than an edge re-enables the machine the moment the guard closes if the button has stuck. Whether the logic sits in a relay or a safety PLC, the test is the same. Validation of the safety functions on the machine itself follows on site.

8. Alarms

Trigger alarms from the cause, not by forcing the alarm bit; forcing proves the screen, not the logic. Alarm design covers what a good alarm list looks like before you test it.

9. HMI

10. Communications and failure modes

These are the tests most checklists leave out, and the faults most likely to happen in the first year.

11. Punch list and sign-off

Every fault goes on the punch list with an owner and a date. The LADX template grades them in two: Category A stops the system doing a specified function or is a safety issue, and must be closed before despatch; Category B is cosmetic, documentation, or does not prevent use, and may be closed on site by agreement. Nothing ships with an open Category A.

At sign-off, record the program version and checksum that was tested, beside the signatures of the test engineer, quality, the client's witness and the project manager. Any change after that goes through version control and a retest of what it touched.

Dry-run the logic before the witness day

Most FAT time is lost to logic faults found while the witness watches. Run the sequences and interlocks through the LADX ladder editor first: it simulates the scan with an output image, edge memory per instruction and millisecond timers, so permissive and timeout behaviour show up at a desk. Bind the alarm list to those tags in the HMI builder to see the ISA-18.2 alarm states before the HMI is built. It is a simulator: it finds logic faults, not wiring faults.

The template and a signed record

The free FAT protocol template contains every section above, in 14 parts from scope to acceptance, written against IEC 62381, with the I/O, interlock, safety and failure tables ready to fill. It downloads as Markdown without an account, alongside the SAT protocol that follows it on site.

To carry the test out as a record rather than a printout, LADX Studio, a free account, can start a FAT run against a project. Each step gets a pass, a fail or a note, on a phone if that is where you are, and the run is signed off with a name and role. Signing closes the run and goes into the audit log; reopening removes the signature and is logged too. The signed run is then written up as a project document that can be shared and exported.

What goes wrong at a FAT

• Starting before the entry criteria are met. The witness watches you finish the build.
• A partial I/O check. Twenty points checked out of two hundred is not an I/O check.
• Marks tested, blanks not. The interlock that does too much passes.
• Untracked program changes. A fix made at 3 pm and not recorded means the signed version is not the one that ships.
• Simulation mistaken for proof. A FAT proves the panel and the logic. Field devices, cable runs and real process timing belong to the SAT.
• Signatures without witnessing. A witness who signs pages they did not see has accepted nothing.