EtherCAT – The Ethernet Fieldbus

2

Contents

A bus system might not be everything …

3

A bus system might not be everything …

4

EtherCAT at a glance

6

The EtherCAT Technology Group8

Why use EtherCAT?

10
10
11
12
14
16
18
19
21
22

The technology in detail
EtherCAT: Based on Ethernet technology
How does EtherCAT work?
The EtherCAT protocol
Flexible topology
Distributed Clocks for high-precision synchronization
Diagnostics and error localization
Principle of EtherCAT MainDevice independent diagnostic interface
High availability requirements
EtherCAT G: Communication at gigabit levels… but a machine is nothing without it!
It forms the core of the system architecture
and its performance also determines
whether the entire system is able to reachits full potential. The bus system is also
a key factor in determining system costs,
commissioning time, and robustness.
A good engineer therefore selects the rightbus technology first of all when designinga system.
We’ve written this brochure to introduce
you to EtherCAT, the Ethernet fieldbus. Not
only will you get to know EtherCAT – youwill also learn what makes EtherCAT thefastest Industrial Ethernet standard.
This brochure also presents the EtherCAT
Technology Group (ETG), the world’s largest
fieldbus organization. Most importantly,
we hope to convey why EtherCAT is theright choice for your application. If you
have any questions, feel free to contact us.
We’re passionate about EtherCAT and lookforward to hearing from you.
On behalf of the
EtherCAT Technology Group team,Martin Rostan, Executive Director,
EtherCAT Technology Group

24 System overview
26
28
30
33
35
36

EtherCAT P: Communication and power in one cable
Safety over EtherCAT
Communication profiles
Plant-wide communication with the EtherCAT Automation Protocol (EAP)
Integration of other bus systems
Powering the digital transformation with EtherCAT, Industry 4.0 and IoT

38 Implementing EtherCAT interfaces
40 Implementing a MainDevice (MDevice)
42 Implementing a SubDevice (SDevice)
44 Conformance and certification

47 Contact

Martin Rostan, Executive Director,
EtherCAT Technology GroupThe worldwide ETG team
at a global strategy meeting.

34

EtherCAT at a glance

EtherCAT is a high-performance, low-cost,easy to use Industrial Ethernet technology
with a flexible topology. It was introduced
in 2003 and has been an international
standard since 2007. The EtherCAT
Technology Group promotes EtherCAT andis responsible for its continued development.
EtherCAT is an open technology: anyone isallowed to implement or use it.

How it works
EtherCAT’s key functional principle lies in
how its nodes process Ethernet frames:
each node reads the data addressed to it
and writes its data back to the frame allwhile the frame is moving downstream.
This improves bandwidth utilization (oneframe per cycle is often sufficient forcommunication) while also eliminating
the need for switches or hubs.

Network performance
The unique way EtherCAT processes frames
makes it the fastest Industrial Ethernet
technology; no other technology can top
EtherCAT’s bandwidth utilization or the
performance it elicits.

5Flexible topology

Low-cost

Open technology

In addition it its speed, an EtherCAT network
can support up to 65,535 devices without
placing restrictions on their topology:
line, bus, tree, star – or any combination
thereof. Fast Ethernet physics allows two
devices to be up to 100 m (330 ft) apart,and greater distance scan be achieved withfiber optics. EtherCAT also has additionalfeatures that offer further topologicalflexibility, such as Hot Connect and
Hot Swap for devices, and added
redundancy through a ring topology.

EtherCAT delivers all of the advantages ofIndustrial Ethernet at fieldbus prices. How?
Firstly, EtherCAT doesn’t require any active
infrastructure components.
The controlling device doesn’t requirea special interface card and the connected
devices use highly integrated, cost-effective
chips available from a variety of suppliers.
Furthermore, there’s no need for costly
IT experts to commission or maintain thesystem.

EtherCAT is an internationally standardized
open technology, meaning anyone isfree to use the technology in a compatible
form. However, being an open technology
doesn’t mean that anyone can arbitrarilychange EtherCAT to suit his or her needs.
This would put an end to interoperability.
The EtherCAT Technology Group, theworld’s largest fieldbus organization, is
responsible for the further developmentof EtherCAT so it remains both open andinteroperable.

Versatility
EtherCAT is suitable for both centralized
and decentralized system architectures.
It can support MainDevice-to-MainDevice,
MainDevice-to-SubDevice and SubDeviceto-SubDevice communication as well as
incorporate subordinate fieldbuses. At
factory level, the EtherCAT Automation
Protocol has communication covered – allwith the existing infrastructure.

Simplicity
When compared to a classic fieldbus
system, EtherCAT is the obvious choice:node addresses can be set automatically,
there’s no need for network tuning, andonboard diagnostics with fault localization
make pinpointing errors a snap. Despite
these advanced features, EtherCAT is alsoeasier to use than Industrial Ethernet:
there are no switches to configure,and no complicated handling of MAC
or IP addresses is required.

Industrial Ethernet
EtherCAT also supports common internet
technologies without jeopardizing the
network’s real-time capability. Its Ethernet
over EtherCAT protocol transports FTP,
HTTP, TCP/IP, etc.

Functional safety
Safety over EtherCAT is just like EtherCAT
itself – lean and fast. Functional safety
is built directly into the bus with options
for both centralized and decentralized
safety logic. Thanks to the Black Channel
approach, it is also available for other bus
systems.

Tried and tested
EtherCAT is currently in use across theglobe in an unrivaled range of applications.
EtherCAT is used in machine control,
measurement equipment, medical devices,automobiles and mobile machines, and ininnumerable embedded systems.

6

ETG exhibition booths present
the technology as well as thebroad EtherCAT product range.

ETG holds regional member
meetings on a regular basis.

The EtherCAT Technology GroupThe EtherCAT Technology Group keeps
EtherCAT technology open for all
potential users. It brings EtherCAT device
manufacturers, technology providers,and users together to further thetechnology.
It provides multiple Technical Working
Groups where experts carefully work on
various specific aspects of EtherCAT. Allof these activities are focused on one
common goal: keeping EtherCAT stable
and interoperable. That’s why there is
only a single version of EtherCAT, and not
a new version each year.
The ETG holds multiple EtherCAT Plug
Fests in Europe, Asia, and America eachyear. These events bring EtherCAT device
developers together to test and ensure
device interoperability. Using the official
EtherCAT Conformance Test Tool, eachmanufacturer tests its EtherCAT devices forconformance prior to their release. The ETG
awards the manufacturer a conformancecertificate following a successful test in an
accredited test lab.
The ETG also holds internationalseminars and workshops and represents
EtherCAT at exhibitions throughout the
globe. It also provides product guides, joint
exhibition booths, and seminar exhibits
to help its members market their EtherCAT
products.

The ETG has the largest number of membersout of any fieldbus organization in theworld. The list of members can be foundon the ETG’s homepage. However, thecrucial factor is not how many members
there are, but how active the members arein the ETG. Both the number and variety
of EtherCAT devices are unparalleled, andEtherCAT’s adoption rate across the globe
is outstanding.

Become a member
ETG membership is open to all companies,
whether they be device manufacturers orusers.
ETG members:	receive access to technical specifications
and the developer’s forum	contribute to the further developmentof EtherCAT in the way of Technical
Working Groups	receive implementation support fromtheir local ETG office	receive free software stacks,
software tools, and access to additional
development products	are permitted to use the EtherCAT
and ETG logos	display their EtherCAT products andservices in the official EtherCAT Product
Guide, exhibitions, and at ETG events.

7

International standardization

Global activities

The EtherCAT Technology Group is an
official partner of the IEC. Both EtherCATand Safety over EtherCAT are IEC standards(IEC 61158 and IEC 61784). These standards
not only include the lower protocol layers,
but also the application layer and device
profiles, e.g. for drives. SEMI™ (Semiconductor
Equipment and Materials International)
has accepted EtherCAT as a communication
standard (E54.20) for the semiconductor
industry. The various task groups in
the ETG Semiconductor Technical Working Group (TWG) have defined industryspecific device profiles and implementation
guidelines.
The EtherCAT specification is available
in English, Japanese, Korean, and Chinese.

