FIELD NOTE / LINKEDIN
AI can draft PLC logic. The plant decides.
The complete written thought and the evidence behind it. The video edition will follow its public release.
The written argument is here.
This approved LinkedIn edition is on the journal now. Its video player and original platform link will appear after each public release is verified.
AI can draft PLC logic. The plant decides.
Day 31 · 2026-10-24 · LinkedIn
Short video caption
AI can speed PLC engineering, including drafting SCL/LAD logic, test logic and documentation; Siemens documents these as vendor capabilities. The acceptance boundary is the physical process. For a changed requirement, define expected actuator response, allowed timing and fault cases, then test them in simulation, appropriate hardware-in-the-loop and qualified commissioning. Keep safety functions under engineered safety controls and signed change authority. Conveyor example is simulated; no live plant was tested. #EricFieldNotes
Full written post / accessible read
AI can be genuinely useful in industrial automation. Siemens now documents an engineering assistant that generates SCL and ladder logic, tests and documentation inside TIA Portal. The crucial question is what evidence turns a good draft into an accepted change on a physical process.
Imagine a conveyor change that compiles and passes a nominal simulation. In the real acceptance case, a sensor stays high after a guard opens. The consequences are physical. Neither readable logic nor a generated test proves the required stop behavior or timing under that fault.
Let AI draft routines, migrate comments, generate candidate tests and map change impact. Then run a versioned cause-and-effect matrix through simulation with sensor and actuator faults, hardware-in-the-loop where appropriate, and qualified commissioning. Keep any safety function under its engineered safety control and change process, not a model's live judgment.
Before deployment, require each changed requirement to name the physical response, allowed time, fault test and accountable engineer. Keep the measured result with the versioned program. Do this because in OT the cost of a wrong assumption leaves the screen and enters the plant.
#EricFieldNotes
Evidence and boundary
On-screen boundary: VENDOR CAPABILITY · SIMULATED PLANT. The sources below support documented mechanisms and specifications; illustrative scenarios are not presented as measured incidents.
- NIST OT security SP 800-82r3 (S16)
- PLCopen IEC 61131-3 (S18)
- Siemens Eigen Engineering Agent (S61)
AI belongs in industrial engineering. Acceptance belongs to the plant.
Industrial automation teams have a genuine use for coding assistants. Siemens documents an engineering agent connected to TIA Portal that can generate or adapt SCL and ladder logic, create test logic, fix syntax errors, apply style rules and prepare documentation. These are vendor-described capabilities; they justify trying AI in engineering workflows, not assuming a generated change is safe for a physical process. Siemens Eigen Engineering Agent.
The value is clearest in repetitive, inspectable work: translating a documented routine, explaining legacy code, generating candidate tests, tracing changed tags, or surfacing where a requirement touches HMI, PLC and historian behavior. A human engineering team can save time when the tool produces a reviewable artifact and the plant's acceptance criteria already exist.
The dangerous shortcut is promoting compiler success or a nominal simulator pass into physical acceptance. PLCopen's IEC 61131-3 overview specifies programming-language syntax and semantics. It does not make a program correct for the timing, instrumentation, actuator response and fault modes of a particular installation. NIST's OT security guide specifically frames these systems around physical interaction and unique performance, reliability and safety requirements. PLCopen IEC 61131-3 · NIST SP 800-82 Rev. 3.
Consider a simulated conveyor change. The generated logic compiles and a nominal cycle completes. Now hold a sensor high after a guard opens. The requirement is about a physical stop state and a bounded response time. Whether that requirement is handled by a separate engineered safety function, normal control logic, or both is a design decision for qualified personnel and the relevant installation. A plausible code trace cannot certify the actual response.
I would put an AI-generated change through a versioned cause-and-effect matrix: each affected requirement, the expected physical state, the timing limit, the fault to inject, the test environment, the measured outcome and the accountable engineer. Use offline simulation for broad cases; use hardware-in-the-loop where it adds representative I/O and timing; use qualified commissioning for site behavior. Keep the safety function under its engineered authority and change process rather than giving a model a live control vote. A mismatch blocks deployment, even if the code is beautiful.
That arrangement is pro-AI: it lets assistants do more of the draft, search and test-generation work while preserving a clear route from requirement to observable plant behavior. In OT, the final oracle is not the text of the answer. It is what the machine does under the relevant normal and fault conditions, at the required time, with a named person accepting the evidence.
Evidence boundary: The Siemens feature list is vendor-reported. The conveyor is a simulated acceptance scenario. No PLC, HIL bench or plant was exercised for this post.