In September 2016, a group of the world’s largest automation companies announced an initiative at SPS for the standardization of OPC UA over TSN as a universal, vendor-independent industrial communication platform. From the onset the goals of full interoperability and convergence for industrial automation components and data access “from sensor to cloud” were clear.

However, large parts of the technology were new and not yet proven in industrial use, industrial standards needed to be created to achieve openness and interoperability, and major obstacles to technical realization were expected by some skeptical voices.

In this article, we will look at the situation today and see how users of the technology who are currently integrating and evaluating OPC UA over TSN for their automation components and systems fared with respect to these concerns.

Users of OPC UA over TSN

As a supplier of the core technology elements, TTTech Industrial is working with automation component manufacturers that are integrating TSN capabilities into their products. We are also discussing benefits, developing prototypes, and evaluating functionality and performance of OPC UA over TSN with potential end users who want to prepare for the introduction of the technology into their systems and get a better understanding of the implications, capabilities and possible pitfalls.

This has given us insight not only into requirements and upcoming use cases for this technology, but also into the practical issues that potential users of this technology have encountered, and will encounter, when getting hands-on with OPC UA over TSN products.

Depending on the position of their product in the automation system hierarchy, companies need very different building blocks and steps for integrating and utilizing these technologies.

Chip makers adding TSN capabilities to their switch chips or NIC components can integrate TSN features into their FPGAs and ASICs for use in standalone switches or switched endpoints. There are also some TSN-enabled endpoint chips such as the Intel i225.

Device manufacturers developing TSN enabled industrial switches and endpoints using either dedicated ASICs or an FPGA-based solution for TSN networking, as well as software stacks implementing various Ethernet and TSN related protocols and functions such as synchronization and configuration. For OPC UA, embedded stacks are available from several vendors and open source initiatives.

System integrators building entire systems such as machines or production cells can most clearly see the benefits of OPC UA over TSN, as they are particularly evident on the system level.

The controllers and devices used to build the system must include the hardware and software components to enable the use of OPC UA over TSN on the system level, and the system integrator needs configuration and testing capabilities for OPC UA over TSN.

In this article, we are contrasting the expectations and doubts that accompanied the initial steps to develop OPC UA over TSN as an industry-wide standard for communication with the experiences and feedback regarding OPC UA over TSN prototypes for machine-to-machine use cases. These experiences result from concrete evaluations and integration of solutions by technical specialists together with customers during the past year.

This provides a ‘snapshot’ which shows which steps are typically taken to evaluate current state-of-the-art building blocks for this technology, how relevant some of the initial concerns were and if they have been resolved, which expectations were met, and where more development is needed. It also shows how different use cases can drive and adopt the same technology with very different focus and speed.

When we discuss various issues that early adopters encountered with this technology, we will try to separate what is inherent in the technology e.g. resource consumption of software stacks, from what is related to product design e.g. user interfaces of configuration tools.

Feedback from early customers allows vendors to improve their products with respect to functionality, performance, and usability, while constraints and issues relating to the technology itself should not be resolved by vendors in a proprietary way and instead need to be addressed by industry standards. The ongoing TSN work on configuration enhancements (IEEE 802.1Qdj) is an example for this.

Evaluating TSN separately from OPC UA

To fully experience the benefits of vendor-independent interoperability and IoT connectivity from sensor to cloud requires that OPC UA and TSN are used in combination, but this is not a hard technical requirement and the two technologies offer independent functionality.

Many companies interested in the combination of OPC UA and TSN have prior experience with OPC UA Client/Server, and therefore several evaluation projects specifically focus on TSN to find out how the networking hardware is impacted and how the TSN software stack interacts with the hardware and the operating system.

Many of the integration and evaluation projects we have supported fall into this category. The application layer in such projects sometimes consists of existing OPC UA applications, showing (not surprisingly) that an incremental approach to the introduction of OPC UA over TSN is possible. More often the application layer is simple benchmarking and measurement code to evaluate and analyze performance, latency, and other relevant properties of the TSN subsystem.

Readiness of the standards

The number of standards related to OPC UA over TSN is growing, with the aim of using the technology to address use cases for interoperability in specific applications such as the plastics industry standard EUROMAP 79, or the OPAS standard for process automation.

