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

Last Updated: November 2026

For four decades the plant floor ran on a quiet bargain. You bought a programmable logic controller from one vendor, and in exchange for its predictability you accepted a proprietary CPU, a proprietary backplane, a proprietary runtime and an obsolescence clock you did not control. Software-defined manufacturing and the virtual PLC break that bargain by lifting the control logic off fixed-function hardware and running it as software, often as a container, on a standard industrial server.

This matters now because the pieces finally line up. Real-time Linux (PREEMPT_RT) was merged into the mainline kernel in the 6.12 cycle, Time-Sensitive Networking (TSN) gives standard Ethernet bounded latency, and the major vendors ship virtual controllers: Siemens with the SIMATIC S7-1500V, Beckhoff with TwinCAT for Linux, CODESYS with Virtual Control SL. At the same time, the hard problems, determinism under containment, safety certification, redundancy and liability, are still unsettled and vendors tend to skip over them.

You will leave with a layered reference architecture, a working model of how a container holds a control cycle, a failover budget calculation, a safety-placement decision, and a pilot checklist.

What this covers: the decoupling thesis, real-time Linux and TSN mechanics, redundancy and orchestration, the 2026 vendor landscape, safety and security limits, and a practical adoption path.

Context and Background

The PLC has been the atom of factory automation since the Modicon 084 shipped in 1969. Its defining virtue is not intelligence but a bounded scan cycle: read inputs, solve logic, write outputs, repeat, in a window that does not drift for decades in an electrically hostile cabinet. That is why the installed base is enormous and replacement cycles are glacial.

The incumbents built business models on this. Rockwell, Siemens, Mitsubishi, Schneider and others each pair proprietary silicon with a proprietary engineering tool and a proprietary fieldbus. The IEC 61131-3 standard gave the industry portable languages (ladder diagram, structured text, function block diagram) but never a portable runtime. Your logic was standard; the box it ran on was not. If you want the language-level contrast with the newer event-driven model, our comparison of IEC 61499 vs IEC 61131-3 distributed control covers it in depth.

Two forces cracked the model open. First, x86 and Arm compute became cheap: a fanless industrial PC today carries more compute than an entire mid-2000s control cabinet. Second, IT learned to run latency-sensitive services on commodity Linux, isolate them with namespaces and cgroups, and manage them declaratively. Control engineering is now borrowing that toolchain.

What “virtual PLC” actually means

The term covers three distinct things, and conflating them causes most of the confusion in vendor conversations.

1. A soft PLC on an industrial PC. A runtime installed directly on Windows or Linux, as CODESYS Control and TwinCAT have done for many years. It is software, but it is tied to one machine and installed like any application.
2. A containerised or VM-hosted controller. The runtime is packaged as an image and deployed through a container engine or hypervisor. CODESYS documents its Virtual Control for Linux SL add-on as built on Docker or Podman, with multiple containers running on the same system and a Runtime Deploy tool that transfers images and creates instances. This is the pattern most people mean by virtual PLC.
3. A centrally orchestrated controller fleet. Many virtual controllers placed, monitored, updated and restarted by an orchestration layer in a rack or data centre. Siemens positions the S7-1500V as a hardware-independent controller managed through Industrial Edge Management, per Siemens material summarised by ARC Advisory Group.

Only the second and third genuinely change lifecycle economics. The first is a familiar product with a new label. A useful test: can you move the exact same image to a different server model, without re-engineering, and have it run the same cycle? If not, you have a soft PLC, not a software-defined architecture.

Who is shipping what

Beckhoff announced TwinCAT for Linux and a virtual PLC concept in November 2024. Its press release describes running TwinCAT as containers, spreading applications across several containers, and extending applications into a local data centre, while noting the virtual PLC targets applications with lower real-time requirements. I/O reaches the virtual controller through the EK1000 EtherCAT coupler over a switched and routed IP network, and ADS-over-MQTT handles communication across networks.

Siemens markets the S7-1500V as a complete virtual PLC compatible with the TIA portfolio so existing projects can be reused, and has extended it with a fail-safe variant. ARC reports that variant is TÜV-assessed to IEC 61508 and IEC 62443-4-2 and targets SIL 3 or PL e use. CODESYS ships Virtual Control SL for Linux, and its safe sibling is documented in a separate product datasheet. On the process side, the Open Process Automation Forum standard (O-PAS) builds on IEC 61499 and OPC UA, and the ExxonMobil Lighthouse project at Baton Rouge put it into production.

