EtherCAT (Ethernet for Control Automation Technology)

EtherCAT - the Ethernet Fieldbus.

This section provides an in-depth introduction into EtherCAT (Ethernet for Control Automation Technology). EtherCAT is a real-time Industrial Ethernet technology originally developed by Beckhoff Automation. The EtherCAT protocol which is disclosed in the IEC standard IEC61158 is suitable for hard and soft real-time requirements in automation technology, in test and measurement and many other applications.

The main focus during the development of EtherCAT was on short cycle times (≤ 100 µs), low jitter for accurate synchronization (≤ 1 µs) and low hardware costs.

EtherCAT was introduced in April 2003, and the EtherCAT Technology Group was founded in November 2003 - Meanwhile ETG has grown into the world’s largest Industrial Ethernet and fieldbus organization. The ETG brings together manufacturers and users, which contribute in technical working groups to the advancement of the EtherCAT technology.

1. Features of EtherCAT

1.1 Functional Principle
1.2 Protocol
1.3 Topology
1.4 Synchronization
1.5 Diagnosis and Error Localization
1.6 High Availability
1.7 Safe Data Transfe
1.8 Communication Profiles
1.8.1 CAN Application Protocol over EtherCAT (CoE)
1.8.2 Servo Drive Profile according to IEC 61491-7-204 over EtherCAT (SoE)
1.8.3 Ethernet over EtherCAT (EoE)
1.8.4 File Access over EtherCAT (FoE)
1.9 EtherCAT Automation Protocol (EAP)
1.10 Integration of other Bus Systems

2. Implementation

2.1 Master
2.2 Slave

3. Conformance and Certification

3.1 Plug Fest
3.2 Conformance Test Tool
3.3 Technical Working Group Conformance
3.4 EtherCAT Test Center

4. International Standardization

1. Features of EtherCAT 

top

 

1.1 Functional Principle 

The EtherCAT master sends a telegram that passes through each node. Each EtherCAT slave device reads the data addressed to it “on the fly”, and inserts its data in the frame as the frame is moving downstream. The frame is delayed only by hardware propagation delay times. The last node in a segment (or branch) detects an open port and sends the message back to the master using Ethernet technology’s full duplex feature.

The telegram’s maximum effective data rate increases to over 90 %, and due to the utilization of the full duplex feature, the theoretical effective data rate is even higher than 100 Mbit/s (> 90 % of two times 100 Mbit/s).

The EtherCAT master 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 capabilities.

The master uses a standard Ethernet Media Access Controller (MAC) without an additional communication processor. This allows a master 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 Slave devices use an EtherCAT Slave Controller (ESC) to process frames on the fly and entirely in hardware, making network performance predictable and independent of the individual slave device implementation.

1.2 Protocol 

EtherCAT embeds its payload in a standard Ethernet frame. The frame is identified with the Identifier (0x88A4) in the EtherType field. Since the EtherCAT protocol is optimized for short cyclic process data, the use of protocol stacks, such as TCP/IP or UDP/IP, can be eliminated.

To ensure Ethernet IT communication between the nodes, TCP/IP connections can optionally be tunneled through a mailbox channel without impacting real-time data transfer.

During startup, the master device configures and maps the process data on the slave devices. Different amounts of data can be exchanged with each slave, from one bit to a few bytes, or even up to kilobytes of data.

The EtherCAT frame contains one or more datagrams. The datagram header indicates what type of access the master device would like to execute:

• Read, write, read-write
• Access to a specific slave device through direct addressing, or access to multiple slave 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 GBytes of address space is available. During network startup, each slave device is assigned one or more addresses in this global address space. If multiple slave devices are assigned addresses in the same area, they can all be addressed with a single datagram. Since the datagrams completely contain all the data access related information, the master device can decide when and which data to access. For example, the master device can use short cycle times to refresh data on the drives, while using a longer cycle time to sample the I/O; a fixed process data structure is not necessary.

