TSN series part 17
First steps into practice
Is Time Sensitive Networking still grey theory or can TSN-based networks with controllers from different manufacturers already be implemented today? A setup with B&R and Beckhoff controllers was created at Kempten University of Applied Sciences. A field report.
Driven by the benefits of more standardized, new technologies, the Time-Sensitive Networking Standard, or TSN for short, is emerging as a possible real-time capable fieldbus alternative. This picture is underlined by the absence of proprietary hardware and Ethernet formats, meaning that TSN can be integrated with and into existing Ethernet networks. The only flaw is that the TSN standard is still in a definition phase, which leads to a current lack of usable hardware and software and makes the evaluation of a TSN network time-consuming.
The following components were used to implement a manufacturer-independent TSN network at Kempten University of Applied Sciences: a TSN Ethernet switch 0ACST052.1 provided by B&R as well as two B&R and one Beckhoff controller. The TSN Ethernet switch is used to implement the manufacturer-independent TSN network between the two B&R controllers and the Beckhoff controller, in which the participants communicate via OPC UA Pub/Sub: one of the B&R controllers acts as a talker/publisher and has a B&R controller and a Beckhoff controller as counterparts that serve as listeners/subscribers. Test data streams in the network are measured using Wireshark and the network is loaded with non-prioritized data streams and Ethernet frames of maximum length in order to put the TSN functionality through its paces.
The configuration of the switch
The Slate XNS tool from TTTech Industrial and an OPC-UA client, in this case UaExpert from Unified Automation, are required to configure the TSN switch. After connecting to the TSN switch via OPC UA, a user account must be created there and assigned the corresponding roles. This makes it possible to transfer the TSN network configuration from the Slate XNS tool to all devices participating in the network via Secure Shell and YANG model/XML.
|
A reality check |
|---|
|
Time-Sensitive Networking (TSN) has been the focus of research, development and many discussions for years. Even though standards are still being developed and many issues have not yet been finally resolved, an increasing number of products are in the starting blocks or are already available on the market. And a lot can still be expected in 2022, particularly in terms of available infrastructure and corresponding hardware components. There are already some testbeds that are implementing and evaluating TSN scenarios - but these examples are generally still manufacturer-driven. In this article, Prof. Josef Griesbauer and Alexander Sturm from Kempten University of Applied Sciences take a close look at the interaction of controllers from two manufacturers via TSN from an independent perspective and explain their impressions. A big thank you for this from our side. As always, we welcome any feedback, comments or suggestions on our series. Yours, Florian Frick and Meinrad Happacher (redaktion[at]computer-automation.de) |
When creating the network in Slate XNS, the participants are distributed to the corresponding ports of the TSN switch and the connection type - copper cable or fiber optic connection - and the length of the cable/fiber are specified in order to be able to calculate the transmission delay. For the configuration of the actual TSN streams, a 'talker' (transmitter) is always assigned to one or more 'listeners' (receivers), and a VLAN ID and a VLAN priority are assigned. These are different for each stream in the network and are used to identify the TSN packets so that the TSN infrastructure can recognize important traffic and transmit it via the TSN stream. Different VLAN IDs and priorities can be used to implement and prioritize multiple data streams in a network. Based on the maximum permitted latency specified for each listener, Slate XNS tests whether transmission is possible within the parameters or whether the network topology or cable lengths would result in a latency that is not permitted for the safe use of the network. If errors occur, the user is warned and can adjust the network project in order to finally transmit the configuration of a successfully planned TSN network to the participants.
Configuration of the Publisher/Talker in Automation Studio
To create the pub/sub configuration for the B&R controllers in Automation Studio, after creating the hardware configuration, an OPC UA configuration must be added under "Connectivity", in which only variables that are activated for use by OPC UA can be used. All important settings, such as the multicast address of the packets, the publisher ID and the transmission interval, are defined there and the published dataset of a 'writer group' is generated, in which it is specified which variables are contained at which point in the DataSet messages of the OPC UA pub/sub system. For simple configuration of the subscribers, this configuration can then be exported as a '.uabinary' file by right-clicking on the publisher configuration and read in again by the subscribers so that they can interpret the transmitted binary data correctly. The settings for the TSN functionality of the pub/sub system must be explicitly displayed on the configuration page (green button in the top bar of the editor) in order to be able to edit the VLAN configuration and set it to the values assigned in Slate-XNS, such as VLAN ID 3 and Priority Code Point 7.
Configuration of the subscriber/listener in Automation Studio
As with the procedure for the publisher side, an OPC UA configuration must again be created for the subscriber side in which the target variables are to be entered. In the pub/sub configuration, the entries (multicast address, port, publisher ID and the VLAN settings) must match those of the publisher. The "Reader Group" can be created using the exported ".uabinary" file by right-clicking on the entry "Reader Groups" -> "Import uabinary". All necessary parameters and the sequence of the DataSet variables are automatically transferred and can be assigned to the PLC variables.
Configuration of the subscriber/listener in TwinCAT
The OPC UA pub/sub module for TwinCAT is required to create a subscriber for the Beckhoff controller in TwinCAT. After creating the project, a "Real-Time OPC UA Device" must be added under "I/O->Devices" and a ".uabinary" file must be imported under the "Settings" tab in the "Offline Management" area. As a result, TwinCAT automatically creates all relevant objects with the correct settings and the OPC variables can be linked to the PLC variables.
The measurement results
After the configurations described, the data streams generated for the test - individual I/O data from the controllers - could be transferred without any further problems. To evaluate the network set up, various observations were made in which the network was partially loaded by additional data streams: A UDP packet flooding with 50 µsec interpacket delay, fixed length of 1472 bytes and 75% utilization of the bandwidth in unicast and multicast was carried out. This resulted in the following transmission times:
- Transmission times/jitter without additional network loads:
Standard deviation: 17 µseconds
Maximum jitter: 198 µseconds (single packet) - Transmission times/jitter with additional network loads:
Standard deviation: 19 µseconds
Maximum jitter: 192 µseconds (single packet)
Overall, this confirms the vision of a convergent network envisaged by TSN, in which both real-time and "standard" network participants can communicate together in one and the same medium without restrictions.
A summary
The authors: Prof. Dr. Josef Griesbauer (left) is Professor of Automation and Measurement Technology at Kempten University of Applied Sciences, Alexander Sturm is a student completing his Bachelor's thesis at Kempten University of Applied Sciences.
© HS KemptenBoth B&R and Beckhoff have done their homework, despite the still partially undefined TSN standards: both the configuration and operation of a real-time-capable pub-sub network via TSN are possible. At the same time, the status of the unfinished standard is still evident: many paths have to be taken with additional tools - Slate XNS, OPC UA client - and with basic know-how acquired in-house. Irrespective of this, this application example demonstrates that the future is already open for the use of TSN and PubSub.
|
The advantages of TSN |
|---|
|
The technologies established in recent years as Industrial Ethernet, such as Profinet, Ethernet Powerlink or Ethercat, raise the question of what advantages the IEEE802-TSN can still offer. In contrast to Profinet or Powerlink, the 802-TSN works directly on the data link level of the ISO-OSI model, i.e. below the IP stack, and yet, unlike Ethercat, remains completely compatible with other Ethernet devices. This enables the creation of convergent networks, i.e. networks that can route both deterministic control data and less important other data streams via the same medium. An entire automation company could thus be realized in a single network: machines would communicate securely and in real time via the same network, workstation computers would access controllers, sensors or actuators directly and the entire office communication would be handled. The full bandwidth of the Ethernet could be used to realize larger data streams within a machine or between machines and other participants in the network. All in the spirit of big data and the large volumes of data required in Industry 4.0, for example for predictive maintenance or machine learning. Overall, this leads to a major advantage in the form of an open and cross-industry standard in which everything available on higher layers of the OSI model can be easily adapted for use with TSN. |
You might also be interested in
A common test plan for the industry profile
Avnu, CLPA, ODVA, OPCF and PI are cooperating to generate a standardized test plan for the emerging TSN profile IEC/IEEE 60802 for industrial automation. All the organizations will be able to test their products for conformity with the new profile.
read more...Focus on interoperability
Testbeds play a decisive role in the development of TSN towards a cross-manufacturer ecosystem. What progress has the TSN testbed at ISW made in recent years and what current challenges are currently being discussed there?
read more...Call for Papers - submit presentations by April 29
The TSN/A Conference has become 'the' international information and discussion platform for real-time Ethernet par excellence. Become part of the community and submit your presentation to the presence event on September 28 and 29!
read more...Distributed real-time applications based on TSN
Time-Sensitive Networking (TSN) is one of the key technologies for future distributed real-time applications. In addition to the actual TSN-based communication, the ecosystem and its components must be considered for successful implementation.
read more...Uniform standard for real-time data communication
Automation and networking are basic requirements for Industry 4.0. Reliable data communication at high transmission rates is essential. TSN helps to merge IT and OT into a uniform network without compatibility problems.
read more...Multi-vendor demo celebrates its premiere
Three years after its launch, the OPC Foundation's Field Level Communications (FLC) initiative has now completed the second release candidate - a multi-vendor installation demonstrates the progress made.
read more...Virtualized control systems using TSN backbone
The major challenges in implementing virtualized control systems are scalability and connectivity to the field level. An implementation at the ISW shows that this can already be achieved today using a TSN network.
read more...TSN in combination with EtherCAT
TSN is an important building block for convergent communication in flexible production. Mastering and integrating existing fieldbus technologies such as EtherCAT is an important part of the transition. An inventory of what is already possible.
read more...TSN - backbone for virtualized control systems?
It is currently a major vision: the virtualization of control systems. This and the next article in this series will address this topic. The decisive prerequisite and content of this article is the connectivity of the control system right down to...
read more...