For a head-to-head view of the two most common runtimes, see our CODESYS vs TwinCAT soft PLC comparison. What follows is about the architecture that sits around them.

The thesis of this article

Most coverage frames the virtual PLC as “the same PLC, but in a container.” That undersells the change and hides the risk. The original claim here is that a virtual PLC is a scheduling and failure-domain problem before it is a software problem. A hardware PLC gives you a timing guarantee and a failure boundary for free, bundled into the box. A virtual PLC unbundles them: you must now choose, measure and defend the CPU isolation, the network path, the redundancy design and the blast radius of the host. Teams that treat those as engineering deliverables succeed. Teams that treat them as defaults produce pilots that pass a demo and fail a maintenance window.

Reference Architecture of Container-Based Control

A virtual PLC architecture splits what a hardware PLC fuses into one sealed unit: the control application, the runtime that executes it, the operating system underneath, and the hardware beneath that. Each layer is then versioned, patched and replaced on its own schedule, while a TSN network and an orchestrator provide timing and availability around them.

Figure 1: Reference architecture for a container-based virtual PLC. Application, runtime, operating system and hardware are decoupled, with TSN and an orchestrator around them.

Figure 1 reads from top to bottom. Control logic, written in IEC 61131-3 languages or as IEC 61499 function block applications, compiles into an artifact that a runtime container executes. That container sits on a PREEMPT_RT Linux host on a multi-core industrial server. Field traffic leaves through a TSN-capable network interface to I/O couplers, drives and remote I/O. An orchestration layer watches the runtime, holds a standby, and handles updates. HMI, historian and analytics containers share the same host at lower priority, which is the entire point of consolidation and also its main risk.

Decoupling is the whole thesis

Running control “in a container” is a mechanism, not the benefit. The benefit is that decoupling breaks the obsolescence chain. When a proprietary CPU reaches end of life, the traditional migration path is a forced project: new hardware, new I/O mapping, re-validation of logic you never wanted to touch. When control is an image, the server underneath can be refreshed while the image, and therefore the validated logic and its configuration, stays byte-identical. You re-run commissioning tests rather than re-engineer.

There is a second, less discussed benefit: testability. A virtual controller can run against a simulated plant on a developer laptop or in a CI pipeline, using the same image that will run in production. Hardware-in-the-loop rigs are expensive and scarce; containers are not. Teams that connect their virtual PLC to a plant model, for instance one exported as a Functional Mock-up Unit, get regression tests on every logic change. That is a genuine capability hardware PLCs cannot match, and it ties directly into digital twin workflows such as those described in our piece on digital twin MES reference architecture.

One server, several controllers

A modern edge server has cores to spare, so one box can host several controller instances that were previously several physical PLCs. CODESYS documents multiple containers on one system; Beckhoff describes distributing TwinCAT applications across several containers. Consolidation cuts cabinets, spares and power draw. It also concentrates failure: a host fault now stops every controller on it. The correct response is not to avoid consolidation but to define the failure domain explicitly, typically one host per machine cell or per safety zone, and to pair hosts for redundancy instead of packing one large server.

Where the I/O lives

A hardware PLC owns its backplane. A virtual PLC has no backplane, so the I/O must come over the network. There are three common patterns, and each has a distinct timing profile.

• EtherCAT or PROFINET to a distributed I/O node. The virtual controller acts as the fieldbus master or controller through a real-time capable NIC. Beckhoff’s EK1000 coupler pattern, which carries EtherCAT I/O across a switched IP network, is one vendor example. Cycle times are bounded by the network and the host scheduler together.
• OPC UA over TSN or OPC UA FX. Controller-to-controller and controller-to-device traffic on standard Ethernet with scheduled transmission. This is the pattern the industry is converging toward; our PROFINET vs EtherCAT vs OPC UA FX comparison lays out where each fits.
• Gateway to legacy buses. A small hardware gateway keeps old fieldbus devices alive while the logic moves to software. This is the realistic brownfield path.

The choice matters because the network becomes part of the control loop. A 1 ms cycle that depends on a switched network needs scheduled traffic, redundant paths and measured jitter, not a best-effort VLAN.

Application portability: 61131-3 versus 61499

