Software-Defined Manufacturing: The Virtual PLC and Container-Based Control in 2026

For forty years, the plant floor ran on an unspoken bargain: you bought a programmable logic controller from a vendor, and in exchange for its determinism you accepted a proprietary CPU, a proprietary backplane, a proprietary runtime, and a fifteen-year obsolescence clock you did not control. Software-defined manufacturing and the virtual PLC break that bargain by peeling the control logic off the fixed-function hardware and running it as a container on a standard industrial server. In 2026 this is no longer a research slide. Siemens ships a UL-verified virtual S7-1500, Schneider deploys IEC 61499 applications to third-party hardware, Beckhoff runs TwinCAT in Linux containers, and CODESYS packages a soft PLC for Podman and Docker. The economics, the compute, and the standards have finally converged.

This piece is opinionated but evidence-based. It argues the shift is real and structurally significant, then spends most of its length on the parts vendors gloss over: determinism, safety certification, liability, and cultural inertia.

What this covers: the architecture of container-based control, real-time Linux and TSN, the 2026 vendor landscape, the genuine barriers that will slow adoption, and a concrete decision framework for OT architects.

Context and Background

The programmable logic controller has been the atom of factory automation since Dick Morley’s Modicon 084 in 1969. Its defining virtue is not intelligence but predictability: a hardware scan cycle that reads inputs, solves logic, and writes outputs in a bounded, repeatable window, decade after decade, in an electrically hostile cabinet. That predictability is why the installed base is measured in hundreds of millions of nodes and why replacement cycles are glacial.

The incumbents built empires on this. Rockwell’s ControlLogix, Siemens’ SIMATIC S7, Mitsubishi’s MELSEC, and Schneider’s Modicon each pair proprietary silicon with a proprietary engineering tool and a proprietary fieldbus, producing switching costs that are the entire point of the business model. The IEC 61131-3 standard, first published in 1993 and revised in 2013, gave us portable languages — ladder, structured text, function block — but not portable runtimes. Your ladder logic was standard; the box it ran on was not.

Two forces cracked this open. First, x86 and Arm compute at the edge became absurdly cheap and capable: a fanless industrial PC now delivers more compute than an entire 2005 control cabinet. Second, the IT world learned to run latency-sensitive workloads on commodity Linux with containers. Software-defined networking and software-defined storage already collapsed proprietary appliances into orchestrated software; software-defined automation applies the same playbook to control. The IEC 61499 event-driven model supplies the portable, hardware-agnostic application layer that IEC 61131-3 never quite delivered, and UniversalAutomation.org provides a shared runtime implementation multiple vendors can build on.

The Reference Architecture of Container-Based Control

Software-defined manufacturing decouples four things that a traditional PLC fuses into one sealed unit: the control application, the runtime that executes it, the operating system underneath, and the hardware it all sits on. The virtual PLC is the runtime, repackaged as a container image, running on real-time Linux on a standard industrial server, talking to the field over deterministic Ethernet. Break the fusion and each layer can be versioned, scaled, patched, and replaced on its own clock instead of the vendor’s.

Figure 1: Reference architecture for a container-based virtual PLC. Control logic is decoupled from the runtime, the runtime from the OS, and the OS from the hardware — each layer versioned independently.

Figure 1 shows the stack. Control logic — authored in IEC 61131-3 or the event-driven IEC 61499 — compiles into an application that a vPLC runtime container executes. The container sits on a PREEMPT_RT Linux kernel on a multi-core industrial edge server, reaches the field through a Time-Sensitive Networking (TSN) network interface, and is supervised by an orchestrator that can spin up a hot-standby instance. The legacy fixed-function PLC it replaces is shown dashed: same logic, radically different lifecycle.

Decoupling is the whole thesis

