Today's common control systems are based on the hardware platform, the electronic substructure, although the software determines the function of the process. More recently, virtual control systems have also required hardware for execution. In contrast to software-based control systems, however, the hardware is now completely abstracted. This means that the executed soft PLC no longer needs to know which device it is running on.

These can still be dedicated control devices, such as multifunctional control platforms or industrial PCs, or edge computing platforms, which are becoming increasingly common in the control networks of machine and plant operators, or even cloud computing platforms. The decisive factor is the abstraction of the hardware using containers or hypervisors. The soft PLC is "deployed" on these using standard means or orchestrated using a tool - there is no need for installation as with software-based control.

In order to divide applications into fine-grained microservices, several instances can be created in parallel for different control tasks if required - scalable in terms of memory and CPU performance. A connection to physical fieldbus systems can be implemented via virtual LAN interfaces. The real-time behavior of the controller is implemented by containers or hypervisors in the adaptations to the operating system. The advantages over other controller types: a significant reduction in costs and effort for procurement, wiring, maintenance, rolling out applications and administration of the devices.

The most expensive space in a machine, the control cabinet, is no longer occupied by one or more controllers. Power supply units and their wiring are no longer required; instead of procuring and installing several controllers, it is sufficient to use an available IT platform in the network with virtual controllers and manage these centrally - and this is done by IT specialists instead of automation specialists. OT and IT are thus completely merged.

Everyone is familiar with virtual drives and virtualized computers. These images of physical devices, in this case hard disks or Windows PCs, help to use their functions without the devices actually being present. The images are created by software on powerful computer architectures. In IT, such virtualizations are useful for

• increase the data security of systems through sensible access limits
• enable independent configurations for different applications.

The same applies to virtual control systems: First of all, powerful hardware is required as a substructure. Even if the PLC is abstracted, it must be hosted and executed somewhere. In this respect, the virtual PLC is initially no different from an industrial computer with an operating system and a soft PLC installed on it. However, in order to be able to operate any number of such virtual controllers independently of each other on a piece of hardware, a further abstraction must be made.

Software containers or hypervisors are suitable for this purpose. They separate the hardware and the operating system running on it. Before creating a container or virtual machine, the user defines its functionality and performance in container descriptions, including the corresponding configuration for the SoftPLC, e.g. Codesys Virtual Control SL. The hardware resources that the container can access are also defined. This is essential in order to be able to implement I/O accesses from the controller.

Ethernet-based communication protocols and fieldbus systems are particularly suitable for this. This allows virtual LAN ports to be defined in the container, which are linked to physical ports in the container description. Thanks to hardware-supported virtualization, this is possible with high performance on modern systems. This means that better real-time values can be achieved than with soft PLCs that run natively on the host system thanks to better process delimitation and hardware support.

Deployment

If the configuration file is available, any number of virtual controllers can be created from it, i.e. "deployed". In contrast to the soft PLC, however, a complete image of a physical component is created rather than software being installed. This can be done in different ways:

By manually executing functions of the operating system or virtualization platform, such as Docker Container - this is an approach that gives system administrators in particular complete freedom during deployment. These functions can also be summarized as scripts and thus simplified considerably.

• Generic software platforms such as Kubernetes or Open Shift, which enable automated configuration, management and coordination of computer systems, applications and services - orchestration for short - are available as products and offer the option of introducing usage-based billing models (platform as a service) for the virtual control systems created in this way.
  
• Through proprietary platforms with additional benefits for automation technology, such as the Codesys Automation Server - even if the function for deploying the virtual PLC in Codesys' own Industry 4.0 platform is currently still under development, it is still suitable for this purpose. This is because, in addition to the deployment of virtual controllers, a number of typical tasks for automation engineers can be carried out even more conveniently.

In the PLC programming system, the controllers created in this way are displayed in exactly the same way as any dedicated, physically available PLC. This means that as soon as the desired device description has been set in a PLC project, the user can search for suitable systems in the network. However, there are two differences to the dedicated controller:

Figure 2: Deployment of three virtual controllers and a gateway via Linux script.

© Codesys

• By embedding the PLC in a container or hypervisor, it is also encapsulated from the outside. In the case of Codesys, this means that the local gateway as a communication service between the configuration PC and the PLC finds all controllers in the network. However, if hardware is connected on which virtual PLCs are running per container or virtual machine, these controllers will not be found. "It's not a bug - it's a feature": Unwanted, unauthorized access is excluded from the outset. Access is only enabled once a gateway has been deployed alongside the containers with the virtual controllers. Instead of the local gateway, this remote gateway is then selected on the configuration PC for access to the target system platform - either via its IP address or host name.
  
• Hardware-specific properties must be addressed generically, especially when it comes to industrial devices that have local I/Os, for example. These generic interfaces must be addressed separately from the process.

These were the differences. As before, all available virtual controllers are found with the device search. The Codesys Development System does not care for which controller is currently being programmed or configured. If virtual Ethernet ports have been created in the configuration file or connected to physically available ports, they can also be integrated in the Codesys project and configured and used as Ethercat, Profinet or EtherNet/IP, for example. The container/hypervisor loops through these virtual ports and ensures deterministic execution of the bus cycles - just like a "real" PLC.