Make the AI Agent Write the PLC Test Matrix Before It Writes Control Code

Your first PLC AI proof of concept should not be code generation. Give the agent one exported routine, one approved cause-and-effect sheet, and an offline emulator. Then measure whether its reviewed test matrix exposes missing cases before FAT.

Most PLC AI pilots start with the most expensive question: can the model write ladder logic or structured text? That creates a review problem before the team has proved that the agent understands the machine's expected behavior.

The agent reads one frozen controller export, maps interlock dependencies, and drafts the cases. A controls engineer approves every expected result. A deterministic runner executes only those approved rows in an offline emulator or isolated test bench.

Choose one pump skid, conveyor section, or equipment module with roughly 15 to 30 ordinary-control interlocks. Exclude E-stops, guards, burner management, safety PLC logic, SIS functions, and anything covered by the site's functional-safety lifecycle.

Do not give the agent a production endpoint, credentials, download permission, online-edit access, or force capability. If two documents disagree, the agent records the conflict instead of guessing.

Each proposed case needs a deterministic starting state, a traceable requirement, an input transition, an expected result, a timing window, reset behavior, and evidence to retain.

The tag names in the example are placeholders. The expected result and time window must come from an approved requirement.

Do not let the controller code become the only source of expected behavior. If the agent reads the code, predicts what it will do, and calls matching behavior a pass, the test may only prove that the program agrees with itself.

A controls engineer must approve every expected result against a cause-and-effect sheet, control narrative, equipment specification, or another independent requirement. Ambiguous rows go into a question queue. They do not run.

A 2024 study of LLM-generated PLC test cases found that generated tests could reach strong statement coverage on a small set of open-source function blocks, while assertions often required manual correction. Coverage shows which logic executed. It does not make an invented answer correct.

After engineering review, execute only the approved cases against the exact named controller artifact.

The pilot can demonstrate logical behavior for modeled inputs. It cannot prove physical I/O, field wiring, calibration, networks, mechanics, real process dynamics, operator response, or safety performance.

Record logical pass in the named emulator or test bench separately from physical pass on the actual installation. Never let the first imply the second.

Continue only if the workflow produces complete traceability, repeatable execution against the same artifact hash, no unapproved oracle, and zero production connections, downloads, online edits, or forces.

This small internal harness will not replace a full virtual-commissioning platform. It can show whether your requirements and test architecture are ready to benefit from one.

Practical AI Foundations is a forthcoming beginner course for manufacturing, IT, and OT teams. It focuses on useful prompting, verification, read-only first passes, human approval, and implementation boundaries. Join the verified launch list on the courses page.

Ignition AI Skills provides reusable, version-aware workflows for Ignition 8.1 and 8.3 work. It is designed to reduce common errors, wrong assumptions, invented functions, Python-version drift, and repeated example-pasting. It does not promise zero hallucinations or production safety.

Keep human review, diffs, read-only discovery, dry runs, Gateway validation, readbacks, logs, backups, and rollback explicit.