The value is not that control “runs in a container” — that is a means. The value is that decoupling breaks the obsolescence chain. When a proprietary PLC CPU goes end-of-life, you migrate the whole system on the vendor’s timetable, often re-engineering I/O and re-validating logic you never wanted to touch. When control is a container, the hardware refreshes underneath a byte-identical image. Siemens frames its Industrial Edge offer explicitly around running control on industrial PCs, in a server rack, or on standard server infrastructure — the point being that the substrate is now interchangeable (Siemens).

One server, many controllers

Because a modern edge server has cores to spare, one box can host several vPLC instances that were previously several physical PLCs. Beckhoff makes this concrete: with TwinCAT for Linux, several TwinCAT runtimes can execute on a single industrial PC for the first time, each isolated in its own container (Beckhoff). CODESYS Virtual Control SL likewise runs multiple instances on almost any x86 or Arm Linux device via Podman or Docker (CODESYS). Consolidation cuts cabinet count, spares inventory, and power — but it also concentrates failure, which we return to in the trade-offs.

The application layer finally goes portable

IEC 61131-3 standardized languages but not runtimes, so “portable” logic still married a vendor box. IEC 61499’s event-driven function blocks and the shared UniversalAutomation.org runtime aim past that: Schneider’s EcoStruxure Automation Expert can now deploy IEC 61499 applications onto Phoenix Contact PLCnext hardware, meaning the same application targets multiple vendors’ devices (ARC Advisory). That is the “software-defined” promise made literal — the app outlives the box.

Real-Time Linux, TSN, and the Determinism Problem

The hard question is not whether Linux can run control logic — it obviously can — but whether it can do so with the bounded, repeatable timing a physical PLC guarantees by construction. This is where software-defined automation earns its scepticism, and where the last decade of engineering has quietly changed the answer.

Figure 2: How a virtual PLC achieves bounded latency on general-purpose Linux — real-time scheduling, CPU isolation, and TSN traffic shaping working together.

Figure 2 shows the mechanism. The vPLC task runs at real-time priority (SCHED_FIFO 99) on a PREEMPT_RT kernel that makes almost all kernel code preemptible and pushes interrupt handling into schedulable threads. The control cores are fenced off with CPU isolation (isolcpus) so the general-purpose scheduler and housekeeping never touch them, while HMI and AI-inference containers run at lower priority on the remaining cores. Egress traffic is shaped by TSN-aware queue disciplines — Earliest TxTime First (ETF) and time-aware priority (TAPRIO) — and the NIC applies hardware timestamps so cyclic frames leave on a schedule, not when the CPU gets around to it.

PREEMPT_RT went mainline, and that matters

The PREEMPT_RT patch set spent roughly two decades out-of-tree; the bulk of it merged into the mainline Linux kernel in 2024. That is not a cosmetic milestone. It means real-time Linux is now maintained by the whole kernel community, not a side project, and vendors can build on a supported base. CODESYS explicitly targets RHEL and Debian with the PREEMPT_RT patch for its virtual controller (CODESYS). A well-tuned PREEMPT_RT system routinely holds worst-case scheduling latency into the low tens of microseconds on isolated cores — comfortably inside a 1 ms control cycle, and adequate for many motion applications. Treat that figure as directional: measured worst case depends on hardware, BIOS SMIs, and load, and must be validated per deployment, never assumed.

TSN moves determinism off the private fieldbus

Deterministic timing inside the box is only half the loop; the frames still have to cross a network on time. TSN is the set of IEEE 802.1 amendments that give standard switched Ethernet bounded latency through shared time (802.1AS), scheduled gates (802.1Qbv), and — critically for safety — frame replication and elimination (802.1CB). The IEC/IEEE 60802 profile pins these down specifically for industrial automation. TSN is what lets control traffic, HMI traffic, and camera streams share one converged Ethernet instead of a proprietary fieldbus per function (IEEE 802.1 TSN).

Containers add a determinism tax you must pay down

