With the power of many cores: CODESYS Multicore on a welding system

Modern control systems are taking on more and more tasks. However, reliability and guaranteed real-time performance must not suffer as a result. The solution lies in powerful control systems with multi-core processors in which the various cores perform dedicated tasks. Thanks to a multi-core capable development environment for programmable logic controllers according to the IEC 61131-3 standard, implementation is now easy.

New generations of controllers increasingly include CPUs with two or more cores. By distributing the application across several cores, control manufacturers expect higher availability of the individual components, better real-time properties of independent execution threads, and better performance of the overall system. Symmetric multicore processors are typically used in these controllers, which have an identical core architecture and share resources such as main memory, interrupts, or I/Os. They also allow code to execute independently on each core. On the software end, synchronization and therefore the consistency of data and hardware access have to be guaranteed. Up until now, manufacturers of controllers with CODESYS runtime systems could only make this kind of distribution between the runtime system and possible additional software components. It has not been possible to distribute the CODESYS runtime system until now.

Problems

Therefore, it is almost impossible to talk about "multicore systems" here because the CODESYS runtime system constitutes the vast majority of the PLC functionality and also executes integrated add-on functions. Especially in the case of applications with a large share of visualizations, intensive motion or CNC calculations, or otherwise computationally intensive PLC tasks, the application engineers soon reached the load limits of the systems. MS Ultraschall Technologie GmbH, for example, measured well over 90% constant CPU load on its soniTOP ultrasonic welding systems. The TRsystem GmbHs controllers running on a real-time operating system with Intel x86 quad-core (1.9 GHz) are by no means weak. The consequences of this high load were a nearly inoperable graphical user interface, tasks with low priority that were almost no longer used, and shaky real-time communication via EtherCAT. For some time already, TRsystems and MS Ultraschall have been looking into the possibilities of leveraging all available cores. While one of four cores was working at full capacity, the other three cores were almost completely inactive. Thus, MS Ultraschall prepared the application for multicore operation, divided the various tasks of the soniTOP system into separable tasks, and ensured data consistency between these tasks. However, without the corresponding support of the CODESYS runtime system, no decisive advantages could be achieved here. At the same time, 3S-Smart Software Solutions worked for some time on a multicore integration into the CODESYS runtime system. Through the existing contact, the idea was conceived to include the controller used with the welding application in the field test for CODESYS Multicore support.

The CODESYS Multicore solution

The aim of CODESYS Multicore: A technically flawless solution that is easy to use and fully integrated into the CODESYS runtime and development system. As the runtime system and the application executed within are already capable of multitasking, this mechanism was used and extended with multicore processing. This now allows tasks to be organized into task groups, in which all tasks in a task group have the same distribution strategy. Distribution strategies include pinning to a dedicated core, sequential distribution across all available cores, and free distribution by the operating system. Configuration is performed in the task configurator, which allows for easy and fast organization of all IEC tasks by means of a tree view. If a task group is pinned to a core, then execution is always guaranteed on this core. In the context of this core, the tasks are executed according to their priorities. With sequential distribution of a task group, the runtime system assigns all tasks to be distributed in order to the available cores. If there are more tasks than cores, then it starts again from the beginning. For tasks that are organized in a task group for free distribution, the operating system is granted full responsibility for execution on any core. This may not sound very deterministic at first, but will subsequently prove to be a promising variant. Application engineers can view the corresponding evidence in the core monitoring of the device trace or in the online view of task monitoring.

Multicore support in the CODESYS runtime system primarily uses the conventional multicore functions provided by the operating systems for distribution, synchronization, and atomic data processing. These are abstracted using generic interfaces in the runtime system and thus provide the basis for platform-independent management of multicore operating systems and processors. In addition, the core management of the CODESYS runtime system is able to handle any number of cores – even a single core. As a result, CODESYS continues to guarantee platform independence, both for operating systems and CPUs. The switch from a multicore CPU to a single core and vice versa does not require any adaptations of the application.

For the field test, the runtime system of the TRsystems controller was first extended to include multicore support. As VxWorks, Linux, and Windows are among the CODESYS standard platforms, there was no additional implementation work. The multicore functionality could be verified correspondingly quickly and tested with small applications. In the next step, the ultrasonic welding application was tested in three phases and the results were compared. For this purpose, the IEC tasks of the application were initially divided into four task groups: one group for real-time tasks with motion and EtherCAT (1 ms task cycle time each), one group with a high¬priority application task (also 1 ms task cycle time), one group with low-priority tasks and longer task cycle times, and one task group for visualization.

Results

In addition to the explicitly configured tasks and task groups, the controller creates runtime system tasks for specific purposes automatically and implicitly, for example for communication via OPC UA or the display of visualization elements. Previously, these tasks were also restricted to one CPU, but now with the multicore solution they are distributed automatically to the available cores. This is why the IEC tasks were not yet distributed in the first phase of the test. The measurements in this phase should show the performance advantage that can be achieved by distributing runtime system tasks without changing the application. The load on the main core dropped sharply from over 90 % and stabilized at a solid 50 %. The previously unusable visualization was again responsive and could be operated smoothly, and the jitter of all tasks decreased significantly. Nevertheless, the task monitoring clearly showed that the cores could not be loaded evenly.

For the second phase, the IEC task groups were therefore distributed in such a way as the best overall performance had been calculated: Both task groups with the real-time tasks were pinned to different cores, while the group with the low-priority tasks and the visualization task were distributed freely. All tasks were assigned priorities in the real-time area. From this moment on, animations were also displayed smoothly in the visualization. The jitter in all tasks was then diminished significantly. In task monitoring alone, the cores on which the real-time tasks were executed could be identified. These had a slightly increased load in comparison with the other two cores.

The third phase therefore provided for all tasks to be distributed freely by the operating system, including motion and EtherCAT tasks. As a result, this strategy produced the best overall performance. Firstly, the cores were working between 10 and 30 % and therefore quite balanced. Secondly, there was another significant reduction in the jitter. The real-time tasks exhibited almost no measurable jitter anymore, even though they had to switch the cores and therefore the entire task context regularly. A long-term effect that can only be predicted on the basis of the previous observations: Due to the balanced utilization of the CPU cores, the controller is thermally less stressed and therefore more permanently available.

Conclusion

With multicore support, CODESYS provides device manufacturers and application engineers with a powerful tool for ensuring that applications are programmed correctly. With this tool, a totally new quality of automation applications will be possible. Machine learning, anomaly detection, and other computationally intensive operations can be solved with multicore at the PLC level, something that has previously been unthinkable or could only be implemented with severe restrictions. Device manufacturers and CODESYS end users are therefore well-prepared for the major Industry 4.0 challenges.

The article by Samuel Greising, Product Manager at the CODESYS Group, was published in the German A&D-Magazine 10/2018.

Download article (Original version: German): Multicore-Unterstützung für SPS