Time Sensitive Networking (TSN) has become well established in the vocabulary of the automation industry. All leading companies in this market have started activities for evaluation or even for the introduction of TSN. But what are the goals for application of TSN technology in industrial and process automation and what has already been achieved today that can be used concretely by customers? What is still missing?

Many manufacturers, consortia and TSN testbeds are exhibiting TSN demonstrators showing concrete applications of this new technology with components already available today. For example, Renesas is demonstrating a Profinet PLC with IO-Link master connection via TSN based on a current chip. Depending on the requirements to be fulfilled, the implementation of such TSN-based solutions based on available hardware is rather simple.

Protocols such as Profinet or Ethernet/IP can utilize TSN just by extending the Ethernet Layer 2 and without interfering with the higher protocol layers. Scheduled traffic is the most common method here, because this mechanism has already been sufficiently tested and widespread in industrial automation. Well-known systems such as EtherCAT, Profinet IRT or SERCOS III are successfully using this method, which was generalised in the course of TSN development, for years. However, TSN-based solutions have not yet really arrived in the portfolio of automation companies. The reason for this lies in the current discrepancy between the actual goals of TSN introduction and those currently achieved.

The goals

TSN is an important building block in meeting the targets set for Industry 4.0. The technology has the potential to break down the boundaries that currently exist between proprietary real-time solutions by establishing a unified standard. This makes data sharing within individual sections of a production facility simpler and transparent. Different domains can share information directly via a uniform network infrastructure, without the need for gateways or other adaptations (horizontal communication).

As an example, machines from different manufacturers can be flexibly combined into production lines or exchanged between different domains without having to consider communication standards that are still incompatible today. In addition, customers can implement the complete continuity of the information flow in the vertical direction, in a “Sensor to the Cloud” manner that enables new business models.

A further objective is the standardisation of automation equipment and its components, which will reduce the cost of developing, manufacturing and stocking spare parts, as well as the maintenance of the production facility. Specialists personnel in design and maintenance can be deployed more flexibly, warehousing for spare parts is limited to one device type and standardised hardware components become cheaper due to the resulting higher quantities.

 

Requirements

This abstract goal allows for several possible solutions, which differ particularly in the lowest level of the automation pyramid. Basically, we can distinguish between coexistence and compatibility. Coexistence or convergence means that devices can share a common network segment and communicate over it without affecting each other. Compatibility means that in addition devices can “understand” each other, i.e. share information among themselves.

The real-time networks available today are predominantly neither coexistent nor compatible with each other. TSN as a uniform network standard can meet the demand for coexistence. In fact, IEEE only develops horizontal network standards that describe basic functions.

For example, for “Scheduled Traffic” (IEEE802.1Qbv-2015, now adopted in IEEE802.1Q-2018), only the principle and mechanisms are defined for controlling the transmission times of Ethernet packets. However, a concrete application requires specific definitions, such as the cycle time, the concrete sequence of the time intervals, the definition and handling of the priority classes, the type and method of network administration and much more. This represents the application-specific profile or vertical standard. Without this agreement, different devices that use TSN mechanisms differently would still not be able to coexist in a heterogeneous network. Consequently, TSN-based networks would be fragmented again. Even the use of the same semiconductor chips might be inefficient in this case if the hardware requirements of the profiles differ too much.

Since 2018, a joint working group IEEE/IEC60802 has been dealing with this problem. Its task is to define a uniform TSN profile for Industrial Ethernet applications and to close any gaps in the IEEE specifications. The success of this working group, to which many experts and consortia are contributing, will make the interoperability of future industrial TSN applications take a decisive step forward. The profile is expected to be adopted in 2021.

The second aspect of the Industry 4.0 objectives concerns the compatibility of automation devices. In addition to coexistence in the same network, this also requires a common language and similar management and planning of the automation application (“engineering”). The common language has already been found. This is OPC-UA pub/sub, the real-time extension of the established OPC-UA standard. At SPS IPC Drives 2018, a new initiative was announced to define a uniform OPC-UA pub/sub-based fieldbus standard under the umbrella of the OPC Foundation, in which all leading manufacturers participate in the same way as to IEEE/IEC60802.

OPC-UA pub/sub enables real-time communication at the level of established protocols with cycle times of less than 1 ms, such as Profinet or EtherNet/IP. OPC-UA pub/sub uses multicast frames that a publisher sends cyclically to one or more subscribers. This enables real time connections down to the machine level (controller to controller).

At the lowest level of the automation pyramid, the field level within a machine or production unit, smaller cycle times of less than 100 µs are sometimes required. In its classic form, the Publisher-Subscriber process cannot be used to implement longer device chains with these cycle times, as is the case with EtherCAT or SERCOS III, for example. In practice, there are three possible solutions.

The PLC at the lowest control level communicates only with the higher layers via the TSN network and OPC UA-pub/sub protocol, so that interoperability between system parts or machines is simplified. Communication at field level continues to be based on established standards. The advantages are the proven technology and devices at field level, so new developments are not necessary. However, as before, the field level will not be connected transparently, and support for “Sensor to the Cloud” remains complex.

The current line structure is being avoided and flatter hierarchies are being increasingly adopted in order to reduce the number of switches to be passed from the PLC to the most distant field device. Depending on the application, this increases the cabling effort and requires a larger number of switches. On the other hand, end devices no longer need an integrated switch. The PLC then must evaluate a large number of short Ethernet frames within the network cycle instead of an aggregated frame. The performance of the network stack is particularly critical here.

For OPC-UA pub/sub, field devices use familiar mechanisms such as aggregated frames and data sharing during cut-through to support very short cycle times. It will be crucial that this concept can be applied consistently within the standards currently under discussion. The replacement of a proprietary standard by a new one with comparable performance would be difficult to justify.

Whichever technical solution will ultimately prevail, network administration and engineering will always remain a major challenge. With the activities ongoing in IEEE/IEC60802 and the OPC-UA Foundation, the chances have greatly increased for the hoped-for Industry 4.0-capable overall solution for a uniform, real-time TSN network.

Arno Stock, Renesas Electronics