Here is the honest caveat vendors underplay: containerization can break determinism if you are naive about it. Academic work on KuberneTSN documents that some container images do not support the SO_TXTIME socket option and that transmission timing is not forwarded from the container’s network namespace out to the virtual switch — so a scheduled frame silently loses its schedule at the veth boundary (arXiv 2302.08398). The fix is deliberate: SR-IOV or macvlan to give the control container direct NIC access, SO_TXTIME support end to end, and pinned cores. Containers are not free real-time; they are real-time you have to engineer.

Redundancy, Orchestration, and the 2026 Vendor Landscape

Once control is software, availability becomes a software problem — which is both the opportunity and the trap. A physical PLC’s redundancy is a second chassis and a proprietary sync link. A virtual PLC’s redundancy is an orchestrated standby holding a synchronized copy of the process image, promoted on failure. Done right, failover is faster and cheaper. Done with a naive Kubernetes reschedule, it is far too slow for control.

Figure 3: Hot-standby failover for a virtual PLC. The standby holds a synchronized process image and is promoted within the failover budget so cyclic I/O resumes bumplessly.

Figure 3 walks the failover. The primary vPLC drives cyclic I/O (say every 1 ms) and streams a state heartbeat to a standby holding the same process image. An orchestrator liveness-probes the primary; on node failure it promotes the standby, which resumes cyclic I/O within a defined failover budget. The subtlety is the budget: a generic Kubernetes pod reschedule takes seconds to tens of seconds, which trips every drive in the cell. Real control redundancy needs sub-cycle-to-few-cycle state sync and pre-warmed standbys — which is why vendors ship their own redundancy layers rather than leaning on stock K8s.

The vendor moves that make 2026 the inflection year

The signal that this is real is that the incumbents — who have the most to lose from openness — are shipping it themselves.

• Siemens presented three software-defined entry points at Hannover Messe 2026: the S7-1500 virtual PLC (including a safety-rated variant), Industrial Edge for AI, and an open engineering toolchain. Its virtual PLC and Industrial Edge earned a Platinum UL verification, and WinCC Open Architecture now runs as an Edge App against the SIMATIC S7-1500V (Siemens news). Audi’s “software-defined factory” is Siemens’ flagship reference (Siemens).
• Schneider Electric used Automate 2026 to push open, software-defined automation built on IEC 61499, and launched “Industrial Automation Modernization as a Service” pairing EcoStruxure Automation Expert with HPE SimpliVity hybrid-cloud infrastructure — control moving from CapEx to OpEx (PR Newswire).
• Beckhoff ships TwinCAT for Linux as a virtual PLC, container-distributable, multiple runtimes per IPC (Beckhoff).
• CODESYS offers Virtual Control SL for Linux with container or hypervisor deployment, RHEL/Debian PREEMPT_RT, multi-instance (CODESYS).
• Rockwell is expanding both its Open Process Automation portfolio and edge AI — integrating NVIDIA Nemotron small language models into FactoryTalk workflows across HMI, appliance, and server tiers (PR Newswire).
• The Open Process Automation Forum (OPAF) anchors the process-industry flank: ExxonMobil’s Lighthouse project cut over roughly 1,000 I/O and 100 controllers at a Baton Rouge resin plant at the end of 2024 and, per ARC, ran through 2025 with no significant interruptions (ARC Advisory).
• NVIDIA supplies the AI-and-orchestration substrate: at Hannover Messe 2026 it showed AI-driven manufacturing with Siemens, Rockwell, and ABB, with Siemens delivering NVIDIA-accelerated industrial PCs and BlueField DPUs at the edge (NVIDIA blog).

Read together, that is discrete factory automation (Siemens, Beckhoff, CODESYS), process automation (OPAF, ExxonMobil), the openness camp (Schneider, UniversalAutomation.org), and the AI-infrastructure layer (NVIDIA) all converging on the same architecture within a single trade-show season. When your architecture data plays cleanly into a unified namespace over Sparkplug B, the software-defined stack stops looking like a control experiment and starts looking like the plant’s operating system.

Trade-offs, Gotchas, and What Goes Wrong

Software-defined control is genuinely better on lifecycle and worse — for now — on several axes that OT teams care about deeply. Pretending otherwise is how pilots become cautionary tales.