The EtherCAT Technology Group is active
worldwide. Experts in the ETG offices inGermany, China, Japan, Korea, and the USA
support ETG members before, during, andafter implementation.
The technology is maintained in several
Technical Working Groups (TWG), which
define enhancements and also homogenize
device behavior via device profiles andimplementation guidelines. All members
are encouraged to actively contribute to
the TWGs.

EtherCAT is also a national standard
in many countries, such as Korea
and China.

EtherCAT milestones

2003

2007

2011

2013

2015

2017

EtherCAT
introduced
ETG founded

EtherCAT becomesan IEC standard	EtherCAT becomesa SEMI standard	EtherCAT interface
in standard µP + µC

	2500 members
	Test Center in China
	10 Years of EtherCAT
and ETG

FSoE Test Center	Industrie 4.0
and IoT initiative	10 Years ETG Offices
in China, Korea
and USA	TSN Profile

EtherCAT G

2005

2008

2012

2014

2016

2018

2020

Safety over
EtherCAT
1st Plug Fest

EtherCAT
Conformance
Test Tool	1st Asian Plug Fest

	2000 members
	semiconductor
profiles	EtherCAT becomesa Korean standard

3000 members
	Test Center inNorth America	EtherCAT becomesa Chinese standard

4000 members
	EtherCAT P
	10 Years ETG
Office Japan

5000 members
50th Plug Fest	FSoE becomesa Chinese standard

6000 members	3000 Vendor IDs

2006

2009

Bylaws, the registration form, andadditional information are available via
info@ethercat.org and www.ethercat.org
EtherCAT ASIC

1000 members
Test Centers inGermany and
Japan

2019

2021

2023

2024

	1st Interoperability
Testing Week

	7000 members	20 Years of EtherCAT	7500 members

and ETG

2022
1st International
Technology Week
Dynamic Process
Data Channel

8

Why use EtherCAT?

9

The unique way that EtherCAT works makes it the engineer’s choice. The following
features are particularly advantageous for certain applications.

1. Exceptional performance
EtherCAT is by and large the fastest Industrial
Ethernet technology, but it also synchronizes
with nanosecond accuracy.
This is a huge benefit for all applications
in which the target system is controlled
or measured via the bus system. The rapid
reaction times reduce the wait times
during transitions between process steps,
which significantly improves application
efficiency. Lastly, the EtherCAT systemarchitecture typically reduces the load on
the CPU by 25–30% in comparison to otherbus systems (given the same cycle time).
When optimally applied, EtherCAT’s
performance leads to improved accuracy,
greater throughput, and thus to lowered
costs.

2. Flexible topology
In EtherCAT applications, the machine
structure determines the network topology,
not the other way around. In conventional
Industrial Ethernet systems, there arelimitations on how many switches andhubs can be cascaded, which places limits on
the overall network topology. Since EtherCAT
doesn’t need hubs or switches, there areno limitations. In short, EtherCAT isvirtually limitless when it comes to network
topology. You can create line, tree, star
topologies and any combinations thereofwith a nearly unlimited number of nodes.
Thanks to automatic link detection,

nodes and network segments can be
disconnected during operation and thenreconnected, even in another position if
required. Line topology is extended to a ring
topology to assure cable redundancy. All thecontrolling device needs for this redundancy
is a second Ethernet port, and the connected
devices will then support cable redundancy.
This means that devices can be switched out
during machine operation.

3. Simple and robust
Configuration, diagnostics, and maintenanceare all factors that contribute to systemcosts. The Ethernet fieldbus makes allof these tasks significantly easier: EtherCAT
can be set to automatically assign addresses,
which eliminates manual configuration.
A low bus load and peer-to-peer physics
improve electromagnetic noise immunity.
The network reliably detects potential
disturbances down to their exact location,
which makes troubleshooting far faster.
During startup, the network compares theplanned and actual layouts to detect any
discrepancies. EtherCAT performance also
helps during system configuration byeliminating the need for network tuning.
Thanks to the large bandwidth, additional
TCP/IP can be transmitted together withthe control data. However, since EtherCAT
itself isn’t based on TCP/IP, there is noneed to administer MAC addresses or
IP addresses or to have IT experts
configure switches and routers.

4. Integrated safety
Functional safety is integrated into the
network architecture with FailSafe over
EtherCAT (FSoE). FSoE has proven itself inpractice as it is used in TÜV certified
devices that have been on the market since2005. The protocol fulfills the requirements
for SIL 3 systems and is suitable for both
centralized and decentralized control
systems. Thanks to the Black Channel
approach and the incredibly lean safetycontainer, FSoE can also be used in otherbus systems. This integrated approachand the lean protocol help keep systemcosts down. Additionally, a non-safetycritical controller can also receive and process
safety data.

5. Affordability
EtherCAT delivers the features of Industrial
Ethernet at a price similar to or even belowthat for a classic fieldbus system. The only
hardware required by the MainDevice isan Ethernet port – no expensive interface
cards or co-processors are necessary.
EtherCAT SubDevice Controllers are available
from various manufacturers in different
formats: as an ASIC, based on FPGA, oras an option for a standard microprocessor
series. Since these inexpensive controllers
shoulder all the time-critical tasks, EtherCAT
itself doesn’t place any performancerequirements on the CPU of field devices,which keeps device costs down. EtherCAT
doesn’t require switches or other active
infrastructure components, so the costs forthese components and their installation,
configuration, and maintenance are also
eliminated.

For these reasons, EtherCAT
is often seen in:	robotics
machine tools	packaging machinery	printing presses
plastic manufacturing equipment
	presses
	
semiconductor manufacturing machines	test benches
pick and place machinery	measurement systems	power plants	substations
material handling applications
	baggage handling systems
stage control systems
automated assembly systems
	pulp and paper machinery	tunnel control systems
	welding machinery
cranes and lifts	farm machinery	offshore applications
sawmills
	window manufacturing equipment	building automation systems
	iron and steelworks
	wind turbines
furniture manufacturing equipment
milling machinery
automated guided vehicles
entertainment automation
	medical devices
	woodworking machinery
flat glass manufacturing equipment
	weighing systems
	and many more

10

The technology
in detail
EtherCAT: Based on
Ethernet technology
EtherCAT is Industrial Ethernet and utilizes standard frames and the physical layer as
defined in the Ethernet Standard IEEE 802.3. However, it also addresses the specificdemands faced in the automation industry, where:
there are hardline real-time requirements with deterministic response times
	the system is usually made up of many nodes, and each node only has asmall amount of cyclic process data
hardware costs play an even bigger role here than they do in IT and office applications.
The above requirements make it practically impossible to use a standard Ethernet networkat field level. If an individual Ethernet datagram is used for each node, the effective data
rate sinks significantly for just a few bytes of cyclic process data: the shortest Ethernet
datagram is 84 bytes long (including the interpacket gap), of which 46 bytes can beused for process data. For example, if a drive sends 4 bytes of process data for the actual
position and status information and receives 4 bytes of data for the target position andcontrol information, the effective data rate for both datagrams sinks to 4/84 = 4.8%.
Additionally, the drive usually has a reaction time that triggers the transmission of theactual values after the target values have been received. At the end, not much of the
100 Mb/s transfer rate remains.
Protocol stacks, such as those used in the IT world for routing (IP) connection (TCP),
require additional overhead for each node and create further delays through the stackruntimes.

11

How does EtherCAT work?
EtherCAT overcomes the difficulties described in the previous section with its
high-performing mode of operation, in which a single frame is usually sufficient
to send and receive control data to and from all nodes!
The EtherCAT MainDevice sends a datagram that passes through each node. Each
EtherCAT field device reads the data addressed to it on the fly and inserts its data into
the frame as the frame is moving downstream. The frame is only delayed by hardware
propagation delay times. The last node in a segment or drop line detects an open port
and sends the message back to the MainDevice using Ethernet technology’s full duplex
feature.
The datagram’s maximum effective data rate increases to over 90%, and, due to theutilization of the full duplex feature, the theoretical effective data rate is even greaterthan 100 Mb/s.
The EtherCAT MainDevice is the only node within a segment allowed to actively send
an EtherCAT frame; all other nodes merely forward frames downstream. This concept
prevents unpredictable delays and guarantees real-time capability.
The control unit uses a standard Ethernet Media Access Controller (MAC) without anadditional communication processor. This allows a MainDevice to be implemented on
any hardware platform with an available Ethernet port, regardless of which real-time
operating system or application software is used.
EtherCAT field devices use an EtherCAT SubDevice Controller (ESC) to process frameson the fly and entirely in the hardware, making network performance predictable andindependent of the individual SubDevice implementation.

