Many manufacturers, consortia and TSN testbeds are exhibiting TSN demonstrators that show applications of this technology with components that are already available. Renesas, for example, is already showing a Profinet PLC with IO-Link master connection via TSN based on a current chip. Depending on the requirements to be fulfilled, it is relatively easy to implement such TSN-based solutions on the basis of available hardware. Protocols such as Profinet or Ethernet/IP can be made TSN-capable simply by extending Ethernet Layer 2 and without interfering with the higher protocol layers. Scheduled traffic is the common method here, as this mechanism has already been tried and tested and is widely used in industrial automation. Well-known systems such as Ethercat, Profinet IRT or Sercos III have been using this method successfully for years.

However, TSN-based solutions have not yet really arrived in the portfolio of automation specialists. The reason for this lies in the current discrepancy between the actual goals of the TSN introduction and what has been achieved to date.

The goals of the TSN introduction

Figure 1: The automation pyramid and data consistency

© Renesas

TSN is an important building block for fulfilling the goals set for Industry 4.0. The technology has the potential to remove the boundaries that currently exist between the various proprietary real-time solutions by means of a unified standard. This will make data exchange within individual components of a production facility simpler and more transparent. Different areas of the plant can exchange information directly with each other via a standardized network infrastructure without the need for gateways or other adaptations. For example, machines from different manufacturers can be flexibly combined to form production lines or exchanged between different areas without having to take into account a communication standard that is still incompatible today. In addition, the complete continuity of the information flow can be realized in a vertical direction, keyword 'sensor to the cloud', which makes new business models possible.

Another goal is the standardization of automation devices and their components, which reduces the costs for their development, manufacture and spare parts stocking, as well as the maintenance of the production facility. Specialist personnel in design and maintenance can be deployed more flexibly, spare parts storage is limited to one device type and standardized hardware components are more cost-effective in the resulting higher quantities.

The requirements

This abstract goal allows for several possible solutions, which differ particularly at the lowest level of the automation pyramid. Basically, we can distinguish between coexistence and interoperability. Coexistence or convergence means that devices can share a common network segment and communicate via it without interfering with each other. Interoperability also means that the devices 'understand' each other, i.e. can exchange information with each other. Most of the real-time networks available today are neither coexistent nor interoperable with each other. TSN as a uniform network standard can fulfill the requirement for coexistence. However, the IEEE only develops horizontal network standards that describe basic functions. For example, 'Scheduled Traffic' (IEEE 802.1Qbv-2015, now adopted in IEEE 802.1Q-2018) only defines the principle and mechanisms for controlling the transmission times of Ethernet packets. However, a specific application requires specific definitions such as: the cycle time, the specific sequence of time intervals, the definition and handling of priority classes, the type and manner of network management. This then represents the application-specific profile or the vertical standard.

Figure 2: Horizontal and vertical standards

© Renesas

Without this agreement, different devices that use the TSN mechanisms differently would still not be able to coexist in a heterogeneous network. The consequence would be a renewed fragmentation of TSN-based networks. Even the use of the same semiconductor chips would possibly be inefficient in this case if the hardware requirements of the profiles were to differ too much.

Since this year, a joint IEEE/IEC 60802 working group has been dealing with this problem. Its task is to define a standardized 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 take the convergence of future industrial TSN applications a decisive step forward. The profile is expected to be adopted in 2021.

The second aspect of the Industry 4.0 goals concerns the interoperability of automation devices. In addition to coexistence in the same network, this requires a common language and similar management and planning of the automation application (engineering). The common language has already been found. It is OPC UA Pub/Sub, the real-time-capable extension of the established OPC UA standard. At SPS IPC Drives 2018, a new initiative to define a uniform OPC UA Pub/Sub-based fieldbus standard was announced under the umbrella of the OPC Foundation, in which all well-known manufacturers are participating, similar to IEEE/IEC 60802.
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 networking down to machine level (controller to controller).

Available chip components

© Renesas

TSN generally offers two main methods for the deterministic transmission of data:

• prioritization and frame preemption for asynchronous transmission
• synchronous, time-controlled transmission in reserved time windows (TDMA method).

