How to Prove AI-Generated Ladder Logic Meets IEC 61508 Part 3 Rigor

To evaluate AI-generated ladder logic against IEC 61508 Part 3, engineers should test deterministic behavior, fault response, and traceability through simulation rather than prompts alone. OLLA Lab provides a bounded validation environment where logic can be exercised against realistic machine behavior, observed under fault conditions, and documented as audit-ready execution evidence.

AI-generated ladder logic does not fail audit because it is "AI." It fails audit because functional safety requires deterministic, traceable, and verifiable behavior, while LLM output is probabilistic until an engineer constrains and proves it.

A recent internal Ampergon Vallis analysis found that 68% of 500 AI-generated motor-control routines failed a bounded predictability screen under simulated sensor-loss conditions until manually constrained by an engineer [Methodology: n=500 generated motor-start and permissive/interlock routines tested in OLLA Lab simulation, baseline comparator = deterministic acceptance criteria derived from predefined sequence and fault-response expectations, time window = January-March 2026]. This metric supports one narrow point: unconstrained AI output often violates predictable fault behavior in simulation. It does not support a claim about all PLC code, all vendors, or formal certification outcomes.

That distinction matters. You cannot audit a prompt. You can only audit the deterministic execution of the resulting logic under simulated physical constraints. Syntax is cheap; deployability is not.

AI-generated logic fails IEC 61508 Part 3 audits because the standard is concerned with systematic integrity of software behavior, not with how quickly code was produced. IEC 61508-3 requires software to be specified, structured, verified, and justified in a way that supports predictable operation in defined conditions and defined failures.

The core conflict is simple. LLMs generate likely next tokens from patterns in training data. Safety software must produce bounded, explainable state transitions under known process conditions. One is probabilistic generation; the other is deterministic accountability.

This is why prompt history is not compliance evidence. A prompt may explain intent, but it does not prove scan-cycle behavior, fault handling, safe-state transition, or timing compliance.

The practical failure modes are familiar to controls engineers:

• permissives that energize correctly but do not de-energize deterministically
• latched bits that survive abnormal restart conditions without explicit reset logic
• alarm handling that detects a bad value but does not force a safe response
• analog comparisons with no out-of-range handling
• step logic that works in the happy path and fractures under asynchronous inputs
• overcomplicated rung structures that obscure verification

IEC 61508 uses different terminology across lifecycle activities, but the engineering demand is consistent: software behavior must be justified, testable, and traceable to safety intent. AI can draft logic. It cannot inherit systematic capability by enthusiasm.

This is where OLLA Lab becomes operationally useful. Its role is not to certify AI code. Its role is to provide a risk-contained environment where engineers can run the generate-validate loop, observe scan behavior, induce faults, compare ladder state to simulated equipment state, and document what the logic actually does.

"Simulation-Ready" means an engineer can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process.

That definition is operational, not aspirational. A Simulation-Ready engineer can:

• define what correct behavior looks like before testing starts
• run logic against a machine or process model rather than against assumptions
• monitor I/O, internal bits, analog values, and sequence state during execution
• inject abnormal conditions such as sensor loss, stale feedback, power cycling, and permissive dropout
• identify where ladder state diverges from expected equipment behavior
• revise logic and re-test until the behavior is bounded and explainable

This is the real distinction between ladder syntax and commissioning judgment. Plenty of people can draw a rung. Fewer can explain why a pump should refuse restart after a failed proof, or why a permissive must veto a run command unconditionally after a fault.

The "16 pillars" below are a practical engineering synthesis derived from IEC 61508-3 software safety lifecycle expectations, especially the standard's emphasis on correctness, verifiability, fault avoidance, and disciplined design. They are not a verbatim named list from the standard. They are a working structure for evaluating whether AI-generated ladder logic is moving toward auditable rigor.

### Group 1: Architecture and determinism

All defined operating modes, startup states, shutdown states, and abnormal states are addressed.

• 1. Completeness

The logic matches the intended control philosophy and safety requirements.

• 2. Correctness

Execution behavior is bounded and repeatable under the same conditions.

• 3. Predictability

The design avoids internal contradictions, unintended latching, deadlock-like sequence stalls, and unstable state interactions.

• 4. Freedom from intrinsic faults

Complexity is minimized so the logic remains reviewable and testable. AI often fails here by producing ornate logic that compiles but is difficult to justify.

• 5. Simplicity

### Group 2: Fault tolerance and response

The logic handles invalid, noisy, missing, or out-of-range inputs without undefined behavior.

• 6. Robustness

