PLC · 9 min read · Updated November 2026
Software-Defined Automation and Virtual PLCs: What Buyers Should Know Before Committing
Siemens SIMATIC S7-1500V, Schneider EcoStruxure Automation Expert, CODESYS Virtual Control, Rockwell FactoryTalk Logix Echo and Beckhoff TwinCAT on standard IPCs — the control logic is leaving dedicated hardware. Hannover Messe 2026 made it the headline trend. The promise, the hardware that still has to exist, and how to tell whether your plant is ready.
"Software-defined automation" (SDA) means decoupling the control software from the controller hardware: the PLC runtime becomes a software container or virtual machine on standard industrial computing hardware, engineered and deployed with IT practices — version control, CI/CD pipelines, orchestration — and the I/O connects over PROFINET, EtherCAT or EtherNet/IP as before. Siemens ships the SIMATIC S7-1500V, a virtual S7-1500 CPU running on a hypervisor (initially Proxmox/KVM-based Industrial Edge hardware); Schneider's EcoStruxure Automation Expert implements IEC 61499 with portable runtimes; CODESYS Virtual Control runs CODESYS runtimes as Docker containers; Beckhoff has run TwinCAT on IPCs for two decades; Rockwell's Logix Echo virtualises ControlLogix for test, with hardware-independent control on the roadmap. It is real, it is shipping, and for most plants it is not yet the right purchase. Here is how to think about it.
What problem it solves
- Lifecycle decoupling. The controller "hardware" becomes a server you refresh on an IT cycle; the control application outlives several hardware generations. For plants that have just lived through the S7-300 or SLC 500 obsolescence, that is attractive.
- Engineering practices. Code in Git, automated testing against a virtual controller, staged deployment — the things that make IT software reliable become available to OT.
- Consolidation. Ten small PLCs become ten virtual controllers on two redundant servers, with centralised monitoring and backup.
- Vendor independence (partly). IEC 61499 and CODESYS promise portability; vendor-specific virtual PLCs (S7-1500V) keep the vendor but free the hardware.
What does not go away
| Still needed | Why |
|---|---|
| Field I/O and the network to it | Sensors and actuators are physical; ET 200SP, WAGO 750, Beckhoff EtherCAT terminals connect to the virtual CPU over the same fieldbus. The I/O network becomes more critical, not less. |
| Deterministic hardware | Real-time control needs a real-time hypervisor and NICs with hardware timestamping. Not any server: Siemens IPC/Edge devices, qualified industrial servers, specific NICs. |
| Safety | Functional safety (PL e / SIL 3) stays on certified hardware — safety PLCs, safety I/O, safety relays — for now. Virtual safety is in development and will need certification. |
| Motion | Hard real-time motion over EtherCAT or PROFINET IRT works on IPC-based systems (Beckhoff proved it), but it demands careful hardware and network design. |
| Local control for availability | A line must survive the loss of the server room. Redundant hosts, local fallback controllers for critical loops, and UPS are part of the design. |
| Skills | Someone must run the hypervisor, the network, the container registry and the backups. If the plant has no IT/OT team, it is buying a problem. |
When it is the right call
- Greenfield plants with an OT/IT team and a strategy for software lifecycle, especially in process and discrete industries with many similar cells.
- Large brownfield plants consolidating dozens of small PLCs for non-safety, non-motion tasks (utilities, conveyors, building services).
- Machine builders who ship fleets and want test automation and over-the-air updates for the control application.
- Anyone whose main pain is obsolescence of controller hardware rather than of I/O.
When it is not: single machines, plants without IT capability, safety-heavy or high-speed motion applications, and anywhere the existing PLC fleet is modern and supported. A plant that just standardised on S7-1200 G2 or NX1P2 has ten years before this question matters.
What to buy now so you are ready later
- Networks first. Managed switches with redundancy, segmentation and time synchronisation; field I/O on PROFINET/EtherCAT that any controller can own later. The ET 200SP and WAGO 750 families already work behind virtual controllers.
- Edge hardware with headroom. Where you install an edge computer for data (an UNO-2271G class device for gateways, a Siemens IPC or Industrial Edge device for anything that will run control), choose hardware the vendors list as qualified for their virtual runtimes.
- Engineering discipline. Put PLC projects in version control today, standardise libraries, write tests. This is the part of SDA that pays regardless of hardware.
- Security architecture. A virtual PLC is an IT asset in the OT zone; the zoning and hardening must exist before it arrives.
Our view
Treat 2026–2028 as the pilot window: run one non-critical cell on a virtual controller, learn the operations model, keep hardware PLCs on safety and motion. Buy I/O and networks that are controller-agnostic. And be sceptical of any proposal that moves control into the cloud: edge-hosted virtual control with local determinism is engineering; cloud-hosted PLCs for a production line are a demo.
What a pilot looks like
A sensible first project is a utilities area — compressed air, cooling water, building services — currently on two or three small PLCs with no safety or motion. Hardware: two industrial servers or vendor-qualified edge devices in a redundant pair with a real-time hypervisor, UPS, and two managed switches in a ring; the existing field I/O replaced or kept where it is PROFINET-capable. Software: the vendor's virtual runtime, the engineering tool you already use (TIA Portal for S7-1500V, Automation Expert, CODESYS), a Git repository for the projects, and a monitoring stack for the hosts. Process: migrate one PLC's program, run it in parallel with simulated I/O, cut over, monitor jitter and cycle time for a month, then migrate the next. Success criteria written down before you start: cycle time and jitter within the control requirement, failover tested with a pulled power cord, a full restore from backup rehearsed, and the operations team able to redeploy a controller without the vendor.
Questions to put to the vendor
- Which host hardware, hypervisor versions and NICs are qualified, and what happens to support if we deviate?
- What are the measured cycle-time and jitter figures on that hardware, and under what load?
- How is redundancy done — hypervisor-level failover, application-level, or neither?
- Which fieldbuses and I/O families are supported, and is PROFINET IRT / EtherCAT distributed clocks available?
- Licensing model: per instance, per host, per I/O count, subscription? What happens to a running controller when the licence server is unreachable?
- Security: how are images signed, how are updates delivered, how does the runtime fit IEC 62443 zoning?
- Safety and motion roadmap, with dates you are willing to be quoted on.
Need engineering help with this?
Our engineers apply this to real projects every week — selection, specification, commissioning. Send your question or a part number.
Quick answers
Is a virtual PLC slower than a hardware PLC?
Usually faster in raw execution — a server core outruns a PLC CPU — but jitter depends on the hypervisor and NIC. Vendors specify cycle times and jitter for qualified hardware; for sub-millisecond motion, hardware controllers or Beckhoff-style IPC designs remain the safer choice.
Can I run safety functions on a virtual PLC?
Not today for certified PL d/e or SIL 2/3 functions. Safety remains on certified safety controllers and I/O; vendors are working on certified virtual safety, but plan with hardware safety for the foreseeable future.
Does S7-1500V replace my S7-1500 hardware?
It is an option, not a replacement: the same TIA Portal project targets either. Siemens positions S7-1500V for plants that want IT-style lifecycle management; hardware S7-1500 continues for everything else.