In addition to cyclical data, further datagrams can be used for asynchronous or event driven communication. Besides the logical addressing, the master device can also address a slave 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 master device can assign each node a 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 slave-to-slave communication. A slave device can send data directly to another slave device that is connected further downstream in the network. Since EtherCAT frames can only be processed going forward, this type of direct communication depends on the network’s topology, and is particularly suitable for slave-to-slave communication in a constant machine design (e.g., in printing or packaging machines). In contrast, freely configurable slave-to-slave communication runs through the master device, and requires two bus cycles (not necessarily two control cycles).

1.3 Topology 

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

When wiring the system, the combination of lines with branches or drop lines is beneficial: the ports necessary to create branches are directly integrated in many I/O modules, so no additional switches or active infrastructure components are required.

Modular machines or tool changers require network segments or individual nodes to be connected and disconnected during operation. EtherCAT slave 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 < 15 μs guarantee a smooth changeover.

Additional flexibility is given regarding the possible cable types. Inexpensive industrial Ethernet cable can be used between two nodes up to 100m apart in 100BASE-TX mode. The Power over EtherCAT option (compatible with IEEE 802.3af) enables the connection of devices such as sensors with a single line. Fiber optics (such as 100BASE-FX) can also be used, for example for a node distance greater than 100 m.

Up to 65,535 devices can be connected to EtherCAT, so network expansion is virtually unlimited. As is usual with Ethernet, arbitrary changes between the physical layers are allowed.

1.4 Synchronization 

In applications with spatially distributed processes requiring simultaneous actions, exact synchronization is particularly important. For example, this is the case for applications in which multiple servo axes execute coordinated movements.

In contrast to completely synchronous communication, whose quality suffers immediately from communication errors, distributed synchronized clocks have a high degree of tolerance for jitter in the communication system. Therefore, the EtherCAT solution for synchronizing nodes is based on distributed clocks (DC).

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

Since the time sent from the reference clock arrives at the slave devices slightly delayed, this propagation delay must be measured and compensated for each slave device in order to ensure synchronicity and simultaneousness. This delay is measured during network startup or, if desired, even continuously during operation, ensuring that the clocks are simultaneous to within much less than 1μs of each other.

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 in addition to synchronicity and simultaneousness. In such applications, velocity is typically derived from the measured position, so it is critical that the position measurements are taken precisely equidistantly (i.e. in exact cycles).

Additionally, the use of distributed clocks also unburdens the master device; since actions such as position measurement are triggered by the local clock instead of when the frame is received, the master device doesn’t have such strict requirements for sending frames. This allows the master stack to be implemented in software on standard Ethernet hardware. Since the accuracy of the clock does not depend on when it’s set, the frame’s absolute transmission time becomes irrelevant. The EtherCAT master needs only to ensure that the EtherCAT telegram is sent early enough, before the DC signal in the slave devices triggers the output.

1.5 Diagnosis and Error Localization 

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.

The EtherCAT Slave Controller in each node checks the moving frame for errors with a checksum. Information is provided to the slave application only if the frame has been received correctly. If there is a bit error, the error counter is incremented and the subsequent nodes are informed that the frame contains an error. The master device will also detect that the frame is faulty and discard its information. The master device is able to detect where the fault originally occurred in the system by analyzing the nodes’ error counters. EtherCAT can detect and localize occasional disturbances before the issue impacts the machine’s operation.

Within the frames, the Working Counter enables the information in each datagram to be monitored for consistency. Every node that is addressed by the datagram and whose memory is accessible increments the Working Counter automatically. The master is then able to cyclically confirm if all nodes are working with consistent data. If the Working Counter has a different value than it should, the master does not forward this datagram’s data to the control application. The master device is then able to automatically detect the reason for the unexpected behavior with help from status and error information from the nodes as well as the Link Status.

Since EtherCAT utilizes standard Ethernet frames, EtherCAT network traffic can be recorded with the help of free Ethernet software tools. For example, the well-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.

1.6 High Availability 

For machines or equipment with very high availability requirements, a cable break or a node malfunctioning should not mean that a network segment is no longer accessible, or that the entire network fails.