The EtherCAT protocol

12

the data from each node has to be read individually, sorted with the help of theprocess controller, and copied into memory. With EtherCAT, the control device only
needs to fill a single EtherCAT frame with new output data, and send the frame to
the MAC controller via automatic direct memory access (DMA). When a frame withnew input data is received via the MAC controller, the control unit can copy the frame
into the computer’s memory via DMA – all without the CPU having to actively copy
any data.
In addition to cyclical data, further datagrams can be used for asynchronous or
event-driven communication.

EtherCAT embeds its payload in a standard Ethernet frame. The EtherCAT frame isidentified by the identifier (Ox88A4) in the EtherType field. Since the EtherCAT
protocol is optimized for short cyclic process data, bulky protocol stacks, such as
TCP/IP or UDP/IP, can be eliminated.

Ethernet header

ECAT

EtherCAT frame

Ethernet

Preamble

SFD

DA

SA

EtherType

Frame HDR

Datagram 1

Datagram 2

Datagram n

PAD

FCS

(7)

(1)

(6)

(6)

(2)

(2)

(10+n+2)(10+m+2)(10+k+2)(0…32)

(4)

13

MAIN
DEVICE

EtherType Ox88A4
EtherCAT in a standard Ethernet frame (according to IEEE 802.3)

To ensure Ethernet IT communication between the nodes, TCP/IP connections can also
be tunneled through a mailbox channel without impacting real-time data transfer.
During startup, the control unit configures and maps the process data on theconnected devices. Different amounts of data can be exchanged with each node,from one bit to a few bytes, or even up to kilobytes of data.
The EtherCAT frame contains the frame header and one or more datagrams.
The datagram header indicates what type of access the MainDevice would liketo execute:	read, write, or read-write	access to a specific field device through direct addressing, or accessto multiple field devices through logical addressing (implicit addressing).
Logical addressing is used for the cyclical exchange of process data. Each datagram
addresses a specific part of the process image in the EtherCAT segment, for which
4 GB of address space is available. During network startup, each node is assigned
one or more addresses in this global address space. If multiple nodes are assigned
addresses in the same area, they can all be addressed with a single datagram. Since
the datagrams contain all the data access related information in full, the MainDevice
can decide when and which data to access. For example, the MainDevice can use
short cycle times to refresh data on the drives, while using a longer cycle time tosample the I/O; a fixed process data structure is not necessary. This also relieves
the controlling device in comparison to conventional fieldbus systems, in which

Ethernet header

ECAT HDR

Datagram 1

Datagram 2

Datagram 3

Logical process,image task 1

Logical process,image task 2

Logical process,image task 3

Inserting process data on the fly

In addition to logical addressing, the control unit can also address a field device via its
position in the network. This method is used during network boot-up to determine the
network topology and compare it to the planned topology.
After checking the network configuration, the MainDevice can assign each nodea configured node address and communicate with the node via this fixed address.
This enables targeted access to devices, even when the network topology is changed
during operation, for example with Hot Connect groups. There are two approaches
for SubDevice-to-SubDevice communication. A SubDevice can send data directly toanother node that is connected further downstream in the network. Since EtherCAT frames

Ethernet14

can only be processed going forward, this type of direct communication depends on the
network’s topology, and is particularly suitable for for high-speed SubDevice-to-SubDevice
communication in a fixed machine design (e.g. in printing or packaging machines). In
contrast, freely configurable SubDevice-to-SubDevice communication runs through thecontrol device and requires two bus cycles (but not necessarily two control cycles). Thanks
to EtherCAT’s excellent performance, this type of SubDevice-to-SubDevice communicationis still faster than that of other communication technologies.

Flexible topology
Line, tree, star, or daisy-chain: EtherCAT supports almost all topologies. With
EtherCAT, you can create a pure bus or line topology with hundreds of nodes
without the limitations that normally arise from cascading switches or hubs.

MAIN
DEVICE

Flexible topology: line, tree, star, or daisy-chain

When wiring the system, the combination of lines with drop lines is particularly beneficial:
the ports required to create drop lines are directly integrated in many I/O modules, so no
additional switches or active infrastructure components are required. The star topology,
the Ethernet classic, can also be utilized.
Modular machines or tool changers require network segments or individual nodes
to be connected and disconnected during operation. EtherCAT SubDevice Controllers
already include the basis for this Hot Connect feature. If a neighboring station is removed,
then the port is automatically closed so the rest of the network can continue to operate
without interference. Very short detection times of under 15 microseconds guarantee
a smooth changeover.
EtherCAT offers a lot of flexibility regarding cable types, so each segment can use theexact type of cable that best meets its needs. Inexpensive Industrial Ethernet cables canbe used between two nodes up to 100 m apart in 100BASE-TX mode. Furthermore, theEtherCAT P technology enables data and power to be transmitted via one cable. This
option enables devices such as sensors to be connected with a single line. Optical fibers(such as 100BASE-FX) can also be used, for example for a node distance greater than 100 m.
The complete range of Ethernet wiring is also available for EtherCAT.
Up to 65,535 devices can be connected to one EtherCAT segment, so network expansion
is virtually unlimited. As a practically unlimited number of nodes are available, modular
devices such as sliced I/O stations can be designed so that each module is an EtherCAT
node of its own. The local extension bus is thus eliminated; the high performance of
EtherCAT reaches each module directly and without any delays since there is no gateway
in the bus coupler or head station anymore.

15

16

Distributed Clocks forhigh-precision synchronization

Since the time sent from the reference clock arrives at the field devices with a slight delay,
this propagation delay must be measured and compensated for in each field device in orderto ensure synchronicity and simultaneousness. This delay is measured during network
startup or, if desired, continuously during operation, ensuring that the clocks are
simultaneous with each other at within much less than 1 µs.

In applications with spatially distributed processes that require simultaneous action,
precise synchronization is particularly important. For example, this is the case forapplications in which multiple servo axes execute coordinated movements.
In contrast to completely synchronous communication, where communication errors
have an immediate impact on quality, distributed synchronized clocks have a high degreeof tolerance for jitter in the communication system. Therefore, the EtherCAT solution forsynchronizing nodes is based on these distributed clocks (DC).

tSynchronicity and simultaneousness– scope view of two distributed devices with 300 nodes and 120 m
cable length

MAIN
DEVICE

Completely hardware-based synchronization with compensation for propagation delays

The calibration of the clocks in the nodes is completely hardware-based. The time fromthe first DC SubDevice is cyclically distributed to all other devices in the system. With
this mechanism, the field device clocks can be precisely adjusted to this reference clock.
The resulting jitter in the system is significantly less than 1 μs.

If all nodes have the same time information, they can set their output signals simultaneously
and affix their input signals with a highly precise timestamp. In motion control applications,
cycle accuracy is also important, along with synchronicity and simultaneousness. In suchapplications, velocity is typically derived from the measured position, so it is critical thatthe position measurements are taken precisely equidistantly (i.e. in exact cycles). Even verysmall inaccuracies in the position measurement timing can translate to larger inaccuracies
in the calculated velocity, especially in relation to short cycle times. With EtherCAT, theposition measurements are triggered by the precise local clock and not the bus system,
leading to far greater accuracy.
Furthermore, the use of Distributed Clocks also frees up the control unit; since actions
such as position measurement are triggered by the local clock instead of when the frame
is received, the requirements for sending frames are less strict for the control unit.
This allows the MainDevice stack to be implemented in software on standard Ethernet
hardware. Even jitter in the range of several microseconds does not diminish the accuracyof the Distributed Clocks! Since the accuracy of the clock does not depend on when it’s set,
the frame’s absolute transmission time becomes irrelevant. The EtherCAT MainDevice only
needs to ensure that the EtherCAT frame is sent early enough, before the DC signal in thenodes triggers the output.

