How vPLCs Are Changing Industrial Control Systems

Breaking the Cycle of Proprietary Vendor Lock-In

Source: Pichcan/stock.adobe.com, generated by AI

Published June 4, 2026

Most programmable logic controllers (PLCs) in industrial automation are proprietary, with tightly coupled hardware and software and a vendor-specific ecosystem. The proprietary nature of PLCs creates challenges for data integration, leading to siloed systems that conflict with the modern need for flexible, interoperable manufacturing systems. These constraints result in operational bottlenecks that hinder the implementation of modular production and plant-wide optimization strategies.

The industry is responding to these constraints by moving toward software-defined automation (SDA), in which the automation logic—including control, motion, safety, and visualization functions—is no longer tied to specific proprietary hardware. Instead, it runs as a portable software workload in a virtual machine or a container. The core principle of SDA is to treat the control logic as code.

The most practical implementation of this SDA approach is the virtual PLC (vPLC). This software-based control runtime executes in a virtualized environment on commercial-off-the-shelf (COTS) computing hardware. Whereas before we examined the PLC selection criteria designers consider when developing automation control systems, this final blog of our PLC series zeroes in on the advantages of choosing the virtual route. Overall, the shift toward virtualized environments aims to eliminate vendor lock-in, enabling scalability and facilitating the easy integration of logic control systems with an enterprise-level data platform.

Understanding the vPLC Runtime

At the core of a vPLC is its runtime engine. This software application is responsible for parsing and executing control logic programs written in languages compliant with the IEC 61131-3 standard. Adhering to this standard improves portability at the language level. However, practical portability across vendors still depends on exchange formats, libraries, toolchains, and runtime-specific features.

One of the key characteristics of conventional PLCs is deterministic, cyclic behavior. The vPLC runtime relies heavily on the scheduling, interrupt handling, and memory management capabilities of its host operating system (OS) to replicate this. For deterministic control, a vPLC relies on a real-time-capable host environment, such as a real-time operating system (RTOS) or Linux OS with real-time extensions and tuning. The priority-based preemptive scheduler within the RTOS is designed to ensure that high-priority, time-critical tasks, such as the vPLC’s control loop, are executed precisely within their specific deadlines.

Managing memory is also important for reducing latency. Converting memory addresses between the guest OS running the vPLC and the physical hardware introduces potential overhead. To solve this, vPLC host systems use hardware-assisted virtualization features built into modern central processing units (CPUs), such as Intel^® Extended Page Tables (EPT) or AMD Rapid Virtualization Indexing (RVI).

While the execution model of the vPLC is designed to mimic the predictable behavior of a traditional PLC’s scan cycle, it does so through a different mechanism. vPLCs realize cyclic behavior through software scheduling. The control runtime executes as a high-priority, periodic task managed by a real-time capable host operating system. This scheduler is responsible for invoking the control task at defined intervals to maintain deterministic execution.

At each scheduled execution, the vPLC performs a single logic scan; reads current process input/output (I/O) from a fieldbus, networked I/O, or other interfaces; executes the control logic; and writes outputs back through those interfaces. After completing its cycle, the task goes back to sleep until the scheduler wakes it for the next interval.

Deployment Architectures for SDA

The practical implementation of SDA depends on the choice of virtualization technology and the strategy for deploying workloads. Two common approaches for deployment utilize hypervisor stacks and containerization.

Hypervisor-Based Deployment

Hypervisor-based deployment is a mature technology that involves a software layer (i.e., the hypervisor) creating and managing one or more completely separate virtual machines (VMs) on a single physical server. Industrial applications commonly use server-grade hypervisor stacks, such as VMware ESXi or kernel-based virtual machine (KVM) platforms configured for real-time operations. These stacks run directly on the server’s hardware, reducing performance overhead compared to Type 2 hypervisors that run on top of a host operating system.

The architectural benefit of the hypervisor model is its strong isolation. The hypervisor abstracts the physical hardware and provides a virtualized set of hardware to each guest VM. Each VM then runs its own independent guest operating system. This allows multiple, disparate operating systems to run securely and concurrently on the same physical machine.

Container-Based Deployment

Containerization is a more lightweight form of OS-level virtualization. Instead of virtualizing the entire hardware stack, containers run as isolated user-space processes that share the single operating system kernel of their host machine. A container engine uses features within the Linux kernel to create the sandboxed container environment.

The advantage of this approach is efficiency. Because container images do not require a guest OS, they are much smaller than VM images. Therefore, their memory consumption is lower, and they can be started almost instantaneously. This allows a much higher workload density to be deployed on a given piece of hardware and enables rapid, agile deployment of workloads in line with modern DevOps practices.

This software-based deployment model also makes automation logic easier to manage by using common software development practices. When control applications are deployed as software workloads, engineering teams can store logic in version-control systems, test changes in virtualized environments, and promote validated updates across development and production systems.

While industrial control still requires strict validation, safety checks, and deterministic performance, this approach enables the application of Continuous Integration and Continuous Deployment (CI/CD)-inspired workflows to automation systems.

Conclusion

The shift to software-defined automation is setting the stage for a future where factory floors are highly scalable and manageable. The most significant long-term impact of this approach will be the adoption of DevOps methodologies in the industrial automation domain. By treating control logic as version-controlled software, manufacturers can adopt workflows rooted in CI/CD for testing, tracking, and deploying validated changes more consistently.

Finally, as control runtimes become increasingly standardized, software packages compliant with open standards such as IEC 61499 and running on COTS hardware will bring the vision of vendor independence closer to reality. Achieving this vision could finally break the cycle of proprietary vendor lock-in that has constrained the industry for decades.