Do you speak my plant language? Multi-protocol industrial communication

Robotic systems on the factory floor usually need to connect to the plant network as part of a synchronized production process. Consortia-led and OEM-driven “open” Ethernet-based protocols — such as EtherCAT, EtherNet/IP, CC-Link IE, and PROFINET — are among the many available standards. Machine builders have the task of picking one protocol to support their designs. In addition, servo drive interfaces are using encoder protocols such as EnDat, BiSS, A-Format, and others that are also claiming turf in a war of protocols.

But do machine builders really have to choose only one network?

Industrial networking at the machine level requires efficient packet handling with low latency and needs to be as deterministic as possible. TCP/IP protocol cannot be used for real-time controls in which PLCs need to send commands to drives or actuators and assume the message is received and executed very quickly. Instead, industrial networking protocols typically use the UDP protocol to send the packets of data. The recipient slave devices receive the packets and execute or forward them to the next device on the network. The approach for these different protocols is to define their own packet message or datagram and leverage from Layer 2 (data link) customized MACs and up to the Layer 7 application layer by defining their own object identification. Either way, industrial networking packet software is needed to handle the Ethernet header and data. This can be a burden to the CPU that manages this communication, controls an actuator, or drives a motor.

Implementation

For years, the approach has been to use ASICs or FPGAs to support these protocols and offload the burden from the CPU. However, the problem with ASICs is that you are typically committed to one protocol. If you walk into a factory and they happen to use a different protocol than the one you support, you will need to add a protocol converter. On the other hand, if you’re using an FPGA, you will certainly get the flexibility of the various protocols, but then you’ve just increased your BOM costs by at least 30%, increased your power consumption, and added to development complexity.

Hardware accelerators

A new option is to use MPUs that have built-in hardware accelerators to manage the packet handling. Operations such as encoding and decoding data packets or computing simple checksums can be implemented in hardware to improve packet processing, freeing CPU bandwidth for other tasks. These accelerator blocks remove the software from most of the low-level processing of the Ethernet frame and the software stack code is reduced.

Fig. 1:  Built-in hardware accelerators can implement the various protocols.

Reprogrammable hardware

Another approach in supporting different protocols in a single device is to have an SoC with a programmable block that can be configured to support different protocols, such as encoders. Servo drive encoder protocols — such as EnDAT, BiSS, or A-Format — carry information about rotor position, angle, and rotation counts in a specific format. The problem is how to incorporate the ability to support multiple encoders on the same device.

A processor SoC

One example of a processor SoC that is designed to support real-time applications, such as servo drives and motion controllers, is the Renesas RZ/T1. It has a dynamic reconfigurable processor (DRP) core with an array of processing elements and a DMA controller structure that can be field-reconfigurable by firmware to allow for an almost infinite variety of functions. The DRP logic is stored in RAM so it can be changed at run time within a single CPU cycle. 

Fig. 2:  SoC with DRP core enables simple configurability to different encoder interfaces.

A DRP block can be used to support the different absolute encoder interfaces. The profile of each encoder can be changed by a simple change in the firmware (in C-code) and will not need any FPGA-like programming knowledge.

The processor uses a Cortex-R4 with FPU core, which was designed for real-time processing, and is capable of operation at up to 600 MHz. Access does not need to be performed via cache memory, and tightly-coupled memory capable of definitive real-time response processing is built in. RZ/T1 devices that are equipped with an R-IN engine, an accelerator for industrial Ethernet communications, can perform industrial Ethernet processing without loss of real-time performance.