To validate AI-generated ladder logic before a factory acceptance test, put it through the same gates as any other code, plus two automatic ones at the front: it must compile, pass static analysis, survive a line-by-line review against the functional spec, run correctly on a scan-accurate simulator with forced inputs and faults, and then behave against a model of the machine. Only then is it ready for FAT. AI-generated PLC code is not unsafe by nature, but it is unproven, and the gates are how it gets proven.
Why AI ladder logic needs its own gates
General AI assistants write ladder logic that looks right. That is the problem. A classic example: asked for a motor seal-in, a model writes a latch branch that holds only the motor contact, so the motor latches on and the stop button no longer breaks the rung. It reads plausibly and it is a defect. LADX uses this exact case to explain why it puts a compiler in the loop rather than trusting the model (LADX Chat).
Research points the same way. The LLM4PLC study raised its PLC code generation success rate from 47% to 72% by adding syntax checking, formal verification and feedback loops around the model (Fakih et al., arXiv 2024). The Agents4PLC work, published in October 2024, went further with a closed loop of LLM agents that generate and verify PLC code against formal specifications (Liu et al., arXiv 2024). The lesson for a controls team is practical: the model is the least important part. The checking around it is what makes the output usable.
The six gates
Gate 1: it compiles
Before a human reads a rung, a real compiler should accept it. LADX compiles generated logic with matiec, the open-source IEC 61131-3 compiler (matiec on GitHub), and sends failures back to the model with the compiler's own errors, so you only see attempts that built. In Studio 5000 or TIA Portal the equivalent is a clean verify or compile with zero warnings you have not explained.
Gate 2: static analysis
Compiling proves the code is valid, not that it is sensible. Static analysis catches the next layer: unused variables, outputs written in two places, unreachable branches. LADX runs iec-checker, an open static analyzer for IEC 61131-3 programs (iec-checker on GitHub), plus a PLCopen schema pass on the structure. On vendor platforms, use the cross-reference and duplicate-destructive-bit checks your IDE already has.
Gate 3: engineer review against the spec
This is the gate no tool replaces. Read every rung as you would a junior colleague's code, with the functional design specification open beside it. LADX says it plainly: whether an interlock is sufficient for the hazard is an engineering judgment, and it stays with the engineer. Check that the generated rungs use your existing tags rather than inventing new ones, and that names, comments and structure follow your plant standard.
Gate 4: bench test on a scan-accurate simulator
Run the logic, force inputs and record what happens. The simulator must behave like a PLC: an output image updated once per scan, edge memory per instruction, timers on elapsed milliseconds. A simulator that solves rungs like equations will pass logic that fails on a real controller. Test the unhappy paths as hard as the happy ones: stop pressed during start, a sensor that drops out for 50 ms, power returning with a latched output.
Gate 5: virtual commissioning against the machine model
A bench test proves the logic does what the logic says. It cannot know the conveyor takes 1.8 seconds to stop. For sequences, motion and anything with real timing, run the program in emulation against a model of the machine. This is where virtual commissioning earns its cost, and our virtual factory acceptance test guide shows how the same model supports remote acceptance.
Gate 6: FAT with records
The factory acceptance test is still the formal gate. IEC 62381:2024 sets out requirements and checklists for FAT, factory integration test, SAT and site integration test on process automation systems (IEC webstore). Attach the saved simulator runs and the review record to the FAT pack. A passing simulation is evidence for a FAT, not a substitute for one.
Factory Acceptance Test Explained - Part 2 | PLC Digital I/O Test
RealPars
This video is hosted on YouTube. Playing it loads content from Google, which may set cookies.
Watch on YouTubeDefects we see most often in generated rungs
| Defect | Why it slips through | Gate that catches it |
|---|---|---|
| Seal-in branch without the stop condition | Looks like a valid latch | Review and bench test |
| Same coil written in two routines | Each rung is fine on its own | Static analysis |
| Timer never reset after a fault | Works on the first cycle | Bench test with faults |
| Invented instruction or library block | Model has seen another platform | Compile |
| Wrong assumption about machine timing | No model knows your actuator | Virtual commissioning |
Write the policy down
A short team policy prevents most arguments later. NIST's AI Risk Management Framework, organized around its Govern, Map, Measure and Manage functions, is a sensible structure to borrow (NIST AI RMF). One page is enough: which tools are approved, what code and data may be sent to which provider, which gates are mandatory, and how AI assistance is recorded in the change log. Safety functions stay out of scope for generated code.
Next step
LADX builds the first two gates into generation and gives you a scan-accurate simulator for the fourth. Read more on our industrial AI service, or see our overview of AI for PLC programming for the wider picture of vendor copilots. If you want a second pair of eyes on AI-assisted code before a FAT, contact us and tell us the platform and the size of the program.
