EtherCAT: leveraging industrial Ethernet for 20 years

EtherCAT is the only industrial fieldbus that leverages Ethernet for both high speed and real-time performance.

When it comes to industrial fieldbuses, it seems we are indeed spoilt for choice! The range of options is so vast, it can be hard to know which one will be right for your application. And while it may seem most will do a similar job, says Martin Rostan, the Executive Director of the EtherCAT Technology Group: “The importance of the bus technology is often underrated. Most people think that the controller is the core of the control architecture, but in fact it’s the bus that determines if you can make use of that controller performance or not.”

There are significant differences between fieldbuses, so it’s important to be informed. While a detailed comparison between industrial fieldbuses is beyond the scope of this article, we’ll concentrate on EtherCAT here, which celebrates 20 years of existence this year. That it has made significant inroads into a highly competitive market (Figure 1) suggests it’s worth a second look.

What is an industrial fieldbus?

Fieldbuses have been with us for almost as long as we’ve had industrial controllers (namely PLCs). That’s because not all I/O can be centralised around where the controller will be mounted. While the initial solution for linking remote devices may have been to hardwire everything back to the central controller, it soon became clear from the sheer number of devices concerned and the distances involved that a more efficient method would be needed.

It wasn’t long before the same vendors that produced PLCs brought out their own industrial fieldbuses to link I/O and devices via a network. Each vendor used their own proprietary protocol, which precluded any device not produced by that vendor from being connected into the network. But limiting remote devices to only those available from a single vendor severely limited the effectiveness of the fieldbus, as no one vendor covers all areas of the market equally well.

This situation was addressed in the early 1990s with the release of open vendor networks, such as ProfiNet and DeviceNet. Some or all of the protocol and interfacing details of these fieldbuses were released, which allowed other vendors to produce devices for them. Each network was promoted by its own vendor-neutral organisation, which also safeguarded its integrity by ensuring all vendors produced compliant equipment.

Figure 1: The number of deployed EtherCAT nodes worldwide has shown exponential growth since 2014. For a larger image click here.

Having a fieldbus that allowed devices from multiple vendors to be interconnected meant end users could choose a ‘best of’ technology for their application. This also had the effect of keeping pricing ‘honest’, as suppliers had to compete with each other.

Another major development occurred around the late 1990s, with the widespread adoption of Ethernet into industrial systems. Hereto, networks like RS422/RS485 and a host of other interfaces had been used. Ethernet had already been used in office networking for some years. It allowed large amounts of data to be transferred quickly, in ad hoc fashion. For example, sending a large document to a printer is a one‑off event. Standard Ethernet gives no consideration for real‑time performance as it doesn’t matter if the network is busy and the document arrives a few seconds late at the printer.

Today’s Ethernet’s topology is that of a star, where every node must be connected to a central network switch. This does mean though that all communications are lost if this switch ever fails.

Industry adopts Ethernet

Several of Ethernet’s advantages were highly attractive to industry, namely its high capacity (100 Mb transmissions) over relatively long cable distances (100 m per segment) and using inexpensive cabling (category 5 twisted-pair).

But perhaps the biggest driver for Ethernet was its almost universal adoption by the PC world. As Hans Beckhoff, founder and current Managing Director of Beckhoff Automation, states: “The RS485 and CAN-based networks of the time (ie, mid 1990s) worked well, but they were limited in terms of bandwidth and performance. By the early 2000s, PCs were equipped with Ethernet interfaces as standard, and the first processors with integrated Ethernet interfaces hit the market. EtherCAT was developed so that this new IT medium could be used on machinery, in line with our philosophy, which is to connect the IT world with automation.”

While Ethernet was initially used by industry for communications between controllers and to SCADA systems, it took some time before it was used in a fieldbus. This is because industrial fieldbuses present some unique requirements not seen in general-purpose networking, namely the need for ‘real‑time’ or ‘deterministic’ performance. Working in real time means any transmission delays need to not only be small, but also predictable, so that they can be compensated for. Machines need update rates of around 1 ms to be able to synchronise servo drives and provide accurate time‑stamping of events.

Industrial systems usually send only short messages, which need to be sent often. As Hans said: “The Ethernet protocol is designed for the transmission of large amounts of data and long data telegrams, not for the small units of information common in the machine environment, such as a 1-bit limit switch value or a 16-bit analog value.”

A brief primer on EtherCAT

EtherCAT, a contraction between the words Ethernet for Control Automation Technology, is an industrial fieldbus that takes advantage of Ethernet but applies it somewhat differently to gain real‑time performance.

It was first shown at the Hanover Messe Fair in 2003, the same year its governing body, the EtherCAT Technology Group (ETG), was founded. Both EtherCAT and Safety over EtherCAT (FSoE) were standardised in 2007 as IEC 61158 and IEC 61784 respectively. These standards not only include the lower protocol layers, but also the application layer and device profiles, eg, for drives. EtherCAT complies fully with the standard frames and physical layer defined in the Ethernet standard IEEE 802.3. From the outset, EtherCAT was open vendor, meaning its standards were open for anyone to create devices for it.

