Time-Sensitive Networking (TSN) technology is the subject of much debate. The subsumed standards from the Audio Video Bridging (AVB) standardization project, which deals with the digitization of audio and video signals, were created under this term. The members of the AVB Task Group quickly realized that the solution they had developed had more potential if it was supplemented with additional functions. This is why the Time-Sensitive Networking Task Group was founded within the framework of the IEEE 802.1 standard.

TSN not only opens up new possibilities in automation technology: The technology is also to be used for networking in cars or airplanes, for example, which will drive up the quantities of corresponding chips and reduce their costs. All chip manufacturers that offer Ethernet integration have therefore released TSN-capable hardware or announced their first products in the near future. TSN technology will therefore also develop and establish itself without automation technology. TSN will then flow automatically into automation devices. The respective manufacturers simply have to use the standard correctly. With this in mind, numerous companies and fieldbus organizations are already supporting the technology. Many protagonists are looking for a migration strategy to transfer existing solutions to the TSN standard. One well-known competitor is the OPC Foundation, which is not promoting a fieldbus system with OPC UA, but a secure, flexible and scalable data exchange model from the sensor to the cloud. The introduction of the publisher/subscriber method, which is ideally suited to TSN technology, is proving to be advantageous. This is one of the reasons why the OPC Foundation has already set up an OPC UA TSN working group.

Data exchange across network boundaries

Streams ensure a channel between talker and listener that routes - isochronous to event-based data - with its real-time requests through the entire network.

© Phoenix Contact

All players - whether standardization bodies, user organizations or device and system manufacturers - promote TSN technology with the term 'convergence for Ethernet-based automation solutions'. The first step is therefore to describe the term 'convergence' more clearly. An attempt: "In a convergent automation system, several engineering tools can set up different data streams - from synchronous with low latency times to event-based - and expand or change them at any time. The data exchange works across network boundaries." Those responsible for partial functions in a convergent system - for example, IO communication, control communication or communication to the cloud - can therefore be sure that their partial solution will neither interfere with other communication nor be affected by it.

At this point, it is important to briefly discuss the technology: TSN standards serve layer 2 in the Ethernet communication model. All TSN participants in such a layer 2, i.e. switched network, include a time synchronization function and can synchronize themselves to the microsecond using a clock in the system in accordance with the IEEE 802.1ASref standard. Time synchronization is one of the last TSN functions at the lower automation level that has not yet been adopted internationally, but this is expected to happen soon. The data streams to be set up are called streams and have a multicast MAC destination address defined in IEEE 802.1Qbu.

When is a telegram forwarded?

Sketched overtaking process of a short, high-priority telegram (HP) on a long, low-priority telegram (BE).

© Phoenix Contact

Contrary to the practice in today's networks, the route of a telegram is not automatically learned by a switch, but must be made known by the switch in advance of the telegram transmission via the IEEE 802.1Qbv standard. The standard defines three different configuration methods in the broadest sense: centralized, decentralized and hybrid. There are several specifications in the TSN standard that determine when a telegram is to be forwarded. In general, a stream priority according to the strict priority method is used. According to this standard, the switch searches through all incoming telegrams and forwards those with the highest priority. The credit-based shaper, on the other hand, aims to ensure that telegrams with a lower priority are also transmitted if only high-priority telegrams have been communicated for a long time. If the switch is only to transport certain telegrams at a defined time, the time-aware shaper is used. It keeps special times free for telegrams in the switches. Low-priority telegrams are held back. Policies and filters have been defined to deal with error situations. They describe what happens if a telegram is fed into the network outside the specified time or a stream is fed into the network more often than planned (IEEE 802.1Qbu and IEEE 802.1Qav).

In addition to these standards, which influence the actual forwarding of telegrams, another important standard should be mentioned: IEEE 802.1Qbu - also referred to as frame preemption - enables longer telegrams routed through a switch to be cut off in the event of a higher-priority telegram arriving a short time later. After the higher-priority telegram has been brought forward, the rest of the truncated telegram is then transmitted. This allows the latency of a higher-priority telegram to be significantly reduced, particularly with a gigabit data rate.

