Industrial Ethernet Standards

This white paper looks at Industrial Ethernet implementation options from the point of view of the factory automation vendor developing slave systems, such as I/O modules and drives.

Introduction

By now it is a well understood fact that Industrial Ethernet is becoming the dominant technology within factory automation for a variety of reasons that have been documented in countless articles, market research reports, and white papers.

What does not get quite the same attention is the implementation of this communication technology in vendor systems. But, in fact, how you implement this increasingly required function makes a difference in the cost, form factor, and power profile of your system. This white paper looks at Industrial Ethernet implementation options from the point of view of the factory automation vendor developing slave systems, such as I/O modules and drives.

The challenges faced by these OEMs are unique, so there are good reasons for reviewing the slave system architecture. Vendors designing slave systems are not wed to any one protocol variant. They must support any standard that may be implemented within a given factory and are not in a position to dictate the protocol variant. Rather, they must adapt their system to any one of the variants. The newer slave protocol standards being developed also have unique hardware features. In fact, they cannot use the standard MAC implementation, which creates some unique challenges and impacts the choice of an implementation platform.

About Industrial Ethernet

Originally, Ethernet- "original" Ethernet at 10 Mbps, fast Ethernet at 100 Mbps, and Gigabit Ethernet at 1 Gbps- was a way to transmit a signal between devices over a shared medium, but was not useful for industrial applications. But the advent of fast Ethernet (100 Mbps) in switch mode with full duplex capability means a point-to-point link can now be built between devices, allowing Ethernet to be used for most industrial applications. All Industrial Ethernet protocols have a need for some level of determinism, which traditionally has been addressed by using a special software protocol stack.

The Need for Speed (Or in This Case, Latency)

We all know that factory automation systems have real-time response requirements. But what exactly is "real time"? The answer is that it depends on the type of application. Sometimes it is measured in terms of hundreds of milliseconds and sometimes in terms of tens of microseconds. And there are different design approaches to get the communication protocol to support differing latency requirements.

As shown in Figure 1, the PHY layer usually is a separate analog device. However, the other functions can be implemented in a digital logic device with a processor to run the software for the protocol stack as well as the customer application. While all Industrial Ethernet protocols require a special software stack, some of the newer protocols (shown on the right side of the figure) use a non-standard, unique design for the media access control (MAC) and/or the switch.

Figure 1. Architecture of the Industrial Ethernet Protocol

EtherCAT and Profinet IRT are two of the newer protocols that require a special MAC design. EtherCAT in particular uses an innovative methodology to pack more data packets within a single Ethernet frame. Data for multiple slave devices is packed into a single Ethernet frame. When a slave device reads the Ethernet frame, it must extract the data package meant for itself and ignore the others. More importantly, it must do this extraction "on-the-fly." The data package is extracted in order to reach the very low latency requirements when many slave devices are connected. For example, if you are the 256th slave device on the network, a single frame latency is incurred rather than a 256 frame latency. Typical applications are motion control or multi-axis robot drives.

To support the chosen protocol, the design of the MAC in the slave device differs from the traditional Ethernet MAC and requires a special design in an FPGA or ASIC. From a system design perspective, if you must support a standard MAC implementation as well as a special implementation, then the design should either include both the MAC designs or be reprogrammable in hardware. Figure 2 shows how different real-time requirements can lead to different architectures of the communication protocol standards.

Figure 2. Different Real-Time Requirements Lead to Different Implementations