Time-sensitive networking (TSN) is poised to have the biggest impact on industrial networking since Ethernet was introduced to the plant floor more than two decades ago. “The goal is to ensure a harmonized protocol-agnostic TSN network that avoids different ‘flavors’ based on the protocol used,” says Michael Bowne, executive director of Profibus and Profinet in North America.
TSN is a set of bridging, or switching, standards being developed by the Institute of Electrical and Electronics Engineers under its IEEE 802 networking standards group. “The promise of TSN is to make standard Ethernet real-time capable and entirely deterministic,” explains Ken Austin, senior Ethernet product marketing specialist at Phoenix Contact. “Should the TSN concept be successful, it will mean the removal of network delays and uncertainty in time-sensitive applications via time synchronization and prioritization of data streams through scheduling and coordination of best communication paths.”
Naturally, this promise has generated a lot of enthusiasm in industry. The major industrial protocol associations have already announced their support for TSN, and some have even gone so far as to publish early concepts of how their protocols will work with it. The associations have also been collaborating with automation vendors to bring TSN to fruition.
Right now, the automation industry is in the midst of a two-step process: the writing of the underlying IEEE standards and the development of a profile for industrial automation. “TSN is not just one thing,” explains Bowne. “It is a collection of IEEE standards that can best be thought of as a toolbox.”
Because IEEE 802 standards cover all industries, each industry will need to identify which of these tools it needs and use them to define a common profile for itself. To develop such a profile for industrial automation, the IEEE and the International Electrotechnical Commission (IEC) have joined forces and are working to develop a joint profile called the IEC/IEEE 60802 TSN Profile for industrial automation (TSN-IA profile).
Bowne and others, however, expect that it will be a few years before TSN-based networks will begin appearing in the field. They generally give four reasons. “First, the TSN-IA Profile needs to be completed, and the last remaining IEEE standards need to be finalized,” says Bowne.
“The basic TSN technology needed for bridges was completed with the release of IEEE 802.1AS this year,” adds Paul Brooks, manager of technology business development at Rockwell Automation. “Assuming that it will have sufficient scope, the key basic standard for interoperability of applications will be ‘IEEE 802.1Qdj, Configuration Enhancements for TSN’, which is scheduled for a 2023 or 2024 release.” Meanwhile, the IEC/IEEE 60802 joint working group debating the TSN-IA profile is scheduled to be complete in 2021. At least, those were the expectations before the COVID-19 outbreak.
The second reason that implementing TSN will take a few years is that, once the standard and profile is finished, chip makers will need time to produce TSN-capable chips. “Automation devices will use TSN-based standard communication chips instead of today’s specific real-time Ethernet hardware,” explains Thomas Brandl, communication product owner at Bosch Rexroth.
The third reason involves downstream development cycles. “Automation device manufacturers will need to implement these chips in their devices,” says Bowne. And finally, the fourth reason, is that end-users must decide that they can install those devices in their factories. “Because you need a whole marketplace of devices for that to happen, it’s going to be a long time before people are going to start seeing TSN in the real world,” Bowne adds.
Once TSN implementation begins, it is expected to start in select applications. “Small-scale bounded TSN implementations that are limited to single machines will likely be more common initially in existing facilities, and some greenfield developments could see wider scale TSN rollouts,” says Dr. Al Beydoun, executive director and president of ODVA.
Standards harmonization
To do their part in making that happen, industrial protocol associations are already busy preparing their protocols to accommodate TSN. “The specification for running Profinet over TSN has been written, prepared, approved, and published since mid-2019,” reports Bowne. However, his organization’s work is not finished. It is developing testing procedures that ensure devices conform to the specification.
Bowne attributes the rapid development of the specification for running Profinet over TSN to the fact that many of the mechanisms employed by TSN had already been part of Profinet for many years. For this reason, he expects the long-term effects of TSN on Profinet itself to be minimal.
The OPC Foundation is likewise looking to harmonize with TSN, which it is doing through the Field Level Communications (FLC) initiative OPC launched on November 5, 2018. The organization sees TSN as an opportunity for bringing its OPC UA (Open Platform Communications with Unified Architecture) technology to the field level between controllers and devices such as sensors and actuators. TSN would allow OPC UA not only to offer an open, standardized, and interoperable product for most industrial communications, but also to provide semantic interoperability from sensors to the cloud.
A key aspect of the FLC initiative is a universal quality of service (QoS) concept. “OPC UA does not define its own transport protocols,” explains Peter Lutz, director of the FLC initiative. “Instead, OPC UA is an industrial framework that can be easily adapted to existing transport layers, depending on the different requirements and use cases. This framework already includes mechanisms for a secure, reliable, manufacturer-and platform-independent information exchange.” He also notes that the universal QoS modeling concept allows mapping the modeled information and services to different underlying transport protocols and physical media.
Lutz reports that his organization has specified first use cases and applications that build on the QoS model for controller-to-controller (C2C) and controller-to-device (C2D) interoperability for factory and process automation. “C2C and C2D require cross-vendor semantics for motion control, functional safety, and remote I/O,” he says. “At the same time, they also demand real-time communication capabilities with guaranteed bandwidth and low latencies.”
The OPC Foundation has already developed many of the required specifications. The first release of the functional safety specification is under review, and the first specification for control-to-control communication was announced at the SPS event in Nuremberg, Germany, in 2019. “The next step will be to extend the OPC FLC standard for the communication between controllers and devices, like I/O and servo drives,” says Brandl. The OPC Foundation launched a Motion Working Group in May 2020 to define the motion profile for standardized communication between controllers and drives.
Having been involved with the OPC FLC’s working groups from the beginning, Bosch Rexroth is preparing a software upgrade that will allow its new automation control platform to adopt the new communications standard. “The modular architecture of our new ctrlX Core controller allows for using OPC FLC with TSN and EtherCAT simultaneously without mutual impact,” says Brandl.
Accommodating high speeds
TSN will not replace protocols that have excelled in applications requiring highly synchronized, highly deterministic motion control. “TSN is an augmentation to the best effort approach in Ethernet,” explains Bob Trask, North American representative of the EtherCAT Technology Group. “TSN provides bounded determinism in heterogeneous IEEE 802 networks, but it still has a significant latency.” Consequently, high-speed machinery and other motion-control applications will still need an industrial protocol like EtherCAT that can guarantee real-time communication of data.
EtherCAT’s bridging concept relies on shared frame forwarding and processing on the fly to streamline communications. “It can pack a frame with many nodes of information going to a bunch of slave devices,” says Trask. Consequently, integrating EtherCAT into a TSN network does not need a port for each slave and can get by with fewer ports, which reduces both complexity and latency.
Inserting a TSN infrastructure between the master and the slave segment also creates a logical separation. The result is greater flexibility for master devices, a guaranteed maximum for latency, and a predictable frame loss rate.
The CC-Link Partner Association (CLPA) has also incorporated TSN into its protocol, releasing CC-Link IE TSN in November 2018 as a technology for deterministic, high-speed control. “Having CC-Link IE TSN supported natively in devices will allow doing safety, motion, and control on machines and devices that were previously disconnected,” says Tom Burke, who is both global strategic advisor for CLPA and global director of industry standards at Mitsubishi Electric Automation. Because of TSN, the machines and devices will now be able to perform transactional control.
Burke reports that CC-Link IE TSN is already being adopted in Asia and that CLPA is also working with its partners to deploy it in Europe and North America. The plan is for CC-Link IE TSN to be CLPA’s flagship protocol. “Because we have a huge installed base of devices from all of our partners that support our current protocols, CC-Link IE field and CC-Link IE control, we have a migration plan that allows our suppliers to add support for CC-Link IE TSN to their existing devices,” says Burke. “We are working with our suppliers on the appropriate bridges and gateways to make this a reality.”
A wait-and-see approach
Not all protocol associations have released their adaptations yet. “ODVA has chosen a measured approach by waiting until the TSN standards are finalized before adapting EtherNet/IP for TSN,” reports Beydoun at ODVA. He and his colleagues want to avoid false starts and any resulting adverse effects on the many contributors and users in the EtherNet/IP ecosystem.
This strategy, however, doesn’t mean that ODVA has been idle. On the contrary, it has been busy working through strategic member groups to adapt its EtherNet/IP for TSN. Part of the groups’ mandate is to develop adaptations that will allow EtherNet/IP to support the TSN standard without any proprietary modifications.
“All current technologies—including DLR (Device Level Ring), CIP (Common Industrial Protocol) Motion, and CIP Sync—will be able to adopt methods that 60802 defines through the introduction of new hardware, and some through the introduction of firmware upgrades,” says Beydoun. The member groups are working to keep the additional technology to a minimum and to ensure that existing EtherNet/IP installations will be able to take advantage of their past investments.
One of these strategic members, Rockwell Automation, has been supporting this work on a few levels. At the 2020 ODVA Industry Conference, for example, a representative delivered a presentation on adapting CIP Motion for TSN (http://awgo.to/LQvgX). The automation vendor is also supporting the standard through prototyping activities in its pre-product development.
“Fortunately, because EtherNet/IP was designed using standard, unmodified Ethernet and the TCP/UDP/IP software suite, we believe that the primary impact of TSN will be on product hardware,” says Brooks. “The impact on the protocol will be relatively small.”