All EtherCAT networks have a single master node, usually in the controller. It is also possible to have a redundant master node. Hardware design of the master is straightforward as it requires no special hardware.

Slave nodes, on the other hand, always have two RJ45 ports, for upstream and downstream connections. These are controlled by an EtherCAT Slave Controller (ESC), which can be implemented either in an application specific integrated circuit (ASIC), a field programmable array (FPA), a microprocessor or even a microcontroller.

Like CAN, EtherCAT requires only that the chip manufacturer license their hardware, the cost of which is included in the purchase of the ESC device. There are no other licensing costs for using EtherCAT, and there are many competing suppliers of ESC devices.

The ESC handles the reading and writing of both cyclic (process) and acyclic (mailbox) data. In the case of digital I/O, it’s already built into the ESC’s functionality by being mapped into a logical process image, up to 4 Gb in size; there is no software interaction required for this.

Often nicknamed ‘Ethernet on the fly’, EtherCAT frames originate from the master node and traverse each slave node sequentially. Each time a frame arrives at a slave node’s upstream port, it’s almost immediately retransmitted from its downstream port. The incoming data payload can however be read and be modified to include data that needs to be transmitted to another node. This process only requires several nanoseconds, which gives EtherCAT its speed. Once the data packet arrives at the final node, it’s transmitted back to the master utilising the full‑duplex capability of Ethernet.

The frame-traversing principle is akin to a train stopping at a station, where it allows passengers to both disembark (read data) and other passengers to embark (write data), before moving to the next station (node).

EtherCAT takes full advantage of Ethernet’s inherent capacity and achieves an overall bandwidth utilisation of over 90%. It can update 1,000 I/O points every 30 µS. We can appreciate just how much more efficient EtherCAT is at sending small data packets from Figure 2, where it’s compared to polling and broadcast transmission systems.

A distributed clock mechanism built into EtherCAT means network delay times can be calculated and compensated for. This reduces jitter (the time variance between true periodic signal and its internal reference), making it well under a microsecond.

Figure 2: Bandwidth utilisation for EtherCAT compared with polling and broadcast protocols.

Further speed advances

Having dual Ethernet ports in each slave allows nodes to be connected in a line (also known as a ‘daisy‑chain’), making a central network switch unnecessary in EtherCAT. Speed of communication is improved with the removal of the switch, which inevitably introduce delays due to a switch’s processing and store‑and‑forward operating mechanism. Reducing the required hardware also improves network reliability, reduces costs and simplifies installation and maintenance.

The protocols that run over Ethernet support sophisticated routing to allow web browsers to access websites from anywhere around the world. While this is highly desirable for web‑based traffic, it’s clearly not needed for fieldbuses which run only within a premise. EtherCAT therefore did away with the entire TCP, UDP and IP protocol stacks, thereby making the protocol much simpler and faster.

A simpler protocol also reduces the amount of processing required in each slave node, which in turn reduces heat and power consumption in the node. Some nodes may be simple on/off devices, contributing a single bit of data; they should not have to process large, complex data frames.

Other advantages

The layout of devices in some installations calls for different networking topologies. This is because the equipment within the plant is mounted in such a way that a single topology cannot provide adequate coverage.

To accommodate this, some slave nodes make provision for multiple downstream ports, which means topologies such as line, star and tree connections can all be created. Ring topologies can also be constructed when the master supports two ports. Ring connections have the advantage of providing cable redundancy.

One of the difficulties in a remote I/O network has always been fault‑finding, as it can be very difficult to locate faults down to a particular node or connection. However, the ESC in each slave device counts instances the carrier signal fails and detects corrupted data frames by the cyclic redundancy check provided by Ethernet. That this is done for each port allows problems to be exactly pinpointed.

Extensions to a single standard

Perhaps EtherCAT’s biggest strength is that its initial standard is still current today; it has never changed. This means the very first devices created for it can still communicate with the very latest devices. But this is not to say there haven’t been developments to extend its capabilities over the years. All extensions have first and foremost been 100% backwardly compatible with the standard.

EtherCAT G and EtherCAT G10 are one such extension, which utilise transmission rates of 1 Gb/s and 10 Gb/s respectively. While few applications need anything beyond the normal 100 Mb/s transmitted through Cat 5 cable, some vision applications or linear transport systems with multiple movers do require higher rates of data throughput. In these cases, higher speed links are used as a data backbone to interconnect a series of standard EtherCAT networks together.

EtherCAT P is another extension, where communications and power are combined into a standard 4‑wire Ethernet cable. This effectively halves the cabling requirements as it alleviates the need to run separate power cables to the slave nodes. This not only saves cabling, but it also reduces installation time and is ideal for applications such as smart machines and even processing plants.

Conclusion

This short overview can only give a brief outline of EtherCAT and its capabilities; there are many more facets that couldn’t be mentioned in the space available. It is, however, clear that the network that was designed specifically for the unique requirements of industrial automation has been a success. That the specification has never been altered in the 20 years of its existence is a testament to the foresight of the original designers.

Top image: iStock.com/rozdemir01