17

18

Diagnostics and error localization

19
Cyclic synchronous diagnostics
CyclicExperience with conventional fieldbus systems has shown that diagnostic characteristics
play a major role in determining a machine’s availability and commissioning time.
In addition to error detection, error localization is important during troubleshooting.
EtherCAT allows you to scan and compare the actual network topology with the planned
topology during boot-up. EtherCAT also has many additional diagnostic capabilities
inherent to its system.
The EtherCAT SubDevice Controller in each node uses a checksum to scan the moving
frame for errors. Information is only provided to the SubDevice application if the frame
has been received correctly. If there is a bit error, the error counter is incremented and thesubsequent nodes are informed that the frame contains an error. The control unit will
also detect that the frame is faulty and discard its information. The control unit is able
to detect where the fault originally occurred in the system by analyzing the nodes’ error
counters. This is an enormous advantage in comparison to conventional fieldbus systems,
in which an error is propagated along the entire party line, making it impossible to localize
the source of the error. EtherCAT can detect and localize occasional disturbances
before the issue impacts the machine’s operation.
Thanks to EtherCAT’s unique principle of bandwidth utilization, which is far better thanIndustrial Ethernet technologies that use single frames, the likelihood of bit errors induced
by disturbances within an EtherCAT frame is substantially lower if the same cycle time isused.
If, in typical EtherCAT fashion, much shorter cycle times are used, the time required
for error recovery is significantly reduced. Thus, it is also much simpler to resolve theseissues within the application.
Within the frames, the working counter (WC) enables the information in eachdatagram to be monitored for consistency. Every node that is addressed by the datagram
and whose memory is accessible increments the working counter automatically.
The control is then able to cyclically confirm whether all nodes are working with consistentdata. If the working counter has a different value than it should, the MainDevice does not
forward this datagram’s data to the control application. The MainDevice is then able toautomatically detect the reason for the unexpected behavior with help from status anderror information from the nodes as well as the link status.
Since EtherCAT utilizes standard Ethernet frames, Ethernet network traffic
can be recorded with the help of free Ethernet software tools. For example, thewell-known Wireshark software comes with a protocol interpreter for EtherCAT,
so that protocol-specific information, such as the working counter, commandos,
etc. are shown in plain text.

Further information on diagnostics can be found here: www.ethercat.org/diagAcyclic- working counter

Hardware diagnostics

Software diagnostics- lost link counters- RX error counters- state machine errors- diagnosis history object

Hardware

SoftwareSummary of EtherCAT diagnostic functionalities

Principle of vendor-independent diagnostic interface
These functionalities provide all of the necessary diagnostic information for monitoring
the network state and detecting and locating errors on the MainDevice in all EtherCAT
networks.
This raw information also needs to be provided to diagnostic tools and to end users
in order to be interpreted and used. With the ETG.1510 specification, the ETG has defineda solution which enables external tools to access the diagnostic information provided by
EtherCAT networks in a way that is independent from the specific MainDevice vendor
and software implementation.
The ETG.1510 profile enhances the ETG.1500 specification and extends the object
dictionary of the EtherCAT MainDevice defined in ETG.5001.3 Annex A. The diagnostic
objects can be read by the CAN application protocol over EtherCAT (CoE) mailbox protocol
using the already specified mailbox gateway functionality. As it is fully based on existing
standards, the new profile only requires a few elements in the object dictionary of the
MainDevice. Both the network structure as expected by the MainDevice based on theoffline configuration and the current network topology as detected by an online scanare provided. The diagnostic information itself is mapped in the form of consistent,
cumulative counters that summarize the network state from its start up to the present.
As a result, the diagnostic interface can be accessed at a frequency that is independent
from the cycle time of the EtherCAT network, and realtime performance is not requiredin the external tools.

20

The diagnostic information is accessed via the well-established CAN application protocol
over EtherCAT (CoE). Based on already existing and fully standard protocols andfunctionalities, this diagnostic interface can easily be implemented as a lean software
extension on top of any standard MainDevice implementation. The amount of resources
required by such a software extension is very small, which makes implementation of
the diagnostic interface feasible for all MainDevice solutions, including simple and compact
embedded systems.
Using the EtherCAT diagnostic interface, providers of machine and network diagnostic
tools can use a general purpose, universal interface to collect diagnostic data from
EtherCAT networks. They are able to report this information to technicians and engineers
in a user friendly, graphically intuitive way. The networks do not need to change their
behavior to fit the specific MainDevice manufacturer nor use a vendor’s proprietary
access protocol for each different MainDevice implementation.

Diagnostic
interface

HMI ordiagnostic
tool

Diagnostic
interface

Diagnostic
interface

MAIN
DEVICE

Vendor 1

MAIN
DEVICE

Vendor 2

MAIN
DEVICE

Vendor n

SUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICEHigh availability requirements
For machines or equipment with very high availability requirements, a cable break or amalfunctioning node should not mean that a network segment is no longer accessible,or that the entire network fails.
EtherCAT enables cable redundancy via simplicity. A cable from the last node can beconnected to an additional Ethernet port in the MainDevice to transform a line topology
is extended into a ring topology. A redundancy case, such as a cable break or a node
malfunction, is detected by a software add-on in the MainDevice stack. That’s all there is to
it! The nodes themselves don’t need to be modified, and don’t even know that they’rebeing operated in a redundant network.

MAIN
DEVICE

Inexpensive cable redundancy with standard EtherCAT field devices

The diagnostic interface enables vendor-independent access to EtherCAT diagnostic data

Link detection in the connected devices automatically detects and resolves redundancycases with a recovery time of less than 15 microseconds, so that only a single communication
cycle is disrupted at maximum. This means that even motion applications with very shortcycle times can continue working smoothly when a cable breaks.
With EtherCAT, MainDevice redundancy with hot standby can also be achieved.
Vulnerable network components, such as those connected with a drag chain, can be wiredwith a drop line, so that even when a cable breaks, the rest of the machine keeps running.

21

22

EtherCAT G: Communication
at gigabit levels
EtherCAT G is an extension of the standard EtherCAT protocol that enables data
communication at rates of 1 Gb/s up to 10 Gb/s. This is particularly useful whentransmitting large amounts of process data per network participant, as is the case withmachine vision, high-end measurement technology or in complex motion applications.
The EtherCAT protocol itself, along with its positive features, are fully retainedin EtherCAT G/G10. EtherCAT G/G10 is fully compatible with the IEEE 802.3 standard andthe topology flexibility that it provides is also identical: drop lines, lines, daisy chains ortree structures can all be created.
A central element of EtherCAT G is the branch concept. It is achieved with an
EtherCAT Branch Controller (EBC), which essentially fulfills two main functions:	it acts as a kind of node for the integration of independent segmentswith 100 Mb/s devices	it enables parallel processing of the connected EtherCAT segments.
As a result, the propagation delay is significantly reduced, which increases system
performance many times over previous levels.
The data is forwarded into the single segments under priority and/or time control,with each branch treated like an independent EtherCAT segment: the frame doesn’t run
through all segments in series; instead, the segments are processed in parallel. This
reduces propagation times in large networks significantly and increases the system
performance many times over.
With the branch concept, even big plants can be managed from one central control
unit. In typical EtherCAT fashion, the configuration of the EtherCAT Branch Controllers
is managed via the MainDevice, so no additional configuration tools are needed. The
MainDevice only has to have an appropriate Gb/s port. Important features such as
diagnostics or network synchronization via Distributed Clocks are supported by the
EBCs and are forwarded into the connected segments transparently.
EtherCAT G/G10 thus taps into the advantages of significantly increased bandwidthand reduced propagation times without the field devices themselves having to beequipped with gigabit interfaces: the tried and tested 100 Mb/s devices are retained
and, through the EtherCAT Branch Controller concept, still benefit from the technology
expansion. This means that EtherCAT is ready to meet more stringent future requirements.

Segment 1

MAIN
DEVICEEBC

23
1 Gb/sSegment 2

EBC

100 Mb/s

100 Mb/s

10 Gb/sSUB
DEVICE

Segment 3
EBC

1 Gb/s100 Mb/s