Ongoing standard work

Table of the most important TSN standards

© Phoenix Contact

As the IEEE has completed almost all TSN standards, various committees are now trying to define the missing building blocks based on this technology. A joint IEC/IEEE 60802-IA standardization group, which aims to combine the relevant standards in a profile for industrial automation, is very important.

In addition, other organizations - such as the AVNU Alliance - specify general definitions of how the standards converge in a convergent automation network and can also be tested, for example. The Industrial Internet Consortium (IIC), on the other hand, defines so-called traffic classes in a white paper as part of its TSN testbed. A distinction is made here between high-priority isochronous, cyclical and event-based classes. For all classes, there is a definition of which TSN standards must be developed and how. The traffic classes are an important building block for the aforementioned convergent networks. Only when all participants have agreed on this set of rules with its TSN properties can streams from different engineering tools be set up consistently in a network. These traffic classes must of course be transferred back into the standardization.

The LNI testbed (Labs Network Industrie 4.0) is currently working on an interface that can be used to create and operate streams in a decentrally configured network. The OPC Foundation is currently specifying an interface for creating streams for the central model in an OPC pub/sub network. One challenge of these many activities is the compatible extension. Only then can the goal of convergence be achieved.

Gigabit is a must

In convergent networks, one hardware feature of the new TSN-capable chipsets in the automation devices - the higher network speed of 1 gigabit or more - proves to be essential. Gigabit communication is practically a gift to the user. TSN will therefore drive the widespread introduction of gigabit technologies. Only gigabit enables the non-reactive use of the network via convergent streams.

Other important factors

Non-functional requirements are also crucial to the success of TSN technology. All protagonists of the TSN standard agree that users should not be directly confronted with the technologies described. Rather, the TSN mechanisms should be concealed by communication, application and device profiles - whether based on OPC UA or other standards. The user should not perceive the internal complexity of the TSN system as such. Further functional critical success factors result from the convergent engineering processes. Automation is characterized by a highly planned approach: The function is defined in a rough planning phase and the solution is largely developed to completion offline in a distinct engineering phase. However, it must be possible to transfer various TSN devices to the various engineering ecosystems using a device description language that is as standardized as possible. The engineering ecosystems must be familiar with the real-time properties of the entire network so that there are no surprises during commissioning.

The diagnostic properties in a convergent network prove to be a critical success factor during commissioning and ongoing operation. During diagnostics, the real application is compared with the target status from the engineering phase during commissioning or negative change processes are displayed during operation. Here, the TSN system must be able to compete with the diagnostic properties of current fieldbus systems. Even untrained personnel should be able to safely maintain operation around the clock.

The vision

Despite the listed critical requirements for a standardized device description and diagnostics, which have not yet been implemented, TSN technology in conjunction with OPC has considerable potential for innovation. If all participants in a language can exchange data with each other isochronously, asynchronously or event-based, new scenarios and functions can be solved across manufacturers. For device providers, there is also the major advantage that only one hardware platform needs to be maintained, which can in principle be adapted to different systems by means of a firmware update.

Author:
Robert Wilmes is a software marketing employee in the Control Systems business unit at Phoenix Contact Electronics.

Interview: "TSN is just the beginning"

Will the 30-year fieldbus war come to an end with an agreement on the TSN and OPC UA combination? And what trends are boiling up in parallel with these technologies in industrial communication? Martin Müller, Vice President Automation Infrastructure, assesses the developments.

Martin Müller: "TSN will shape automation - but not alone: topics such as SPE, APL and 5G are already waiting in the wings!"

© Phoenix Contact

Mr. Müller, Phoenix Contact sees itself as a leading provider of communication and automation technology. How important is a uniform, manufacturer-independent communication standard to you - as it now seems to be within reach with the combination of TSN and OPC UA?

