A Universal Approach for Implementing Real-Time Industrial Ethernet

Introduction

“Industrial Ethernet” is a broad term that generally refers to two distinct types of networking: (1) non- or Soft Real-Time (SRT), which is primarily characterized by information processing and (2) Isochronous Real-Time (IRT), which offers deterministic control messaging for high performance factory floor equipment.

An example of SRT would be a warehouse in which the enterprise network has to communicate information to and from a barcode scanner in the receiving department. In this example, seconds or even minutes are perfectly acceptable update rates for this level of processing.

In a production environment, there may be a machine for which IRT characteristics must be employed. In such machines, it is necessary that the various sensors and actuators communicate very fast and with determinism. Fieldbus communication such as Profibus, DeviceNet, and CANopen are typically employed to transfer control data within milliseconds among the distributed sensors and actuators on a machine.

In order to improve machine throughput beyond the fieldbus data rates, Ethernet is considered to be a faster messaging transport layer.

Ethernet, by itself, is inherently non-deterministic and cannot guarantee that all nodes on a network will be able to access the network, a requirement in IRT applications. To circumvent this deficiency, measures have been taken, by virtue of the many industrial Ethernet standards, to insure that all nodes on a network are able to transmit data within less than a millisecond. Slower performance (i.e. greater than a millisecond cycle time) does not justify the additional expense of using a higher cost 32-bit Ethernet device over an 8- or 16-bit lower cost fieldbus device for IRT type communication.

 

IRT Industrial Ethernet Performance Criteria

The performance criteria associated with IRT Ethernet are:

1. Overall jitter precision of the system
2. Minimum cycle time
3. Response time of the nodes

 

Jitter

Jitter is a term used to describe timing deviation of cyclic events. For example, if an event should occur every 500µs, and it actually occurs after 498µs in the best case and 504µs in the worst case, the difference is referred to as jitter. In this example, the jitter is 6µs. Network jitter refers to the jitter caused by the network and its components, including all connected devices. Most IRT Ethernet standards have a network jitter of less than 1µs. Therefore, the timing fluctuation between any of the connected devices is always less than 1µs.

 

Cycle Time

Most IRT Ethernet applications target a cycle time of 500µs. In some applications, 200µs are required, but there is generally a reduced number of nodes. The cycle time is determined by the total of all communications on the bus. Since every individual node performs specific tasks, there are also node internal processes like Network Management and Cycle State Machine tasks that must be considered. When considering an IRT Ethernet standard, it is important to calculate cycle times that take into account all the message events on the bus.

 

Response Times

Another important performance criterion is the response time, which is the time gap between the reception of an incoming request and the transmission of the response. The lower the response times of a node, the higher the bandwidth usage of the bus. Since there is no function to handle the low level package handling (reception/transmission) in software, typical microcontrollers are able to achieve response times in the range of 3-10µs. Low response times on microcontrollers can typically be achieved with highly optimized assembler routines, which makes such routines very specific. The drawback of this approach is that changing the hardware microcontroller platform is problematic due to the uncertainty of performance levels that can be achieved on alternative systems.

An alternative to the microcontroller approach is an FPGA with an integrated HUB/Ethernet Controller and a hardware state machine for package handling (both in VHDL). This alternative makes the response time much faster and more deterministic. The hardware state machine is completely independent of factors like interrupt latencies or DMA speed. Providing such IP in VHDL language reduces the dependencies on specific processor platforms. The FPGA approach guarantees response times of less than 1µs. We will come back to this issue later on. First, it is necessary to understand some of the basic differences between the existing open industrial Ethernet standards.

 

Industrial Ethernet Standards

At last count, there were nineteen industrial Ethernet protocols announced by various vendors. However, only six of these are generally regarded as open standards. EtherNet/IP, ProfiNet I/O and MODbus TCP are popular SRT choices. ETHERNET Powerlink (EPL), SERCOS III, EtherCAT and ProfiNet IRT are being deployed in IRT applications such as motion control.

The most important question for equipment vendors is “how can we manage these multiple protocols on a single platform?”

The implementation strategies outlined in this article illustrate how an FPGA vendor and a protocol supplier have worked together to offer a single FPGA platform for all SRT and IRT protocols. With this comprehensive and flexible solution, FPGAs enable equipment vendors to design a single hardware platform that can be installed with application relevant SRT and IRT protocols. This process avoids costly development time and vastly increases the communication flexibility of the OEM’s and supplier’s products.

 

SRT Protocols on an FPGA

ProfiNet I/O device and EtherNet/IP adapter can be fully executed on the Nios II embedded processor of the FPGA, both stacks are based on a standard TCP/IP stack without specific real-time requirements. However, due to performance optimization, the cyclic I/O data are communicated directly with the Ethernet controller bypassing the ProfiNet or Ethernet/IP stack (left path) while configuration or service data must go through the stack. Additionally, the FPGA implementation of ProfiNet and Ethernet/IP provides a direct TCP/IP communication path which can be used for general purpose protocols such as http or ftp.

 

 

IRT Protocols on an FPGA

Ethernet Powerlink

The implementation of Powerlink on an FPGA provides a very powerful and highly flexible solution. The FPGA contains an Ethernet hub and an Ethernet controller/EPL packet handler. In addition, a 32-bit CPU core is also included in the FPGA. This processor core provides the flexibility to execute a scalable amount of software. For slower I/O (Control Nodes), the whole EPL stack plus application software can be implemented without a host CPU. For faster control nodes, only the EPL stack (or a part of it) has to be implemented. A part of the EPL V2 stack is executed on the CPU embedded in the FPGA and the other part of the stack is executed on the host processor.

The most important advantage of this approach is that the host CPU is isolated from the Ethernet Powerlink’s critical real-time processes.

 

 

Figure 2 illustrates the host CPU with additional FPGA containing the CPU core. The application code is executed on the host CPU and the EPL Stack is executed on the FPGA.

Alternatively, the EPL stack can be divided into two parts. The low level routines stay on the FPGA and the higher layer part (e.g. Object Dictionary or PDO Mapping) can be executed on the host processor CPU. This achieves shorter cycle times. The FPGA contains the Ethernet controller and hub, which guarantees ultra low response times of less than 1µs. Hub latency is approximately 400ns.

 

SERCOS III and EtherCAT

SERCOS III and EtherCAT are the two IRT protocols meeting highest real-time requirements. To achieve this performance, specific Ethernet MACs are required. These specific Ethernet MACs are available as routable net lists and have been implemented in the FPGA by providing the necessary number of logic cells. The EtherCAT protocol can be scaled to the extent necessary for different device types. Typical consumption of logical cell for a synchronized servo drive is 12-15kcells, which is the same for SERCOS III.

 

 

Conclusion

For industrial automation equipment vendors and users, interoperability is no longer a barrier when deploying the solutions presented in this article. Of profound importance is the ability for sensor and actuator vendors to employ one FPGA device that supports multiple Industrial Ethernet protocols. The ability of a CPU enabled FPGA operating as a communication processor in conjunction with a master or slave processor offers very tangible advantages in terms of reducing up front development costs as well as increasing performance of such a solution.