SUB
DEVICE
Segment 4

EBC

1 Gb/sSegment 5

10 Gb/s

EBC

100 Mb/s

100 Mb/s

Example setup for an EtherCAT G/G10 network

Further information about EtherCAT G can be found here: www.ethercat.org/ethercat-g

System overview
EtherCAT plant network

EtherCAT machine control network

MAIN
DEVICESUB
DEVICE

Distributed Clock:reference clock

Decentralized
Safety over EtherCAT
MainInstance

SAFETYSAFETY

MainInstance

MES

MAIN
DEVICEESC
PORT 2Externalsynchronization:- GPS- IEEE 1588
- DCF77

Distributed Clocks (DC):provide extremely
accurate synchronization;jitter < 1 µs

Optical fibre:
up to 20 km between
two devices

SubInstance

Large amount ofprocess data:
e.g. machine vision

EtherCAT BranchController

LVDS
backplane

SafetySubInstance

PORT 3
PORT 1

Standard
Ethernet
interface

EPU

EtherCAT Device Protocol (EDP)
PORT 0EtherCAT Automation Protocol (EAP)

Flexible topology:- line- tree- star- branch

High-end
measurement

EtherCAT P:
data and power on
the same cable

Up to 65,535
nodes

EtherCAT P
power
sourceEBC
24 V DC
Segment 1

ID 01
Hot Connect
ERP

Junction

Segment 2

EBC

SwitchSensor

Actor

ID 02
Explicit device
identification
Junction

Actor

Segment m
ID 03

Controller tocontroller
communication

Class A or class B
MainDevice according to
MainDevice Class Directive

HMI

Copper cable:
up to 100 m between
two devices

TabletGatewayHigh availability:
cable redundancy

WiFi

SAFETY

MainInstance

SUBDEVICE
Switch port

SUBDEVICE
SUBDEVICE

Centralized
Safety over EtherCAT
MainInstance

MAIN
DEVICE

SubDevice to
MainDevice

Fieldbus integration
via gateways

MAIN
DEVICE

MAIN
DEVICE

Data exchange &synchronization
between EtherCAT
segments

SAFETYSubInstance
Other fieldbuses

Standard Ethernet
integration:- Ethernet over
EtherCAT (EoE)
e.g. TCP/IP

Drive integration:- CAN application protocol over EtherCAT (CoE)with DS402 drive profile- Servo drive profile over EtherCAT (SoE)- Safety drive profile- Modular Device Profile (MDP)26

EtherCAT P: Communicationand power in one cable

27

RX-

TX-

TXUS

TX+

SUB
DEVICE

RXUP

RX+

EtherCATPower

SUB
DEVICEUSSUB
DEVICE

UP

TX+
GNDS

Power: 2 x 24 V DC,
3 A (US , UP)

GNDS

Two-cable connection: EtherCAT and power separated

SUB
DEVICERX+
GNDP

EtherCAT P: data and power via one cable

GNDP

EtherCAT P (P = power) is an addition to the previously described EtherCAT
protocol standard. It enables the transmission of both communication data
and the peripheral voltage via a single, standard four-wire Ethernet cable.
EtherCAT and EtherCAT P are identical in terms of protocol technology, as
the addition exclusively affects the physical layer. New EtherCAT SubDevice
Controllers are not required for using EtherCAT P. EtherCAT P has the samecommunication advantages as EtherCAT, but also provides the power supply
via the communication cable, offering attractive benefits and enhancements
for numerous applications.
Two electrically isolated, individually switchable 24 V supplies power the
EtherCAT P devices, available with US for the system and sensors and UP for the
periphery and actuators. Both voltages, US and UP, are directly coupled to the
100 Mb/s EtherCAT communication line. Thanks to this power transmission, theuser can cascade several EtherCAT P devices and therefore only needs one cable.

This facilitates reduced cabling, more compact, cost-effective wiring, lower system costs,
and a smaller footprint for devices, equipment, and machines.
EtherCAT P is especially useful for the parts of a machine that are self-contained andoften a bit isolated, as they can be supplied with data and power through a single stubcable. Sensors of all types are perfectly suitable for EtherCAT P: a single compact M8connector enables efficient integration of these field devices into the high-speed networkand connects them to the supply voltage. Potential error sources while connecting devices
are avoided, thanks to mechanical coding of the connector.
EtherCAT P can be used in a network together with standard EtherCAT technology.
Appropriate rectifier units transform common EtherCAT physics to EtherCAT P byconsistently maintaining the Ethernet data encoding. In the same way, a device itself
can be supplied with EtherCAT P and can also transmit.
Further information about EtherCAT P can be found here: www.ethercat.org/ethercat-p

Safety over EtherCAT

28

Modern communication systems not only transfer control data deterministically, they also enable the transfer of safety-critical control data through the same medium. EtherCAT
utilizes the Safety over EtherCAT (FSoE = FailSafe over EtherCAT) protocol for this very
purpose and so provides:	a single communication system for both control and safety data
the ability to flexibly modify and expand the safety system architecture	pre-certified solutions for simplifying safety applications
powerful diagnostic capabilities for safety functions
seamless integration of the safety design in the machine design
the ability to use the same development tools for both standard and safety applications

additional information used to secure this data. The safety containers are transported as partof the communication’s process data. The safety of the data transfer does not depend on theunderlying communication technology, and isn’t restricted to EtherCAT; safety containers cantravel through fieldbus systems, Ethernet or similar technologies, and can make use of copper
cables, fiber optics, and even wireless connections.

Ethernet telegram
ECAT HDR

Ethernet header

Datagram 1

Datagram 2

FSC

Safety over EtherCAT frame
CMD

Safe data

CRC_0

Safe data

CRC_1

Conn ID

The Safety over EtherCAT frame (safety container) is embedded in the cyclical communication’s process data.

MAIN
DEVICE

MAIN
DEVICESAFETYrelay logic

SAFETY

MainInstance

SAFETYSubInstanceSUB
DEVICEDue to this flexibility, safely connecting different parts of the machine becomes more
simple. The safety container is routed through the various controllers and processed in thevarious parts of the machine. This makes it easy to implement emergency stop functions
for an entire machine or to bring targeted parts of a machine to a standstill – even if theparts of the machine are coupled with other communication systems (e.g. Ethernet).
Implementing the FSoE protocol in a device requires few resources and can leadto a high level of performance and result in short reaction times. In the robotics industry,for example, there are applications that use FSoE for safe motion control
applications in an 8 kHz closed loop.

Device 1

Device 2
Controller B
safetyprotocolController A
safetyprotocolEtherCAT SubDevice Controller

Controller B
safetyprotocolController A
safetyprotocolEtherCAT SubDevice Controller

Safety over EtherCAT enables simpler and more flexible architectures than those achieved with relay logic.
IN

The EtherCAT safety technology was developed according to IEC 61508, is approved by
TÜV SÜD Rail, and is standardized in IEC 61784-3. The protocol is suitable for safety
applications with a safety integrity level of up to SIL 3.
With Safety over EtherCAT, the communication system is part of a black channel, which
is not considered to be safety-relevant. The EtherCAT standard communication system
makes use of a single channel to transfer both standard and safety-critical data. Safety
over EtherCAT frames, known as safety containers, contain safety-critical process data and

OUT

IN

OUT

Black channel principle: the standard communication interface can be used.

Further information regarding Safety over EtherCAT can be found on the ETG website:www.ethercat.org/safety

29

30

CAN application protocol over EtherCAT (CoE)Communication profiles
In order to configure and diagnose SubDevices, the variables provided for the network
can be accessed with the help of acyclic communication. This is based on a reliable
mailbox protocol with an auto-recover function for erroneous messages.
In order to support a wide variety of devices and application layers, the following
EtherCAT communication profiles have been established:	CAN application protocol over EtherCAT (CoE)	servo drive profile according to IEC 61800-7-204 (SoE)	Ethernet over EtherCAT (EoE)	file access over EtherCAT (FoE)	ADS over EtherCAT (AoE)

File system,
bootloader

File accessSubordinatedobject dictionaries or devices

Gatewayfunction

HTTP, FTP, etc.

IEC 61800-7-204
application(SERCOS)CANopenapplication

