In five points, Bodo Broszeit summarizes the advantages (and also challenges) that OPC UA holds for the automation of the future. The Head of Electronics Development – System Architecture at KEB Automation is also a member of the OPC UA FLC (Field-Level Communication) working group, which deals with the specifications for OPC UA-capable field devices, as well as the OPC UA Motion working group, which handels the specification of drive systems.
The advantages of OPC UA in drive and automation technology
For manufacturers such as KEB Automation, OPC UA offers the opportunity to reduce the number of communication protocols to be maintained in the medium term. The products are used in a wide range of applications and currently support virtually all established fieldbus and real-time Ethernet communication protocols. This requires considerable effort both in development and in sales and service. OPC UA offers an – albeit resource-hungry – possibility for standardization here. In addition, its use in our controllers and drive controllers enables easy integration into multi-vendor systems and the possibility to offer own cloud services to the devices.
Multi-level and open specification concept
Building on the OPC UA specifications, various working groups of the OPC FLC initiative are defining extensions for the use of OPC UA in areas that were previously reserved for proprietary fieldbus systems. In addition, these working groups are also defining profiles for various components, such as drive controllers, IO’s, etc. Various Companion Specifications (CS) build on this. They are often developed in Joint Working Groups from OPC Foundation and other organizations, for example VDMA (German Engineering Federation). CS define information models for machines, devices or applications. This is a great advantage since product-specific know-how of the manufacturers or users can be included. The cooperation with the OPC Foundation ensures that already existing CS are considered. The “Powertrain System” CS, for example, describes a drive axle with the help of a flexible asset model. It contains properties of the components such as drive controller, motor, gearbox, EMC filter as well as a functional model that describes the behavior of the drive axle. This model specifies additional functionalities that go beyond the Motion Specification of the OPC Foundation.
Migration from current fieldbuses to OPC UA and TSN
OPC UA in combination with TSN (Time-Sensitive Networking) should enable the same or better performance than existing fieldbus systems. There are applications in which the technical advantages of OPC UA do not contribute significantly to the improvement, but the use of Ethernet technology and standard protocols results in a number of additional possibilities, especially when integrating into further networks. Applications that do not need this option or provide it via gateways will certainly continue to use proprietary fieldbus systems in some areas for a long time. With the introduction of OPC UA, such brown-field scenarios will be the rule. The conversion of all fieldbuses used in a system to OPC UA in one step is a rather unlikely scenario.
High requirements for the combination of OPC UA and TSN
Technically, OPC UA/TSN is certainly suitable for meeting hard real-time requirements. However, considerably more resources are required in the devices for this than with existing solutions. The transparent integration of simple and thus price-sensitive components in an OPC UA/TSN network is certainly still a challenge. However, it enables the simple coexistence of real-time and non-real-time applications in a network. The challenge lies in configuration and administration. OPC UA/TSN offers a high-performance, real-time communication system with many additional features, such as the integration of security, but also requires considerable know-how in the application.
Interoperability of different devices in IIoT applications
Existing solutions based on proprietary fieldbuses also offer the connection of devices to cloud applications. However, this usually requires a gateway that prepares the data for the IIoT application. If additional data is to be transmitted, this gateway must be programmed or configured again. This means an intervention in the system. With OPC UA – thanks to a continuous protocol family from the sensor to the cloud – cloud services can be used simply by authorizations on an existing system. This enables IIoT services independent of the details of the system. This is how we achieve a whole new level of interoperability. Not only can devices communicate with each other, but applications also understand the importance of data.