Any companion specification defining not only OPC UA data models for Client/Server but also the use of the OPC UA Publish/Subscribe mechanism can utilize the combination with TSN. Our customers’ primary concerns were about TSN standards and their potential impact on networking hardware design.

The IEEE/IEC 60802 standard defines which of the many capabilities standardized by the IEEE TSN working group should be mandatory for TSN use in industrial automation, and how these capabilities should be utilized to achieve interoperability as well as configurability. There is a compact set of required TSN capabilities for industrial automation components: network-wide synchronization service (IEEE 802.1AS-2020), mechanisms required to achieve deterministic communication latency (known as IEEE 802.1Qbv) and frame preemption (known as IEEE 802.3br/802.1bu).

The configuration services are currently extended (IEEE 802.1Qdj) and will also be part of the reference set of capabilities. TSN network redundancy capabilities (IEEE 802.1CB) are currently considered optional and will likely not be mandatory for TSN components in industrial automation, although at least some products already today support this standard and customers are beginning to evaluate these capabilities for increased network resiliency.

Although some elements of these standards are still ongoing, several chip makers have already created TSN switch components suitable for OPC UA over TSN. Sufficient progress was made concerning the capabilities related to OPC UA and TSN on hardware to provide improved latency and more determinism in networks used for real-time applications with OPC UA PubSub (and other real-time protocols, industrial or other) in combination with regular non real-time traffic such as for OPC UA Client/Server.
The resulting FPGAs and ASICs are one essential building block for the subsequent evaluations of the technology.

Benchmarking OPC UA & TSN stacks

Another important concern was and is whether OPC UA over TSN solutions require substantially more resources – mainly concerning RAM and CPU utilization – on embedded devices compared to other industrial networking technologies. Here we observed that the resource consumption of OPC UA and TSN on embedded devices in an automation system varies a lot with the amount of application functionality required by the customer for networking on the specific device.

Devices with a simple static application can be implemented with a very resource-efficient profile of OPC UA and TSN functionality. Devices that need to provide more functionality and flexibility and generally have a more demanding role in the system architecture require substantially more resources for OPC UA and TSN.

The reason for this is that there are two main storylines for OPC UA over TSN in industrial automation, the C2C (controller-to-controller or machine-to-machine) and C2D (controller-to-device) use cases.

As of today, most of the integrations and evaluations for OPC UA over TSN are focused on the C2C use case. Controllers already run operating systems where many shared libraries and existing functionality can be re-used by the TSN network stack.

Still, the full networking protocol suite has substantial memory demands. On 64-bit architectures running Linux, the average additional RAM usage for Ethernet/TSN networking on switches and switched endpoints was four to five megabytes for a NETCONF server, network clock synchronization, and networking protocols required for dynamic Ethernet/TSN operation such as LLDP and MSTP.

Similar observations have been made for other embedded operating systems. The OPC UA server’s memory requirements depend on the chosen server profile and the size of the information model needed for the application. As a reference point, the frequently evaluated open62541 stack supporting the “micro embedded” server profile adds less than 100 kilobytes for very small information models.

The RAM usage then increases linearly with the amount of data elements managed, and experiments show that with one megabyte of additional RAM several hundred data elements used for Client/Server and Publish/Subscribe access can be managed in an OPC UA stack.

CPU load for TSN networking was found to be low – for a typical setup of the synchronization protocol, less than one percent of an embedded 800 MHz CPU core is utilized. In a case where an existing SNMP stack was replaced with NETCONF, the CPU utilization allocated by networking functions has even been observed to decrease.

To sum up, the resource consumption by the full OPC UA and TSN feature set can be accommodated in typical controllers of C2C use cases, such as industrial edge servers, IPCs, and high-performance PLCs. For resource-constrained PLCs and field devices in C2D use cases this might be different. But that is not necessarily an obstacle for using the technology.

Most applications using TSN only require regular Ethernet plus clock synchronization on endpoint devices without switching functionality, and OPC UA information models will be smaller.

Easy to configure and use

