Selecting PLC and SCADA AI Control Boundaries Safely

The engineer sees management proposing an autoregressive language model in a PLC or SCADA control path because demonstrations look accurate. Stop the design review at the authority boundary: a probabilistic model may draft, classify, or recommend, but it must not gain direct authority over sensing, interlock evaluation, safety functions, or actuator commands unless the complete implementation has been engineered and validated for that duty.

1. Control-authority classification

1. List every proposed AI output and the destination that consumes it.
2. Mark whether the output is advisory, an engineering artifact awaiting approval, a constrained runtime proposal, or a direct control command.
3. Trace each output to its final effect: display text, configuration file, PLC logic, SCADA write, motion request, motor command, or valve command.
4. Do not move on until every path has an identified reviewer or deterministic enforcement point.

Autoregressive models select outputs from learned probability distributions. A plausible response is not proof that a requested state is permitted. Even a measured 99% success rate means one unsuccessful result per 100 evaluated cases under the tested distribution; it says nothing about untested states, common-cause failures, or the consequence of the unsuccessful case. Do not translate model accuracy into a safety claim.

2. Consequence and timing check

1. For each runtime output, record the worst credible result of a wrong, late, repeated, missing, or malformed response.
2. Read the required response time from the machine risk assessment, control narrative, drive or device behavior, and existing protection design.
3. Measure end-to-end latency through the proposed model, communications path, validation layer, controller scan, and output update.
4. If an error can expose personnel, start motion unexpectedly, defeat an interlock, or damage a physical asset, route the function through deterministic control logic and independent protection.
5. If response must occur at millisecond scale, reject any path whose worst-case latency and failure behavior have not been bounded and tested.

3. Requirement-completeness gate

Before anything else, confirm that the process requirements agree with each other. Automation work is not dominated by typing instructions; much of the engineering effort converts vague, conflicting, or physically impossible requests into testable behavior. Ten documents describing the same function with slightly different limits cannot be made correct by feeding all ten to a model.

1. Build a state-and-transition list from the approved control narrative.
2. For each transition, record permissives, interlocks, operator authority, automatic authority, abort behavior, restart behavior, and the response to lost inputs or communications.
3. Resolve conflicting descriptions with the process and safety owners. An instruction such as “stop everything on sight” must become defined detection inputs, affected equipment, stop behavior, reset conditions, and exceptions.
4. Reject requirements that conflict with physical behavior or applicable legal obligations. Do not encode a contradiction and call the resulting implementation validated.
5. Convert every accepted rule into a test with a known initial state, stimulus, expected state, prohibited state, and acceptance result.

A constraint engine cannot repair an omitted rule. It can evaluate only the formal constraints presented to it. If the rule set says Valve A cannot open if Pump B is running, the engine can reject that prohibited combination. It cannot infer missing hazards, decide that the process requirement is flawed, or determine whether the rule covers startup, coast-down, feedback failure, and maintenance modes unless those cases are represented.

4. Determinism and plant-response separation

1. Apply the same complete input state to the proposed decision component repeatedly.
2. Confirm whether the component returns the same result, within a bounded execution time, for every repetition.
3. Change one input at a time and verify that each boundary produces the documented state transition.
4. Remove an input, delay a response, corrupt a value, and interrupt communications. Record the resulting command and recovery behavior.

Separate deterministic computation from predictable plant behavior. PLC logic can evaluate the same inputs to the same outputs while the physical process still varies because of load, friction, backlash, sensor noise, mechanical adjustment, and disturbances. A PID calculation can be deterministic in software even though the controlled process response is uncertain and requires commissioning adjustment. Determinism does not eliminate process dynamics; it makes the decision path repeatable and diagnosable.

Constraint-based evaluation also has a narrower meaning than a general safety guarantee. It can prove that a proposed state satisfies the encoded rule set. It does not prove that the rule set is complete, the inputs are truthful, the output hardware follows the command, or the physical system remains safe after the transition.

5. Architecture branch selection

The useful boundary is not “AI versus no AI.” It is authority versus verification. An assistant can save engineering time when it creates a tag-extraction utility, transforms an XML export, drafts a display, or proposes code. Its output becomes an ordinary project artifact: review it, compile it, simulate it, version it, and test it. The same assistant becomes a different risk when its response is interpreted as an executable plant decision.

6. Deterministic constraint gate

Where a runtime proposal has a legitimate use, place a deterministic gate between the model and the control system. The gate must evaluate current validated inputs and reject any proposal outside the permitted state space.

1. Define the finite set of commands the interface accepts. Reject free-form text at the control boundary.
2. Validate message type, source, freshness, sequence, range, and target before evaluating process rules.
3. Evaluate hard permissives and prohibited state combinations in deterministic logic. For the stated example, enforce NOT (Valve A open AND Pump B running).
4. On invalid, missing, late, or ambiguous data, reject the proposal and retain or enter the engineered fallback state.
5. Require the controller to own sequencing, feedback confirmation, timers, retries, alarms, and recovery.
6. Log the proposed command, relevant state, gate result, rejection reason, final command, and feedback without making the log path necessary for control execution.

The gate is not a language translator. It is an executable contract with a bounded input vocabulary and explicit rejection behavior. A model may select among permitted proposals, but it does not override the contract. If the permitted state space cannot be enumerated or tested adequately, keep the model advisory.

7. Controlled deployment and verification

1. Freeze the approved requirements, constraint set, interface schema, and test cases under change control.
2. Run generated code and graphics through the same compiler, import checks, peer review, simulation, and version comparison used for manually created artifacts.
3. Test every allowed transition and every prohibited transition. Confirm both the controller command and physical feedback.
4. Inject missing data, stale data, invalid values, network loss, model timeout, repeated messages, and component restart. Confirm that none bypasses the deterministic gate.
5. Verify manual, automatic, startup, shutdown, maintenance, fault, and recovery modes separately.
6. Commission with model authority disabled first. Compare recommendations against approved expected results before enabling any bounded proposal path.
7. After enabling that path, repeat the fault tests and confirm that independent protection and controller interlocks remain effective without the model.

FAQ