Moving the runtime into a container does not by itself make the application portable between vendors. Each vendor’s IEC 61131-3 project still depends on its own libraries, task model and I/O configuration. IEC 61499 attacks this from the other side with an event-driven function block model and explicit deployment of blocks to devices. The UniversalAutomation.org runtime and the O-PAS standard are the two largest efforts to make the application outlive the box. The ExxonMobil Lighthouse deployment, which ran IEC 61499 runtime applications on distributed control nodes, is the most cited production proof point; ControlEng reports it at more than 100 controllers and 1,000 I/O points, with hot cutover in November 2024.

Treat portability claims with care. Portability of the language is not portability of the system. Timing behaviour, diagnostics, redundancy semantics and I/O addressing remain vendor-specific, and those are what break during migration. If portability is a procurement requirement, test it by actually moving a non-trivial application between two runtimes during evaluation, and record every manual change required.

Real-Time Linux, TSN, and the Determinism Problem

Can a container on general-purpose Linux hold a control cycle? Yes, within engineered bounds. It needs a PREEMPT_RT kernel, isolated and pinned CPU cores, real-time scheduling for the control task, and a network path that preserves scheduled transmission. Each element is necessary; none is sufficient alone, and the container boundary can silently undo the network part.

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

Figure 2 shows the mechanism. The control task runs under a real-time scheduling policy such as SCHED_FIFO on a kernel where almost all code is preemptible and interrupt handlers run as schedulable threads. Control cores are removed from the general scheduler with kernel parameters such as isolcpus, nohz_full and rcu_nocbs, so housekeeping work, timer ticks and RCU callbacks stay on other cores. Non-critical containers are pinned elsewhere. Egress frames are queued through a time-aware qdisc and a hardware-timestamping NIC so they leave on a schedule instead of whenever the CPU gets to them.

PREEMPT_RT is mainline now

PREEMPT_RT spent roughly two decades as an out-of-tree patch set. Phoronix reported it merged for Linux 6.12 in September 2024, initially for ARM64, RISC-V and x86. The consequence is practical: real-time Linux is now maintained as part of the kernel, distributions can ship supported RT kernels, and vendors can build products on a base they do not have to fork. Our walk-through of mainline PREEMPT_RT versus Zephyr and Xenomai covers the kernel side in more depth.

How good is it? A well-tuned PREEMPT_RT system with isolated cores can keep worst-case scheduling latency in the range of tens of microseconds, which is comfortably inside a 1 ms cycle and workable for many motion tasks. Treat that as directional, not a guarantee. Worst-case latency depends on the CPU, firmware System Management Interrupts, power-state transitions, memory pressure, cache contention from neighbouring workloads and driver behaviour. The only number you can rely on is the one you measure on your own hardware, for days, under representative load.

TSN moves determinism off the private fieldbus

Timing inside the host is half the loop. The frames still have to cross a network on time. TSN is a family of IEEE 802.1 standards that give switched Ethernet bounded latency: time synchronisation (802.1AS), scheduled gates (802.1Qbv), frame preemption (802.1Qbu with 802.3br), and seamless redundancy through frame replication and elimination (802.1CB). The IEC/IEEE 60802 profile specifies a TSN profile for industrial automation. Our detailed look at the 802.1Qbv time-aware shaper and gate control lists shows how a schedule is actually built.

The key mental shift for controls engineers: in TSN the schedule is computed centrally and installed in every switch, and the host must send each frame at a precise time. That puts a hard requirement on the host. If the control task wakes late, the frame misses its gate and waits for the next cycle. Host jitter converts directly into network latency.

Containers add a determinism tax you must pay down

Here is the caveat marketing decks omit. Containerisation can break scheduled transmission. The KuberneTSN paper (Garbugli, Rosa, Bujari and Foschini, arXiv 2302.08398) addresses a gap in networking support for time-sensitive workloads in containerised environments and proposes a kernel-bypass overlay with a userspace TSN-style scheduler, reporting that it can meet deterministic deadlines comparable to bare metal and outperform a Flannel overlay in their testbed. The implication, which matches the older versions of this article, is that a default container network path (virtual Ethernet pair, bridge, overlay) is not designed to preserve per-packet transmit times.

Practical mitigations, in order of preference:

