EtherCAT and TSN - Best Practices for Industrial Ethernet ... · PDF file12 List of ... the profile at the master and slave segment adaptation is ... Ethernet has a history that spans

EtherCAT and TSN ‐ Best Practices for

Industrial Ethernet System Architectures

Author Dr. Karl Weber, EtherCAT Technology Group

Abstract EtherCAT is the dominant technology in the fieldbus domain, and Ethernet is the standard for

wired office applications using switching technology. TSN is the enabler for real‐time

communication in a heterogeneous environment. In some cases, a combination of these two

technologies is required. A better understanding of TSN and the streaming concept is a

precondition for a successful implementation at the factory floor. The adoption of EtherCAT in

this environment can be done very efficiently, with an upgrade at the master side and no

changes to the slaves, and a moderate extension in the bridges connecting EtherCAT segments.

Whitepaper

EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures

© 2017 EtherCAT Technology Group www.ethercat.org Page 1 of 13

Content

I. Objective ...................................................................................................................................... 2

II. EtherCAT and TSN – Best Practices for Industrial Ethernet System Architectures ......................... 3

1. Evolution of TSN ...................................................................................................................... 3

2. Possible Application Scenarios ................................................................................................. 5

3. Understanding TSN .................................................................................................................. 6

3.1 The TSN Task Groups ................................................................................................................. 6

3.2 EtherCAT streaming in IEEE 802.1 Networks ............................................................................ 9

4. EtherCAT and TSN: A Perfect Match ....................................................................................... 12

List of Figures

Figure 1. Industrial Ethernet Communication Evolution ......................................................................... 3

Figure 2. EtherCAT performance advantages for shared frames, and optimized forwarding ................ 4

Figure 3. Scheduled traffic latency enhancement by blocking other traffic ........................................... 7

Figure 4. Difficulty finding an optimal schedule in TSN ........................................................................... 7

Figure 5. Streams are reserved communication channels within an Ethernet channel ......................... 8

Figure 6. TSN enables isolation of EtherCAT communication in a network .......................................... 10

Figure 7. Stream adaptation and TSN provides a virtual Ethernet channel .......................................... 11

Figure 8. TSN and EtherCAT protocol fields separated ‐ no additional protocol needed ..................... 11



I. Objective

Time Sensitive Networking (TSN) has been a well‐known acronym since the task group was founded in

the Institute of Electrical and Electronics Engineers (IEEE) working group 802.1. This whitepaper

explains how to use this up‐and‐coming technology in the context of industrial automation. TSN is a

technology that can be used in a variety of applications, including audio/video (A/V), automotive,

mobile network base stations and energy generation. The TSN model introduces the streaming of data

in the IEEE 802.1 context. It supports a set of features to improve the real‐time capability of streaming,

but does not define how to use it in a dedicated environment. The term “toolbox” is used to explain

that a model is needed to describe the TSN application in the context of industrial automation.

The EtherCAT approach does not mix both technologies, but defines an adaptation to use TSN streams.

There is no selection of specific TSN elements; the profile at the master and slave segment adaptation

is usable with all options to forward time sensitive streams. There is no change needed within a slave

segment. Therefore, this profile requires attention for the master system provider to integrate stream

adaptation and a system integrator to select the components required for TSN‐to‐EtherCAT segment

adaptation. This mapping should help manufacturers of automation components, machine builders

and technology experts at the manufacturing site take the appropriate steps in order to adopt TSN.



II. EtherCAT and TSN –

Best Practices for Industrial E thernet System Architectures

1. Evolution of TSN

TSN is a set of bridging standards that connects end nodes. “Bridging” is the term used in standards

activities, but the popular term is “switching”. It is independent of the underlying communication

technology, although Ethernet is the preferred TSN base. The use of switches has no impact in regards

of reaction time for typical office users as there are not many switches between the web client and

the web server, and the human interaction requires network transactions in the second range. The

understanding of low latency communication in the context of switched networks requires a closer

look at standard office communication.

Ethernet has a history that spans over 40 years. It was initially a joint effort of Digital Equipment, Intel

and Xerox to establish a flexible way to interconnect computers. The primary use case at the time was

the connection of workstations to servers. Flexibility was crucial from the beginning, so the

communication was organized using the “best‐effort” principle, which is based on client‐server

