EtherCAT, with around 80 million nodes in the field and a user organization of over 8000 members behind it, is an established communication standard in industrial automation worldwide, a good 22 years after its introduction. But how exactly does EtherCAT work, what does the protocol do and how does it differ from comparable systems? We will use a series of articles in the Industrial Ethernet Book to refresh your knowledge of EtherCAT technology.

Processing on the fly – how it works

Traditional networks in automation are characterized by small amounts of data per node; usually less than the minimum payload of an Ethernet frame. One frame per node, direction and cycle therefore does not make optimum use of the available bandwidth and thus limits the performance of the entire system.

This is where the functional principle of EtherCAT comes in. With EtherCAT, the nodes read data intended for them from the frame and write their own data back into the same frame as it passes through the node. Standard Ethernet frames are used, the size of which is usually sufficient to transport all the process data required for the cycle in one telegram.

Figure 1: With EtherCAT, process data is inserted into the datagram as it passes through.

Furthermore, the network nodes can act as connectors and have more than two ports, which is why no switches or hubs are required. The last node sends the telegram back to the controller using the full-duplex function of Ethernet. Only the controller, the EtherCAT MainDevice, actively sends frames, which avoids delays caused by collisions and ensures the real-time capability of the system. All that is required is a standard Ethernet MAC, so that any controller with an Ethernet port can become an EtherCAT MainDevice via software.

On the side of the connected field devices, called EtherCAT SubDevices, EtherCAT SubDevice Controller Chips are used, which integrate all time-critical functions in hardware, which in turn avoids delays caused by large software stacks.

In terms of overall network performance, EtherCAT’s functional principle overcomes the three biggest limiting factors, namely insufficient bandwidth utilization and delays caused by switches and large software stacks.

Figure 2: EtherCAT uses standard Ethernet frames in accordance with IEEE 802.3.

Fast, flexible and precise

Another feature of EtherCAT is its versatility. As the protocol does not require hubs and switches, as described above, there are practically no restrictions in terms of topology. Line, tree, star and all conceivable combination of these are possible. Thanks to automatic link detection and HotConnect functionality, nodes and segments can be disconnected and reconnected during operation – even at a different location and without disrupting the network.

Figure 3: Flexible topology: line, tree, or star.

Line topology can be closed to form a ring for the purpose of cable redundancy, which enables applications with high availability requirements. All the controller needs on the hardware side is a second Ethernet port; the field devices themselves support cable redundancy from the outset.

There are also different transmission variants for different requirements. If required, not only data but also power can be transmitted on just one line. With an almost unlimited number of network participants per segment, there is no need for local expansion buses and all modules benefit directly from the EtherCAT performance.

Figure 4: Simple cable redundancy with standard EtherCAT SubDevices.

Also of great importance for the performance of a network is the precision of the synchronization of the connected devices. Compared to fully synchronous communication, whose quality suffers immediately from communication errors, a solution with high synchronized clocks distributed across the network enables high jitter tolerance in the system. EtherCAT follows this approach and uses distributed clocks (DC) for this purpose.

Figure 5: The synchronization of the participants is completely hardware-based; runtime delays are calculated and compensated.

The clocks in the nodes are synchronized in hardware, whereby the time of the first synchronously operating node is distributed cyclically to all other clocks in the system, which are set exactly to this reference clock. As the information from the reference clock arrives late at the other clocks in the cycle due to propagation delays on the cable and in the nodes, the delay is measured and compensated individually for each node in order to achieve synchronization as well as simultaneity. And so, with EtherCAT the latter is significantly less than 1µs, just like the jitter of the clocks. And the EtherCAT MainDevice is also relieved when using the distributed clocks, as it only has to ensure that the EtherCAT frame is sent early enough before the clock signal in the nodes triggers the outputs to be set.

Christiane Hammel, EtherCAT Technology Group