EtherCAT enables cable redundancy with simple measures. By connecting a cable from the last node to an additional Ethernet port in the master device, 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 master stack.

Link detection in the slave devices automatically detect and resolve redundancy cases with a recovery time of less than 15 μs, so at maximum, a single communication cycle is disrupted. This means that even motion applications with very short cycle times can continue working smoothly when a cable breaks.

With EtherCAT, it’s also possible to realize master device redundancy with Hot Standby. Vulnerable network components, such as those connected with a drag chain, can be wired with a drop line, so that even when a cable breaks, the rest of the machine keeps running.

1.7 Safe Data Transfer 

For the transfer of safety relevant data EtherCAT utilizes the protocol Safety over EtherCAT (FSoE). The benefits are as follows:

• A single communication system for both control and safety data
• The ability to flexibly modify and expand the safety system architecture
• Pre-certified solutions to simplify 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

The EtherCAT safety technology was developed according to IEC 61508, is TÜV certified, and is standardized in IEC 61784-3. The protocol is suitable for safety applications with a Safety Integrity Level up to SIL 3.

With Safety over EtherCAT, the communication system is part of a so-called Black Channel, which is not considered to be safety relevant. The standard communication system EtherCAT makes use of a single channel to transfer both standard and safety-critical data. Safety Frames, known as Safety Containers, contain safety-critical process data and additional information used to secure this data. The Safety Containers are transported as part of the communication’s process data. Whether data transfer is safe does not depend on the underlying communication technology, and isn’t restricted to EtherCAT; Safety Containers can travel through fieldbus systems, Ethernet or similar technologies, and can make use of copper cables, fiber optics, and even wireless connections.

The Safety Container is routed through the various controllers and processed in the various parts of the machine. This makes emergency stop functions for an entire machine or bringing targeted parts of a machine to a standstill possible – even if the parts of the machine are coupled with other communication systems (e.g. Ethernet).

1.8 Communication Profiles 

In order to configure and diagnose slave devices, it is possible to access the variables provided for the network 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)

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

1.8.1 CAN application protocol over EtherCAT (CoE) 

With the CoE protocol, EtherCAT provides the same communication mechanisms as in CANopen®-Standard EN 50325-4: Object Dictionary, PDO Mapping (Process Data Objects) and SDO (Service Data Objects) – even the network management is similar. This makes it possible to implement EtherCAT with minimal effort in devices that were previously outfitted with CANopen, and large portions of the CANopen Firmware are even reusable. Optionally, the legacy 8-byte PDO limitation can be waived, and it’s also possible to use the enhanced bandwidth of EtherCAT to support the upload of the entire Object Dictionary. The device profiles, such as the drive profile CiA 402, can also be reused for EtherCAT.

1.8.2 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, are mapped to the EtherCAT Mailbox.

1.8.3 Ethernet over EtherCAT (EoE) 

EtherCAT makes use of 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. Using the Ethernet over EtherCAT (EoE) protocol any Ethernet data traffic can be transported within an EtherCAT segment. Ethernet devices are connected to an EtherCAT segment via so-called Switchports. The Ethernet frames are tunneled through the EtherCAT protocol, similarly to the internet protocols (e.g. TCP/IP, VPN, PPPoE (DSL), etc.) as such, which makes the EtherCAT network completely transparent for Ethernet devices. The device with the Switchport property takes care of inserting 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 Internet protocols (such as HTTP) and can therefore behave like a standard Ethernet node outside of the EtherCAT segment. The master device acts as a Layer-2-switch that sends the frames via EoE to the corresponding nodes according to their MAC addresses. In this way, all Internet technologies can also be implemented in an EtherCAT environment, such as an integrated web server, E-mail, FTP transfer, etc.

1.8.4 File access over EtherCAT (FoE) 

This simple protocol similar to TFTP (Trivial File Transfer Protocol) enables file access in a device and a uniform firmware upload to devices across a network. The protocol has been deliberately specified in a lean manner, so that it can be supported by boot loader programs – a TCP/IP stack isn’t required.