communication. Best‐effort means that clients can access data equally, and that no clients are granted

priority access to data. If too many clients are trying to access a single path at the same time, the

communication is delayed and so is the server response.

This principle did not change with the Internet, but the workstations evolved into PCs and ultimately

smartphones, all accessing web servers and the cloud. Ethernet is a Local Area Network (LAN) concept

that acts as a subnet of the Internet. However, subnets tend to become larger and larger and the

original Ethernet concept does not scale with the number of nodes. The bridging technology,

introduced more than 25 years ago by IEEE 802.1, improves this situation significantly. It enables the

simultaneous use of networks with different speeds and allows easy integration of other networking

technologies such as wireless. Bridges divide the communication system into end nodes and

communication infrastructure. The best‐effort paradigm was the baseline for all of these technology

developments.

Figure 1. Industrial Ethernet Communication Evolution



Industrial communication protocols – generally referred to as fieldbuses – took shape in the late 1980s,

with a breakthrough around five years later. Industrial controllers no longer needed to be monolithic,

vendor‐specific blocks with extensive cabling to sensors and actuators, but instead a structured

network of I/O components from multiple technology providers. The baseline for technology in

automation has always been a guaranteed level of service quality. This means efficient use of

communication bandwidth, low frame drop rate and a limited communication delay. Dedicated

communication technology was the choice at the beginning, but the higher bandwidth and availability

offered by PC‐based systems placed Ethernet in a viable position for fieldbus use as well. However, the

best‐effort policy makes it difficult to use Ethernet in automation the same way as in the Internet

domain. Even the organizations that try to use an unmodified infrastructure have established quite a

few rules regarding the use of Ethernet in the fieldbus environment, such as limiting non‐real‐time

traffic or reducing the number of nodes. The fieldbus approach is an integrated network that leads to

two‐port devices, which can be used to replace the line topology common to fieldbus networks. Using

an individual frame approach for field devices with a typical process data size in the range of eight

bytes results in poor efficiency, wasting as much as 90 percent of the Ethernet bandwidth, just like a

delivery truck transporting each packet individually. This challenge is a major reason why the EtherCAT

approach using Ethernet was successful. EtherCAT offers a completely modified bridging concept that

can resolve the Internet infrastructure issues as described. Shared frame forwarding and processing

on the fly are the key improvements that enable high performance applications to fully harness the

capabilities of Ethernet.

Figure 2. EtherCAT performance advantages for shared frames, and optimized forwarding

A paradigm shift in the IEEE 802 world, TSN addresses the real‐time needs of various industries. TSN

forwards frames as fast as possible in the IEEE 802.1 context and without losses due to congestion.

This implies many changes in the best‐effort world that may take a while to resolve. However, it does

not address the basic problems of Ethernet, which are efficiency of the individual frame approach,

along with the complexity and performance of the forwarding procedure.



TSN is not a true fieldbus replacement because it only offers 10 percent of the performance available

in alternate solutions and it forces users to wait for required fine‐tuning of systems by the technology

providers. The chances of successfully replacing CAN or PROFIBUS with TSN are practically zero.

EtherCAT provides much higher performance for a given transmission speed. Therefore, TSN cannot

replace EtherCAT as a fieldbus.

However, TSN has advantages in scenarios with heterogeneous requirements and high amounts of

Internet traffic. The combined use of cameras and/or various different real‐time standards may be a

reason to use TSN as a backbone. An embedded PC with a single Ethernet interface can use the TSN

network access as a virtual port multiplier. The coexistence of EtherCAT as a fieldbus with already

available devices and TSN will be another option in the automation communication infrastructure over

the next decade.

2. Possible Application Scenarios

TSN is not limited to industrial automation. On the contrary, there are many other possible use cases.

The initial use case was in A/V applications, as the IEEE 802.1 task group used to be known as AVB

(Audio Video Bridging). The early standard helped enhance professional A/V installations such as live

video transmission of sporting events. It was also possible to set up large audio installations using the

technology. One advantage in this environment was the ability to quickly change the data flow without

shutting down the whole system. Improved flexibility with less cabling was the major reason to switch

from the analog installations to Ethernet and wireless. There will be more demanding applications in

the future such as 3D pictures with changeable views, or systems with highly precise distance