TCP UDPIDN

Objectdictionary

IP

Servicechannel

SDO

AoE

EoE

SoE

Mailbox

Servo drive profile according to IEC 61800-7-204 (SoE)
SERCOS™ is known as a real-time communication interface, especially for motion control
applications. The SERCOS™ profile for servo drives is included in the international standard
IEC 61800-7. The standard also contains the mapping of this profile to EtherCAT. The service
channel, including access to all drive-internal parameters and functions, is mapped to
the EtherCAT mailbox.

Ethernet over EtherCAT (EoE)
PDO
mapping

Ethernet
FoE

Process data

With the CoE protocol, EtherCAT provides the same communication mechanisms
as in CANopen® Standard EN 50325-4: object dictionary, mapping of process data objects(PDO) and service data objects (SDO). Even the network management is similar.
This makes it possible to implement EtherCAT with minimal effort in devices that werepreviously outfitted with CANopen, and large portions of the CANopen firmware can evenbe reused. Optionally, the legacy 8-byte PDO limitation can be waived, and the enhanced
bandwidth of EtherCAT can also be used to support the upload of the entire object
dictionary. The device profiles, such as the CiA 402 drive profile, can also be reused for
EtherCAT.

CoE

AT
MDT

CoE/SoE

EtherCAT utilizes physical layers of Ethernet and the Ethernet frame. The term Ethernet
is also frequently associated with data transfer in IT applications, which are based on
a TCP/IP connection. Any Ethernet data traffic can be transported within an EtherCAT
segment using the Ethernet over EtherCAT (EoE) protocol. Ethernet devices are connected

Process data

EtherCAT SubDevice Controller

MAIN
DEVICE

Physical layer
Different communication profiles can coexist in the same system.

A field device isn’t required to support all communication profiles; instead, it may
decide which profile is most suitable for its needs. The MainDevice is told which
communication profiles have been implemented via the SubDevice description file.

Transparent transmission of standard IT protocols

Switch port

Web
server31

32

to an EtherCAT segment via switchports. The Ethernet frames are tunneled through the
EtherCAT protocol, similar to the internet protocols (e.g. TCP/IP, VPN, PPPoE (DSL), etc.),
which makes the EtherCAT network completely transparent for Ethernet devices. The
device with the switchport property inserts TCP/IP fragments into the EtherCAT traffic
and therefore prevents the network’s real-time properties from being affected.
Additionally, EtherCAT devices may also support Ethernet protocols (such as HTTP)
and can therefore behave like a standard Ethernet node outside of the EtherCAT
segment. The control device acts as a layer 2 switch that sends the frames to thecorresponding nodes via EoE according to their MAC addresses. All Internet technologies
can thus also be implemented in an EtherCAT environment, such as an integrated web
server, e-mail, FTP transfer, etc.

File access over EtherCAT (FoE)

Plant-wide communication
with the EtherCAT Automation
Protocol (EAP)The process control level has special communication requirements that differ slightly
from the requirements addressed by the EtherCAT Device Protocol, described in theprevious sections. Machines or sections of a machine often need to exchange status
information and information on the following manufacturing steps with each other.
There is also usually a central controller that monitors the entire manufacturing
process, thus providing the user with status information on productivity, and assigningorders to the various machine stations.

This simple protocol similar to TFTP (Trivial File Transfer Protocol) enables file access ina device and a uniform firmware upload to devices across a network. The protocol is leanand does not require much software to implement, so that it can be supported by bootloader programs. A TCP/IP stack isn’t required.

ADS over EtherCAT (AoE)
As a mailbox-based client-server protocol, ADS over EtherCAT (AoE) is defined by the
EtherCAT specification. While protocols such as CAN application protocol over EtherCAT(CoE) provide a detailed semantic concept, AoE complements these perfectly via
routable and parallel services wherever use cases require such features. For example,
this might include access to sub-networks through EtherCAT using gateway devices
from a PLC program such as CANopen®, IO-Link™, and others.
AoE comes with far less overhead compared to similar services provided by theInternet Protocol (IP). Both sender and receiver addressing parameters are always
contained in the AoE datagram. As a result, implementation on both ends (client andserver) can be very lean. AoE is also the protocol of choice for acyclic communication via
the EtherCAT Automation Protocol (EAP) and therefore provides seamless communication
between an MES system, the EtherCAT MainDevice, and subordinated fieldbus devices
connected via gateways. AoE serves as the standard medium for obtaining EtherCAT
network diagnostic information from a remote diagnostics tool.

ERP

HMI
(e.g. OPC,
thin client)

SwitchMAIN
DEVICESUB
DEVICE

EtherCAT Automation Protocol
Process
Control

ConfigHandheld

MAIN
DEVICE

MAIN
DEVICE

MAIN
DEVICE

MAIN
DEVICE

Switchport

EtherCAT Device Protocol
Factory-wide communication with EtherCAT

33

The EtherCAT Automation Protocol (EAP) fulfills all of the above requirements.
The protocol defines interfaces and services for:	exchanging data between EtherCAT MainDevices(MainDevice-to-MainDevice communication)communication to human machine interfaces (HMI)	a supervising controller to access devices belonging
to underlying EtherCAT segments (routing),	integration of tools for machine or plant configuration,and for device configuration.

34

Integration of other bus systems

PROCESSCONTROL

EtherCAT Automaton Protocol (EAP)

EtherCAT’s ample bandwidth allows conventional fieldbus networks to be embedded
as underlying systems via an EtherCAT gateway, which is particularly helpful when
migrating from a conventional fieldbus to EtherCAT. The changeover to EtherCAT is gradual,
making it possible to continue using automation components that don’t yet support an
EtherCAT interface.

Safety over EtherCAT

SAFETY
MainInstance

MAIN
DEVICESAFETYSubInstance

SubInstance

SAFETY

MainInstance
MDEVICESAFETYMAIN
DEVICESAFETYSAFETY

MainInstanceMAIN
MDEVICEDEVICESAFETYSUB
DEVICESUB
DEVICESAFETYSubInstance

Machine module A

The cyclic EAP communication can be directly embedded in the Ethernet frame without
additional transport or a routing protocol. Again, the EtherType Ox88A4 identifies the
EtherCAT-specific use of the frame. This enables the exchange of high-performancedata with EAP in a millisecond cycle. If data routing between distributed machines isrequired, the process data can also be transmitted via UDP/IP or TCP/IP.
Additionally, with the help of the Safety over EtherCAT protocol, safety-critical data
can also be transmitted via EAP. This is common in cases where parts of a large machineneed to exchange safety-critical data to execute a global emergency stop function, or to
inform neighboring machines of an emergency stop.

Machine module B

MAIN
DEVICE

Gateway

Gateway

SubInstance

Machine module C

Factory-wide communication architecture with the EtherCAT Automation Protocol and Safety over EtherCATThe communication protocols used in the EAP are part of the international standard
IEC 61158. EAP can be transmitted via any Ethernet connection, including a wireless link,
making it possible to include automated guided vehicles (AGV), for example, which arecommon in the semiconductor and automotive industries.
Cyclic process data exchange with EAP follows either the push or poll principle.
In push mode, each node sends its data either with its own cycle time or in a multipleof its own cycle time. Each receiver can be configured to receive data from specificsenders. Configuring the sender and receiver data is done through the familiar object
dictionary. In poll mode, a node (often the central controller) sends a frame to theother nodes, and each node responds with its own frame.

EtherCAT enables the integration of decentralized fieldbus interfaces

The ability to integrate decentralized gateways also reduces the physical size of theindustrial PC, sometimes even to an embedded industrial PC, since extension slots
are no longer necessary. In the past, extension slots were also required to connect
complex devices, such as fieldbus MainDevice and SubDevice gateways, fast serialinterfaces, and other communication subsystems. In EtherCAT, only a single Ethernet
port is needed to connect these devices. The process data from the underlying
subsystem is made directly available in the process image of the EtherCAT system.

35

36