1. Give the control container direct NIC access. Use host networking, macvlan or SR-IOV virtual functions so frames bypass the bridge and overlay entirely.
2. Verify transmit-time support end to end. Confirm the application and socket options support scheduled launch times (for example SO_TXTIME with an ETF or taprio qdisc), and confirm with hardware timestamps that frames leave on schedule.
3. Pin and isolate. Dedicate cores with CPU sets, keep non-real-time containers off them, and disable frequency scaling and deep C-states on those cores.
4. Constrain memory. Lock memory (mlockall), avoid swap, and pre-fault the heap so a page fault never lands in the control cycle.

Containers are not free real-time. They are real-time you have to engineer, and the engineering is repeatable once you have done it for one host image.

What a measurement plan looks like

A credible determinism claim has four parts. First, the stimulus: the control workload running at its real cycle time with HMI, historian and logging containers active. Second, the instrument: cyclictest or equivalent for scheduling latency, plus hardware timestamps on the wire for network jitter. Third, the duration: long enough to catch rare events such as firmware interrupts and thermal throttling, meaning days rather than minutes. Fourth, the pass criterion: a maximum, not an average, set at a fraction of the cycle time with an explicit safety margin.

Report the maximum and the 99.999th percentile, not the mean. A mean of 8 microseconds with a 900 microsecond outlier is a failed control loop in a 1 ms system. Keep the histogram as a commissioning record, so that after a kernel or firmware update you can compare like with like.

Redundancy, Orchestration, and the Vendor Landscape

Once control is software, availability becomes a software problem. A physical redundant PLC pair is two chassis and a dedicated synchronisation link. A virtual redundant pair is two instances on two hosts, a state replication channel and a decision mechanism that promotes the standby. Done properly this is faster and cheaper than hardware redundancy. Done by leaning on a stock orchestrator’s default restart behaviour, it is far too slow for a control loop.

Figure 3: Hot-standby failover for a virtual PLC. The standby holds a synchronised process image and is promoted within a defined failover budget.

Figure 3 shows the sequence. The primary drives cyclic I/O and streams its process image and internal state to the standby each cycle or every few cycles. A watchdog, ideally independent of the general orchestrator, monitors the primary. On failure the standby takes over the I/O relationship and resumes cyclic output. The field devices should see, at worst, a few missed or repeated cycles that their own watchdogs tolerate.

The failover budget

Every actuator has a tolerance for stale commands. Define it first, then work backwards.

Take an illustrative example, with numbers chosen for the arithmetic and not measured from any product. Suppose a drive’s communication watchdog trips after three missed 1 ms cycles, so the control system has 3 ms before the drive faults. Failure detection through a heartbeat missed for two cycles costs 2 ms. That leaves 1 ms for promotion, I/O takeover and the first valid output. A container rescheduled by a generic orchestrator, which involves detecting node failure, evicting, scheduling, pulling or starting an image and initialising, takes seconds to tens of seconds in typical configurations. It misses that budget by three or four orders of magnitude.

The conclusion is not that orchestrators have no place. It is a division of labour:

• Fast path (microseconds to milliseconds): a pre-warmed standby with continuous state synchronisation and a dedicated failure detector. This is control-grade redundancy and is typically provided by the vendor’s runtime.
• Slow path (seconds to minutes): the orchestrator restores the lost redundancy by starting a new standby on a healthy host, rolling out updates, and managing images and configuration.

Lightweight Kubernetes distributions fit the slow path well. Our K3s edge Kubernetes production guide covers how to run a small cluster at the edge, and the comparison of K3s, MicroK8s and KubeEdge helps choose between them. Use them for lifecycle, not for the control cycle itself.

Network redundancy is part of controller redundancy

Two hosts do not help if both reach the field through one switch or one cable. Redundant paths for the control network can come from ring and parallel protocols standardised in IEC 62439 (MRP, PRP, HSR), or from TSN frame replication and elimination under 802.1CB. Recovery times differ by orders of magnitude: a ring protocol may recover in tens of milliseconds, while PRP and HSR deliver zero-recovery-time by duplicating frames. Our article on industrial Ethernet redundancy with PRP, HSR and MRP explains which suits which cycle time.

Updates without stopping the line