measurement. These features require very precise time synchronization. High system availability is a

very important factor for quality live streaming and it requires a reasonable frame loss ratio, as well as

the possibility to react quickly to system failures. Some requirements in the area of augmented reality

(AR) can also be reasons to use this technology in a larger field of applications. In the future, this can

be possible with TSN.

The second use case for Ethernet‐based technology was to supplement automotive infrastructure.

CAN had been the networking technology for quite a few subsystems in the automotive industry, but

cameras and other complex infotainment systems drove demand for much higher bandwidth.

Diagnostics and service of the electronic subsystems in vehicles was the other reason for integrating

an Ethernet backbone. Having both applications on a single network requires the separation of the

data traffic patterns. Communication for advanced powertrain systems can be another reason for

enhanced communication.

Currently, this is controlled by an isolated network, which requires additional cabling and computing

power to feed in new signals. Connecting and synchronizing all networks in a car can lead to additional

control options, and the mechanical and electrical components can be monitored to implement high

level condition monitoring functions and more accurate service indicators. The resulting “cable tree”

is an expensive component in a modern car. A TSN backbone approach, combined with efficient

subsystems, can significantly improve car designs in terms of time critical data exchange. While TSN is

the primary choice for the automotive backbone and for the camera system, the integration of CAN

subsystems and the powertrain may be interesting areas for Ethernet applications. Nevertheless, both



communication technologies have characteristics similar to protocols found in industrial automation,

especially if an enhanced electrical drive subsystem is used. The pervasiveness of Ethernet in

automotive systems will boost the industry, and quite a few of these elements may be interesting to

the automation industry as well.

Affecting another enormous consumer‐focused industry, mobile networks will be powered by TSN in

the near future, and Ethernet will power the backhaul communication infrastructure. This is the

communication layer between radio equipment (RE) units and the RE control infrastructure.

Synchronization is a very important task and the frame loss rate is another crucial factor. The fifth

generation of mobile networks (5G) will add quite a few additional performance requirements, and

the market’s technology providers have started a project to use TSN as the control infrastructure for

backhaul networks.

A/V technology is also being incorporated in the automation industry, and further developments in the

areas mentioned above can accelerate the adoption of these systems. A/V nodes tend to have byte

counts in the range of 500 – 1,000 bytes, so they could be moved into a specific data traffic class below

the industrial requirements. The robot market will also grow quickly, and the combination of robots

and other machines require some time‐sensitive communication. Currently, this is solved by using

fieldbus communication, however, the other machines and/or their PLCs act as devices in such a

network as well. The chances of a specific combination of machines and robots may not support the

same protocol is high. TSN would make the communication infrastructure much simpler as robots and

machines need no multiple interfaces for the various kind of communication needs. A common

infrastructure at that level can accelerate the use of robots and smart machinery, all using a standard

communication interface for multiple purposes.

Further possibilities to combine TSN with fieldbus technology will be discussed in the section that

examines TSN in the context of EtherCAT.

3. Understanding TSN

3.1 The TSN Task Groups

The TSN task group within the IEEE 802.1 working group is responsible for enhancing the real‐time

capabilities of bridged networks. The communication between end nodes in TSN is done by “streams”.

The IEEE 802.1 standards use the term “talker” for the sender of a stream, and the term “listener” for

the receiver of a stream. A stream is a unidirectional flow of data from a talker to one or more listeners.

An RT stream talker will not send more than a number of frames with a number of octets per interval.

A stream requires stream identification in order to function in an IEEE 802.1 network. Several

identification schemes can be used, but a few of the TSN standards use the destination MAC address

and the VLAN for stream identification. There are several standards that address different aspects of

streaming.



To date, the TSN group has initiated the following standardization projects:

Improved synchronization behavior (IEEE 802.1ASbt) The previous version of IEEE 802.1AS had already specified a synchronization protocol for the

timing of distributed clocks, based on the IEEE 1588 standard. It had promoted the integration

into a standard Ethernet environment. However, compatibility with other 1588 Ethernet

profiles was lost. The new version will incorporate the accepted features of one‐step

transparent clocks. The main area for improvement right now is the response to error

situations, such as failure of a communications line or a master. The new version should also

be able to deal with different time domains in a device.

