The convergence of IT and OT systems is a key enabler of the digitalization of production. This involves using the same hardware and software solutions, striving for system consistency and adopting methods and tools. In addition, the infrastructure concept from IT is also playing an increasingly important role: solutions are no longer implemented as closed hardware-software systems, but are instead implemented digitally on a shared infrastructure as far as possible, which is supplemented by additional hardware components depending on the application. The central components of this infrastructure are the network and compute resources, as shown schematically in Figure 1. The degree of convergence can vary greatly: From simple access to data, for example for tracking, to the use of a shared IT/OT infrastructure for distributed real-time applications of virtualized control systems. The latter have recently gained popularity, particularly in the form of virtualized PLC controllers (vPLC).

The reasons for this are manifold: it allows the consolidation of many controllers on a single platform instead of a large number of distributed devices in the field, but also offers advantages such as centralized maintainability and monitoring, redundancy and reliability, and in particular the complete availability of all internal control information on one IT system, for example for digital twins or AI applications.

In addition to consolidating real-time workloads, a key challenge for vPLCs is connecting the field level. This requires convergent real-time networks, for which Time-Sensitive Networking (TSN), the extension of Ethernet standards to include deterministic functions, is recognized as an enabler across all industries. However, TSN can only ever be part of the solution, as it only covers the lower levels of communication.

Field communication in the context of TSN

Figure 1: The infrastructure of the factory of the future.

© ISW

Today, field devices are typically connected via fieldbuses, which can be divided into Ethernet-based and those with their own transmission layer. For the latter, however, there are a variety of adapters and bridges to integrate them into Ethernet-based fieldbuses. As most Ethernet-based fieldbuses use many aspects and hardware of Ethernet, but deviate from the standard to achieve real-time capability, there is no direct compatibility with a standard Ethernet network.

However, this statement needs to be re-evaluated in the context of TSN. Although the fundamental compatibility problem does not change, TSN can be configured interoperably with various fieldbuses thanks to deterministic functions - and completely transparently for the fieldbus. Dedicated consideration is required for fieldbuses such as Profinet or EtherCAT.

With the increasing importance of TSN, the fieldbus organizations have published various approaches on how TSN can be used for the lower layers in compliance with the standard, for example using CC-Link IE TSN or the specification of TSN as a new conformance class for Profinet.

There are two basic options for using TSN: TSN can either be used as a technological module in a separate solution. In this case, the required features are used in a specific configuration for the entire communication system consisting of end devices, infrastructure and management. A major advantage is the independence from external systems and further developments and therefore immediate usability, which is why this variant was chosen for CC-Link IE TSN and Profinet. A significant disadvantage is the very limited interoperability with other solutions, for example for best-effort data traffic.

The second fundamental approach to using TSN is to view the network as a resource: applications can allocate parts of it as required by means of management, for example streams or bandwidth reservations. This enables the coexistence of many real-time applications, but places significantly higher demands on interoperability, management and engineering.

OPC UA FX, the approach currently being standardized to use OPC UA down to field level, is based on this resource model. Accordingly, this technology is associated with many hopes for an interoperable implementation of the vision from the sensor to the cloud.

The approach presented by the EtherCAT Technology Group on how EtherCAT can be used in combination with TSN, which plays a special role, is also based on this. Unlike Profinet or CC-Link IE TSN, in this case TSN is not spoken up to the field device, but only EtherCAT segments are coupled via a TSN network. For this connection, the EtherCAT data is adapted to TSN streams, which requires special functions at the transition, for example in the first field device or a special switch. How the TSN streams are actually managed in the network is outside the scope of the ETG, but a resource-based approach can easily be chosen here. To summarize, there are at least three basic ways in which TSN can be used for field communication, but they are only interoperable with each other to a limited extent.

TSN backbone for the factory

The network of a convergent infrastructure for the factory of the future consists of a general IT part and a deterministic part. The latter is based on TSN and faces the interoperability problems mentioned above. In the long term, a resource-based solution covering all subsystems is desirable. At the moment, this is not realistically and efficiently possible due to the lack of standards and tools. In addition, the described communication approaches will be present at least for the period of the typical life cycles of machines. For the TSN backbone, it is therefore necessary to clarify how it should be fundamentally specified in order to meet the requirements in the long term. On the other hand, the backbone should make it possible to use the approaches and solutions already available as quickly as possible in order to benefit from convergence and make virtual control systems scalable.

The central requirements can be formulated for the TSN backbone:

• Application independence: Different applications must be able to use the backbone in parallel and also use different TSN functions for this purpose, for example streams or reserved bandwidths.
• Parallel, equal real-time applications: Different real-time data, for example from vPLCs, must be transferable without interference. There must therefore be no cross-application conflicts in prioritization or pre-emption.
• Management: The backbone must be usable without the need for in-depth knowledge of it. Suitable interfaces, both technical and organizational, must be available to users.

Field communication via the TSN backbone

The efficient and timely use of the TSN backbone requires solutions for interoperability. In many discussions, the prevailing opinion is that the different approaches cannot be used together. Another argument is often that TSN can only be used sensibly once the configuration issue has been fully resolved and that this will not be the case for many years. In order to achieve maximum network utilization and the theoretical optimum in terms of latency and jitter, this argument is certainly correct. However, in view of the fact that mainly isolated 100 Mbit networks with a utilization of less than 10 % are used in industrial environments, the question arises: isn't a convergent GBit network with a double-digit utilization rate already a desirable advance and added value?

Figure 2: The transparent channel through a TSN network.

© ISW

Based on this assumption and a detailed analysis of the individual technologies, various pragmatic approaches can be used. Approaches that can already be implemented and used: A transparent approach lends itself to tunneling the group of classic Ethernet-based fieldbuses through a TSN network. The basic idea is to configure the network in such a way that the TSN route behaves like a long but deterministic cable. A combination of logical and temporal separation using VLANs and time slots or streams can be used for this purpose. Depending on the requirements of the fieldbus, the communication channel established in this way can be asynchronous - but potentially with a higher frequency - to the fieldbus or synchronized. For synchronization, a software-based master can be synchronized to the TSN time using local application scheduling; traffic upstream of a fieldbus segment can be introduced into a fieldbus segment using planned queuing and Qbv time slots with an accuracy of around 20 ns(Figure 2). In order to integrate the TSN-based fieldbuses into the backbone, it is necessary to consider which data a specific application actually communicates and which requirements apply to the data streams. With the application knowledge, the relevant part of the fieldbus-over-TSN network can be logically and temporally sorted into the backbone. The integration of stream-based approaches can be achieved through dedicated planning of the streams.