One of the real attractions is the update model. With a hot-standby pair you can update the standby, validate it against live inputs in a shadow mode where its outputs are not applied, then switch roles and update the former primary. That gives a rolling update for control logic, something that on a hardware PLC typically requires a stop or a vendor-specific online-change feature with limits. It also means a rollback is a role switch to a known-good image. The caveat is state compatibility: if the new logic changes the layout of retained data, the standby cannot simply adopt the primary’s state, so you need a state migration step or a planned brief pause. Treat state schema as a versioned interface.

The 2026 Vendor Landscape, Verified

The signal that this shift is real is that incumbents, who have the most to lose from openness, ship virtual controllers themselves. What follows is limited to what could be confirmed from primary or reputable sources in November 2026. Anything else is flagged.

Siemens. The SIMATIC S7-1500V is described as a hardware-independent virtual controller managed through Industrial Edge, compatible with the TIA portfolio so existing project data can be reused. ARC reports a fail-safe variant, the S7-1500V F, holding TÜV approval under IEC 61508 and IEC 62443-4-2 for use up to SIL 3 or PL e, running in an industrial edge environment. Siemens and Audi have publicised a software-defined shop-floor programme. Claims about specific 2026 trade-show announcements and third-party verification levels from earlier drafts of this article could not be re-verified here and have been removed.

Beckhoff. TwinCAT for Linux, announced in November 2024, lets TwinCAT run as containers with application components distributed across several containers. Beckhoff states the virtual PLC addresses applications with lower real-time requirements and moves control, simulation and test tasks into a local data centre. That caveat is important: it is an honest statement that the virtual path is not aimed at the tightest motion loops.

CODESYS. The Virtual Control for Linux SL add-on provides hardware-independent controllers built on Docker or Podman, with multiple containers on one system and a deployment tool for images and instances. A separate safe variant exists as a product. See the CODESYS and TwinCAT comparison for the engineering differences.

Schneider Electric and the open camp. EcoStruxure Automation Expert is built on IEC 61499 and the UniversalAutomation.org runtime. Cross-vendor deployment claims, such as running its applications on another vendor’s hardware, have been made publicly but are not re-verified here. Open-source IEC 61499 tooling is a useful way to experiment without vendor lock-in; see our coverage of Eclipse 4diac and IEC 61499 with EtherCAT.

Process automation and O-PAS. The ExxonMobil Lighthouse project at the Baton Rouge resins finishing plant used the Open Process Automation Standard version 2.1, with distributed control nodes running IEC 61499 applications. ControlEng reports more than 100 controllers and 1,000 I/O points, a hot cutover on 8 November 2024, first sold production on 18 November and stable operation reported by February 2025. The same report cites a figure of 52% hardware and software savings against a traditional DCS, attributed to participants, which should be read as a claim from project stakeholders rather than an audited result.

Read together: discrete automation vendors, an open standards camp and a process-industry user all converge on the same decoupled architecture. The differences are in how much real-time responsibility each places on the virtual layer.

Decision matrix: virtual, soft or hardware?

Criterion	Hardware PLC	Soft PLC on IPC	Containerised vPLC	Orchestrated vPLC fleet
Timing guarantee	By construction	Engineered per machine	Engineered and measured	Engineered, plus network scheduling
Hardware refresh	Vendor schedule	Re-install per IPC	Image portable across hosts	Automated rollout
Consolidation	None	Limited	Several controllers per host	High, with failure-domain risk
Redundancy	Vendor pair	Vendor option	Vendor option plus second host	Fast path plus orchestrated recovery
Safety function	Certified safety PLC	Separate safety hardware	Certified variant only	Certified variant only
Best fit	Tight motion, safety, legacy	Single machines	Cells with obsolescence pressure	Multi-line plants and utilities

Security and the Software Supply Chain

A sealed PLC hides its operating system. A virtual PLC exposes it, and that cuts both ways. You can patch a vulnerability in days instead of waiting for a vendor firmware release, but you are now responsible for a Linux kernel, a container runtime and an image supply chain on the most consequential network in the building.

Four controls matter more than the rest. Image provenance: build from pinned base images, sign them, and scan them before they reach the host; our Trivy and Cosign supply chain pipeline shows one way to do this. Runtime hardening: drop capabilities, use a read-only root filesystem, apply seccomp and mandatory access control, and never run the control container privileged unless the vendor documents a specific need. Segmentation: put the control host in its own zone with conduits defined under IEC 62443, so that HMI and analytics containers cannot reach the control network except through defined paths. Update governance: an emergency patch for a container escape must still go through a validation step that checks timing, because a kernel update can change latency.

