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
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 2 of 13
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.
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 3 of 13
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
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 4 of 13
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.
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 5 of 13
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
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 6 of 13
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.
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 7 of 13
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
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 8 of 13
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
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 9 of 13
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
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 10 of 13
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.
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 11 of 13
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 and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 12 of 13
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.
EtherCAT and TSN ‐ Best Practices for Industrial Ethernet System Architectures
© 2017 EtherCAT Technology Group www.ethercat.org Page 13 of 13
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.