TSN (Time Sensitive Networking) Offering

In 2018, for the first time, the newly installed industrial Ethernet nodes made up more than half of the total newly installed nodes (with a declining growth rate for industrial field busses), a clear indicator that Ethernet is going to be the predominant medium for industrial communication in the coming years. The main reason for this is the desire to converge Operation Technology (OT) such as industrial communication and Infrastructure Technology (IT), such as IT services to one single physical networking technology, ideally into one unified network.

The advantages are manifold. Having one single, unified connector and cabling erases many human risk factors during installation and maintenance and significantly reduces the training effort for employees. The cabling setup of manufacturing halls is highly simplified and having one cheap, unified physical media allows for great flexibility in machine setup and reorganization. A device can be addressed with one unique IP and MAC address and protected as whole by the same known-good firewall technologies as already used in IT. Device manufacturers can use cheap, existing MAC and PHY technologies that are available in huge varieties and from multiple sources instead of having to use proprietary solutions with few sources. Using a known technology also reduces time-to-market and reduces the driver and software maintenance costs. Last but not least, Ethernet has simple, standardized ways to switch between different physical media. For example, in a radiation-noisy environment, fiber cables could be used instead of copper wires and in an environment with existing two-wire fieldbus installations (e.g. CAN), this fieldbus could be replaced by single-wire Ethernet using technologies such as 100BASE-T1 or 1000BASE-T1.

Due to the huge number of already deployed but competing “Industrial Ethernet Protocols” another major expectance towards TSN is to finally add a standardized way of addressing industrial control requirements within the official IEEE802.1 Ethernet standard in a converged network. However, the installed base of Industrial Ethernet nodes is immense and many of these protocols offer specific performance and configuration advantages that might never be achieved by TSN. For this reason, nobody expects the industry to switch to the new standard and replace existing equipment immediately. In addition, many of the traditional industrial Ethernet protocols offer not only solutions for the industrial communication part, but a complete ecosystem with device profiles, system setup and configuration mechanisms which are well established.

Therefore, for a long time to come, “Brownfield” installations, a mix of TSN and traditional industrial Ethernet installations are expected to be the common case. This means, that the TSN nodes will need to consider and coexist with existing network and management setups and also integrate or coexist with existing legacy realtime Ethernet networks. A simple potential scenario is the connection of multiple existing non-TSN islands or functional clusters (different production floors, different production automatons) via a TSN backbone, which implies bridging of industrial Ethernet fieldbus streams and encapsulating payload and control information into the TSN packet payloads. A different scenario would be adding singular TSN-capable devices to an existing non-TSN island, which implies a full protocol bridge (and unified configuration / setup mechanisms). Solutions to such scenarios are currently discussed by the respective traditional industrial Ethernet stakeholders to actively shape the standard and integrate TSN into their products.

Worth mentioning is the highly advanced joint IEEE/IEC 60802 approach to specify a TSN Profile for Industrial Automation [1] which describes the functional, infrastructure and performance requirements to TSN communication and maps these to industrial usecases. The “PROFINET over TSN” guideline, released by the PI Organization adopts some of these concepts and usecases and directly applies these to create a PROFINET communication structure based on TSN. By restricting itself to only a small (and finalized) subset of the TSN amendments to IEEE802.1Q, PROFINET over TSN can directly profit from a huge number of available SoC target devices and accelerate adoption in the market.

Ultimately, the mentioned and other upcoming approaches will allow to seamlessly integrate TSN into existing installations, while further stimulating a momentum towards an incremental but swift adoption of TSN into “greenfield” (TSN – only) installations.

Software and Services TSN offering

The following graphics illustrates some of our services offered around the topic TSN:

TSNEyes Demonstration Platform

Avnet Silica Software and Services created a TSN Demonstration and Evaluation platform called TSNEyes, which is used for customer demonstrations and at shows and conference to illustrate some TSN usecases and standards in action. Find out more about TSNEyes here.

Customer engagements with TSN

TSN has been a major topic in industrial automation for some time, and “TSN – enabled” SoCs and FPGA IP cores are becoming available from multiple suppliers. Although many of these solutions proudly claim to have “TSN support”, the picture is different when digging deeper and looking at the specific support for single sub-standards:

• As of today, it is impossible to support all standards, because several standards are still in Draft phase (e.g. IEEE802.1AS-rev). IP cores offer some advantages here because they can easily adapt to changes in the standards in the future and often provide support for the “current state” of a draft standard. Because lots of functionality is realized in software, many adjustments can also be made on (non-FPGA) SoCs, as long as the basic hardware support is there to support these draft standards. However, the current state of support and (negative) impacts of ongoing changes need to be carefully monitored.
• Supporting a standard not only depends on supporting the relevant hardware features, but also on enabling the support in software. In many current solutions, although the hardware support is there, the software and stack implementations are still in Beta phase, with ongoing improvements and bug fixes happening. This is not a bad thing itself, because it allows customers to evaluate solutions at an early stage and even contribute to improvements, however realizing a product based on such solutions bears some risks. Again, improvements and degradations need to be carefully monitored, in the best case based on relevant usage models and in an automated way.
• In many solutions (especially those released by the early adopters), functionality and configuration mechanisms are currently implemented in a proprietary way, with a focus on enabling features, not on compliancy with existing solutions or emerging standards. With such standardizations coming up and ongoing adoptions for TSN hardware (for example in the Linux Kernel) this is going to change. However, compared to a purely proprietary and optimized solution, this will introduce undesired side effects and features that used to work might break or degrade in performance.

Contact us to talk about the current status of solutions in Avnet Silica's Linecard. We can help to select the optimal solution and help you realize your project.