TSN, as part of IEEE 802.1 Ethernet, is a network standard and correspondingly relevant for the communication infrastructure. However, TSN is even more important as a basic technology for convergent IT/OT networks and therefore for the endpoints on which future applications will be implemented. Just as is the case with Ethernet today, the greatest potential - and therefore also business and revenue - lies in the applications running over the network. No business model on the Internet is differentiated from the competition by a better Ethernet driver - and this will not be the case with TSN for innovative industrial applications either. Interoperability, stability, robustness, rapid development of the ecosystem and market penetration are much more important for all participants in a TSN network than their own 'better' implementation.

Open solutions can make a decisive contribution to this. Because they make it possible:

- Directly deployable implementations,

- 'Inspiration' and reference for proprietary solutions,

- Support standardization through early testing and validation,

- the basis for developing innovative applications and business models before the entire ecosystem is available.

Many different manufacturers and initiatives are therefore actively contributing to open source solutions. These include projects such as AccessTSN (Linutronix, Hirschmann, ISW and HS Offenburg), organizations such as OSADL (with IOSB and Kalycito), Linaro as a supporter of various hardware manufacturers and individual companies such as Intel.

Open source is uncharted territory for many in the automation industry and is often still viewed very critically. Currently, even basic technologies are often proprietary solutions and reliable cash cows for some companies. Furthermore, in the automation industry, open source is often seen as a community driven by idealistic hobby programmers. A look at other industries - whether IT or mobile - shows that open source is definitely an enabler for innovative, efficient, reliable and sustainable applications and business models. Accordingly, all those involved in the digital transformation of the automation industry should endeavor not to get lost in the details of basic technologies, but to focus on innovative applications.

TSN endpoints

The structure and functions of a TSN end point.

© ISW

Open source solutions are primarily highly relevant for TSN endpoints. However, there is no such thing as a typical endpoint. Instead, the degree of TSN functions supported by the respective endpoints can vary greatly depending on the application. Endpoints can be categorized according to various aspects:

- Significant differences in the available computing power result in the decision as to whether an operating system or a bare-metal implementation is used.

- The deterministic requirements can range from 'just connectivity' to the network to nanosecond-precise synchronization.

- There are also major differences in the hardware support of the TSN functions and in the number of ports.

The image above shows a generalized overview of the structure and functions of a TSN endpoint. But which functions exactly are required in the TSN endpoints and which open solutions are already available for these functions today?

The real-time operating system

In industrial applications in particular, the endpoints must fulfill deterministic requirements in addition to the communication network. If sufficient resources are available - so that no bare-metal solution or a minimal operating system has to be used - Linux with the real-time extension Preempt-RT is a good option. Thanks to the constantly growing ecosystem, a large community and the increasing integration into mainline Linux, solutions for many tasks are already available, broad hardware support is guaranteed and long-term support is ensured.

Time synchronization

A common time base is essential for distributed real-time applications in a TSN network. There are open implementations for the synchronization protocols used for this, IEEE 1588, the IEEE 802.1AS based on it and the revision coming out this year. Linux PTP (ptp4l) is of central importance here. This fully supports IEEE 1588 and 802.1AS-2011 for endpoints. Missing features for full support of bridges and the new functions in the context of 802.1AS-2020 are currently being discussed and developed. Linux PTP can work both as a pure software solution or with hardware support. Likewise, thanks to appropriate mechanisms, the local real-time system can be synchronized with the synchronized clock, which can be located in the network card.

Traffic management

The schedule according to IEEE 802.1Qbv and the associated qdisc configuration.

© ISW

To ensure deterministic communication, various mechanisms are used to control data traffic in the context of TSN. The most relevant are the time-controlled transmission of data, for example for streams, and the class-based transmission of data according to a schedule (IEEE 802.1Qbv).
The basic communication architecture for Ethernet remains the same in Linux even with the addition of TSN features: Applications use sockets to transfer data to the communication stack, which transfers the data to the network card using hardware-specific drivers. Structures for sorting and prioritizing packets already exist within the stack. Queueing disciplines (qdiscs) are used for this purpose, which are organized hierarchically and can be configured depending on the application.

Two mechanisms in particular are of central importance for the time-controlled sending of data: Firstly, a new socket option has been introduced in Linux, which allows packets to be given a send timestamp (launch time). The newly introduced qdisc etf (earliest txtime first) is used to ensure that packets are sent at the desired time. This sorts packets to be sent according to the time stamp and ensures deterministic communication. If available, hardware-based time-controlled transmission mechanisms can also be used (hardware offloading).
The new qdisc taprio can be used for class-based transmission in accordance with an IEEE 802.1Qbv schedule. This allows the Linux priority classes to be mapped to network priority classes and time slots. The image above shows an example configuration of the mechanism according to the schedule shown. Hardware offloading is also possible here. Efficient configuration and thus utilization of the new mechanisms is currently the focus of various activities.

The multiport support

Devices with multiple ports are particularly widespread in the automation industry and will also be found in TSN-based networks. In the past, these were usually proprietary and hardware-dependent solutions. For TSN, there are already open approaches for abstracting and using this device class in a standardized way. For details, see also page 5 "Linux-based switched endpoints".

Protocols on higher layers

Florian Frick is group leader for real-time communication and control hardware at ISW Stuttgart.

© ISW

As part of Ethernet, TSN covers layers 1 and 2 of the OSI model as well as time synchronization. Applications therefore always require protocols on the higher layers. For classic IT applications, the established standards such as TCP, IP, http and similar are still used, for which there are well-known open solutions.
OPC UA plays a central role in the automation industry. While there is industry-wide agreement on the use of OPC UA for communication from controllers to IT and usually also from controller to controller, there are two competing camps with regard to the field level: some favour standardization up to the application level with OPC UA, while others strive to use existing fieldbus protocols via TSN. In addition to other open implementations, there is a project for OPC UA that is supported by a broad industrial community and also supports the pub sub-standards: open62541. An introduction to the project can be found in the report on page 6 "OPC UA PubSub via TSN".

Ready to get started?

In summary, it can be said that many TSN mechanisms are already supported today and integrate seamlessly into the existing ecosystem. For initial experimental use or as a foundation for future projects, it is possible to work with a wide range of PC and embedded hardware that is already available. To make the start as easy as possible, a sample configuration is offered for free use as part of the Access TSN project(more information).

TSN in Corona times

Meinrad Happacher, Editor at Large Computer&AUTOMATION

© WEKA Trade Media

There is no question that the TSN community has also been hit hard by the effects of the pandemic: The number of canceled meetings of IEEE, IEC, OPC Foundation, FLC Group and the testbeds is increasing daily and many tasks to be completed will therefore certainly take a little longer than hoped. Nevertheless, progress is being made, whether in terms of standards such as AS, configuration or available products.
Nevertheless, there is no reason for potential users of the technology to delay the development of TSN solutions. The fundamentals are sufficiently stable and solutions are already available to start developments.
In line with this, this second part of this series of articles now looks at open solutions for TSN. If you are already working on a prototype yourself or are inspired to do so, you are probably wondering how you can test the latest developments in a meaningful way. We will address this soon in the next part of the series.

Yours, Florian Frick and Meinrad Happacher