Soft­ware-Defined Automa­tion (SDA)

What does soft­ware-defined automa­tion mean?

Soft­ware defined automa­tion means that the func­tions of control systems are defined by code rather than by the device they run on. A virtual PLC executes the control logic, for example programmed according to IEC 61131–3, on stan­dard compute infra­struc­ture. Appli­ca­tions are pack­aged, deployed and updated through pipelines, and an orches­tra­tion layer decides where they run. Virtu­al­iza­tion and open-source tools decouple the control program from the device, which makes the automa­tion system modular and scal­able. The idea follows the path that networking and data centers took before: from dedi­cated appli­ances to virtual func­tions. AI adds a further step, because agents can auto­mate engi­neering tasks once the stack is program­mable.

How does SDA differ from tradi­tional automa­tion?

• Compute: stan­dard indus­trial PCs instead of a dedi­cated controller per task
• Deploy­ment: containers and remote deploy­ment instead of manual down­loads on site
• Life­cycle: updates and roll­backs through CI/CD instead of rare, risky changes
• Scaling: add or move work­loads without replacing hard­ware
• Vendor inde­pen­dence: appli­ca­tions from different vendors on a shared, open plat­form instead of propri­etary, hard­ware-based automa­tion

Bene­fits of soft­ware-defined automa­tion

SDA brings proven devel­op­ment methods such as DevOps, version control and auto­mated testing to the shop floor. For automa­tion engi­neers, this means faster changes and less down­time. It reduces depen­dency on specific devices and the vendor lock-in that comes with it, shortens the time from change request to running code and makes redun­dancy and failover easier. Central manage­ment also simpli­fies secu­rity updates, which matters for the Cyber Resilience Act. The conver­gence of IT and OT is not free of chal­lenges, though: real-time require­ments, safety and the skills gap between IT and OT teams need careful atten­tion.

SDA in prac­tice: three OI4 projects

Phase 1: in the first SDA project, OI4 members built a Kuber­netes-based demon­strator that runs container­ized work­loads on edge nodes managed from a central cloud control plane. They enabled remote manage­ment via APIs without direct network access, demon­strated failover between redun­dant devices, inte­grated OPC UA-based remote I/O instead of tradi­tional field­buses and migrated work­loads from staging to produc­tion to vali­date consis­tency.

Phase 2: the second phase scales this to a multi-vendor ecosystem. Open­De­vS­tack serves as the CI/CD back­bone, and Margo, an open inter­op­er­ability stan­dard for indus­trial edge deploy­ment, serves as the compli­ance layer. The deliv­er­ables include deploy­ment of multi-vendor appli­ca­tions to Margo-compliant edge devices at the Boehringer Ingel­heim chem­ical pilot plant and a refer­ence archi­tec­ture presented at SPS 2025.

Agentic engi­neering: in the Soft­ware-Defined Brewery, an engi­neer described a temper­a­ture moni­toring task in plain language. A team of AI agents turned it into a BPMN work­flow, gener­ated instru­ment spec­i­fi­ca­tions, config­ured the control logic in zenon and deployed a container­ized PLC to a Margo-compliant edge gateway, with compo­nents from six orga­ni­za­tions working together through open inter­faces.

How can compa­nies get started with soft­ware-defined automa­tion?

1. Start with non-crit­ical appli­ca­tions such as moni­toring, data processing or AI-based analytics before moving core control.
2. Build a container-capable edge infra­struc­ture, see indus­trial edge computing.
3. Rely on open stan­dards for commu­ni­ca­tion and deploy­ment, such as OPC UA and Margo.
4. Bring IT and OT teams together early, because the new automa­tion model changes respon­si­bil­i­ties on both sides and adop­tion depends on both.

Frequently asked ques­tions