Safety certification is the hardest wall. A safety function under IEC 61508 (and its process sibling IEC 61511) demands a certified execution path with a documented systematic-capability argument. A general-purpose Linux kernel plus a container runtime is a large, fast-moving attack surface that is difficult to freeze and assess for SIL 2 or SIL 3. This is why Siemens ships a separate safety variant of its virtual PLC and why most 2026 deployments still route the safety function through a discrete, hardwired safety controller alongside the vPLC — the standard logic goes soft, the safety logic stays certified. Do not conflate “the vendor has a virtual PLC” with “you can run your SIF in a container.”

Figure 4: Where the safety function lives. In 2026 most designs keep the certified safety runtime distinct from the standard vPLC, using black-channel protocols over TSN 802.1CB redundancy.

Figure 4 shows the decision. Only a TÜV-assessed safety runtime may host the safety function; everything else falls back to a discrete safety PLC. Either path uses a black-channel protocol — PROFIsafe or FSoE — so the safety layer is agnostic to the transport, with TSN 802.1CB frame replication providing the redundant delivery the protocol assumes.

Liability shifts and nobody has settled it. When a sealed PLC misbehaves, the vendor owns the box top to bottom. When your control is a container you assembled on a kernel you patched, orchestrated by software you configured, the failure-analysis question — and the legal one — gets genuinely murky. Who owns the incident when a mistuned isolcpus mask let a housekeeping thread jitter the control loop? OT organizations underestimate how much of their risk posture rode on that single-vendor throat to choke.

Cybersecurity cuts both ways. A software-defined plant inherits IT’s patch cadence, which is good — you can actually fix a CVE — but it also inherits IT’s attack surface on the most consequence-laden network in the building. Siemens is targeting IEC 62443-4-2-certified security functions including air-gapped operation for the second half of 2026, which tells you the vendors themselves treat this as unfinished (Siemens). Container escape on a control host is a categorically worse day than container escape on a web tier.

Cultural inertia is rational, not stubborn. A controls engineer who has kept a line running for twenty years is right to distrust a stack that changes monthly. The failure mode here is not Luddism; it is a legitimate demand for evidence that the new substrate holds determinism under real load and real faults. Consolidation also concentrates risk: one edge server hosting eight former PLCs is one node whose failure or compromise now stops eight things.

Practical Recommendations

Treat 2026 as the year to build competence, not to bet the crown-jewel line. The technology is ready for the right workloads; your organization’s evidence base and skills usually are not yet. Start where a failure is cheap and the lifecycle pain is real — a machine cell facing an obsolescence cliff, a greenfield line with no legacy fieldbus to honor, or a non-safety balance-of-plant function.

Keep the safety function discrete until you have a certified path and an assessor who will sign it. Let the standard control logic go soft first; the safety instrumented function can follow later, on the vendor’s certified runtime, not on your DIY kernel. Measure determinism, do not assume it: run cyclictest under representative load for days, not minutes, and validate TSN scheduling end to end including the container network boundary.

Checklist for a first software-defined control deployment:

• [ ] Pick a non-safety, obsolescence-driven or greenfield workload for the pilot.
• [ ] Standardize on PREEMPT_RT with isolcpus, threaded IRQs, and pinned control cores.
• [ ] Give the control container direct NIC access (SR-IOV/macvlan); verify SO_TXTIME end to end.
• [ ] Validate worst-case latency with cyclictest under load — publish the measured number, never a datasheet one.
• [ ] Use the vendor’s control-grade redundancy, not a stock Kubernetes reschedule, for failover.
• [ ] Keep the safety function on a certified runtime or a discrete safety PLC; document the IEC 61508/61511 argument.
• [ ] Harden to IEC 62443, segment the control host, and own a CVE-patching runbook before go-live.
• [ ] Write down who owns the incident — assign OS, runtime, orchestration, and application responsibility explicitly.

Frequently Asked Questions

What is a virtual PLC?