On regulation, the EU Cyber Resilience Act and NIS2 add obligations for manufacturers and operators; our CRA, NIS2 and IEC 62443 mapping is a starting point. A container escape on a control host is a categorically worse event than one on a web tier, so threat models should be written for that consequence.

Trade-offs, Gotchas, and What Goes Wrong

Software-defined control is better on lifecycle and, for now, worse on several axes that operations teams care about. Pretending otherwise is how pilots turn into cautionary tales.

Safety certification is the hardest wall. A safety function under IEC 61508 (and the process-industry IEC 61511) needs a certified execution path and a documented argument for systematic capability. A general-purpose Linux kernel plus a container runtime is a large, fast-moving codebase that is difficult to freeze and assess. This is why vendors ship a separate safety variant, such as the S7-1500V F with its TÜV assessment, rather than certifying the standard runtime. Do not conflate “the vendor has a virtual PLC” with “I can run my safety instrumented function in a container I built.” The mapping of safety integrity levels to architecture is covered in our IEC 61508 SIL and safety PLC architecture guide.

Figure 4: Where the safety function lives. Only a certified safety runtime may host it; otherwise it stays on a discrete safety PLC, with a black-channel protocol in both cases.

Figure 4 shows the placement decision. If a certified safety runtime exists for your target SIL and you accept the vendor’s conditions of use (specific hardware, configuration and kernel), the safety function can live there. Otherwise it stays on a discrete safety controller. Either path uses a black-channel protocol such as PROFIsafe or Fail Safe over EtherCAT, in which the safety layer treats the transport as untrusted and detects corruption, delay and repetition itself. That is why safety can ride on a converged network at all, and why TSN redundancy improves availability of safety without being part of the safety argument.

Consolidation concentrates risk. One server hosting eight former PLCs is one node whose failure, mis-patch or compromise stops eight machines. The mitigation is design, not hope: define failure domains, cap controllers per host, and refuse to co-locate controllers whose failure would create a hazard together.

Noisy neighbours are real. A logging container that suddenly flushes to disk, an analytics job that saturates the memory bus or a firmware power-state change can all inflate worst-case latency on a shared host even with core isolation, because last-level cache, memory bandwidth and interrupt routing are shared. Isolation of cores is not isolation of the machine. Test with the noisiest realistic neighbour running.

Liability is unsettled. When a sealed PLC misbehaves, the vendor owns the box from silicon to firmware. When control is a container you assembled on a kernel you patched, orchestrated by software you configured, root-cause analysis and contractual responsibility are murkier. Who owns the incident when a mistuned isolation mask let a housekeeping thread jitter the control loop? Write down ownership of the OS, runtime, orchestration and application before go-live, and get the vendor to state which configurations they support.

Time is a dependency. A virtual PLC that uses TSN depends on a grandmaster clock and 802.1AS synchronisation. Loss or drift of that clock can disturb scheduled traffic across the network. Monitor synchronisation offset as a first-class control-system metric and design a holdover behaviour.

Cultural inertia is rational. A controls engineer who has kept a line running for twenty years is right to distrust a stack that changes monthly. The fix is evidence: published latency histograms, fault-injection results, a rollback that has been rehearsed. It is not a slide deck.

Common anti-patterns:
– Running the control container with default bridge networking and assuming scheduled transmission survives.
– Using orchestrator restarts as redundancy for a sub-10-ms loop.
– Mixing real-time and best-effort containers on the same cores.
– Updating the kernel through the normal IT patch cycle without re-running the timing validation.
– Treating one successful week of testing as evidence of a worst case.

Practical Recommendations

Treat 2026 as the year to build competence and an evidence base, not to bet the line that makes the money. The technology is ready for the right workloads. Most organisations’ measurement practice, skills and support contracts 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 honour, a non-safety balance-of-plant function, or test and simulation environments where the benefit is faster iteration. Keep the safety function on a certified path, meaning a vendor-certified safety runtime with a named assessor or a discrete safety PLC. Let standard logic go soft first.

Choose the vendor path to match the loop. For tight motion, favour the vendor’s own real-time runtime on controlled hardware, as Beckhoff’s own positioning of the virtual PLC implies. For supervisory and batch-like control, a container fleet with orchestrated recovery is a strong fit. For multi-vendor plants, push toward OPC UA and IEC 61499 so portability is tested, not assumed. For the edge platform, our IIoT edge gateway architecture guide covers hardware and connectivity choices.

