Determinism in industrial ethernet: the EtherCAT protocol

Last year we published a review of technologies that are used to provide real-time or near-real-time operation over ethernet networks. This month we examine one of them in more depth.

As we looked at in the July and August issues last year, the non-deterministic nature of traditional IEEE 802.3 Ethernet presents some challenges for achieving real-time operation with this open, high-speed network technology. But, since the benefits outweigh the challenges, there have been a number of approaches used to achieve different levels of real-time operation.

The concept of ‘real time’ is relative - whether the communication is for a motion control system, where response is measured in microseconds or milliseconds, or whether the control system is tracking the sun in a solar power plant, both could be called real-time control.

In relation to real-time networking, applications can be divided into three broad categories:

• Non real time - normal data processing environments where timeliness of data delivery can vary widely and can be measured in seconds or minutes without detrimental impact, such as data transfers between higher-level systems such as MES and ERP - in other words, higher-level plant management and business applications.

• Soft real time (SRT) - providing real-time deterministic messaging in the range up to 100 ms response time, using higher level control of (mainly) UDP packets, where a strict master/slave communication is maintained.

• Isochronous real time (IRT) - which provides deterministic messaging for high-speed equipment such as motion control systems, where sub-millisecond timing is required.

In this article we will be describing how the EtherCAT protocol, developed by Beckhoff Automation, provides an isochronous real-time Ethernet master/slave network using standard ethernet frames. This is achieved by modifying the way standard ethernet frames are handled at the lower layers, so that the large protocol overhead of standard ethernet is minimised.

Ethernet frame overhead

In most ethernet-based communication systems, individual ethernet frames are used to send data to each device - a single unicast frame has only one destination. Despite the high transmission speed of ethernet, this results in a low effective data rate in industrial environments, since the typical data payload in a single industrial communication is very small.

As shown in Figure 1a, the smallest possible ethernet frame is 84 bytes long (72 bytes plus the obligatory interpacket gap of 12 bytes at 100 Mbps). If, for example, a drive typically sends 4 bytes of data and status information, then the actual payload efficiency is 4/84 or just 4.8%. 84 bytes of ethernet data is being used to carry only four bytes of useful information - and this is if we assume that the network response time of the drive is infinitely small, and that the utilisation of the network is 100%. If the response time of a device such as a drive is 10µs, then the data rate drops to 1.9%, or effectively 1.9 Mb/s on a 100 Mb/s network.

This limitation applies to all approaches that use individual ethernet frames for each communication with each device, regardless of the higher-level protocols and controls used. This is one of the main limitations that limits determinism in industrial ethernet for applications that require sub-millisecond response.

EtherCAT

EtherCAT technology overcomes the packet overhead problem, since a single ethernet frame is shared by multiple devices for both receiving and transmitting data - increasing the effective data rate by an order of magnitude.

Normally, EtherCAT devices are wired in a logical ring topology, in such a way that the data frames are passed through from device to device, each device reading the data addressed to them, while the frame passes through. Return data is also inserted while the frame passes though. The delay at each node is typically only a few nanoseconds and, since the frame is carrying the data of many devices in both the send and receive direction, then the useable data rate increases to over 90%. The ethernet protocol remains conformant with IEEE 802.3 right up to the individual device.

Figure 1: EtherCAT transports data to and from multiple slave devices in a single frame, either (a) directly encapsulated, or (b) as a UDP/IP payload.

The EtherCAT protocol

EtherCAT data can be transported in an ethernet frame directly, or as a UDP payload, as shown in Figure 1b.

When transmitted directly, the special ethertype 88A4 is used (Figure 1a). A single frame can carry several EtherCAT datagrams and their sequence is independent of the physical order of the devices in the network, so addressing can be in any order. Broadcast, multicast and direct communication between slaves (peer-to-peer) are all possible. Use of direct ethernet frame transfer is for cases where maximum performance is required and the nodes are all in the same ethernet subnet.

When EtherCAT UDP is used, the EtherCAT datagrams are packed inside UDP datagrams with a UDP port of 88A4 (Figure 1b). The additional IP header then allows the frame to be carried across multiple subnets. In this case, the UDP datagram needs to be unpacked in the first station addressed by the packet.

Slave peer-to-peer

As well as master/slave communication, slave/slave communication is possible with EtherCAT in two ways that are topology dependent.

Upstream nodes can communicate with downstream nodes within the same packet cycle as master/slave communication, making the communication extremely fast. Since this method is dependent on the order of the slaves, it lends itself well to slave/slave communication that frequently occurs in machine or mechatronic systems, such as printing and packaging systems.

Where the receiving slave is not downstream of the sending slave, then two cycles are needed to achieve communication.

Topology

EtherCAT can support a variety of different topologies - bus, tree or star - and any combination of them, and wiring choices can be standard wired ethernet cabling or optic fibre for special applications. Because fast ethernet is the base technology for EtherCAT, nodes can be up to 100 m apart and a maximum of 65,535 devices can be connected.

Clocks

In order to apply ethernet in a distributed control system where different processes require synchronised action, accurate time synchronisation is important. An example may be the coordination of several servo axes simultaneously. The method now frequently used for managing accurately aligned distributed clocks is described in the IEEE1588 standard, which provides a high degree of tolerance to faults and delays in the communication system.

With EtherCAT, due to its predictable ring structure, the network propagation delay is easily determined and the clock offset for each slave can therefore be determined accurately in the hardware, providing a network timebase with less than 1 µs jitter. External synchronisation with other devices on the ethernet network can be achieved via the IEEE 1588 protocol.

Performance

In EtherCAT devices, all protocol processing is performed in the interface hardware, rather than in software-based protocol stacks running under an operating system. It is therefore independent of CPU performance or variations in software implementation. This results in an update time for 1000 I/Os of only 30 µs including the I/O cycle time. Since up to 1486 bytes of process data can be exchanged in a single ethernet frame, almost 12,000 digital inputs and outputs can be handled in a transfer time of around 300 µs.

Under normal circumstances the EtherCAT protocol therefore leaves more than sufficient bandwidth for asynchronous communication such as TCP/IP-based management and configuration, parameter download or diagnostic data upload. We also must not forget that, since it is based on ethernet, EtherCAT is therefore scalable to gigabit ethernet and higher and is not fixed to a specific transmission speed like traditional fieldbus systems. Availability EtherCAT provides optional cable redundancy that allows devices to be shut down or single cable breaks to be tolerated. Adding an additional Ethernet port in the master device allows a single cable device topology to be turned into a ring, in which switchover during failure takes only one cycle. Redundant masters with hot stand-by are also supported. Integration with standard ethernet networks Because the EtherCAT frame is a standard ethernet frame with an EtherCAT-specific ethertype, the protocol allows other ethernet-based protocols on the same network.

Figure 2: EtherCAT protocol stack.

Other types of ethernet devices, such as computers, can be connected into the EtherCAT segment via a switch port with minimal affect on performance, and the EtherCAT network is fully transparent for the other devices.

EtherCAT devices can also support other protocols and act like standard ethernet devices, allowing the use of standard TCP/IP-based protocols such as HTTP, FTP and SNMP - making management and configuration of the devices standards based without the necessity of proprietary management systems (Figure 2). This works by virtue of the master device acting as a layer 2 switch that re-directs frames to the respective devices on the EtherCAT segment. EtherCAT also provides a file transfer protocol called File Access over EtherCAT (FoE) that is similar in operation to TFTP, enabling simple firmware uploads to devices irrespective of whether they support TCP/IP.