Figure 1: The decentralized approach: the distributed configuration model for TSN.

© Belden

OPC UA TSN can make use of these basic network configuration mechanisms from the TSN sub-standard IEEE Std. 802.1Qcc-2018. Two basic concepts are described in this standard. One of these two approaches is distributed: Here, the network configuration is carried out without a central control unit using a reservation protocol, for example the Stream Reservation Protocol (SRP) or the Resource Allocation Protocol (RAP) intended for TSN. RAP is used to exchange the information of the TSN communication flows between the individual devices, both between the switches and the end devices(see Fig. 1).

Figure 2: The central approach: the centralized configuration model for TSN.

© Belden

The second approach works with a central configuration and management unit, the Centralized Network Configuration (CNC). This CNC is connected to all TSN switches and controls the configuration of the TSN mechanisms as well as the loading and unloading of the TSN communication flows in a TSN network. The end devices report their communication requirements to the CNC via an interface for end devices, the Centralized User Configuration (CUC)(see Figure 2).

Figure 3: The mixed approach: The hybrid configuration model for TSN.

© Belden

This CUC can either also receive the requests from various end devices centrally or be implemented on end devices. In a centrally managed network or network area, a TSN domain, there may only ever be one CNC, which must of course be designed to be fault-tolerant. This CNC can in turn work with (theoretically) any number of CUCs or end devices.

Finally, the hybrid model is a hybrid of the distributed and centralized configuration approach. Here, the end devices request network resources via RAP, for example, and also receive corresponding configuration information in this way. However, the calculation of this configuration information is not based on a distributed algorithm, but can be calculated by the CNC using knowledge about the network(see Fig. 3)

Both the distributed and the centralized concept have advantages and disadvantages and are suitable for very different usage scenarios. For this reason, OPC UA and TSN need to support and use both methods equally - not only separately in different networks, but also simultaneously in an automation network. However, one approach must be selected for each subnetwork - also known as a TSN domain - within this subnetwork. This enables maximum interoperability between the various manufacturers and devices within a large network. However, there is currently still a controversial debate as to whether the different approaches can be used completely in parallel in a TSN domain in the future or whether one method must continue to be selected for each TSN domain.

In addition to these open technical questions, which the working groups of the OPC Foundation and the IEEE 802 still have to answer, there is another question: Which manufacturer of network devices or solutions will have to provide which configuration components in the future so that a TSN network can be set up and used securely and conveniently for the user?

Who delivers what?

Regardless of whether the centralized or distributed concept is used for automated network configuration: Device manufacturers, both of end devices and switches, must fulfill certain basic requirements in order for this type of configuration to be used.

A manufacturer of pure end devices with a single network connection can, in principle, make a conditional decision as to whether it wants to support only the distributed concept, only the centralized concept or both configuration concepts in its devices. In the case of the distributed concept, the end device manufacturer must support the RAP. For use in the centralized case, the end device can potentially reuse the end device communication protocol for communication with a CUC. This is envisaged in the case of OPC UA TSN, for example.

However, in the latter case, the end device manufacturer must assume that there is a CUC in the network that can handle the configuration protocol it has selected for the end device and establishes the connection with the CNC. In many cases, the development of a CUC is therefore essential for an end device manufacturer in order to be able to offer its users a solution from a single source. The configuration parameters and protocol details for the TSN configuration are standardized to ensure interoperability between the different manufacturers. However, manufacturers can implement additional features in the communication between the end device and the CUC that include unique selling points - for example, additional diagnostic parameters and design algorithms in the CUC. The function and interoperability of the TSN network is not affected by this, as the CNC only communicates with both the CUC and the switches via standard TSN parameters. Any pre-processing in the CUC is decoupled from this.

In short: An end device manufacturer can choose between the methods and should also provide a CUC if centralized configuration is supported - but this is not a binding obligation, as a CUC from another manufacturer can often be used for the TSN standard mechanisms.

For the manufacturers of infrastructure devices, the provision of a CNC is the main focus of the centralized approach in addition to the devices themselves. Infrastructure devices are devices that enable end devices to access the network, for example a TSN Ethernet switch or a device with an embedded switch with multiple ports. The CNC contains numerous logic and evaluation mechanisms that are often already used by infrastructure manufacturers in network management and configuration software. For example, Industrial HiVision, the network management solution from Hirschmann, provides information about the physical topology and the available bandwidth on the individual network ports.

Figure 4: A complex TSN configuration scenario: a network of centralized and distributed configured end devices.

© Belden

The infrastructure manufacturer can also optionally provide an additional CUC - in the event that no other CUC is available in the network. Furthermore, the switch must support at least one mechanism for TSN configuration. It must either provide the configuration protocols and standard TSN management objects for the connection to the CNC or it must include support for the distributed configuration model. Support for both mechanisms is also conceivable for a TSN infrastructure switch. After all, the switches and the network are the linchpin for interoperability between the different manufacturers.
A complex use case for a TSN network with automated configuration could therefore be a network of centralized and distributed configured end devices that is used together with a CNC from the infrastructure manufacturer and several CUCs from different end device manufacturers in the same network(see Figure 4).

However, only time will tell whether use cases of this complexity will actually occur and be necessary in practice. Individual details still need to be clarified in the IEEE 802 and OPC UA FLC working groups, such as whether interaction between two end devices is possible across more than one CUC, as would be necessary in the mapping of the complex TSN configuration scenario with end-to-end communication between the control system of manufacturer 3 and manufacturer 4.

TSN-capable switches

With OPC UA and TSN, an important specification phase is now beginning for the coupling of the end-to-end transport protocol with the basic TSN mechanisms. However, the first production-ready TSN infrastructure products are already available today, albeit often still based on programmable devices such as FPGAs. The first switching ASICs from major chip manufacturers have also recently become available on the market. Accordingly, the market penetration of TSN-capable Ethernet switches is expected to increase continuously in the future. It is therefore important for manufacturers to take action now. As soon as a large number of suitably upgraded end devices are available, there will already be sufficient distribution of a TSN-capable network infrastructure to enable the first large-scale tests and operation of OPC UA and TSN.

Furthermore, the TSN technology itself has already been initially tested in some test installations, for example by the Industrial Internet Consortium (IIC) or the Labs Network Industrie 4.0 (LNI 4.0). Both the centralized and the distributed configuration concept can be demonstrated there in networks with devices from different companies.

OPC UA and TSN therefore benefit directly from the groundwork that various manufacturers and organizations have carried out in recent years.

It won't work without migration

With the establishment of the Field-Level Communications initiative and the broad support of all major industrial automation manufacturers, OPC UA and TSN are set for the future as a universal communication protocol. The obvious advantages for users go hand in hand with greater investment security for manufacturers in a standardized basic technology and the opportunity to differentiate themselves through convenience, features and user-friendliness. And it is precisely this user-friendliness that is the key to success! TSN provides the building blocks for automated configuration. However, these must also be implemented in the products. At the same time, manufacturers must develop strategies for migrating users and customers to the new TSN world. The path, for example from Profinet to Profinet@TSN with OPC UA, to name just one of many possible examples, must be possible and manageable for the customer, even in mixed installations.

The network configuration also plays a decisive role here. While the migration represents a challenge for the individual automation providers, it is of great importance that all manufacturers, both of infrastructure and end devices, work together in the OPC Foundation for end-to-end communication and in the IEEE/IEC 60802 working group for the TSN communication profile on the remaining building blocks for the common basic technology of the future.

Author:
Oliver Kleineberg is Global Chief Technology Officer for Industrial Networking at Belden.