Industrial communication technology is characterized by a variety of fieldbuses that have little in common apart from real-time capability. The lack of interoperability with each other and especially with IT has developed from an accepted annoyance to a significant obstacle to the digitalization of production. For a long time, IEEE Ethernet was not an alternative due to its lack of determinism.

This changed fundamentally with the founding of the Time-Sensitive Networking Task Group, which extended the quality of service mechanisms of Ethernet with deterministic guarantees by means of new sub-standards. Accordingly, TSN is not a new technology, but the next evolutionary stage of Ethernet. As a result, comparing TSN with fieldbuses, which represent a complete ecosystem, only makes limited sense.

Figure 2: Relevant aspects of the TSN ecosystem

© ISW

- Multi-technology communication (convergence of technologies): TSN covers local networks, while other technologies such as 5G, Wi-Fi 6 or DetNet are used for wireless connections or wide-area networks. The combination of these technologies enables innovative applications and topologies, whereby a TSN network usually exists from an endpoint perspective.

When discussing TSN in an industrial context, it therefore always makes sense to not only talk about the standards themselves, but to consider the entire ecosystem. Figure 2 provides an overview of the relevant aspects. These are examined in more detail below and current developments are discussed.

The TSN standards

TSN is a series of new sub-standards and extensions to the IEEE Ethernet standards in 802.1. New functions for time synchronization, data traffic control, increased reliability and configuration are introduced as the basis for deterministic communication. For data traffic, both the concept of data classes (traffic classes) and streams are used, which can be realized by using the TSN mechanisms with corresponding deterministic guarantees.

The individual standards are at different stages of development. Some are already available, some are under development and others have so far only been recognized as gaps. Continuous further development is typical of Ethernet and, thanks to the modular structure, many TSN-based solutions can already be developed and used today. Compatibility with Ethernet without TSN functions enables seamless integration and the use of connectivity in classic IT systems.

Time synchronization is a core function of TSN and is based on the Precision Time Protocol (PTP) known from IEEE 1588. The corresponding Ethernet standard IEEE 802.1AS was updated as part of TSN and is now available in version 2020. New functions such as support for multiple time domains have been integrated.

The standards for controlling data traffic, in particular the time-slot-based method standardized in IEEE 802.1Qbv or the credit-base shaper in IEEE 802.1Qav, have been available and stable for some time. The standards for redundancy and frame preemption are also stable.

Standardization activities are currently focusing on the configuration and the data models required for this as well as the use of TSN for various application domains.

The use of TSN

The functions standardized as part of TSN form the basis of deterministic communication. However, how these are used in detail and in what combination is neither obvious nor unambiguous. Rather, there are a variety of options for achieving similar results, whereby the optimum solution can vary greatly depending on the application. In order to achieve a certain level of interoperability at least within individual domains - from usability of the hardware to interoperability at application level - various profiles are currently being developed.

For industry, the dual-logo standard IEC/IEEE 60802 TSN Profile for Industrial Automation is of the greatest relevance. Profiles are also being standardized for other sectors, for example 802.1DG for the automotive sector and 802.1DP for aviation. The profiles specify, for example, details on the use of certain functions, accuracies and other parameters.

The topic of cross-industry interoperability is still the subject of much controversy. The Avnu Alliance, for example, is working on solutions here.

Protocols of the higher layers

As TSN only covers layers 1 and 2 of the OSI model, protocol solutions are always required for the upper layers. These are increasingly application-specific as the layer increases. The protocols previously used with Ethernet, in particular those familiar from the IT environment such as TCP/IP, can continue to be used - potentially now with real-time capability.

Two trends dominate in the industrial environment: Fieldbus-over-TSN and the goal of a standardized solution down to the application level, which is being pursued as part of OPC UA FLC.

- Fieldbus-over-TSN, such as Profinet or CC-Link, preserve established ecosystems, but offer very different levels of interoperability. New solutions were published and launched on the market last year.

- OPC UA FLC: The idea of a standardized solution up to the application layer is being pursued by a large number of key players in the automation industry in the context of the OPC Foundation's FLC activities. The first non-real-time results were presented last year, and more are expected to follow soon. OPC UA's PubSub communication serves as the basis for FLC activities. Important steps were taken last year with regard to mapping to TSN, for example in terms of configuration.

Infrastructure and end devices

TSN affects the network infrastructure as well as the hardware and software architecture of end devices. The requirements vary greatly depending on the application. In addition to many prototypes, more and more products are available on the market for the network infrastructure. There are both classic IT switches and products designed for industrial field use, which are adapted to the corresponding environmental conditions.