Martin Müller: For Phoenix Contact and for me personally, this is the most exciting time in the 30-year history of industrial communication. With OPC UA in conjunction with TSN, it has been possible for the first time to bring together all major and important manufacturers of automation technology under the umbrella of the OPC Foundation with the field-level initiative and to work on the international standard for industrial communication. This overarching communication standard is therefore really within reach. Nevertheless, there are still some activities to be completed in the working groups that have just been launched so that we can speak of a truly uniform standard.

You have 30 years of experience with fieldbus disputes! How confident are you that this time all the players will actually pull together - and
the uniform standard will become a reality?

Martin Müller: I am actually very confident that we will succeed in realizing a uniform standard this time. This confidence comes from the fact that at the preparatory meetings last year, all those involved made it clear that they want to leave the fieldbus wars behind them and are approaching the matter with a great deal of commitment as well as personnel and financial investment. Moreover, this is not the first time that this has happened, as fieldbus organizations and automation manufacturers have already worked together successfully on the topic of FDI - Field Device Integration - and are also doing so in the APL project - the Advanced Physical Layer - for a two-wire Ethernet technology in the field of process automation.
process automation.

Once the topic of TSN and OPC UA from the sensor to the cloud has been finalized, can we tick the box for communication in the factory?

Martin Müller: Over 30 years of fieldbus experience has shown one thing: Communication technologies are constantly evolving, creating benefits for users and applications. This can also be seen with regard to TSN and OPC UA. OPC UA will standardize the protocols and views of field data from the sensor to the cloud with the FLC information model - even without TSN. TSN, in turn, provides the basis for highly dynamic and deterministic communication at field level. But it goes even further: new standards for two-wire Ethernet - Single Pair Ethernet, or SPE for short - are currently being developed in the IEEE standardization committees, which, starting with the transmission rate of 10 MB/s, would be interesting for even the simplest field devices in terms of costs. Based on this, the APL Group is specifying the extensions required to use this technology in the process industry for intrinsically safe transmission in the field. In addition, 5G in particular is developing into the next-generation mobile communications standard, which also opens up completely new application scenarios in terms of performance, latency and deterministics.

How quickly is 5G coming to the factory? What still needs to be done? Where are the problems?

Martin Müller: While 5G technology is already being used in some countries, the 5G frequency auction will start in Germany this year. This is not the only reason why it will be a while before the technology can be used on a broad scale in factories. The first private test cells are currently being set up to test the performance, but also the limits of 5G technology in industrial automation. Based on this, field trials will then begin to test the technology on a larger scale.

The topics of SPE and APL are currently in the definition phase. Why are these two topics so important? Where is the bottleneck? How do you see the timeframe for implementing the technologies?

Martin Müller: SPE and APL are indeed promising technologies, especially for connecting simple field devices that can currently only be integrated into the higher-level communication architectures via gateways. Building on the standardization activities in the IEEE, chip manufacturers are called upon to make the technologies available in series in their chipsets so that the manufacturers of automation devices and systems can integrate them into their solutions. The chip manufacturers' roadmaps assume that the first prototype implementations will be available in the first half of this year and that chipsets will be available in series production by the end of 2020. Devices with corresponding interfaces will also be available on the market immediately afterwards.

Cyber security hangs over all these topics like the sword of Damocles! What are suppliers doing to get to grips with this problem?

Martin Müller: I don't see cyber security as a sword of Damocles, but as an important aspect of modern automation solutions. In addition to the use of automation components with 'hardened' communication interfaces, this also requires users to plan automation systems much more precisely, taking into account possible gateways and implementing appropriate protective measures. As a manufacturer of automation components, Phoenix Contact takes this issue into account through a certified development process in accordance with IEC 62443 and corresponding devices through to industrial routers. To come back to the first question, a uniform and manufacturer-independent communication standard offers the best prerequisites for cyber security in the future.