The program actively recognizes failed sensors, missing proof signals, bad analog values, or communication loss where relevant.

• 7. Fault detection

Hazardous outputs are removed through deterministic veto logic when safety conditions are violated.

• 8. Safe-state transition

Non-critical functions fail in a controlled way while preserving essential safe behavior.

• 9. Graceful degradation

Variables, retained states, and critical values are protected from unintended corruption or misuse.

• 10. Data integrity

The logic responds within the required process safety time and does not rely on unbounded execution assumptions.

• 11. Timing constraints

### Group 3: Verification and traceability

Each safety-relevant rung, interlock, alarm, or sequence step maps back to a defined requirement or hazard control.

• 12. Traceability

Functions are partitioned so they can be reviewed and tested independently.

• 13. Modularity

The logic can be exercised under defined scenarios and shown to meet expected outcomes.

• 14. Verifiability

Future engineers can understand, troubleshoot, and safely modify the code.

• 15. Maintainability

Protection against unauthorized forcing or unsafe modification is considered where software integrity overlaps with cybersecurity practice, including IEC 62443 concerns.

• 16. Security-aware control integrity

These pillars matter because IEC 61508 is not impressed by code that usually works. Safety software is judged by defined behavior under defined stress.

An audit-ready artifact is not a screenshot, a prompt log, or a vague test note. In this context, it should be defined as a time-stamped simulation report that compares intended control sequence behavior against observed state changes during induced fault conditions.

That definition keeps the evidence tied to execution. It also keeps product claims bounded. OLLA Lab can support the production of this evidence by providing simulation, variable visibility, scenario structure, and realistic machine models. It is not itself a compliance authority.

A useful audit-ready artifact should include:

1. System description What equipment or process is being controlled, including major I/O, sequence intent, and operating modes.
2. Operational definition of correct behavior The expected behavior in normal operation and in abnormal conditions.
3. Ladder logic and simulated equipment state The rung logic under test and the corresponding machine or process response in simulation.
4. The injected fault case The exact abnormal condition introduced, such as wire break, failed proof, analog out-of-range value, or power-cycle recovery.
5. The revision made What changed in the logic after the fault was observed.
6. Lessons learned What the failure revealed about assumptions, sequence design, interlocks, or maintainability.

That six-part structure produces engineering evidence rather than a screenshot gallery. Auditors and senior reviewers need a decision trail. So do the people who inherit the code later.

Documentation should be a byproduct of validation, not a cleanup exercise after the fact. If the test process is structured correctly, the evidence package can be assembled from the workflow itself.

A practical workflow looks like this:

1. Define the intended sequence and safety response State what the equipment should do in run, stop, startup, shutdown, and fault conditions.
2. Build or import the ladder logic This may include AI-generated draft logic, but the draft is only the starting point.
3. Run the logic in simulation mode Execute the program while monitoring inputs, outputs, internal tags, analog values, and sequence bits.
4. Inject faults deliberately Use variable controls to simulate wire breaks, failed limits, stale proofs, permissive loss, analog excursions, or restart conditions.
5. Compare expected versus observed behavior Record whether the simulated equipment enters the correct safe state and whether internal logic matches the control philosophy.
6. Revise the logic and retest Add deterministic vetoes, reset handling, fault latching, or sequence guards where needed.
7. Export the test record Preserve the scenario objective, fault case, observed state changes, and final accepted logic behavior.

In OLLA Lab, this workflow is supported by the ladder editor, simulation mode, variables panel, scenario structure, and digital twin context. The key point is not that the platform does compliance. The key point is that it provides a deterministic observation environment where software behavior can be tested against realistic process conditions.

A compact example of deterministic veto logic is below:

[Language: Ladder Diagram] // Example: deterministic veto overriding generated run logic // If AI_Run_Cmd is true, but Safety_Permissive drops, // Motor_Out must unconditionally unlatch.

|---[ AI_Run_Cmd ]----[ Safety_Permissive ]-----------( Motor_Out )---| | | |---[/Safety_Permissive ]--------------------------------(U Motor_Out)-|

The important feature here is not stylistic elegance. It is that the loss of permissive has an explicit, testable, unconditional consequence.

OLLA Lab validates behavior, not certification status. That is the correct boundary.

Systematic capability in IEC 61508 depends on disciplined development and verification practices that reduce systematic faults. A web-based simulator cannot confer systematic capability by itself, but it can provide the environment required to observe whether the implemented logic behaves in a way consistent with those disciplined practices.

In practical terms, OLLA Lab supports this by allowing engineers to:

• build ladder logic with standard control elements including contacts, coils, timers, counters, comparators, math functions, and PID instructions
• execute logic in simulation without physical hardware
• monitor and manipulate variables, I/O, analog values, and PID-related parameters
• test logic against realistic industrial scenarios rather than abstract toy problems
• compare ladder state with 3D or WebXR equipment behavior where available
• rehearse abnormal conditions that would be unsafe or expensive to induce on live plant

That matters because mathematical unit correctness is not enough for industrial control. A rung can be syntactically valid and still fail the process. Digital twin validation is useful precisely because it exposes the interaction between software state and simulated physical state.

Operationally, digital twin validation here means running ladder logic against a realistic machine or process model and observing whether expected equipment behavior, sequence progression, interlocks, alarms, and safe-state transitions occur under both normal and faulted conditions.

Realistic scenarios expose the control assumptions that generic exercises hide. A motor-start tutorial can teach seal-in logic. It usually does not teach failed proof, restart inhibition, lead-lag arbitration, analog alarm deadband, or what happens when an operator command collides with a trip condition.

That is why scenario context matters. OLLA Lab's documented presets across water, wastewater, HVAC, manufacturing, warehousing, food and beverage, utilities, chemical, and pharma are useful not because they are numerous, but because they force logic into operational context.

Different scenarios teach different safety and commissioning patterns:

• Pumping systems teach lead-lag rotation, low-level protection, failed-start detection, and overflow risk.
• Conveyors and packaging lines teach jam detection, sequence permissives, and coordinated stop behavior.
• HVAC and air-handling systems teach interlocks, fan proof, damper position logic, and alarm handling.
• Process skids teach analog thresholds, PID interaction, trip logic, and controlled shutdown.
• Water and wastewater systems teach level control, duty cycling, alarm prioritization, and process continuity under equipment faults.

This is also where guided build instructions help. Quick starts, I/O maps, control philosophy notes, interlocks, tag dictionaries, and verification steps give the engineer a structured basis for proving behavior. That is more useful than dropping someone into a blank editor and calling it realism.

Fault testing should be designed around observable process risk, not around whatever the AI happened to generate. The right question is not does the code run, but what happens when the process lies, stalls, or disappears?

A disciplined fault test set should include, at minimum:

• loss of permissive during active run
• failed feedback or proof signal
• analog signal high, low, frozen, or out of range
• power cycle or restart with retained bits present
• asynchronous operator command during sequence transition
• communication loss or stale data where applicable
• sensor disagreement where redundant or confirming signals exist

For each case, the engineer should define:

• the expected safe response
• the maximum acceptable response time
• the tags and outputs to observe
• the criteria for pass, fail, and revision

The variables panel in OLLA Lab is useful here because it allows direct manipulation of inputs and state visibility during execution. That supports fault injection, tag observation, and repeatable retest. Again, the value is bounded: it is a controlled validation environment for high-risk commissioning tasks, not a substitute for formal site acceptance, hardware verification, or competence on a live process.

A decision package is the assembled proof that explains why the final logic is acceptable. In this article, agentic orchestration should be understood narrowly as the engineer's act of supervising generated logic, testing it against defined scenarios, rejecting unsafe behavior, and preserving the reasoning behind accepted revisions.

A defensible decision package should contain:

• the control objective
• the safety-relevant requirements or hazard mitigations
• the ladder logic revision history
• the simulation scenario used
• the injected fault cases
• the observed outcomes
• the accepted final behavior
• the unresolved assumptions or limits
• the sign-off basis for moving to the next review stage

OLLA Lab contributes to this package by giving structure to the build-and-verify loop through guided scenarios, variable visibility, simulation execution, and digital twin context. It helps engineers produce evidence that can be reviewed. That is the useful threshold.

AI can accelerate draft generation, but it does not reduce the burden of proof. In safety-related software, velocity without evidence is just a faster route to unverified logic.

The practical rules are straightforward:

• treat generated ladder logic as a draft, never as accepted truth
• define correct behavior before testing
• validate against process behavior, not only rung appearance
• inject faults on purpose
• preserve time-stamped evidence of expected versus observed response
• revise for determinism, readability, and traceability
• keep the human engineer responsible for acceptance

That is the real generate-validate loop. It is less glamorous than claims that AI writes PLC code, and more useful in safety work.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 overview (functional safety) - NIST AI Risk Management Framework (AI RMF 1.0) - Digital Twin in Manufacturing: A Categorical Literature Review and Classification (IFAC, DOI) - Digital Twin in Industry: State-of-the-Art (IEEE, DOI)