Mixed hardware-software solutions dominate on the endpoint side. Hardware support is typically required for high-precision applications and is available in increasing numbers in the form of ASICs as well as IP cores for reconfigurable hardware. Also available are network cards for standard IT systems with TSN-relevant features, which allow, for example, high-precision synchronization or offloading of scheduling according to 802.1Qbv. Software is also increasingly available, much of it in the form of open source solutions. For example, extensions to the Linux traffic control system have been published, which enable both the time-controlled transmission of streams (Qdisc ETF) and the definition of a schedule for traffic classes (Qdisc TAPRIO). Several open solutions for time synchronization are also available, for example LinuxPTP.

The configuration

Regardless of the outcome of the technical and political discussions on the use of TSN, the network must be configured automatically for efficient use. The TSN standard IEEE 802.1Qcc describes three basic configuration options: a centralized, a distributed and a hybrid approach, whereby the focus is currently on the first two. However, Qcc is not specific enough for direct implementation, meaning that further standards are required.

Figure 3: Central configuration approach and current standardization activities

© ISW

The distributed approach focuses on the protocols for decentralized resource allocation (LRP/RAP).

Figure 3 provides an overview of the structure and current activities in the context of the central configuration approach.

The centralized network configuration (CNC) is at the heart of the central approach, which is intended to configure a network consisting of infrastructure and endpoints. This knows and coordinates the communication in the network, consisting of streams and traffic classes, among other things. The requirements as to which endpoint wants to communicate with which come from a centralized application configuration (Centralized User Configuration - CUC) for each distributed application. Both CNC and CUC can be seen as functions that are integrated into a higher-level network management or the engineering of an application.

This results in three communication relationships that must be defined using standards.

- Southbound interface (CNC and switches): At the interface between the CNC and the infrastructure, configuration information is exchanged via the established SNMP protocols or, increasingly, via NETCONF. The focus of standardization here is currently on data models, for example 802.1Qcw for schedules.

- Northbound Interface (CNC and CUC): The 802.1Qdj standard, which is currently under development, specifies the communication between CNC and CUC. For example, it defines how a CUC can request new streams from the CNC and how the CNC returns the relevant parameters for configuring the endpoints.

- Endpoint configuration (CUC and endpoints): Endpoint configuration takes on a special role, as this is not in the scope of IEEE802.1, but is regulated on an application-specific basis. Important progress can be seen here around OPC UA, where there are already drafts of standards for endpoint configuration.

Relevant progress can also be observed with regard to the implementation of CNC and CUC. The first commercial solutions are available for CNC and others are in development. There are initial prototypes for CUC in the OPC UA environment, which should be available as an open solution in the future.

Despite initial successes and basic proof-of-concepts in various testbeds, configuration will remain one of the key challenges for TSN for the foreseeable future.

Cross-technology convergence

In addition to TSN, 5G in particular and, with less popularity but high technical relevance, deterministic Wi-Fi 6 and DetNet are regularly found among the trending topics in industrial communication. There is often the impression that these are competing technologies. This is certainly the case for some sub-areas, but in general the situation is similar to Ethernet, IP, mobile radio and Wi-Fi: the technologies complement each other and together cover the range of applications.

A closer look reveals that TSN is the basis of the other deterministic transmission types and therefore also the bracket for these technologies. Work is currently underway on the configuration options for the respective technologies. Ultimately, however, the major challenge will be to realize the cross-technology configuration of the overall networks.

The applications

The author: Florian Frick is group leader for real-time communication and control hardware at ISW Stuttgart.

© University of Stuttgart

For a long time, TSN networks could only be found in the form of demonstrators and testbeds. Recently, however, real applications have become increasingly recognizable. On the one hand, fieldbus-over-TSN solutions are contributing to this - systems designed for future compatibility with FLC can now also be found. On the other hand, more and more users are daring to use TSN for specific projects. Although these are usually characterized by a manageable and manually configured system, they provide very important insights into the use of TSN. There is a growing realization that an application that benefits from TSN often does not necessarily have to have TSN capabilities itself. This applies in particular to all applications that only require connectivity between IT and the real-time system. Developers of innovative services are already starting to rely on end-to-end, TSN-based connectivity and develop their applications.

Recognizing opportunities, minimizing risks

TSN is a cross-industry accepted standard that has made progress in many aspects over the past year. In view of the significant consequences for industrial communication, everyone should monitor this trend and recognize their own advantages and potential. In order to counteract the risks of a misguided development, it is advisable to contact the many initiatives, such as the testbeds, at an early stage in order to get in touch with the community at a pre-economic stage.