Hard real-time via TSN - In industrial automation, this is done in accordance with IEEE 802.1Qbv. This standard avoids unwanted collisions between different data streams. The established procedures according to IEEE 1588 and IEEE 802.1AS also place the same demands on the hardware as IEEE 802.1Qbv. Corresponding components must have a PTP hardware timer from which time stamps are derived when sending and receiving time synchronization messages. It must be possible to readjust the frequency and phase of the PTP timer by means of time synchronization.

The currently available RZ/N1 module from Renesas Electronics already offers mechanisms such as high-precision time synchronization and time-controlled transmission using the TDMA method:

• Support for IEEE 1588: The new IEEE 802.1AS Rev protocol, which is based on IEEE 1588 and makes no additional demands on the hardware, is intended for TSN. Today, its predecessor IEEE 802.1AS or the previous IEEE 1588 is used as an alternative. The differences in the implementation of the two lie exclusively in the software layers.
• Support for the TDMA method: The TDMA method is also already implemented in available chips as an extension of the Qav specification. Here, the classification of Ethernet frames according to Qav is used to assign them to individual time slots within a transmission cycle. This mechanism is the predecessor of the TSN sub-standard Qbv. A chip with 1588/.1AS support and Qav+TDMA is suitable for implementing a simplified Qbv TSN functionality. The differences to Qbv-capable hardware are mainly in the number of different queues and time slots.

In addition, the RZ/N series is suitable for use in industrial network devices. It enables scalability with three product groups:

• The RZ/N1D group for high-end applications such as programmable logic controllers (PLCs) or operator terminals. A Dual Core Arm® Cortex-A7 controls the application software, while an Arm Cortex-M3 has an R-IN engine architecture and supports Industrial Ethernet communication.
• The RZ/N1S group for mid-range applications such as gateways or remote I/O units with an Arm Cortex-A7 application processor, an Arm Cortex-M3 communication processor and a relatively large integrated SRAM.
• The RZ/N1L group with an Arm Cortex M3 communication processor, which offers simple multi-protocol connectivity.

The universal communication API provides a common software infrastructure for major industrial network protocols and accelerates application development. System developers can easily switch between protocols as needed with minimal impact on application software. In addition to Linux, developers can use the ThreadX operating system for the application subsystem, allowing them to choose the operating system to suit the specific requirements of their application. Both operating systems are compatible with the main Industrial Ethernet protocols implemented on RZ/N1.

As part of the ongoing standardization process, Renesas is continuously expanding support for TSN networks in both hardware and software.

Possible solutions

Figure 3: The solution variants for the field level

© Renesas

However, at the lowest level of the automation pyramid, the field level within a machine or production unit, shorter cycle times of less than 100 µs are sometimes required. In its classic form, the publisher-subscriber method 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:

1. The PLC at the lowest control level only communicates with the higher layers via the TSN network and the OPC UA pub/sub protocol to simplify interoperability between plant components or machines. Communication at field level continues to be based on the established standards, with the advantage that tried-and-tested technology and devices are used at field level and new developments are not required. However, as before, the field level is not connected end-to-end and support for 'sensor to the cloud' remains complex.
2. The current line structure is being avoided in favor of flatter hierarchies in order to reduce the number of switches to be passed from the PLC to the furthest field device. Depending on the application, this increases the cabling effort and requires a larger number of switches. On the other hand, end devices would no longer need an integrated switch. The PLC would then have to evaluate a large number of short Ethernet frames within the network cycle instead of a summation frame. The performance of its network stack is particularly critical for this.
3. For OPC UA Pub/Sub, the field devices use familiar mechanisms such as summation frames and data exchange during the cut-through in order to support very short cycle times. It remains to be seen whether this procedure can be applied without contradiction within the standards currently under discussion. It would be difficult to motivate the replacement of a proprietary standard by a new one with comparable performance.

Figure 3 shows the different possible solutions at field level. All three variants are likely to be used, at least in the initial phase of TSN introduction.

Whichever technical solution ultimately prevails, network management and engineering will remain a major challenge in any case. However, with the activities now underway in the IEEE/IEC 60802 and the OPC UA Foundation, the chances of achieving the hoped-for Industry 4.0-compatible overall solution for a standardized, real-time-capable TSN network have increased significantly.

Author:
Arno Stock is Manager in the 'IoT and Infrastructure Business Unit' at Renesas Electronics.