1.9 EtherCAT Automation Protocol (EAP) 

The process management level has special communication requirements that differ slightly from the requirements addressed by the EtherCAT Device Protocol, described in the previous sections. Machines or sections of a machine often need to exchange status information and information about the following manufacturing steps with each other. Additionally, there is usually a central controller that monitors the entire manufacturing process, which provides the user with status information on productivity, and assigns orders to the various machine stations.

The EtherCAT Automation Protocol (EAP) fulfills all of the above requirements. The protocol defines interfaces and services for:

• Exchanging data between EtherCAT master devices (master-master communication)
• Communication to Human Machine Interfaces (HMI)
• A supervising controller to access devices belonging to underlying EtherCAT segments (Routing)
• Integration of tools for the machine or plant configuration, as well as for device configuration

The communication protocols used in EAP are part of the international standard IEC 61158. EAP can be transmitted via any Ethernet connection, including a wireless link, for example making it possible to include automated guided vehicles (AGV), which are common 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 multiple of the own cycle time. Each receiver can be configured to receive data from specific senders. Configuring the sender and receiver data is done through the familiar Object Dictionary. In “Poll” mode, a node (often the central controller) sends a telegram to the other nodes, and each node responds with its own telegram.

The cyclic EAP communication can be directly embedded within the Ethernet frame, without additional transport or routing protocol. Again, the EtherType Ox88A4 identifies the EtherCAT specific use of the frame. This enables the exchange of high-performance data with EAP in a millisecond cycle. If data routing between distributed machines is required, the process data can also be transmitted via UPD/IP or TCP/IP.

Additionally, with the help of the Safety over EtherCAT Protocol, it’s also possible to transmit safety-critical data via EAP. This is common in cases where parts of a large machine need to exchange safety-critical data to realize a global emergency stop function, or to inform neighboring machines of an emergency stop.

1.10 Integration of other Bus Systems 

EtherCAT’s ample bandwidth makes it possible to embed conventional fieldbus networks as an underlying system 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.

The ability to integrate decentralized gateways also reduces the physical size of the Industrial 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 master and slave gateways, fast serial interfaces, and other communication subsystems. In EtherCAT, all that is needed to connect these devices is a single Ethernet port. The process data from the underlying subsystem is made directly available in the process image of the EtherCAT system.

2. Implementation 

top

 

Every sensor, I/O device, or embedded controller should be able to add an EtherCAT interface. Furthermore, the EtherCAT interface also doesn’t require a more powerful CPU- the CPU requirements instead are based only on the needs of the target application.

In addition to hardware and software requirements, development support and the availability of communication stacks are important when developing an interface. Evaluation kits available from multiple manufacturers, developer workshops, as well as free sample code make getting started easier.

2.1 Master 

For the implementation of an EtherCAT master either an on-board Ethernet controller or a standard network card is needed, so no special interface card is required.

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 master device and the network. In an EtherCAT network, mapping occurs at the slave devices. Each slave 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. Therefore, the process image that arrives at the master device is already sorted correctly. EtherCAT master devices 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.

In order to operate a network, the EtherCAT master requires the cyclic process data structure as well as boot-up commands for each slave device. These commands can be exported to an EtherCAT Network Information (ENI) file with the help of an EtherCAT configuration tool, which uses the EtherCAT Slave Information (ESI) files from the connected devices.

The breadth of available master implementations and their supported functions varies. Depending on the target application, optional functions are either supported or purposely omitted to optimize the utilization of hardware and software resources. For this reason, EtherCAT master devices are categorized into two classes: a Class-A-Master is a standard EtherCAT master device, while a Class-B-Master is a master device with fewer functions. In principle, all master 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.

2.2 Slave 

EtherCAT slave devices use EtherCAT Slave Controllers (ESC) in the form of an ASIC, FPGA, or integrated in a standard microcontroller. Simple slave devices don’t need an additional microcontroller, because inputs and outputs can be directly connected to the ESC. For more complex slave devices the communication performance depends only minimally on the microcontroller performance, and in most cases, an 8-Bit microcontroller is sufficient.