Frame preemption (IEEE 802.1Qbu) A major problem for deterministic transfer of time‐critical messages is

legacy traffic on the same network segment, where an individual frame can

be more than 1,500 bytes long. This can result in delays of up to 125 μs per

node cycle. This problem can be addressed by using a frame interruption

mechanism (specified within the IEEE working groups in Ethernet project

P802.3br). Ultimately, this mechanism will require not only new network

components, but also new Ethernet integrated circuits (ICs) in the end

systems.

Enhancements for scheduled traffic (IEEE 802.1Qbv)

The time control of send operations plays a key role in TSN. Just like in

physical roadways, there may be traffic jams on information highways, and

even with high‐priority, real‐time data and preemption, there may still be

some variation in transmission times. Since the time‐sensitive streams are

transmitted cyclically, largely undisturbed communication can be realized

by blocking less time‐critical data just before cyclic communication. The

procedure is comparable to traffic light control.

Figure 4. Difficulty finding an optimal schedule in TSN

Path control and reservation (IEEE 802.1Qca)

In order to get from A to B as quickly as possible, you need a map and a route planner. Just like

in everyday life, a network requires one to capture the way in which components are arranged

Figure 3. Scheduled traffic latency enhancement by blocking other traffic



and determine how to select the communication routes in the most efficient manner. The

protocol can be based on the “Intermediate System to Intermediate System” (IS‐IS) concept,

which is also used by routers. This concept involves gathering and distributing topology

information. After several iterations, all nodes have all of the topology information from the

entire network. If there are several possible routes that lead to the destination, the procedure

can be used to find the shortest one. It can also be used to identify redundant routes. This

project was initiated outside of TSN.

Seamless redundancy (IEEE 802.1CB)

Although international standards already provide specified protocols for seamless redundancy

such as High‐Availability, Seamless Redundancy (HSR), or the Parallel Redundancy Protocol

(PRP), they require the complete data exchange between stations be designed for redundancy.

This can cause problems because the order of the messages is not maintained if there is an

error. In addition, troubleshooting is quite complex. For IEEE 802.1, it was decided to explicitly

apply seamless redundancy only to individual critical data streams. This makes it possible to

reduce the protocol overhead, and it means critical points are easier to identify.

Stream bandwidth reservation (IEEE 802.1Qcc)

A major problem with Ethernet is found in

overload situations, such as when data are

received through two channels and

forwarded over a single output. A large

memory is also sub‐optimal, since the delay

increases with the number of bytes stored.

This delay (best‐effort) cannot be controlled

by increasing the response time in

automation technology. If real‐time data

streams have high priority, this results in a

risk that the rest of the communication is

delayed forever. For this reason, the required

stream bandwidth is determined and reserved. The reservation protocol allows a real‐time

load of up to 80 percent of the bandwidth. It is an extension of the existing reservation

protocol. It has become clear, though, that it will not be feasible to meet all the extended

requirements of TSN by merely extending the existing reservation protocol. This means that it

will still be necessary to find additional mechanisms for implementing real‐time channels in

the future.

Cyclic scheduling (IEEE 802.1Qch)

This is a procedure that involves the forwarding of time‐critical messages only to the

immediate neighbor device during each cycle. This is advantageous if the cascading depth is

low or the number of nodes on a single path with cyclic scheduling is low. The approach can

help integrate wireless devices or other components with a latency that is difficult to

determine, and it is more robust than time control. It allows the easy calculation of cycle times

and may help limit the schedule calculation in complex systems.

Figure 5. Streams are reserved communication channels within an Ethernet channel



Per stream filtering and policing (IEEE 802.1Qci)

An additional aspect discussed by the experts is how to limit the effects of nodes that behave

incorrectly. To this end, the incoming side (ingress) of the nodes must monitor the link traffic

on a per stream base. Depending on the number of streams, this could be a difficult task. If

more bandwidth is consumed than is allowed, specific actions will be taken. One possible result

could be the disabling of a stream that produces errors.

IEEE 802.1Q YANG data models (IEEE 802.1Qcp)

YANG is the new modelling language which should replace MIB, so the idea is to remodel all

MIBs. The starting point is a generic bridge model that should be provided by this standard.

The IEEE 802.1Qcc standard suggested a configuration model that relies on YANG, but this