Powering the digital transformation
with EtherCAT, Industry 4.0 and IoTProcess optimizations, predictive maintenance, manufacturing as a service, adaptive
systems, resource-savings, smart factories, cost reductions: there are countless goodreasons to utilize control network data in higher level systems.
The Internet of Things (IoT), Industry 4.0, Made in China 2025, Industrial Value
Chain Initiative – there is a common demand across the board for seamless, continuousand standardized communication across all levels. Sensor data is uploaded into the cloudalong with recipes and parameters downloaded from ERP systems into distributed
devices; take, for example, a feeding system shared by two machines: there are
requirements on the data flow both horizontally and vertically.
EtherCAT is inherently equipped to deal with digital transformation through its highperformance, flexibility, and open interfaces:	Superior system performance is a prerequisite for adding big data features to control
networks.
	EtherCAT provides the flexibility to add cloud connectivity to existing systems withouteven touching the controller or updating the field devices: edge gateway can accessany data within any EtherCAT field device via the mailbox gateway feature of the
EtherCAT MainDevice. The edge gateway can either be a remote device and talkto the MainDevice via TCP or UDP/IP, or a software entity directly located on
the same hardware as the EtherCAT MainDevice itself.
	Additionally, open interfaces mean that any IT-based protocol can be integrated –including OPC UA, MQTT, AMQP or any others – either within the MainDevice or
directly into the connected devices, thus providing a direct link for IoT without
protocol discontinuities from the sensor to the cloud.

37

The EtherCAT Technology Group (ETG) was also among the first fieldbus organizations
to partner with the OPC Foundation. The OPC UA protocol complements the EtherCAT
portfolio because it is a scalable TCP/IP based client/server communication technology
with integrated security, enabling encrypted data transfer in MES/ERP systems.
With OPC UA Pub/Sub, the usability of OPC UA has been improved in machine-tomachine (M2M) applications and for vertical communication to cloud-based services.
The ETG is actively contributing to all these developments to ensure that they fit
seamlessly into the EtherCAT environment. EtherCAT is not only IoT-ready, EtherCAT is IoT!

OPC UA, AMQP, MQTT, TSN, EAP

ERP
MES
SUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICE

MAIN
DEVICE

MAIN
DEVICEEdge
gatewaySUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICEAll these features have always been part of the EtherCAT protocol, which shows how
forward-thinking the architecture is. Nevertheless, more networking features are added
as they evolve and become relevant. Of course, it is also important to consider the pastwhen looking forward: introduction of valuable new features is managed with total
network continuity. The EtherCAT protocol has been stable at “Version 1” since it was
released in 2003.
Other new developments in Time-Sensitive Networking (TSN) features further improve
the real-time capabilities of controller-to-controller communication. Enabled by TSN,
control systems can access a network of EtherCAT devices across plant networks, too. Since
EtherCAT typically only needs one frame for an entire network, access is much leaner andthus faster than any other fieldbus or industrial Ethernet technology. In fact, EtherCAT
Technology Group experts have contributed to the TSN task group of IEEE 802.1 from day
one, back when TSN was still known as AVB (Audio Video Bridging).

SUB
DEVICE

MAIN
DEVICEEdge
gatewaySUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICE

Further information about EtherCAT and TSN can be found here: www.ethercat.org/tsn

SUB
DEVICEIoT protocols:
OPC UA, AMQP, MQTT

SUB
DEVICE

MAIN
DEVICESUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICESUB
DEVICE38

39

Implementing
EtherCAT interfaces

EtherCAT technology has been specially optimized to enable low-cost design, so adding an
EtherCAT interface to a sensor, I/O device, or embedded controller should not significantly
increase device costs. Furthermore, the EtherCAT interface doesn’t require a more powerful
CPU; the CPU requirements are solely based on the needs of the target application.
In addition to hardware and software requirements, development support andavailability of the communication stacks are important factors when developing aninterface. The EtherCAT Technology Group offers worldwide developer support as it
answers questions and addresses technical issues quickly. Finally, evaluation kitsavailable from multiple manufacturers, developer workshops, and free sample code
make getting started a little easier.
For the end user, the most important factor is the interoperability of EtherCAT devices
from various manufacturers. To assure interoperability, device manufacturers are required
to perform a conformance test before they bring their device on to the market. The test
checks if the implementation follows the EtherCAT specification, and can be performed
with the EtherCAT Conformance Test Tool. The test can also be used during device
development to discover and correct implementation issues early on.

40

Implementing a MainDevice

The interface for an EtherCAT MainDevice (MDevice) has a sole, unbelievably simple,
hardware requirement: an Ethernet port. The implementation uses either the on-board
Ethernet controller or an inexpensive standard network card, so no special interface
card is required. That means that with just a standard Ethernet port, a MainDevice canimplement a hard real-time network solution.
In most cases, the Ethernet controller is integrated via direct memory access (DMA),
so no CPU capacity is required for the data transfer between the MainDevice andthe network. In an EtherCAT network, mapping occurs in the connected field devices.
Each device writes its data to the right location in the process image and reads the data
addressed to it all while the frame is moving through the device. The process image
that arrives at the MainDevice has already been sorted correctly.
Since the MainDevice CPU is no longer responsible for the sorting, its performancerequirements depend solely on the desired application and not on the EtherCAT interface.
Implementing an EtherCAT MainDevice is a snap, especially for small, mid-range, andclearly defined applications. EtherCAT MainDevices have been implemented for a wide
variety of operating systems: Windows and Linux in various iterations, QNX, RTX, VxWorks,
INtime, eCos are just a few examples.
ETG members offer a variety of options that support the implementation of an
EtherCAT MainDevice, ranging from free downloads of EtherCAT MainDevice libraries
and sample MainDevice code to complete packages (including services) for various
real-time operating systems and CPUs.
In order to operate a network, the EtherCAT MainDevice needs the cyclic processdata structure as well as boot-up commands for each field device. These commands canbe exported to an EtherCAT Network Information (ENI) file with the help of an EtherCAT
configuration tool, which uses the EtherCAT SubDevice Information (ESI) files from theconnected devices.

41

The breadth of available MainDevice implementations and their supported functions varies.
Depending on the target application, optional functions are either supported or deliberately
omitted to optimize the utilization of hardware and software resources. For this reason,
EtherCAT MainDevices are categorized into two classes: a class A MainDevice is a standard
EtherCAT MainDevice, while a class B MainDevice is a MainDevice with fewer functions.
In principle, all MainDevice implementations should aim for class A classification. Class B
is only recommended for cases in which the available resources are insufficient to support
all functionalities, such as in embedded systems.

Control task

Process image
description (XML)

Systemconfiguration
tool

EtherCAT Network
Information (ENI)

XML parser

XML

HW configuration
init commands

EtherCAT SubDevice
Information (ESI)

HDR

Process data

Online functions

XML

EtherCAT MainDevice driver
EtherCAT MainDevice

Standard Ethernet MAC
Typical EtherCAT MainDevice architecture42

Implementing a SubDevice

EtherCAT field devices use inexpensive EtherCAT SubDevice Controllers (ESC) in the formof an ASIC, FPGA, or integrated in a standard microcontroller. Simple field devices don’teven need an additional microcontroller, because inputs and outputs can be directly
connected to the ESC. For more complex devices, the communication performance
only minimally depends on the microcontroller performance, and in most cases, an 8-bit
microcontroller is sufficient.
EtherCAT SubDevice Controllers are available from multiple manufacturers, withthe size of the internal DPRAM and the number of Fieldbus Memory Management Units(FMMUs) varies depending on the type. Different process data interfaces (PDI) are available
so that the application controller can gain external access to the application memory.
	The 32-bit parallel I/O interface is suitable for connecting up to 32 digital inputs andoutputs, but also for simple sensors or actuators for which 32 data bits are sufficientand no application controller is required.
	The Serial Peripheral Interface (SPI) is targeted at applications with small amounts
of process data, such as analog I/O devices, encoders, or simple drives.
	The parallel 8/16-bit microcontroller interface corresponds to common interfacesof fieldbus controllers with integrated DPRAM. It is particularly well-suited to complex
nodes with larger amounts of data.
	Suitable synchronous buses for various microcontrollers are provided for FPGA andsystem-on-chip (SoC) implementations.

43

Host CPU
Processdata

Service
data

HTTP,
FTP, etc.
TCP/IP(optional)

