Most manufacturers looking at software-defined automation ask the wrong question first. The question is not “should we replace our hardware PLCs with virtual ones?” At Siemens, the S7-1500 virtual PLC and the hardware PLC share the same components and behave identically as a control layer. The real question is where a virtual PLC actually improves the operation, and where it adds complexity for no gain.
When the Hardware PLC Is Still the Right Call
If the production line is running, the code is stable, and there is no requirement to connect control to data analytics or AI applications at the edge, the hardware PLC stays. Many facilities run automation architectures that have been reliable for years. There is no operational case for replacing them just because a newer architecture exists.
Siemens offers both options precisely because every environment is different. Software-defined automation is not a migration project every plant has to run. A physical PLC fits where the application is fixed and the operation does not need the flexibility that running on shared compute provides.
When a Virtual PLC Earns Its Place
The virtual PLC makes a different kind of sense when a manufacturer wants to consolidate hardware or run control and data workloads on the same infrastructure. Audi is doing this: instead of dedicated controllers at every production line, the company centralizes compute and scales control capacity through software as the operation grows, reducing the hardware investment at each expansion point. For manufacturers already running Siemens Industrial Edge for data analytics and AI applications, adding the virtual PLC to the same platform means one environment handles both the control runtime and the data workloads. Fewer separate modules, lower complexity.
| Physical PLC | S7-1500 Virtual PLC | |
| Control behavior | Dedicated hardware control | Same components, same control layer |
| Best fit | Fixed, stable applications with no edge integration | Centralizing compute, combining control with edge data and AI |
| Hardware model | Separate controller per application | Runs on shared Industrial Edge compute |
| Scalability | Expand by adding hardware | Scale control capacity through software |
| Investment model | Hardware per function | Consolidate across control and data applications |
| Example use case | Standard production lines | Audi centralizing plant compute |
The Version Drift Problem
Many plants carry a maintenance burden that runs deeper than hardware. Years of copying automation code and adapting it machine by machine have left a different version of the same program on every controller in the facility. The result is a “jungle of versions,” and the cost shows up every time a team needs to update, troubleshoot, or scale the system.
Software-defined automation addresses this by changing how automation code is maintained. Instead of adapting logic per machine, teams move to standardized, modular programs kept in one place and deployed consistently across the facility. The physical equipment stays on the floor. What changes is how the logic above it is managed. For plant engineering teams, this is the operational argument for software-defined systems, separate from any discussion about virtual versus hardware controllers.
Industrial Edge and Where Each Workload Belongs
Siemens Industrial Edge can run a virtual PLC as a control runtime alongside data applications, connectivity tools, and an Industrial Information Hub on the same compute platform. Consolidating these on shared infrastructure reduces the number of separate hardware modules and tightens the connection between automation control and data workloads.
Not every task belongs there, though. Real-time control, deterministic execution, safety functions, and shop-floor decisions need local compute where timing is guaranteed. Less time-sensitive work, including recipe updates, historical analytics, and connectivity to enterprise systems, can move toward the cloud. The dividing line is timing: anything requiring real-time guarantees stays local; anything that can tolerate latency moves up. Defining the actuation point for a robot happens on the real-time machine. Updating a recipe happens in batches and goes through the cloud without operational impact.
AI Writes the Code. The Engineer Approves.
AIDEN is Siemens’ engineering agent for TIA Portal. An engineer describes a task in plain language, AIDEN generates the corresponding automation function block, imports it into TIA Portal, compiles the code, and runs an error-correction loop until the program is clean. The engineer then reviews the result and loads it onto the controller.
The engineer’s role in this cycle is at the start and the end. Schulz describes this shift as the engineer becoming “an architect of the system,” directing what gets built rather than writing every line by hand. There is also a secondary benefit: describing tasks in natural language tends to push teams toward more modular, library-based approaches, which reinforces the same standardization benefit that software-defined automation delivers at the code management level.
What Factory Control Architecture Looks Like in a Few Years
The pattern is already visible in cars and smartphones. Modern cars have moved to a central processing unit with defined zones for peripherals. Smartphones decouple the operating system from the underlying hardware, which is why a software update can change device behavior without touching the physical components. Factory automation is heading toward the same structure.
Physical equipment stays physical. Drives, motors, I/Os, and actuators depend on electrical and mechanical connections that stay on the factory floor. What builds on top is generalized compute, either central or distributed, capable of running AI applications and automation control programs side by side. A software layer between that compute and the applications above means either can change without requiring the other to change as well. The control layer remains the place where real-time decisions, safety policies, and shop-floor operations are enforced. AI applications run above it, feeding in insights and taking out instructions.
This article is based on a video interview with Matthias Schulz, Marketing & Communications Manager for Software-Defined Automation & Innovation at Siemens Digital Industries, recorded by Lucian Fogoros of IIoT World.
Frequently Asked Questions
1. What is the difference between a virtual PLC and a physical PLC?
A virtual PLC and a hardware PLC share the same components and behave identically as a control layer. The difference is in the infrastructure they run on. A virtual PLC runs on industrial PCs or shared compute infrastructure such as Siemens Industrial Edge. A hardware PLC is a dedicated control device. The right choice depends on whether the manufacturer needs centralized compute, edge integration, or shared infrastructure for data and AI applications.
2. When should a manufacturer choose a virtual PLC over a hardware PLC?
A virtual PLC makes more operational sense when a manufacturer wants to centralize compute across a facility, combine automation control with data analytics and AI applications on the same infrastructure, or scale control capacity without adding dedicated hardware at each expansion point. Manufacturers without those requirements continue with the hardware PLC. Siemens offers both because different operational environments require different architectures.
3. What is the version drift problem in PLC code?
Version drift happens when engineers copy automation code and adapt it individually for each machine, producing different versions of the same program across a facility. Matthias Schulz of Siemens describes this as “a jungle of versions” that grows harder to maintain, update, and scale over time. Software-defined automation addresses this by moving toward standardized, modular code managed centrally rather than adapted machine by machine.
4. What is Siemens AIDEN and how does it work with TIA Portal?
AIDEN is a Siemens engineering agent that generates automation function blocks from natural language input, imports them into TIA Portal, compiles the code, and corrects errors automatically in a loop until the project is clean. The engineer reviews the finished result and loads it onto the controller. The engineer remains responsible for the final architecture and deployment decision.