standard will provide just a few models of the overall data needed.

Asynchronous traffic shaping (IEEE 802.1Qcr)

This shaper optimizes the latency within a traffic class with multiple streams. The work on this

standard has just started and requires a data base in the range of 0.1 Qci.

Link local registration protocol (IEEE 802.1CS)

This standard implements a base protocol for configuration elements. It is optimized to carry

a larger data volume than MRP. The work on this standard has also just begun.

Auto attach to PBB (IEEE 802.1Qcj)

Provider bridging configuration using Link Layer Discovery Protocol or LLDP (this is not used in

industrial automation)

Profile for fronthaul (IEEE 802.1CM)

Telecom TSN profile (not used in industrial automation)

3.2 EtherCAT streaming in IEEE 802.1 Networks

TSN could be used in heterogeneous networks, but it cannot replace EtherCAT. Because EtherCAT uses

standard elements at the master side, it could be connected to a TSN infrastructure as well. The

connection to TSN, however, has the drawback of adding additional latency in the communication

between master and slave. Yet, it offers the possibility to use a higher data rate if the master has

several communication tasks. Therefore, a couple of hops in a TSN network may consume around 10

µs. However, now it is possible to connect four EtherCAT subsystems and a video system, do the

communication with the controlling station of a subsystem, and run all the interconnections to the

Internet. A single gigabit Ethernet interface is enough for the various communication needs. Therefore,

standard architectures and embedded systems can serve as a multi‐purpose infrastructure in

automation with a TSN subsystem upfront.

The structure and performance at the I/O level is quite different from a typical switched environment.

For efficiency reasons, an EtherCAT segment should be kept together. Again, the latency within a

segment of 10 EtherCAT slaves is around 10 µs (but now with 100 Mbps link speed). This leads to a

structure with a master at one side, a segment with a couple of slaves on the other side and a TSN

network in between. Adding a network infrastructure between the master and the slave segment does



not change the isolation paradigm of such a group, but it does transform a physically separated

network into a logically separated network. This enables a higher level of flexibility for master devices,

and it will maintain a guaranteed latency as well as a predictable frame loss rate.

Figure 6. TSN enables isolation of EtherCAT communication in a network

EtherCAT uses the stream concept of TSN with a one‐to‐one relationship between talker and listener,

unless otherwise specified. A TSN stream will transmit a certain number of bytes within a given interval.

The defined amount of data may be greater than the transmitted number of bytes, but not less than

the reserved bandwidth.

At least two streams will be established between a master and an EtherCAT segment. One goes from

the master to the slave segment and vice versa. Another stream may be used for control purposes of

a group of EtherCAT slaves (client/server kinds of communication). This kind of communication may

have different traffic characteristics and can be put in a lower priority class. Further communication

requirements, such as collecting data for condition monitoring, may require another pair of streams.

The TSN profile describes how to transmit EtherCAT data within a bridged network according to IEEE

802.1. The configuration of the bridges and other bridge‐related service functions are not described in

the EtherCAT‐specific profile, but will be handled in the TSN context. The basic requirements of a

virtual EtherCAT channel in the master is to have a dedicated identifier of the related EtherCAT slave

segment and the send interval, a limit of data that can be sent, and optionally a send time between

the intervals. These are the parameters defined for send streams at the master side. The receive time

of the stream flowing backwards is needed at the master side.



The maximum delay in the slave segment has to complete the schedule. The bridge‐related parameters

are the additional time constraints needed to calculate the EtherCAT turnaround time in this context.

The architectural view is as follows: The identification

of EtherCAT segments will be unique within an IEEE

802.1 network. Address duplication will be detected

by multiple responses to a single request stream.

The identification is a 12‐bit value, which can be set up

by an EtherCAT device within or next to a streaming

instance. The other option is to assign a VLAN

identifier (VID) to an EtherCAT segment to the bridge

port connected to the EtherCAT segment. The use of

VID makes it easier to handle EtherCAT segments in an

IEEE 802.1 environment, as a port VID is a well‐known

parameter of managed switches.

The stream adaptation in the master, and in front of

the EtherCAT segment, use the identification to set up

the slave addresses needed for streaming. According

to the TSN standards, the stream needs unique

addressing. This addressing is deduced from

