The process in detail

Screenshot of Codesys Development System with SIL3 application (right) on a virtual safety controller (left in the tree).

© Codesys

The following questions arise when considering the procedure:

Question 1: Why is this process only being used now if it has been known for a long time?
In fact, the first products with coded processing were released at the beginning of the 2000s. However, they have not gained widespread acceptance. The computationally intensive algorithms from this time led to a runtime extension of up to 1000 times! Code generated in this way, executed on the then current CPUs, was simply unusable for real applications. Today, not only are the processors considerably more powerful, but the software algorithms behind coded processing have also been fundamentally optimized. The application code generated by coded processing, together with the necessary diagnostic functions, is now only 5 to 15 times slower than the purely functional code. At the same time, the synchronization points and CPU and memory tests required for discrete safety controllers, which significantly reduce the load on the CPU, are no longer necessary. In view of the performance of modern processors, nothing stands in the way of the use of soft safety solutions in industrial applications.

Screenshot of a visualization interface with measurement results from four virtual safety controllers and different I/O systems.

© Codesys

Question 2: How can coded processing be combined with virtual controllers?
Instead of using redundant hardware to create two channels as before, the possibilities of virtualization are now available: Both channels now no longer run in parallel on separate physical systems, but sequentially in a virtualized machine, for example in a container or hypervisor. One of the two channels is transformed and executed using coded processing. Diversified encoding is used to compare the results before and after execution. This provides the user with an equivalent solution to that known from physical security control systems. But now with the huge advantage of no longer being tied to dedicated hardware. They can even set up functionally safe control systems as often as they like or in fine granularity and run them on the platforms that are available to them - be it industrial hardware in the control cabinet or IT hardware somewhere in the server room. As already described in the second part of the article series, I/Os can be addressed in real time via virtualized LAN ports. This also applies to Industrial Ethernet protocols with approval for safety-critical applications, such as FSoE (Fail Safe over EtherCAT) or PROFIsafe (F-Host / F-Client).

Roland Wagner is Head of Product Marketing at Codesys.

© Codesys

Question 3: How can users benefit from this?
Using Codesys as an example, the question can be answered as follows: The user deploys or orchestrates their controller on the available hardware and decides whether functionally safe applications should run. If this is the case, a second parallel container is created when the virtual controller is deployed. The application in the safety container is also processed using coded processing. The coded and the original application monitor each other during operation and can immediately assume the safe state if errors are detected. The user uses one and the same tool for project planning: the Codesys Development System. To configure the safe application, he uses the certified add-on modules, which extend the purely functional part. They enable the user to program in the safe IEC 61131-3 editor and download the application code with approved procedures to the virtual safety controller. He only notices that these are virtualized devices when connecting the safety I/O modules in the application. Of course, the configuration of a safety application is in principle more complex than the purely functional part - physical and virtual safety controllers do not differ in this respect. However, there are considerable differences when it comes to installation, maintenance, updates and other aspects.

The orchestration of the virtual controller is identical for the functional or safety application - there are only economic aspects in terms of license costs. The important thing is that the user can prepare for the safety acceptance of his machine or system with a virtualized safety PLC in exactly the same way as he would have done with dedicated devices. With the patented process from SIListra Systems in the virtual safety controller 'Codesys Virtual Safe Control SL', the entire system is approved in accordance with the Machinery Directive as usual, although certified safety hardware is no longer required. The abstraction of the safety controller is therefore the logical next step. Device manufacturers and users alike benefit from this. By integrating the technology, they can now implement safety control systems without a two-channel hardware structure. All they need to provide in order to implement a safety PLC is a suitable computer architecture with industrial properties as well as hardware abstraction via a container and an optional underlying hypervisor. The reduction in effort and costs benefits everyone. Of course, such virtualized control systems will not replace all previous control architectures. But machine and plant manufacturers and, above all, the operators of such systems are given additional degrees of freedom with such a virtual
additional degrees of freedom with such a virtual safety controller.

The voice of the user

Virtual control was the main topic of discussion between users and manufacturers at the one-day Techday 2023.

© Codesys

The virtual PLC was the prominent topic at the Codesys Technology Day on May 10 in Kempten. Keynote speaker Dr. Henning Löser from the Audi Production Lab formulated his vision right at the beginning in front of 500 visitors: "I would like all hardware to disappear from the store floor. I would like to have functionality on site... and functionality is software." To illustrate this, he posed the question: "How are we supposed to manage 15,000 Windows PC changeovers in our plants if this has to be done during a 20-minute shift break?" Looking at the data centers, he says: "The problem is solved differently there than it has been for us in the factory so far." He therefore believes it is important to separate software applications from hardware in the future, with the major advantage that "all applications can then be provided with the same hardware 100 percent of the time." Löser is not sure whether these applications will all be able to run in the cloud in the future: "We have a complete time spectrum of 8 ms from controller to robot and back," he says. Audi is therefore initially planning to establish edge landscapes within the respective factory. A newly established internal department - EC4P (Edge Cloud For Production) - is to drive this project forward.

In the next block of presentations, the audience was able to see live that Codesys already has something up its sleeve to meet these customer requirements: Codesys Virtual Control SL, orchestrated and administered from the Industry 4.0 platform Automation Server. The product managers presented the current performance data using a demonstrator with Profinet and EtherCAT modules. For the first time, they also showed the development status of the virtual safety controller and explained how a two-channel version is possible without a hardware connection. Another premiere was the presentation of Codesys Go!, a new IEC 61131-3 development interface with operation in the browser, hosted on servers, PCs or even dedicated control hardware.

Codesys advertising in transition