A virtual PLC is a programmable logic controller runtime delivered as software — typically a container image — that executes standard control logic (IEC 61131-3 or IEC 61499) on a general-purpose industrial server rather than on proprietary PLC hardware. It provides the same scan-cycle execution model as a physical PLC but decouples the control application from the box, so hardware can be refreshed, instances consolidated, and logic versioned independently. Examples in 2026 include the Siemens SIMATIC S7-1500V, Beckhoff TwinCAT for Linux, and CODESYS Virtual Control SL.

Can a virtual PLC be truly deterministic?

Yes, within engineered bounds. On a PREEMPT_RT Linux kernel with CPU isolation, real-time scheduling, and TSN traffic shaping, a virtual PLC can hold worst-case latency well inside a 1 ms cycle for many applications. The determinism is not free the way a hardware PLC’s is — you must pin cores, give the container direct NIC access, and validate the measured worst case under real load. Naive containerization can silently break scheduled timing at the network-namespace boundary, so determinism is something you engineer and verify, not something you assume.

Is software-defined manufacturing safe for safety-rated functions?

Not automatically. Safety functions under IEC 61508 and IEC 61511 require a certified execution path with a documented systematic-capability argument, and a general-purpose Linux stack is hard to freeze and assess to SIL 2 or SIL 3. In 2026 most deployments keep the safety instrumented function on a separate certified safety runtime — like Siemens’ dedicated safety vPLC variant — or on a discrete hardwired safety PLC, while the standard control logic runs virtualized. Software-defined and safety-certified are converging but are not yet the same thing.

How is a virtual PLC different from IEC 61499?

They solve different layers. A virtual PLC is a runtime — where control executes (software on a server versus a proprietary box). IEC 61499 is an application model — how control is described, using event-driven, distributable function blocks. IEC 61131-3 gave portable languages but not portable runtimes; IEC 61499 plus a shared runtime like UniversalAutomation.org aims for applications that deploy across vendors’ hardware. You can run IEC 61131-3 logic on a virtual PLC, or IEC 61499 applications on a soft or hard controller — the concepts are complementary.

What role does TSN play in software-defined control?

Time-Sensitive Networking (TSN) is the set of IEEE 802.1 standards that give standard switched Ethernet bounded, deterministic latency — via time synchronization (802.1AS), scheduled transmission gates (802.1Qbv), and frame replication for redundancy (802.1CB). It lets control, HMI, and vision traffic share one converged network instead of a proprietary fieldbus per function, and it carries the safety black channel. The IEC/IEEE 60802 profile tailors TSN specifically for industrial automation, making it the transport backbone of the software-defined plant.

Which vendors are leading software-defined automation in 2026?

The landscape spans several camps. Siemens (virtual S7-1500 on Industrial Edge), Beckhoff (TwinCAT for Linux), and CODESYS (Virtual Control SL) lead discrete factory automation. Schneider Electric drives the open flank with IEC 61499 and EcoStruxure Automation Expert, alongside UniversalAutomation.org. The Open Process Automation Forum — with ExxonMobil’s live Lighthouse deployment — anchors process automation, and Rockwell is expanding there too. NVIDIA supplies the AI and orchestration substrate underneath, partnering with Siemens, Rockwell, and ABB.

Further Reading

• IEC 61499 vs IEC 61131-3: Distributed Control Compared for 2026 — the application-model layer that makes control logic hardware-agnostic.
• Ethernet-APL Reference Architecture for Process Automation in 2026 — the physical layer bringing converged Ethernet to the field in process plants.
• Unified Namespace Architecture with HiveMQ and Sparkplug B in 2026 — how software-defined control data flows into a plant-wide data backbone.
• Siemens: Industrial Edge ecosystem strengthens data and AI integration — primary vendor source for the 2026 virtual PLC and Industrial Edge roadmap.
• IEEE 802.1 Time-Sensitive Networking Task Group — authoritative reference for the TSN standards underpinning deterministic Ethernet.

By Riju — about