The goal of deterministic application-level end-to-end communication with OPC UA over TSN is currently defined only for the Publish/Subscribe functionality when using the UADP mapping to the Ethernet/TSN driver and requires appropriate configuration of the TSN network to provide guaranteed latency for the PubSub network streams.

All other OPC UA communication over TSN capable networks is intended to use TCP/IP communication over regular Ethernet mechanisms which are provided by TSN networks as well. This is in line with the use cases defined by the various consortia and with the users’ expectations of the technology.

Users expect the benefits of network convergence i.e. using deterministic traffic with regular traffic on a single network infrastructure, on the same wire, even in the same network interface. However, network convergence should not require dedicated network configuration for regular traffic, it should be easy to implement, and it should be fully transparent to deterministic traffic. In addition, creating and running OPC UA applications on TSN networks should require no expert knowledge in Ethernet and TSN mechanisms from the end user.
In this area we observed very different experiences for different customers. Some configured their system with TSN configuration tools and mechanisms adhering to the official TSN standards for configuration of network components and experienced little or no issues. However, this approach requires the full TSN networking software stack (notably NETCONF) on the network elements.

Others need to or prefer to integrate the configuration capabilities into their existing configuration management system, which was found to be challenging because the TSN configuration elements needed for deterministic communication (scheduling) are different than other Ethernet QoS features.

Nevertheless, both paths – the IEEE standards for configuration, and the integration with vendor-specific configuration – are observed in evaluations, which makes it interesting to see just how well vendor-independent configuration of complex systems based on OPC UA and TSN will work for dedicated TSN network configuration mechanisms.

Here, the outlook is important. The intended solution for full integration of OPC UA PubSub with TSN, which lets the Publisher and Subscriber applications configure the TSN network automatically by means of a broker architecture, has not yet been finished in standardization.

Once it is available, the configuration of the TSN network streams for deterministic C2C (and C2D) communication between OPC UA PubSub endpoints will be transparent to the application developer and integrator and not require dedicated separate TSN network configuration mechanisms to be used by the integrator.

This capability, so far only shown in demonstration systems, is the important next step in the development of mature solutions.

OPC UA over TSN suppliers

The biggest benefits of OPC UA over TSN come from interoperability and convergence on the system level and therefore are most attractive to the OEM or system integrator. However, it is their component suppliers who must integrate and support the technology in their devices, and those companies have less incentive to do so, especially if their current products – without OPC UA and TSN – are functionally adequate.

This creates a “pull” situation, where the end customers in a field team up and jointly require that the technology becomes standard for the components.

Such requirements can be found e.g. in the upcoming EUROMAP 79 standard for the interface between injection molding machines and handling robots, or in the OPAS OCF (Open Connectivity Framework) which describes the open communication interfaces for process automation components such as DCS and MES. Component suppliers who are interested in supporting this kind of standard are faced with a double challenge: They have to not only integrate OPC UA and TSN as platform technologies for communication, but – and this may be the bigger challenge – also the application interfaces and functionalities defined by these standards.

For example, the OPC UA Motion Working Group defines a vendor-independent model for configuration and interaction of controllers and devices in the area of industrial motion control. For motion-control-specific functions in these devices, OPC UA over TSN is defined as the underlying communication technology, as it provides real-time capabilities, precise synchronization and very short latencies.

Conclusions

TTTech Industrial has supported and continues to support multiple integration and evaluation projects of the OPC UA and TSN technologies, mostly targeting C2C use cases by component suppliers and system integrators who need to understand how their existing products or solutions will be impacted.

In these cases, the biggest change required to support OPC UA over TSN is the introduction of switched endpoint nodes that combine controller and network switch functionalities. The necessary building blocks to add to the hardware and software stacks of automation components are already available and have successfully been evaluated in the field in various configurations and combinations.

OPC UA over TSN is still a relatively young technology, but it has been established as a common, open, interoperable platform for industrial automation communication from sensor to cloud. It has also proven itself in first use cases, showing that the technology can be applied successfully. Based on the experience gained from project implementation and customer use cases, TTTech Industrial offers OPC UA over TSN products that allow customers to quickly develop components and easily set-up networks.

Georg Stöger, Director Technical Presales and Training, TTTech Industrial.