Virtual PLCs: From Evolution to Standardization

According to IEC 61131-1 (2003) [IEC 61131-1–Programmable Controllers–Part 1: General information, 2003], the intended use/function of a programmable logic controller (PLC) is signal processing, specifically for controlling and commanding machines and industrial processes. PLCs are typically associated with/connected to peripherals such as sensors and actuators via inputs and outputs (I/Os), human-machine interfaces (HMIs) and programming and debugging tools (PADTs). The functionality of a PLC is executed on specific hardware and software platforms, personal computers with industrial environment features or general-purpose computers.

It is important to note that PLC functionality and PLC hardware/software are different categories.
Traditional or hard/classical PLCs represent the foundational stage in PLC evolution, often just called PLCs. These systems are typically compact or modular devices featuring specific and proprietary hardware and sensor/actuator interfaces (inputs, outputs). The runtime (RT) for signal/data processing is closely integrated into the hardware, with internal communication systems most often being proprietary (Figure 1). PLCs provide real-time behavior as necessary, primarily operating in a cyclic mode with cycle times as short as 1ms.

The PADTs for PLCs often feature simulators without I/O connections for testing and demonstration purposes, if necessary with a digital twin of the machine/process. These simulators are neither intended nor capable to run a real-world system.

Remote I/O

The next step in PLC evolution is the development of remote I/O (RIO) (Figure 2). Here, the sensor/actuator interfaces are separated to cover longer distances (as required in process industries), handle more signals within available space (critical in manufacturing industries) and save resources.

A crucial prerequisite for this development is the implementation of external real-time communication systems such as fieldbus or industrial Ethernet systems. These systems must be standardized to enable multivendor systems with now shared responsibilities among various vendors. Additionally, the coupling of engineering processes (e.g., using device descriptions) is required.

Soft PLCs

Soft PLCs represent a further advance in PLC evolution. Here, the runtime is separated from the hardware (Figure 3). Technically, the runtime can be deployed on various hardware (lines) of a single vendor. Commercially, it can be shared by multiple vendors.

To achieve this flexibility, soft PLCs must be:

• Adapted to different processor platforms such as x86, ARM, PowerPC, etc.
• Ported to various host operating systems such as Linux, Windows, VxWorks, QNX or none.
• Scalable in terms of performance, functionality, memory and interfaces.

A soft PLC running on different hardware is supported by shared PADTs with none, small or more adaptations. The use of common programming languages, as standardized in IEC 61131-3 [IEC 61131-1 – Programmable Controllers–Part 3: Programming languages, 2025], is a necessary foundation for this technology.
Both remote I/O and soft PLCs have been in parallel development since the 1990s. With their advent, an increasing number of automation devices are incorporating PLC functionality, including industrial PCs, operator panels (Figure 4), remote I/O, drive/robot/CNC controllers and more.

Virtual PLCs

The next major advance in PLC technology is the development of virtual PLCs (vPLCs). In this architecture, the runtime environment is locally separated, while physical inputs and outputs remain on the shop floor. This transition occurs progressively, beginning with onsite servers (Figure 5), advancing to private cloud servers and eventually extending to public cloud servers in future.

Optionally, hard and soft real-time functionalities can be separated, with critical functions such as motion control remaining on the shop floor. New business models are emerging, including “PLC-as-a-service” and “control-as-a-service.”

 Virtual PLCs are implemented using container or hypervisor technologies. A container provides an “Isolated execution environment for running software that uses a virtualized operating system kernel.” A hypervisor or virtual machine monitor is “computer software that creates and runs one or more virtual machines.” Hypervisors can be bare metal, running directly on hardware for greater efficiency, or hosted by an operating system for reduced hardware dependency. These implementations can achieve real-time performance.

The introduction of vPLCs is expected to bring several advantages, including:

• Greater flexibility for application development
• Reduced hardware costs through decreased variety and quantity
• Lower maintenance, update, security and energy consumption expenses
• Enhanced scalability over the machine/plant lifecycle
• Centralized and potentially remote digitalized management.

In addition, vPLCs contribute to an overall virtualization trend in industrial automation (cloud-based). This also includes the PADTs.

However, significant challenges remain. A major issue stems from the even more distributed nature of responsibilities among multiple stakeholders, including network equipment vendors, telecommunication providers, container/hypervisor developers and cloud service providers. Questions arise regarding accountability when vPLCs fail to perform as designed: Who will address production stoppages, and who will bear the financial losses?

Additional concerns include whether companies outside the industrial automation sector can guarantee the stringent requirements of a relatively small market, given their more dynamic technology and product development cycles, as well as their organizational structures. While not a new challenge, it remains a critical consideration.

by automation.com