identification combined with an address field reserved

for EtherCAT.

The mapping principle is straightforward: The

EtherCAT fields will not be changed by TSN and the TSN

fields are not used for EtherCAT processing.

Figure 8. TSN and EtherCAT protocol fields separated ‐ no additional protocol needed

An EtherCAT slave segment corresponds to a VID. In this particular case the VID would be sufficient in

combination with the priority field in the VLAN tag to operate. This is a special form of VLAN with just

two end nodes. TSN stream processing is done with stream addresses that are the destination

addresses of the frame. The bandwidth allocation and the forwarding depend upon these addresses.

Therefore, a mapping of the ID to the individual streams is required.

Figure 7. Stream adaptation and TSN provides a virtual Ethernet channel



EtherCAT Stream Address (Header) Identifier

0x 01 05 06 yy yz

X=2: Locally Administered Address yyy: Set by Device ID/ VID

Used for Unicast Communication z: Stream Selector

X=3 Group Address

Used for TSN Streams

Synchronized operation is possible in such networks by sending the frame with a fixed interval from

the IEEE 802.1 network into the EtherCAT slave segment. This requires a limited latency variation. The

send time into the EtherCAT segment is determined by the worst‐case latency. TSN allows synchronous

operations and can provide a global time base to enable synchronous actions beyond a single EtherCAT

slave segment. The quality of synchronous operation depends on the quality of the synchronization

within TSN (IEEE 802.1AS) to keep a precise time and perform timed actions with a very low jitter. The

EtherCAT accuracy is in the range of 100 ns. It is recommended to use bridges that provide a precise

timing in the 100 ns range between the EtherCAT master and the first slave.

4. EtherCAT and TSN: A Perfect Match

Automation applications can vary greatly in form, size and performance requirements.

A car body shop for instance is a very complex application

example: about a thousand robots and thousands of control

units could be connected to tens of thousands of sensors and

actuators.

One robot could consist of several drives and I/Os. Many

sensors provide just a digital or analog signal as data for the

control system. Thousands of I/O boxes help collect and

distribute the process data. On top of such a system, an IEEE

802.1 network may act as the backbone for the automation

infrastructure.

It would be a nightmare to connect and configure all the I/O

boxes, drives and control units directly to this application with

a TSN enhanced network. It would be a never‐ending story

and could imply that every machine element must be

configured outside the manufacturer. It is a very open

solution, but it may be hard to protect the machine from

being configured incorrectly or to maintain the desired

service quality level.

A concept is needed to ensure the appropriate structure from

the top down and from the bottom up.

Limitations of TSN

TSN does not provide an

application layer: TSN is

not a fieldbus.

TSN will not challenge

the EtherCAT Device

Protocol at the field

level.

However

TSN will make inroads in

existing and upcoming

solutions, e.g. EtherCAT

Automation Protocol

(EAP), EtherCAT

Topology Extension, OPC

Publisher/Subscriber

Model.



The intention of this whitepaper is not to cover all these aspects, but to discuss how to integrate the

machine level approach in TSN. One way is to decouple EtherCAT and TSN using a gateway in the

master. Ethernet TCP/IP communication can be routed through the master. Additional flexibility of

network configuration can be achieved by connecting EtherCAT master interfaces and EtherCAT

segments to TSN. The combination of a group of slaves (I/O boxes, drives, etc.) into an EtherCAT

segment significantly reduces the number of streams needed in TSN, and helps protect this group while

increasing the efficiency of the combined EtherCAT/TSN system by an order of magnitude. The reasons

for such an integration could be missing Ethernet interfaces at the master side (quite a few virtual

interfaces are possible with a gigabit Ethernet link) or the mixture of A/V with EtherCAT in a single

infrastructure. Sharing existing communication wiring, but upgrading an existing system with EtherCAT

could be a reason to use TSN. It would be a good opportunity to enhance the flexibility of automation

systems and serve as a step to boost real‐time performance at the automation cell level while

maintaining total control of the various automation tasks.

In conclusion, EtherCAT allows perfect integration with TSN technology without changing the basis

of EtherCAT technology.

Documents

EtherCAT and TSN - Best Practices for Industrial Ethernet ... · PDF file12 List of ... the profile at the master and slave segment adaptation is ... Ethernet has a history that spans