Software-defined Automation – is the squeeze worth the juice?

What Actually is Software-Defined Automation?

The term "software-defined automation" is gaining momentum. It is showing up in analyst reports, on keynote stages, and in vendor roadmaps. That is a good sign — it means the industry is recognizing that the way we manage industrial control systems needs to fundamentally change.

But I have noticed that the term is increasingly being defined from the top down — from the vendor roadmap, from the architecture diagram, from the vision slide. In my experience that gets the sequence wrong. Software-defined automation must be defined from the factory floor up, starting with the problems that production teams actually face every day.

Start from the factory, not from the slide deck

Here is what the factory floor looks like in reality: A global manufacturer operates dozens or hundreds of sites. Each factory runs controllers from multiple vendors — Siemens, Rockwell, Beckhoff, Schneider, Mitsubishi, often on the same line. Firmware generations span two decades. IDE versions vary by site, sometimes by machine. No one has a complete inventory of what software is running where.

Every interaction with a controller requires the vendor's proprietary Windows application, physical access or a VPN, and the hope that someone documented what changed last time. The most critical software in manufacturing — the code that governs what a factory actually does — is frequently managed with less discipline than a junior developer's side project.

This is the problem that software-defined automation must solve. Not in theory. Not in a showcase. In the many factories you already operate, with the controllers you already have, and the engineers you already employ.

Four pillars — and all four matter

A true software-defined automation platform rests on four pillars. Covering one and calling it "software-defined" is like calling a bicycle a car because it has wheels.

IT-style development practices. Version control, branching, merging, code review, collaboration workflows — the disciplines that have transformed software engineering over the past two decades, finally applied to PLC programs. Automation engineers have deserved these tools for years. The fact that some are still debating this in 2026 tells you more about the industry's inertia than about the difficulty of the problem.

A data and management layer. Orchestration of controllers at scale: network topology mapping, credential management, firmware tracking, cyber-security controls. Not a monitoring dashboard, but operational control across the entireinstalled base — from a browser, without site visits. When the CISO asks "can you change every controller password across every factory by Friday," the answer should be yes, not "let me schedule travel."

Vendor independence. This is the pillar that is most often missing from the conversation, and it is arguably the most important. No global manufacturer runs a single-vendor monoculture. Not one. Software-defined automation must work across vendors — Siemens, Rockwell, Beckhoff, Schneider, Mitsubishi — without requiring changes to the controllers themselves. No rip-and-replace. No forced migration. No new hardware or software dependency. The platform meets the factory where it is, including controllers that have been in production for 20 years.

Any definition of "software-defined" that quietly assumes a single-vendor stack — or that only applies to new technology purchased against a new standard — is not describing the real world. It is describing a sales motion.

AI with context. Code documentation, code generation, anomaly detection, autonomous task execution — but built on the complete data layer across all controllers, not limited to one project open on one engineer's workstation. An AI assistant that can see only the PLC in front of you is useful. One that can see every controller in every factory, every program version, every parameter change over the full history of operation — that is transformative. The difference is not a feature. It is an architecture.

A real word about virtual PLCs

Virtual PLCs add flexibility and there are real use cases for them. But they are not software-defined automation, and presenting them as the starting point gets the sequence exactly wrong.

The factories that need software-defined automation today already have thousands of hardware controllers in production. That hardware works. It is paid for. It runs the line. No production manager is losing sleep over the cost of a PLC. What keeps them up at night is the inability to manage, secure, and evolve the software running on those controllers — across vendors, across sites, at scale.

The real "decoupling" that matters is not decoupling control logic from hardware. It is decoupling the management of your automation from any single vendor's proprietary toolchain. That is a fundamentally different proposition — and it is not solved by adopting an open standard that only applies to new technology while your existing installed base remains unmanaged.

Virtual controllers become a natural extension once you have a vendor-independent management layer in place. Without that foundation, they are a different kind of lock-in — running on someone else's runtime, inside someone else's ecosystem, solving a problem that ranks behind a dozen more urgent ones.

Where the value actually shows up

Software-defined automation is most valuable for example in the production factory, where complexity and cost live.

When a F&B producer runs multiple bottling lines and the same error recurs across all of them because there is no cross-line context and no record of what parameters changed over years of operation — that is not a coding problem. It is a data management problem at industrial scale.

When an automation engineer flies to a remote site, spends two days on a task that could have been handled through a browser, and flies home — that is not a technology gap. It is an architecture gap.

When a cyber-security audit reveals that no one knows the current credential state of 40% of the controllers in the organization — that is not a security failure. It is the predictable outcome of managing 21st-century production infrastructure with 20th-century tools.

These are not theoretical scenarios. These are the conversations my team and I have continuously with some of the most elite manufacturers in the world. The technology to solve them exists today. What has been missing is a platform that works with the controllers you already have, across the vendors you already use, without asking you to rebuild your factory around a new architecture.

The test

If you are evaluating what "software-defined" means for your operations, I would suggest a simple test: Does the platform cover all four pillars, or just a subset? Does it work across the controllers you already have — all vendors, all generations — or does it require you to standardize on a single ecosystem first? Does it start from today's reality on the factory floor, or does it ask you to rebuild around a vision that may arrive in five years?

The first approach starts with your factory. The second starts with a PowerPoint. Software-defined automation is not a product feature. It is not a rebranding of an existing portfolio. It is an architectural principle — and the factories that adopt it will operate, evolve, and compete differently from those that do not.