The Ins and Outs of Time-Sensitive Networking

This article is part of TechXchange: Time for Time-Sensitive Networking

What you’ll learn:

  • The key elements that constitute time-sensitive networking.
  • How is TSN used?

Ethernet has been cemented as a dependable wired solution for computer and automation networks. The open standard enables terminals to be quickly and easily connected and scaled to exchange data with relatively inexpensive hardware.

Ethernet was, however, not originally designed to meet the requirements posed by automation technology, particularly when it comes to big data and real-time communication. Due to those restrictions, various bus systems in automation have evolved using Ethernet on a physical level while implementing proprietary real-time protocols on the top end.

Such systems often lead to the exclusive use of the network infrastructure and local dependencies. Networks currently tasked with handling time-critical data are separated from networks directing less-critical data traffic to eliminate reciprocal negative interference.

In the future, Industry 4.0 applications will increasingly require more consistent and robust Ethernet networks. These networks can only be produced at a significant cost with the current infrastructure. To that end, time-sensitive networking (TSN) offers a solution to change these current conditions and provide increased throughput for many industries.

What is TSN?

TSN is a set of standards under development by the Time-Sensitive Networking Task Group, which is part of the IEEE 802.1 working group—an offshoot of the IEEE 802 project created by the IEEE Standards Association (see figure). TSN focuses on creating a convergence between information technology (IT) and industrial operational technology (OT) by extending and adapting existing Ethernet standards.

While it may sound like it, TSN is an Ethernet standard and not an Internet Protocol Standard (IPS). However, the extensions in particular address the transmission of very low transmission latency and high availability.

Now that we’re up to speed on lineage, the standards define mechanisms for the time-sensitive transmission of data over deterministic Ethernet networks. Most projects define extensions to the IEEE 802.1Q (aka VLAN support) Bridges and Bridged Networks, which describes virtual LANs and network switches.

TSN technology aims to standardize features on OSI-Layer 2 so that different protocols can share the same infrastructure. The challenge here lies in configuring critical and non-critical data traffic so that neither real-time characteristics nor performance is impaired.

TSN Breakdown

Typically, traditional Ethernet networks involving automated sectors, such as those found in manufacturing, are based on the hierarchical automation pyramid, separating information technology (IT) from operational technology (OT). IT includes classic office communication with typical end devices, such as computers and network-attached-storage (NAS) systems. The OT end comprises systems, machines, and software used for process control and automation.

Those areas are essentially different in how they communicate, with IT relying on bandwidth and OT tasked for high availability. Data traffic at the IT level is often classified as non-critical, while data traffic is designated time-critical on the OT end. Because of this separation, each level uses a particular communication standard.

While the Ethernet bus system with TCP/IP is largely prominent at the IT level, various bus systems (aka fieldbus systems) that meet requirements for guaranteed latency times are widespread at the OT level. Each local control usually promotes a specific fieldbus system.

For the end-user, it means that selecting the controller also determines the selection of the bus. As a result, the user often became dependent on the manufacturer since the different bus systems were incompatible. This is no longer the case, as continuous data transmission is a fundamental necessity for digitized enterprises, regardless of industry.

Industrial automation is already undergoing a phase of restructuring based on the establishment of flexible and intelligent manufacturing, typically described or already implemented in the context of Industry 4.0, smart production, and the IoT. This is detailed in the automation pyramid, which incorporates TSN and divides the structure in half, with the top portion (strategic management, plant management, supervisory) dedicated to IT and the bottom (control, field devices, etc.) implemented with OT.

The separation of control and field levels is blurring, creating the need for a uniform, convergent network where critical data traffic can be simultaneously transmitted with non-critical data without adverse effects. Thus, the existing Ethernet must be adapted to meet these requirements. This is where the TNS Task Group comes into play, as sub-standards intended to enable converged critical and non-critical data traffic over a shared Ethernet infrastructure are currently being defined.

Time is the Key

All network equipment needs the same understanding of time to meet that aforementioned convergence, which means all switches and terminals on a network must be time-synchronized. To accomplish that task, two different approaches are currently in play.

One is the IEEE 1588-2008 standard, which prompts the provision of the clock with the most accurate time to be designated to act as a Grandmaster Clock, or centralized time element. The Task Group also created a unique profile that outlines the use of IEEE 1588 specifications in conjunction with IEEE 802.1Q, especially those applications that do not require full throughput.

Another important functionality deals with transmitting critical and non-critical data traffic within a converged network. Critical data traffic is prioritized for delivery at a scheduled time, while non-critical data traffic is designated a lower priority. Eight traffic classes are already established according to IEEE 802.1Q, and they’re used to prioritize different types of data traffic.

That said, the standard’s QoS (Quality of Service) was not designed for sending critical and non-critical data traffic in parallel. Due to buffer mechanisms in Ethernet switches, a low-priority Ethernet data packet can delay data streams, even if they’re tasked with high priority. New prioritization mechanisms have been introduced to allow and regulate this coexistence.

Enter IEEE 802.1Qav, which is designed for data streams with real-time requirements to be prioritized over best-effort traffic. A great example of that prioritization includes the Credit-Based Shaper (CBS), which was created by the IEEE 802.1 working group to handle priority transmission for the TSN Audio/Video Bridging (AVB) predecessor technology.

The shaper assigns sending credits to data streams. Data packets with reserved bandwidth are preferably transmitted as long as credit remains in the positive range. Those credits are spent during transmission until declining to a negative. Therefore, once a preferred transmission reaches a negative value, the best effort data packets next in line are transmitted. If this delays the forwarding of data packets designated with reserved bandwidth, credit is increased to allow for prioritized Ethernet frames to be transmitted in succession.

Due to the expansive range of TSN functions, integration is best handled by programmable microchips, such as field-programmable gate arrays (FPGAs). Compared to traditional ICs, where functions are predetermined, FPGAs can be programmed and configured to generate complex digital functions based on the application.

Conclusion

The standardization process is not complete, and the implementation of various standards is an ongoing process as new technologies are continuously introduced to the market annually. Since TSN standards are currently still being revised and changed, the possibility to expand and reprogram is a critical factor in implementation and deployment in an industrial setting.

Nevertheless, TSN provides the foundation to meet those changing requirements and the spectrum makes it possible to fulfill the ever-changing latency, jitter, and reliability requirements to meet the latest application requirements.

Read more articles in the TechXchange: Time for Time-Sensitive Networking

Leave a Reply

Your email address will not be published.

Back to top button
BIELSKO1