Pilot checklist:

• [ ] Pick a non-safety workload with a clear obsolescence or flexibility driver.
• [ ] Standardise a host image: PREEMPT_RT kernel, isolated cores, locked memory, fixed firmware settings.
• [ ] Give the control container direct NIC access and verify scheduled transmission with hardware timestamps.
• [ ] Measure latency for days with real neighbours running; record maximum and tail percentiles.
• [ ] Define a failover budget from actuator watchdogs and test it by pulling power on the primary.
• [ ] Use control-grade redundancy for the fast path and the orchestrator only for recovery.
• [ ] Keep the safety function on certified safety runtime or hardware; document the IEC 61508 argument.
• [ ] Segment under IEC 62443, sign and scan images, and own a patch-and-revalidate runbook.
• [ ] Write down who owns each layer during an incident.
• [ ] Keep a rollback to the legacy PLC for the first production months.

Frequently Asked Questions

What is a virtual PLC?

A virtual PLC is a programmable logic controller runtime delivered as software, often a container image or virtual machine, that executes standard control logic on a general-purpose industrial server instead of proprietary PLC hardware. It keeps the scan-cycle model but separates the application from the box, so hardware can be refreshed and instances consolidated. Examples include the Siemens SIMATIC S7-1500V, Beckhoff TwinCAT for Linux and CODESYS Virtual Control for Linux SL.

Can a virtual PLC be truly deterministic?

Within engineered bounds, yes. On a PREEMPT_RT kernel with isolated cores, real-time scheduling, locked memory and TSN scheduled transmission, a virtual PLC can hold worst-case latency well inside many control cycles. The guarantee is not free as in hardware: you must pin cores, give the container direct NIC access and measure the maximum under load. Vendors themselves position some virtual PLCs for lower real-time requirements, so check your loop against the product’s stated envelope.

Can a virtual PLC run safety functions?

Only through a certified path. Safety functions under IEC 61508 or IEC 61511 need a certified execution environment and a systematic-capability argument. Siemens offers a fail-safe variant, the S7-1500V F, which ARC reports is TÜV-assessed for SIL 3 or PL e use, and CODESYS has a safe virtual control product. A DIY Linux container is not such a path. Most designs keep safety on certified runtimes or discrete safety PLCs with a black-channel protocol.

Does Kubernetes work for real-time PLC control?

Not for the control cycle. Orchestrators handle placement, updates and recovery, which take seconds, while control redundancy must complete within a few cycles. Use vendor-provided hot-standby redundancy for the fast path and a lightweight Kubernetes distribution for deployment, rollout and restoring redundancy afterward. Kubernetes can also schedule real-time workloads onto prepared nodes with CPU pinning, but the timing proof still comes from measurement on that node.

What is the difference between IEC 61131-3 and IEC 61499?

IEC 61131-3 defines the cyclic, scan-based programming languages used in most PLCs. IEC 61499 defines an event-driven function block model with explicit deployment of blocks to distributed devices, which suits portable, multi-vendor applications. Virtual PLC runtimes may support either. Portability of the language does not guarantee portability of timing, diagnostics or I/O configuration, so test migration between runtimes during evaluation.

Is Linux real-time capable enough for industrial control?

Since PREEMPT_RT merged for Linux 6.12, real-time Linux is maintained in the mainline kernel. Properly tuned systems commonly reach worst-case scheduling latencies in the tens of microseconds on isolated cores, which suits many 1 ms cycles. Hard guarantees depend on firmware, hardware and workload, so validate each platform. The tightest motion loops are often still better served by dedicated real-time hardware or vendor real-time kernels.

Further Reading

• Codesys vs TwinCAT soft PLC comparison
• IEC 61499 vs IEC 61131-3 distributed control
• TSN time-aware shaper and gate control lists
• IEC 61508 functional safety and safety PLC architecture
• PROFINET vs EtherCAT vs OPC UA FX
• KuberneTSN: a deterministic overlay network for time-sensitive containerized environments (arXiv 2302.08398)
• Beckhoff: TwinCAT for Linux and virtual PLC press release
• Control Engineering: ExxonMobil Open Process Automation Lighthouse

By Riju — about