The next manufacturing revolution may not begin with a new robot. It may begin with a change in where the factory’s intelligence lives. For decades, production capability was tightly coupled to dedicated controllers, machines and vendor-specific hardware. That architecture produced reliability — but it also made change expensive. A new product variant, a new process or a new control function could mean new hardware, new engineering, commissioning and downtime. Software-defined automation is beginning to separate some of those functions from the physical equipment. The factory does not become software. Its ability to change increasingly does.

This is not the same thing as putting a factory in the cloud. Nor is a dashboard, an IoT gateway or a digital twin by itself a software-defined factory. The meaningful transition is architectural: standardised compute and connectivity, virtualised control runtimes, centrally managed applications, software-style engineering workflows and digital representations that can be used to test and validate changes before they reach production.

From Hardware-Defined Production to a Software Control Plane

Traditional industrial automation deliberately binds control to equipment. A PLC, HMI, safety controller, drive system and machine are engineered as a tightly coupled system. That coupling is useful: deterministic behaviour, known interfaces and functional-safety engineering are not optional in an environment that moves heavy equipment around people.

But it also creates a structural cost. When the control layer is inseparable from the hardware layer, the factory’s upgrade path is constrained by the hardware lifecycle. A capability that is technically “just software” can become a physical engineering project because the software has nowhere standardised to run.

Software-defined automation attacks that coupling. Siemens describes three building blocks: a software infrastructure layer, virtualised runtimes for control/data applications, and IT-like engineering practices that increasingly resemble software development workflows.

That last point is critical. A software-defined factory is not a virtual factory. It is a cyber-physical architecture in which more of the control surface can be changed without physically replacing the thing being controlled.

The Moment the Controller Became Software

The clearest way to see the transition is the programmable logic controller itself. A conventional PLC is a physical industrial computer with tightly defined hardware and software. A virtual PLC moves that controller into a software runtime hosted on general-purpose infrastructure.

This is no longer theoretical. Siemens reports that Audi is using its SIMATIC S7-1500V virtual PLC in production at the Böllinger Höfe plant in Neckarsulm, with the controller deployed through Audi’s Edge Cloud 4 Production architecture. Siemens says the approach allows central management and software-based deployment of production functions; it also reports a failsafe virtual PLC certification for the platform.

The Factory Is Starting to Acquire a Software Lifecycle

Once automation functions become software, an uncomfortable comparison appears. Software engineers expect versioning, test environments, controlled deployment, observability and rollback. Industrial engineers traditionally work through configuration management, commissioning, validation and change control.

The two disciplines are beginning to converge. Siemens explicitly describes the third building block of software-defined automation as IT-like engineering, including DevOps-style practices for industrial automation.

The important word is validate. A factory cannot simply inherit the software industry’s casual attitude toward production deployment. A bad web release can take down a service. A bad industrial release can damage equipment, stop a production line or create a safety event.

The factory’s deployment pipeline is becoming part of the production system.

The Factory Needs a Test Environment for Physical Change

This is where digital twins become strategically important. NIST defines manufacturing digital twins as synchronised virtual representations that can support observation, diagnosis, prediction and optimisation. Its current programme emphasises that useful twins need reliable data, validation and standards — not merely impressive visualisations.

NIST’s July 2026 workshop report is unusually revealing. It identifies four persistent barriers to scalable manufacturing digital twins: interoperability; verification, validation and uncertainty quantification; cybersecurity; and workforce readiness.

The Hard Part Is Not Creating Another Digital Twin. It Is Making Twins Talk.

Factories are not greenfield software projects. They contain equipment from different decades, vendors, engineering disciplines and acquisitions. Each system may expose different protocols, identifiers, data structures and assumptions about what a signal means.

That is why the 2026 additions to ISO 23247 matter. ISO 23247-5 defines a digital thread for connecting and maintaining manufacturing digital twins across design, planning, production and testing. ISO 23247-6 addresses composition and interoperation of multiple digital twins, including integrated, unified and federated approaches.

The implication is bigger than digital twins. The software-defined factory will be limited by its ability to establish common meaning across machines, applications and lifecycle stages. The factory therefore needs something analogous to an API economy — but for physical processes.

When Software Controls Physics, the Deployment Pipeline Becomes an OT Asset

Industrial cybersecurity has traditionally been framed around protecting controllers, networks, engineering workstations and plant equipment. Software-defined architecture adds another critical surface: the systems that build, distribute, authenticate and deploy the software that controls those systems.

NIST’s security work on digital twins points to cybersecurity and trust considerations created by digital representations, real-time monitoring and potential interaction with physical systems.

The Real Prize Is Not Lower Hardware Spend. It Is Lower Change Friction.

It would be easy to overstate the economic case. Software does not eliminate physical capacity. Robots still need to be purchased. Motors still fail. Tooling still wears out. Production cells still need safety validation. A virtual PLC does not turn a CNC machine into a general-purpose computer.

The more defensible proposition is narrower: software can move some kinds of industrial change from the capital-equipment lifecycle into the software lifecycle. Siemens’ Audi example describes exactly this direction: virtualised automation can reduce dependence on new hardware for certain changes, while centralised management can simplify deployment and maintenance.

The Factory of 2030 Will Still Contain Machines from 2005

The software-defined factory is being built on top of an industrial installed base that cannot simply be replaced. A brownfield plant may contain multiple PLC generations, proprietary fieldbuses, old drives, vendor-specific HMIs, specialised machines and systems with long certification or maintenance cycles.

The Factory Is Acquiring a Software Engineering Discipline

This transition does not mean replacing controls engineers with programmers. It means the boundary between the disciplines becomes a critical organisational interface.

The scarce skill will not be “software” or “manufacturing.” It will be the ability to reason across the boundary between them.

Six Moves That Matter More Than Buying Another Dashboard

The Factory Is Not Becoming a Computer. It Is Becoming Programmable.

That distinction matters. Computers are designed around software. Factories are constrained by physics, safety, materials, certification, energy, maintenance and people.

The software-defined factory therefore should not be judged by how much of the plant has been virtualised. It should be judged by a harder metric:

That is why the developments around virtual PLCs, digital twins, industrial edge, IT/OT convergence and manufacturing standards matter together. They are not five unrelated technology trends. They are pieces of an emerging architecture for making physical production more configurable.

NIST’s current digital-twin work describes a systems-of-systems and lifecycle approach, while the newest ISO 23247 work is formalising digital threads and the composition of multiple twins. The standards work is a signal that the industry is moving from isolated digitalisation projects toward interoperable manufacturing systems.