RAM for TCP/IP
and complex
applications

8 I/O

8 I/O

PDI (process data interface)

8 I/O

PDI (process data interface)

Process data
MailboxDual port memory

ESC(EtherCAT SubDevice
Controller)

SYNC manager, FMMU

Registers

RJ 45

8 I/O

SII (e.g.
EEPROM)

Process data
Dual port memory

ESC(EtherCAT SubDevice
Controller)

SYNC manager, FMMU

Registers

EtherCAT processing unit
and auto-forwarder with loop back

EtherCAT processing unit
and auto-forwarder with loop back

EtherCAT Port 0
MII

EtherCAT Port 0
MII

Magnetics

PHY

EtherCAT Port nMII
PHYMagnetics

SubDevice hardware: ESC with host CPU (example)

RJ 45

RJ 45

Magnetics

PHY

EtherCAT Port nMII
PHYMagnetics

SubDevice hardware: ESC with direct I/O (example)

The hardware configuration is stored a in non-volatile memory (e.g. an EEPROM). In
addition, this SubDevice Information Interface (SII) contains information on the main
device features so that the MainDevice can read this at boot-up and operate the device
even if the device description file is not available. The EtherCAT SubDevice Information(ESI) file that comes with the device is XML based and contains the complete descriptionof its network accessible properties, such as process data and mapping options for it,
the supported mailbox protocols including optional features, as well as the supported
modes of synchronization. An EtherCAT network configuration tool uses this informationfor online and offline configuration of the network.
Various manufacturers offer evaluation kits for implementing SubDevices. These kits
include SubDevice application software in source code, and they sometimes also include
a test MainDevice. With an evaluation kit, a fully functional MainDevice-SubDevice
EtherCAT network can be commissioned in just a few steps.
The ETG website contains the ETG.2200 SubDevice Implementation Guide with useful tips
and recommendations for further documentation for implementing field devices:www.ethercat.org/etg2200

SII (e.g.
EEPROM)

RJ 45

44

Conformance and certification

Two of the most important factors for creating a successful communication standard are
conformance and interoperability, and the EtherCAT Technology Group takes both of thesefactors very seriously. In addition to requiring a conformance test for each instance ofdevice implementation (aided by the automated EtherCAT Conformance Test Tool), theETG undertakes a wide variety of activities to ensure interoperability between EtherCAT
MainDevices, field devices, and EtherCAT configuration tools.

EtherCAT Plug FestWhen we test whether multiple devices are interoperable, one of the most pragmaticthings to do is to try connecting the devices together. With this approach in mind, theETG holds multiple EtherCAT Plug Fests each year, with each one usually spanningtwo days. During these events, MainDevice and field device manufacturers meet to test
how their devices behave together, which improves the usability of devices in the field.
Members can exchange EtherCAT tips and tricks and have their questions answered by
EtherCAT experts. The ETG holds EtherCAT Plug Fests in Europe, North America, and Asia.

EtherCAT Conformance Test Tool
The EtherCAT Conformance Test Tool (CTT) enables an EtherCAT field device’s behavior
to be tested automatically.
It’s a Windows program that only requires a standard Ethernet port. The tool sends
EtherCAT frames to the device under test (DuT) and receives responses from it. A test caseis marked as passed if the response from the DuT corresponds to the defined response.
The test cases are defined as XML files. This means that the test cases can be modified
or expanded without having to modify the actual test tool. The Technical Working Group
Conformance is responsible for specifying and releasing the latest valid test cases.
In addition to the protocol tests, the CTT also examines whether the values inthe EtherCAT SubDevice Information (ESI) file are valid. Finally, the CTT performs
device-specific protocol tests, such as for the CiA 402 drive profile.
All of the testing steps and results are saved in a test logger, and can be analyzed
or saved as a documented verification for the device release.
The ETG consistently maintains and adds new test cases to the CTT. It is importantthat a device manufacturer always has the most recent version of the tool for testingproducts prior to release. To make this easier, the CTT is offered as a subscription. The
CTT is also useful for uncovering early errors in the interface implementation during
the design phase.

45

Technical Working Group Conformance
The EtherCAT Conformance Test Policy requires device manufacturers to test each device
with a valid version of the EtherCAT Conformance Test Tool before the device is brought
onto the market. The manufacturer may conduct this test in-house.
The ETG Technical Committee (TC) established a Technical Working Group (TWG)
for Conformance, which determines the test procedures, the contents of the test, and theimplementation of the Conformance Test Tool. The TWG Conformance continuously
expands the tests and their depth.
The TWG Conformance also established an interoperability test process, which can beused to test devices in the context of an entire network.

EtherCAT Test Center
The official EtherCAT Test Centers (ETC) in Europe, Asia, and North America areaccredited by the ETG and perform the official EtherCAT Conformance Test.
The EtherCAT Conformance Test includes the automated tests run with the CTT,
interoperability tests within a network, and an examination of the device’s
indicators, markings, and tests of the EtherCAT interfaces.
Device manufacturers are encouraged but not obligated to have their devices tested
at an ETC. After the conformance test has been passed, the manufacturer receives an
EtherCAT Conformance Tested certificate for the device. This certificate is only issued for
devices that have passed the official conformance test at an ETC, and not for those whichhave been tested in-house.
The additional test in an accredited EtherCAT Test Center further increases compatibility
and aids uniform operation and diagnostics of EtherCAT implementations. End users
should be sure to ask for the EtherCAT Conformance Tested certificate when choosing
devices for their application.
In addition to the EtherCAT Conformance Test, there’s another conformance test which
has been developed especially for devices with a safety interface and which is mandatory
for manufacturers of FSoE devices according to the FSoE policy. The test is conducted by an
official notified body and provides solid confirmation of reliable and standard compliant
implementation of the Safety over EtherCAT protocol.

More information on conformance and certification is available on the ETG website:www.ethercat.org/conformance

46

www.ethercat.org

ETG worldwide

The EtherCAT website provides comprehensive information about the technology
as well as upcoming events, the latest EtherCAT products, and the current
membership directory. It also covers special topics such as functional safety
and conformance of EtherCAT devices. You can find out about the benefitsof free membership, download presentations, press articles, and publicationsat www.ethercat.org/downloads.

47

ETG Headquarters
GermanyETG Office
North America

ETG Office
Korea
ETG Office
China

EtherCAT Product Guide
The EtherCAT Product Guide is a directory listing a selection of EtherCAT products
and services based on information provided by ETG members, and is available
online at www.ethercat.org/products. If you have any questions about the
products, please contact the manufacturer directly, as the ETG itself does notsell any products.

Events
The event section shows the events hosted by the ETG worldwide and thosethat are organized in conjunction with the association. www.ethercat.org/events
is a calendar where all the important dates can be found, including thosefor the technical working group meetings, exhibition appearances, EtherCAT
workshops, and Industrial Ethernet seminars.

Member Area

Contact
ETG Headquarters
Ostendstraße 196
90482 Nuremberg
Germany+ 49 (911) 5 40 56 20
info@ethercat.org

Members have insider access to the protected area of the website atwww.ethercat.org/memberarea, which contains valuable additional items
such as all EtherCAT specifications, the online developer forum, and a knowledge
base containing with all necessary information for implementation, configurationand diagnosis of EtherCAT devices and networks.

ETG Office North America
San Jose, CA, USA+1 (877) ETHERCAT
info.na@ethercat.org
ETG Office China
Beijing, China+ 86 (10) 8220 0090
info@ethercat.org.cn
ETG Office Japan
Yokohama, Japan+ 81 (45) 650 1610
info.jp@ethercat.org
ETG Office Korea
Seoul, Korea+82 (0)2 2107 3242
info.kr@ethercat.org

Technical support
ETG Headquarters
Ostendstraße 196
90482 Nuremberg
Germany+ 49 (911) 5 40 56 222
techinfo@ethercat.org

ETG OfficeJapanEtherCAT®, EtherCAT G®, EtherCAT P®, and Safety over EtherCAT® are registeredtrademarks and patented technologies licensed by Beckhoff Automation GmbH,Germany. Other designations used in this publication may be trademarks which,when used by third parties for their own purposes, could violate the rights of
the owners.
02/2024