Part 4 of the TSN series
The protocols of the upper layers
TSN only covers the lower OSI layers. There are various protocol approaches for the upper layers. Due to the deterministic requirements, these also have an impact on TSN itself - unlike in the past.
Florian Frick is group leader for real-time communication and control hardware at ISW Stuttgart.
© ISWEthernet, and therefore also TSN, covers OSI layers 1 and 2, which is why additional protocols are always required on the upper layers, which typically become increasingly application-specific as the layer increases. Proven IT protocols are often used, for example TCP/IP on layers 3 and 4, but industry-specific protocols are often used on the application layer, for example for automotive or professional audio video. There are currently several approaches in the industrial environment: A basic distinction must be made as to the extent to which TSN should be used - only up to the plant level or up to the field level.
field level. When it comes to use down to field level, there are two basic factions: On the one hand, the representatives of the 'fieldbus-over-TSN' philosophy and, on the other, those who want to achieve standardization through all levels and have come together within the OPC Foundation under the acronym OPC UA FLC (Field Level Communication).
Unlike in the past, it is no longer possible to achieve a clean decoupling between the lower and upper layers in deterministic real-time communication with TSN - the dependencies between the functions on the lower layers and the applications are simply too intertwined. In order to be able to use TSN interoperably, various groups have therefore been formed for the different industries, each of which specifies a common basis for the different protocols via TSN: The 802.1DG profile is being created for automotive, the Milan specification is being developed for professional audio video and the IEC/IEEE 60802 working group has been formed for industrial communication.
The extent to which the profiles will be sufficient to ensure that different protocols
will be sufficient for different protocols to coexist interoperably is still the subject of much controversy, as is the issue of cross-industry interoperability. In this issue of the article series, important factions of industrial communication take a stand on this topic on the following pages: the OPC Foundation, the Profibus user organization, the Ethercat Technology Group and the CC-Link Partner Association.
The TSN approach of the OPC Foundation
What is the OPC Foundation's approach to TSN?
Peter Lutz: OPC UA is not a transport protocol in the conventional sense. Rather, it is an industrial framework that contains mechanisms for secure, reliable, manufacturer- and platform-independent information exchange as well as options for semantic information modeling and self-description of devices. In contrast to other pure fieldbus protocols, OPC UA scales from the sensor across all levels to the MES and ERP systems, but also into the cloud - IT security, which is planned in from the outset, is also a key differentiating feature. With the help of a universal QoS modeling concept, modeled information and services with their respective QoS mechanisms can be easily mapped to various subordinate communication protocols and transmission physics.
The combination of OPC UA with other subordinate infrastructures enables new, extended areas of application: With TSN, OPC UA becomes real-time capable, and in combination with Ethernet-APL or SPE, OPC UA opens up new fields of application in the process industry, discrete manufacturing and beyond.
The OPC Foundation set up a working group back in June 2015 to specify corresponding PubSub extensions for TSN. In November 2018, the Field-Level Communications initiative was also launched to specify all the necessary requirements for OPC UA extensions for applications at control and field level for process and factory automation - including mapping to TSN.
OPC UA FLC end devices are configured via OPC UA - online or offline - and network infrastructure devices are configured via common network management protocols. Both centralized and decentralized configuration is supported. The protocols to be supported for the TSN configuration are compiled or selected in the TSN IA Profile IEC/IEEE 60802.
How does TSN affect your devices and the ecosystem?
TSN extends the application spectrum of OPC UA to areas that require deterministic communication. In addition to a direct layer 2 mapping from OPC UA to TSN for applications with corresponding requirements in terms of real-time capability and protocol efficiency, a layer 3 mapping via UDP is specified to ensure flexible use of OPC UA in the process industry and also in factory automation.
Thanks to the modular principle of OPC UA, all basic services, the information models, the semantic self-description and the security mechanisms remain unchanged and backwards-compatible. This means that existing toolkits can continue to be used and conventional OPC UA devices can be integrated into the communication.
To what extent is your approach interoperable in terms of convergent networks?
The OPC Foundation has made a clear commitment to the IEC/IEEE 60802 profile to ensure that different protocols can use a standardized network infrastructure. We see this as important not only with regard to the convergence of IT and OT, but also to support the migration of conventional fieldbus and real-time Ethernet protocols to a standardized communication solution. The clear objective of the FLC initiative is to standardize the higher protocol layers as well as the semantics of the various control and field devices in factory and process automation in order to contribute to the standardization of the currently heterogeneous protocol and profile landscape.
Are there already existing solutions or when can they be expected?
OPC UA solutions are already available on the market from a large number of different providers and are used in a wide variety of application areas. The first OPC UA devices with TSN have already been presented as prototype implementations.
The specifications that enable cross-vendor interoperability between controllers and field devices from different manufacturers are currently still being developed. A first version of the specification is due to be released this year. We expect this to be implemented in corresponding OPC UA products in the near future.
Why is OPC UA suitable for the digitalization of production?
As a first step, the OPC Foundation's FLC initiative makes it possible to connect devices from different ecosystems horizontally (and deterministically with TSN). The vertical expansion of OPC UA into the field level provides a standardized solution that covers all relevant applications - including motion, safety and real-time - in industrial automation and at the same time ensures complete consistency from the sensor to the cloud and vice versa.
The major advantage of a consistent OPC UA-based solution is that no protocol conversions or data conversions are required to access process and production-relevant information that is needed to implement Industry 4.0 concepts. Instead, the modeled information in the corresponding devices - such as controllers and field devices - can be accessed directly via a uniform communication standard - and this is secure, manufacturer-independent and future-proof.
*) FLC for short
The TSN approach of the Profibus user organization
What approach does the Profibus user organization take in combination with TSN?
Dr. Peter Wenzel: During the specification work on Profinet, care was taken to ensure that suitable international standards - IEEE and IEC - were incorporated into the architecture of Profinet. Profinet-specific mechanisms were only defined for communication mechanisms for which no suitable standards were available.
For example, the IRT protocol1) was developed for hard real-time. Profibus InternationaI - PI for short - has started to integrate
relevant TSN functions into the Profinet architecture has generated added value for the customer and also placed Profinet on a future-proof foundation for Industry 4.0. The basic idea is to now offer TSN as a third option on layer 2 alongside RT and IRT.
When integrating TSN into Profinet, parameters were used that are specified in the relevant IEEE 802.1 standards for synchronization2), TAS3) and preemption4).
Simple configuration of network parameters is crucial for user acceptance. To simplify and standardize this process, the concept of a Network Management Engine - NME for short - was developed. It is to be located in the Profinet controller. The familiar engineering tools will remain the same, but planning will be made considerably easier, as the creation of a network configuration in TSN will no longer be part of the engineering, but will instead be part of the runtime functions in the controller or device. The NME should enable networks to be rescheduled during runtime.
How does TSN affect your devices and the ecosystem?
A cornerstone of PI's strategy is that Profinet can also be operated with underlying TSN at field level. The user view with standardized access to data from production, to diagnostic information and also to profile-relevant parameters such as PA devices or Profisafe remains unchanged. In addition to RT/IRT, TSN 'only' offers additional layer 2 access to a convergent TSN network. Mixed systems can be set up in compliance with defined rules, which enables flexible transitions and extensions from RT/IRT to TSN in brownfield systems.
As a further cornerstone, PI relies on OPC UA as 'middleware' at plant level, i.e. for manufacturer-independent data and information exchange between different controllers and machines. In most cases, this already works on the basis of the TCP/IP substructure and is given additional desired properties with the new Pub/Sub mechanisms. In conjunction with TSN, all of this enables the use of standard hardware, which has a very positive effect on costs for both providers and users.
To what extent is your approach interoperable in terms of convergent networks?
A necessary prerequisite for a high degree of interoperability is the existence of an open interface specification. At PI, this is ensured by globally uniform test standards for the certification of product interfaces. With TSN, interoperability can be raised to a higher level so that different Ethernet systems that use TSN can interoperate. Profinet is designed to coexist with other communication systems such as TCP/IP. Only the bandwidths need to be regulated for parallel operation. This means that Profinet can basically coexist with AVB or the various IT protocols, for example.
The aim of the TSN Industrial Automation Profile5) of IEC/IEEE 6080 is to define a uniform TSN standard for industrial applications in such a way that devices that 'speak' different communication systems can interoperate in the sense of a convergent TSN network. The timetable envisages making the profile available in 2021/22.
Are there already existing solutions or when can we expect them?
TSN is available with the Profinet specification V2.4. Even before the specification work was completed, the first implementations had already been created by several basic technology providers and the concepts for certification had been developed. The early creation of test cases made it possible to start tests at an early stage during the product development phase.
Why is your approach suitable for the digitalization of production?
In order to make Profinet suitable for use in Industry 4.0 generation production systems, the responsible working groups have specified open semantic and information models for the device description and application-related data to be transferred. OPC UA as a vertical communication channel and the use of the OPC UA Information Model for the transitions from Profinet to OPC UA were defined as the basis for implementation.
The implementation of a digital factory requires a high level of machine-processable, standardized information that is available across companies and industries. As a first step, PI has provided features for the provision of device know-how, for example in the form of parameters in device profiles and through definitions on the application layer, such as for an asset management record. However, in order for these to be used as the basis for a machine-processable data flow across the various systems from the sensor to the cloud, the data must be converted into usable information with the help of semantic standards. In cooperation with eCl@ss e.V., semantic identifiers are added to the parameters defined by PI.
1) Isochronous Real Time
2) 802.1 ASrev
3) time aware shaper, 802.1Qbv
4) 802.1Qbu
5) TSN IA profile
The TSN approach of the Ethercat Technology Group
What approach is the Ethercat Technology Group pursuing in combination with TSN?
Martin Rostan: The defining use case for Ethercat is the controller, which communicates 'downwards' within the machine via Ethercat with high performance and hard real-time capability with I/Os, drives and sensors, and 'upwards' exchanges data across machines via Ethernet: with higher-level and neighboring controllers as well as with local and cloud-based systems such as SCADA, ERP and MES.
TSN technologies will also make the 'upper' Ethernet network deterministic - we welcome this and will use it accordingly. Ethercat below the controller does not require TSN technologies: Ethercat has always been hard real-time capable.
The clean structuring of the overall system, which is necessary for stable operation, is only possible if both networks remain separate: if both the 'lower' and 'upper' network nodes share bandwidth and address space and therefore have to be coordinated in the configuration, then the actual machine-internal network part can only be put into operation once the complete network has been set up at the customer's site - and any future expansion of the system then potentially has repercussions on the function of each subsystem.
With our TSN approach, we are opening up the possibility of connecting entire Ethercat segments to a heterogeneous Ethernet network in real time: For this purpose, we will tunnel Ethercat frames via TSN streams, whereby TSN features are no longer required or present within the Ethercat segment. This expands the topology options. The structure is almost completely retained: as only one frame and only one address are required per Ethercat segment, the TSN network is hardly burdened and the configuration is almost independent of the rest of the network.
Incidentally, we are deliberately not advocating a stand-alone solution for the TSN configuration: Ethercat itself will not be based on TSN technologies, but will be linked to future heterogeneous TSN-based networks.
How does TSN affect your devices and the ecosystem?
Practically not at all: Ethercat itself remains stable and will not be subject to versioning problems in the future. Ethercat slave devices do not need to be changed at all because TSN plays no role within the segment. Adaptation to the TSN stream*) will still take place in the TSN switch or in the first device, which must then be equipped for this - leading switch manufacturers have promised their support for this. Controllers that want to communicate with Ethercat segments via the TSN network only require a software extension: here, the Ethercat frames are inserted into the TSN stream.
To what extent is your 'Ethercat-and-TSN' interoperable in terms of convergent networks?
Interoperability - or rather coexistence - with other protocols is precisely the aim of our approach. That is why we are also actively working on IEC/IEEE profile 60802.
Are there already existing solutions or when can we expect them?
The use of TSN only makes sense when TSN technologies can fulfill their promises: using standard Ethernet hardware to operate different protocols deterministically and in parallel, and configuring the network independently of the manufacturer. Looking at the availability of the chips and the progress made in standardizing the TSN configuration, it will take some time.
Why is Ethercat suitable for the digitalization of production?
Because Ethercat already meets the requirements today: extremely fast communication without complex IT configuration where it matters. And IT connectivity - also via OPC UA - where it is needed. And with stable technology, the widest range of devices on the market and no security worries.
1) Stream adaptation
The TSN approach of the CC-Link Partner Association
What approach does the CLPA pursue in combination with TSN?
Christoph Behler: As a user organization, the CC-Link Partner Association - CLPA for short - is the contact for CC-Link IE TSN. CC-Link IE TSN combines the gigabit bandwidth of Ethernet with Time-Sensitive Networking technology for the first time. TSN stands for a new era of data exchange and creates the prerequisites for mastering the challenges of the convergence of the IT and OT worlds.
It is the first open Ethernet technology to combine gigabit bandwidth with important TSN functionalities, time synchronization and data flow prioritization. It also enables the integration and use of existing CLPA networks. The CLPA creates interfaces between OSI Layer 2 and 3. CC-Link IE TSN is set up using a software configuration platform that configures the IE TSN master. All features of the participating devices are parameterized and managed.
How does TSN affect your devices and the ecosystem?
CC-link IE TSN extends data transparency and consistency. Not only ASIC-supported developments are now possible, but also software developments based on standardized TSN hardware. This reduces the development costs for rapid implementation of adaptations.
CC-Link IE TSN is downward compatible and existing CC-Link systems can be integrated, as CC-Link networks inherently support deterministic data traffic. This offers investment protection for existing developments and installations.
Depending on requirements, software solutions implemented on IEEE 802.1AS and IEEE 1588-compatible standardized TSN Ethernet hardware are sufficient for time-critical applications. There is also the option of implementing chips in the master, slave or remote stations for high-performance applications.
The master handles the network configuration on the one hand and the control of data traffic from and to the slaves on the other. The slaves send their information to the master for further processing. Cross-communication between the slaves is possible.
To what extent is CC-Link IE TSN interoperable in terms of convergent networks?
The CLPA has already worked closely with other user organizations in the past and developed a specification for the network coupling of CC-Link IE with Profinet. This development and its benefits will also be continued with CC-Link IE TSN, especially as the data from both systems is coexistent and available on the same TSN network infrastructure. The coexistence, i.e. parallel operation, of different networks already exists. Interoperability is created on the higher layers, such as the application layer.
The 'IEC/IEEE 60802 TSN Profile for Industrial Automation' standard developed in the joint IEC/IEEE 60802 project will become the future basis for the industrial Internet in automation.
We have already implemented the parts of the IEEE802.1 standard in CC-Link IE TSN that have already been published. In particular, the 802.1Qbv, time aware shaping, and 802.1AS, time synchronization, should be mentioned here. IEEE 802.1AS-2020, which has not yet been released, will be taken into account in future development. In addition, the CLPA is involved in developing standardized CA*) test specifications and offering them to partners. This will ensure the quality, coexistence and interoperability of development solutions from a wide range of providers. Synergies are desired and can be exploited.
Are there already existing solutions?
The CC-Link IE TSN protocol has been published since 2018 and has already been implemented in many different devices, components and software stacks. This is supported by the wide range of global technology partners with hardware and software solutions - such as ASICs, embedded boards and software protocol stacks. In addition, CC-Link IE TSN-based safety solutions will be developed in the next step.
Why is CC-Link IE TSN suitable for the digitalization of production?
CC-Link IE TSN is a holistic transparent communication concept for data traffic from the business level with cloud connection to the field level with individual sensors and vice versa. It also enables IT and OT worlds to grow together. This ensures barrier-free data exchange between deterministic and non-deterministic systems
and between systems with different transmission speeds, for example 1 Gigabit and 100 Mbit, as required by the Industry 4.0 concept. This brings us closer to fulfilling this concept.
By combining gigabit bandwidth and TSN technology, we are able to be the first user organization to offer a high-performance network for industry. With CC-Link IE TSN, it is possible to exchange information transparently and bidirectionally across all levels and, for example, to collect data from production processes in real time, process it via edge computing and then transfer it seamlessly to IT systems or cloud servers. The CLPA partners are also already working on OPC UA implementation via CC-Link IE TSN above the controller level.
*) Conformance Assessment
You might also be interested in
An intermediate goal has been reached!
Two years after its launch in November 2018, the OPC Foundation's Field Level Communications Initiative has completed the initial release candidate for the 'Controller to Controller' use case. What is behind this release and what are the next steps?
read more...The future is transparent, convergent and "time-sensitive"
Industry 4.0 has established itself as a trend for factory automation. The aim is to achieve greater convergence and transparency between IT (information technology) and OT (operational technology). Time-Sensitive Networking (TSN) technology is an...
read more...SPS Connect 25.11. - 14:10 - 14:30
CC-Link IE TSN: Open the Future of Connected Industries
The presentation explains the latest developments in the field of open industrial Ethernet and explains how CLPA is taking the step into the future with CC-Link IE TSN.
read more...SPS Connect 25.11. - 15:45 - 16:05
OPC UA for the field level - the status quo
The OPC Foundation's Field Level Communications (FLC) initiative was launched with the aim of bringing OPC UA to the field level and thus has the potential to change industrial communication in the long term and to the benefit of all market...
read more...The key role of configuration
Time Sensitive Networking is gaining ground in convergent networks with critical applications and strict time requirements. But what needs to be considered in network planning? And why does configuration play a key role?
read more...New Board of Directors elected by rotation
The general meeting of the Profibus User Organization (PNO) took place on 14 September 2020 - virtually for the first time due to the coronavirus pandemic. The agenda included the regular election of the Executive Board.
read more...International TSN Conference 2020
Ethernet gets a real-time extension with TSN - and even a new transmission medium with 5G! The impact on all industries will be the focus of the TSN/A Conference on October 7 and 8, 2020, which will be held as a virtual event this year.
read more...TSN alone is nothing!
Yes, TSN is the new basic technology for convergent real-time communication. But which protocols will actually be based on the TSN layers and become established on the market has not yet been decided. In this article, four protagonists have their...
read more...Prototyping and testing of TSN
Very high demands are placed on TSN in terms of interoperability. What contribution do cross-manufacturer testbeds make here? How can the implementations of TSN standards and interoperability be tested?
read more...