Maryam Vahabi ABB Corporate Research Västerås, Sweden, maryam.vahabi@se.abb.com; Hariram Satheesh ABB Corporate Research Bangalore, India, hariram.satheesh@in.abb.com; Alexander Gogolev, Jörgen Gade, Johan Åkerberg, Xiaolin Jiang Former ABB employees
TSN is a family of network enhancement mechanisms that makes regular Ethernet networks deterministic and capable of real-time performance. They are described in a set of IEEE standards that define traffic shaping methods, system-wide synchronization, frame preemption, quality of service (QoS) handling, etc. These features are built on top of existing, mature Ethernet standards. TSN also specifies further mechanisms, such as distributed or centralized network orchestration, on-the-fly data stream scheduling, etc.
Why have TSN?
The driver for TSN is the proprietary, and thus vendor-bound, nature of existing fieldbuses and all the equipment, license, upgrade and modification restrictions this entails. Further, industrial Ethernet solutions such as EtherCAT and PROFINET are not interoperable due to proprietary upper layers on top of the Ethernet-based fieldbuses. TSN resolves this interoperability problem with standardized interfaces and mechanisms. Also, TSN is a converged network, which allows the coexistence of multiple traffic types – for example, high-priority control applications and low-priority tasks, such as Internet browsing – on the same “wire.”
Another advantage of TSN is the ease of access to information it provides. Even in Ethernet-based fieldbuses, it is difficult to access auxiliary information from field devices used for engineering, monitoring, predictive maintenance, etc. since the fieldbuses would need gateways for data caching and bridging. TSN builds on standard and known Ethernet mechanisms, and requires no low-level gateways.
What does TSN offer to ABB?
To an automation business, TSN adoption brings both benefits and challenges. An evident benefit is that TSN can replace multiple fieldbuses with one network that supports more deterministic behavior while providing higher traffic capacity →02. Further, the introduction of TSN standards means that network equipment and orchestration tools will no longer be proprietary – a significant advantage for customers. One challenge faced by TSN is that the relevant. standards are still to be finalized and network orchestration tools must then be implemented according to these standards. Furthermore, the automation end systems must be prepared for TSN, with software and, sometimes, hardware modifications.
What is a “TSN-ready” device?
On the system and software level, the definition “TSN-ready” might include a product that has an orchestration tool to enable efficient TSN management. Hardware-wise, there are at least two types of devices that can be labeled as TSN-ready: the network bridge and the end system.
Today, some network bridges are already designated as TSN-ready, which can be misleading since they often support different sets of TSN features. However, the consensus here is that two features are essential in TSN-ready network bridges: time-synchronization and time-aware traffic shaping (ie, traffic scheduling). These features allow any bridge to precisely synchronize with the network and transmit data at defined times with up to nanosecond precision. Some bridges already offer frame preemption, where important data frames can preempt unimportant data frames on the fly.
For end systems, the story is similar: Depending on the use case, TSN features might be implemented in specific hardware or, with lower cost, in software. In this latter case, TSN performance will not be the best, but first tests show that the determinism achieved suits use cases with millisecond-granular control loops. Faster, microsecond-granular control loops will require specific TSN hardware and software upgrades for the end systems.
The system perspective and open configuration and orchestration
As shown in →03, an automation system using TSN is built on end systems that produce and consume data transported via a TSN network using real-time, scheduled TSN bridges. To guarantee high determinism, these bridges need to be configured to define what data should be forwarded to where and when. TSN has an advantage here as it offers a method by which this configuration can be negotiated by the network configuration entities – CUC and CNC in →03 – based on the device requests. Engineering tools can also play a role in configuration via standard protocols such as NETCONF, the network configuration protocol, or RESTCONF (an HTTP protocol), as opposed to the proprietary configuration methods of fieldbuses.
While the debate on which specific protocol to adopt is ongoing, some switch vendors are already implementing the openly available NETCONF on their bridges. Such adoption hints that automation networks with TSN will not be owned by fieldbus vendors but instead will become an open market for network orchestration tools.
OPC UA and other higher-level protocols
OPC UA (which stands for “Open Platform Communications United Architecture” – a vendor-neutral architecture) is often named next to TSN as one of the pillars of the Industry 4.0 communication architecture. “OPC UA over TSN” generally refers to OPC UA PubSub (an OPC UA publish-subscribe standard) and, less often, to OPC UA client-server. This differentiation is based on PubSub’s real-time capabilities (currently in the last stages of standardization) and the lack of those in OPC UA client-server.
In any case, the advantage of TSN is that it is agnostic to the higher-level protocols, be they PubSub, OPC UA client-server, or any non-OPC UA application. As shown in →04, TSN provides communication on the lower levels, below the network level (“3”) of the Open Systems Interconnection/Reference Model (OSI/RM) and thus delivers standard interfaces to the applications and protocols above it in the diagram. Evaluations show that in a multi-hop network, TSN can ensure request-response latencies in the millisecond range even for constrained embedded devices running an OPC UA client-server.
Use case: TSN for next-generation train communication networks
The European railway industry is currently investigating a new-generation onboard train control and management system (TCMS). A TCMS would interconnect all onboard devices, including passenger Wi-Fi, door and brake safety controls and operator-oriented services using the existing train Ethernet network →05. The new TCMS aims to use a converged network infrastructure to integrate mixed-criticality safety functions, time-critical and mission-critical functions, and non-critical train functions. TSN capabilities match these requirements perfectly.
Use case: TSN early enablement for process automation
Process automation rarely requires microsecond-granular latencies and negligible jitter in data exchanges, but it will still benefit from the network determinism of TSN. TSN can ensure synchronicity between end devices and guarantee timely data exchange with very low jitter, fostering process control stability.
In today’s process automation, the operational technology (OT) and information technology (IT) networks are separate and the data in each domain is locked within it. TSN can unlock the domains to open up new opportunities via IT/OT integration, while still guaranteeing determinism in such converged networks. The IT/OT convergence on one network could enable the OT staff to access directly the intranet/Internet and download software updates or manuals. Moreover, universal and uniform data access simplifies maintenance and diagnostics and enables Big Data applications →05.
Network orchestration requirements
A vital part of TSN adoption is that the proprietary network orchestration mechanisms open up. Essential aspects here are the general network configuration and the items specific to end systems.
In large distributed systems with varying requirements, network configuration can quickly become complex. To mitigate this, TSN breaks down the system configuration. First, TSN splits end systems into Talkers (producers of data) and Listeners (data consumers). Next, the TSN network orchestration defines two configuration modules – the CUC (to serve Talker/Listener requirements) and the CNC (to manage the network topology and resource allocation). In a simple example, the CUC module collects the service requests from Talkers and Listeners and checks with the CNC whether these requests are feasible in the current network. Then, the CNC configures the network infrastructure, while the CUC provides the resulting configuration to the end systems.
TSN foresees the implementation of the CUC and CNC in one of three models. In the centralized system →06, these network orchestration tools are located in one place. In the distributed system →07, the CUC and CNC are distributed over the bridges as a set of communicating modules. These two models can be merged to create a hybrid system →08. The appropriate model is chosen based on the system’s complexity, the set of configured features and the capabilities of the end systems and bridges.
TSN enables the future of networks
With TSN, automation vendors will have the opportunity to provide solutions – ie, suitable combinations of TSN tools – that exploit the advantages of TSN to ensure the vendor’s own control over network performance in new projects. Moreover, brownfield sites with TSN-unaware end systems present an additional upgrade opportunity. The stepwise adoption of already-mature TSN mechanisms could be a solution for both greenfield and brownfield applications.
There are competitive advantages and business opportunities to be found in opening up information in the process industries. TSN enables the transition of today’s industrial automation pyramid to cloud solutions and an industrial Internet of Things, which will help exploit this information. TSN can enable coexistence of business-critical and production-critical traffic and create entirely new business models and innovations in many different industry segments.
Photo: ©bruno/stock.adobe.com
