ISW Stuttgart
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.
The globalization, regionalization and personalization of markets are having a profound impact on manufacturing companies. Flexibility and changeability are necessary to meet these requirements. Various technologies, paradigms and perspectives are seen as enablers of this flexibility and changeability. What these approaches have in common is the increasing networking of the systems used in production. After all, flexibility can only be guaranteed if all systems involved have transparent information at all times. However, communication streams from operational technology (OT) and the control levels (IT) must be brought together for increasing networking. The Time-Sensitive Network (TSN) enables the coexistence of OT and IT communication streams through the standardization of a real-time capable data link layer (layers 1 and 2 of the OSI layer model) by the IEEE. TSN thus makes it possible to maintain the real-time requirements of OT communication while at the same time allowing the network to be used by IT communication. TSN is therefore considered a key technology for this convergent communication. Under the term Industry 4.0, which was coined at the Hannover Messe in 2011, TSN has therefore been used for many years to work towards flexibility and changeability. What has already been achieved?
| 9th TSN/A Conference |
|---|
|
"Application of TSN" - this is the motto of the international TSN/A Conference, which will take place this year on October 1 - 2 in Stuttgart. Become part of the community and discuss the use of the real-time Ethernet standard with experts and users. Take a look at the program and secure your early bird ticket by the end of July! |
TSN as a key technology?
One challenge in the development of TSN standardization is the time required. As a result, product-ready technologies that support important TSN standards for automation have only recently become available.
Another challenge is that TSN only covers the lower communication layers and the higher layers are implementation-specific. OPC UA with the pub/sub extension for real-time communication is one of the most promising candidates to fill these layers in the green field. However, the transition to new technologies will not be seamless due to complexity, unresolved dependencies and network configuration. The interoperability of existing technologies is therefore an important step towards convergent communication based on TSN. Many fieldbuses therefore rely on compatibility and use TSN on the lower two layers, for example EtherCAT and Profinet. But to what extent can the fieldbuses actually already be used convergently in a TSN network?
The EtherCAT candidate
EtherCAT is an established fieldbus that is enjoying growing popularity, partly due to its real-time performance, which also meets critical time requirements such as motion, but also because of its openness and the associated large number of software stacks that are available. This makes EtherCAT an ideal candidate for convergent communication via TSN.
An EtherCAT network consists of a single master and several slaves. The physical wiring can be implemented as a combination of star, tree and line topology. The logical topology is always a ring. The master is the only communication device that sends EtherCAT telegrams. This collective telegram contains the EtherCAT data of all slaves and passes through all communication devices that receive the output process data, enter the input data and forward the telegram. The telegram is sent back to the master by the last device. In addition to the cyclical process data, acyclical data is also exchanged via mailboxes.
| 9 TSN/A Conference |
|---|
|
"Application of TSN" - this is the motto of the international TSN/A Conference, which will take place this year on October 1 - 2 in Stuttgart. Become part of the community and discuss the use of the real-time Ethernet standard with experts and users. Take a look at the program and secure your early-bird ticket by the end of July! |
Synchronization between the devices in an EtherCAT network is based on the Distributed Clock (DC) mechanism. The clocks of all DC-capable devices are typically synchronized to the clock of the first DC-capable slave with an accuracy of less than 100 ns. This allows high-precision time stamps to be assigned to recorded data and synchronization to be achieved, which is essential for motion control applications.
The convergence project
The analysis and evaluation of the already possible convergence potential was carried out at ISW using a cloud-based scenario. This scenario is based on the vision of software-defined manufacturing (SDM), which stands for the separation of hardware and software. In the scenario implemented, a single IPC controls several machines.
EtherCAT uses Broadcast Media Access Control addresses (MAC addresses) to send telegrams to all slaves. Consequently, it is not possible to use the same cable for multiple EtherCAT networks. Additional mechanisms need to be implemented. The EtherCAT Technology Group (ETG) has published the TSN communication profile ETG.1700, which solves this problem by mapping to two unidirectional streams with a defined MAC address. This is implemented via an adaptation layer in the EtherCAT master and in EtherCAT slaves, which is referred to as stream adaptation. The project described here does not use the stream adaptation described in the ETG.1700 profile, but several Virtual Local Area Networks (VLANs), which are defined in the IEEE 802.1Q standard. This makes it possible to use conventional EtherCAT bus couplers instead of specialized TSN-capable couplers.
Although the data traffic of several EtherCAT networks can now flow through the same cable, the synchronization of the clocks still needs to be defined. TSN provides for synchronization of all network participants to a global clock using the Precision Time Protocol (PTP). This is therefore a different technology to the DC mechanism of EtherCAT. This can be solved in a brownfield-friendly way by using the EtherCAT master as a reference clock in the DC mechanism and synchronizing the EtherCAT master to the global TSN time. This procedure is also described in the ETG.1700 profile.
Figure 2: TSN schedule: The three EtherCAT networks are scheduled in three separate time slices.
© ISWThe structure and evaluation methods are shown in Figure 1. The IPC and the TSN switch were realized with freely available products from Kontron. The EtherCAT Terminals come from Beckhoff. The libethercat stack from DLR is used for the EtherCAT master.
The TSN schedule is implemented as shown in Figure 2: Three data traffic classes are used; The three EtherCAT networks are scheduled in three separate time slices. This means that the EtherCAT masters send the cyclical process data packets in their time slices.
The analysis method
Two measurement methods are used to evaluate the real-time performance of the system. Firstly, the data traffic of each cable is monitored and measured using a network test access point (TAP), which has a constant and deterministic monitoring latency. The data traffic is mirrored using the TAP and analyzed in a separate evaluation PC. The clocks of this PC are synchronized with the TSN time. In this way, the latency times of network packets can be precisely determined according to the TSN time domain.
In addition, an EtherCAT slave with a digital output generates a periodic square-wave signal by switching the output in each cycle. This signal is then measured with an oscilloscope and the signal jitter is determined.
The results
The latencies are determined using the scheduled transmission times of the cyclical process data telegrams. They result from the difference between the time a packet arrives at the TAP and the scheduled transmission time. Monitoring takes place separately from the TAP in both packet directions. The four monitoring points Master->Switch, Switch->Slave, Slave->Switch and Switch->Master are therefore used. Two different methods are used to comply with the scheduled transmission times with a Linux RT system.
First, a classic RAW_SOCKET is used(Figure 3). A jitter of 30µs of the packets can be measured, which is caused by the network stack of the Linux kernel. The TSN switch does not add any measurable jitter. The jitter can be reduced using the SO_TXTIME function of the Linux kernel(Fig. 4). Here, the planned transmission time is passed to the network card and the network card uses this time to send the packet at the planned moment. The measurements show that the number of outliers decreases and the jitter decreases slightly. However, a packet loss based on the telegram distance cannot be observed.
The measurements with the oscilloscope are carried out for one minute(Fig. 5). A time span without packet loss is selected for SO_TXTIME. The jitter when using RAW_SOCKET is approx. 7 µs, which is slightly higher than that of SO_TXTIME, which is approx. 2 µs. The signal jitter is therefore lower than the telegram jitter of the periodic EtherCAT packet, which is due to the compensation of the DC mechanism.
The quintessence
The author: Marc Fischer is a research assistant for software and engineering methods at ISW, Stuttgart.
© ISWThe question posed at the beginning can therefore be answered as follows: The EtherCAT fieldbus can already be used convergently in a TSN network. However, the Linux network stack causes a jitter of around 30 µs on the test system used. Another Linux network function is the eXpress Data Path (XDP), which enables packets to be sent and received bypassing the kernel network stack and reduces jitter. Currently, SO_TXTIME cannot be used in combination with XDP, but there are already some patches that try to bring this function into the mainline Linux. XDP is therefore an open topic for future work, which is being addressed by the ISW.
The author: Moritz Walker is a research assistant for software and engineering methods at ISW, Stuttgart.
© ISWTunneling of EtherCAT through TSN based on VLANs and the use of existing EtherCAT couplers is possible. The detailed analysis of time synchronization shows that synchronization of EtherCAT slaves with the DC by the EtherCAT master in a TSN network is possible. It was also demonstrated that the architecture presented enables the operation of several EtherCAT networks via a single cable.
| TSN in practice - time for pragmatism |
|---|
|
The convergence of IT and OT systems as a central enabler for the digitalization of production is accepted throughout the industry. The fact that convergent real-time communication, and therefore TSN, plays a central role in this is hardly ever discussed. However, there is considerable disagreement regarding the question of when TSN has reached the necessary level of maturity. It is certainly true that many challenges still need to be solved for the vision of fully software-defined production, for example in terms of configuration. But does it actually make sense to wait for the 100% solution? Can we perhaps already benefit more from TSN today than we realize? One topic that gives this question new urgency is the discussion about virtual programmable logic controllers. There is broad agreement that these will play an important role in the future, but there is still a lot of guesswork about connectivity and scalability. In this and the next articles in this series, we want to take a closer look at what is already possible today. In this issue, we first take a detailed look at the extent to which EtherCAT and TSN can be used together without adapting the existing components. The article shows that more is already possible with this combination than most people are probably aware of. In the next issue, we will take a more global look at the topic and analyze how different TSN-based and traditional fieldbuses can communicate via a common TSN network - and bring virtual PLCs to life in the process. As always, we welcome any feedback, comments or suggestions on our series. Yours, Florian Frick and Meinrad Happacher PS: Are you interested in TSN? Then come along to our 9th TSN/A Conference! Take a look at the program now! |
You might also be interested in
TSN application engineering
How can the decoupling of network configuration and application engineering work in TSN applications? What could future workflows look like and how will engineering tools be affected? A proof of concept based on open source solutions points the way.
read more...AI - Paving the way for TSN?
What requirements does the use of AI place on automation and networking? Do the mechanisms of Time Sensitive Networks in combination with Profinet perhaps form the optimal architecture for AI applications?
read more...Enabler of SW-defined production?
Digitalization is often reduced to the addition of digital services to traditional systems. However, the real potential lies in a digital ecosystem that needs to be established as part of software-defined manufacturing - TSN plays an important role...
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 - 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...The e-paper of issue 07/2024
Read in the current issue of Computer&Automation how ChatGPT can provide support in the conception phase, how LLMs are used in code analysis and whether TSN can be considered as a backbone for virtualized control systems.
read more...TSN application engineering
How can the decoupling of network configuration and application engineering work in TSN applications? What could future workflows look like and how will engineering tools be affected? A proof of concept based on open source solutions points the way.
read more...Enabler of SW-defined production?
Digitalization is often reduced to the addition of digital services to traditional systems. However, the real potential lies in a digital ecosystem that needs to be established as part of software-defined manufacturing - TSN plays an important role...
read more...On the way to Manufacturing-X
The Manufacturing-X initiative is driving forward the digitalization of supply chains in industry. But what does a factory that can handle this need to look like? The ISW at the University of Stuttgart provides answers to these questions.
read more...