EtherCAT Slave Controllers are available from multiple manufacturers, with the size of the internal DPRAM and the number of Fieldbus Memory Management Units (FMMUs) depending on the variation. Different Process Data Interfaces (PDI) for external access from the application controller to the application memory are available:

• The 32-Bit parallel I/O Interface is suitable for connecting up to 32 digital inputs and outputs, but also for simple sensors or actuators for which 32 data bits are sufficient and 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 interfaces of fieldbus controllers with integrated DPRAM. It is particularly suitable for complex nodes with larger amounts of data.
• Suitable synchronous busses for various microcontrollers have been implemented for FPGA and On-Chip variations.

The hardware configuration is stored a in non-volatile memory (e.g. an EEPROM), the Slave Information Interface (SII), which contains information about the basic device features, so that the master can read this at boot-up and operate the device even if the device description file is not available. The EtherCAT Slave Information (ESI) file that comes with the device is XML based and contains the complete description of its network accessible properties, such as process data and their mapping options, the supported mailbox protocols including optional features, as well as the supported modes of synchronization. The Network Configuration Tool uses this information for online and offline configuration of the network. Various manufacturers offer evaluation kits for implementing slave devices. These kits include slave application software in source code, and they sometimes also include a test master.

3. Conformance and Certification 

top

 

Two important factors for a communication standard to be successful are conformance and interoperability. In addition to requiring a conformance test for each device implementation (aided by the automated EtherCAT Conformance Test Tool), the EtherCAT Technology Group offers a variety of activities to ensure the interoperability between EtherCAT master devices, slave devices, and also the EtherCAT Configuration Tool.

3.1 Plug Fest 

When trying to test if multiple devices are interoperable, connecting the devices together is a pragmatic approach. With this in mind, the ETG holds multiple so called Plug Fests each year, with each Plug Fest usually spanning two days. During the Plug Fests, master and slave device manufacturers come together to test how their devices behave together, which improves the usability of devices in the field. The ETG holds Plug Fests in Europe, North America, and Asia on a regular basis.

3.2 Conformance Test Tool (CTT) 

The EtherCAT Conformance Test Tool (CTT) makes it possible to automatically test an EtherCAT slave device’s behavior. The CTT is a Windows program requiring only a standard Ethernet port. The tool sends EtherCAT frames to the Device under Test (DuT) and receives its responses. A test case is marked as passed if the response from the DuT corresponds to the defined response. The test cases are defined as XML files. This makes it possible to modify or expand the test cases without having to modify the actual test tool. The TWG Conformance is responsible for specifying and releasing the most current valid test cases. In addition to the protocol tests, the CTT also examines if the values in the EtherCAT Slave Information (ESI) file are valid. Finally, the CTT also performs device-specific protocol tests, such as for the CiA402 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.

3.3 Technical Working Group Conformance 

The ETG Technical Committee (TC) established a Technical Working Group (TWG) Conformance, which determines the test procedures, the contents of the test, and the implementation of the Conformance Test Tool. The TWG Conformance is continuously expanding the tests and their depth. The TWG Conformance also established an interoperability test process, with which devices can be tested in the context of an entire network.

4. International Standardization 

top

 

EtherCAT as well as Safety-over-EtherCAT are international IEC standards (in IEC 61158 and IEC 61784). Not only the lower protocol layers are standardized, but also the application layer and device profiles, e.g. for drive technology. In many countries EtherCAT also is a national standard, e.g. in most European countries, in China and Korea. SEMI™ (Semiconductor Equipment and Materials International) accepted EtherCAT as communication standard (E54.20) for the semiconductor industry. The ETG Semiconductor Technical Working Group defines appropriate industry-specific device profiles and implementation guidelines. The EtherCAT specification is available in English, Japanese, Korean and Chinese language.

转载于；

https://www.ethercat.org/en/technology.html