Software Defined Automation: The Execution Surface Industrial AI Has Been Waiting For

Industrial AI has a constraint that nobody talks about enough: in most plants today, agents can watch but they cannot touch.

An agent connected to your historian, your CMMS, and your DCS alarm log can read every data point in the facility. It can reason about what is happening, correlate root causes, generate a recommendation. And then it has to stop - because acting on that recommendation in a traditional PLC environment requires a human to translate it into physical change.

That is not a limitation of the AI. It is a limitation of the control architecture.

Software Defined Automation (SDA) removes that limitation. It is the development that turns industrial agents from advisory systems into operational ones.

The PLC Wall

To understand why SDA matters, it helps to be precise about the constraint.

In a traditional automation architecture, control logic lives in PLC firmware or DCS configuration files. Changing that logic requires physical access to the controller, specialist knowledge of the programming environment (ladder logic, function block diagrams, structured text), and in safety-critical environments, a formal management of change (MOC) process that can take days or weeks.

An agent operating above this layer can do three things: read process data, generate recommendations, and pass those recommendations to a human operator who then decides whether to act. At most, an agent with SCADA access can adjust setpoints within predefined ranges - but it cannot change the underlying control logic, modify alarm thresholds programmatically, or reconfigure a control loop.

This is what the DTC Industrial AI Agent Manifesto calls the separation of control boundary. Agents above the line advise. The humans at the line decide. The PLCs below the line execute.

For many operations this is exactly right - and the Human Agency Scale framework acknowledges this. HAS-01 through HAS-02 operations are advisory by design. The constraint only becomes limiting when you want to move to HAS-03 and beyond: agents that can initiate governed actions, not just generate recommendations.

What Software Defined Automation Changes

SDA - built on IEC 61499 function blocks, OPC-UA as the universal protocol layer, and containerised control logic on standard edge compute - shifts the nature of the control boundary.

In a traditional PLC environment, control logic is firmware. In an SDA environment, control logic is software. The function blocks are configurable through software interfaces. Setpoints are parameters, not hardcoded values. The control logic itself can be modified, reconfigured, and redeployed through the same supervisory control paths that human operators already use.

This is the execution surface that governed industrial AI needs.

An agent with appropriate permissions and a validated governance layer can now do what only a human engineer could do before: propose a change to control logic, have that change validated against formal safety constraints, and execute it through a standard supervisory path - with a complete audit trail from proposal to validation to execution.

Three Action Modes

It is worth being precise about what SDA unlocks, because not everything changes.

Mode 1 - Coordination and information (always available). Raising work orders, sending briefings, correlating alarms, escalating to operators. These actions are above the control layer and available in any environment. This is where advisory agents operate, and where most initial deployments begin.

Mode 2 - Supervisory setpoint adjustment (SCADA-mediated). Adjusting setpoints within declared ranges, modifying alarm thresholds, triggering supervisory control actions. Available in most modern DCS and SCADA environments through standard operator interfaces. Requires permission boundaries and audit trails, but does not require SDA.

Mode 3 - Control logic reconfiguration (SDA only). Modifying IEC 61499 function block behaviour, redeploying updated control logic, adjusting loop configuration. This is the mode that SDA uniquely enables - and it is where the full potential of governed autonomous operations becomes accessible.

Mode 3 does not mean uncontrolled access to the control layer. The governance architecture remains fully in force. Every proposed change passes through the same Propose → Validate → Execute pipeline. The symbolic constraint layer validates that the proposed change is within operating limits, does not violate safety interlocks, and has been authorised for this asset class and this agent role. The existing SIS architecture - hardware safety systems, hardware interlocks, PLC safety logic - is untouched. SDA adds an intelligence surface above that layer; it does not replace the safety architecture below it.

The Transition Problem, Solved

One of the hardest problems in industrial automation is the transition period: startup, grade change, upset recovery. These are the moments when APC gets switched to manual and the experienced operator takes over.

The experienced operator draws on decades of heuristics. They understand how the column behaves in winter. They know the valve that sticks. They know the upstream unit is running lean and will affect feed composition in about 20 minutes. That knowledge is not in any system. It is in their head.

In a traditional control architecture, the best an AI system can do during a transition is advise the operator. The operator still has to translate the advice into action.

In an SDA environment, a governed agent can do something fundamentally different: reconfigure control logic dynamically to match the transition conditions. Update the objective function for this phase of operation. Adjust constraint boundaries that reflect the current operating mode. Not by bypassing the control layer - by proposing changes through it, validated against safety constraints, executed through the same paths the operator would use.

This is the difference between an AI system that tells experienced operators what they already know, and an AI system that operationalises what experienced operators know - and preserves it as institutional memory when those operators retire.

What This Means for Deployment Strategy

SDA is not yet universal. The majority of industrial facilities today run traditional PLC and DCS architectures, and they will for the foreseeable future. Migration to SDA is a multi-year programme, not a switch.

This does not mean industrial AI must wait for SDA.

The right deployment strategy is to start where you are. Mode 1 operations - advisory agents, alarm correlation, shift briefings, automated work orders - are available in any environment and deliver real operational value from the first deployment. Mode 2 operations are available in most modern SCADA environments.

As SDA adoption progresses - and the industry direction toward IEC 61499, OPC-UA, and containerised edge compute is clear - the same MAGS agent architecture that started in advisory mode can progressively unlock Mode 3 capabilities without replacing the underlying intelligence layer. The governance architecture, the agent skills, the operational identity model - all of it carries forward.

SDA is not a prerequisite for starting. It is the horizon that makes the full vision achievable.

The Deeper Significance

SDA represents more than a technical upgrade to the control layer. It represents the closing of a gap that has been open since the first industrial AI systems were deployed: the gap between what an agent can reason and what an agent can do.

For decades, industrial AI has been advisory. Not because the reasoning was insufficient, but because the execution surface was locked. The control logic was firmware. The change process was manual. The action boundary was the human operator.

SDA makes the execution surface accessible to governed software. Combined with the three-layer knowledge architecture that understands physical processes, operational constraints, and organisational context - and governed by the ten laws of the DTC Industrial AI Agent Manifesto - this is the complete picture of what trustworthy industrial autonomy looks like.

The reasoning layer and the execution surface finally meet.

Learn how IndustrialClaw’s three action modes map to your current architecture at Why IndustrialClaw, or contact us to discuss your deployment path.