Real-Time Performance Across The Factory Floor

Next generation processors continue to push the performance envelope. It seems the price continues to drop while the processing speeds increase with each new processor release. I recall discussions not that long ago in which the future utility of real-time operating systems and middleware were being bantered about as if they were not going to be required going forward. After all, with each subsequent new processor released executing faster than its predecessor, wouldn’t the obvious conclusion be that at some point a general purpose operating system and stack on a really fast processor would be good enough? I suspect in many circles that conversation is probably still ensuing.

However, when it comes to many industrial control applications, the need for real-time performance does not appear to have receded and RTOSes with middleware continue to play an important role. Of course there is the hard real-time vs. soft real-time segmentation; depending on the type of control to be performed, the device may fall into one category or the other. I guess one can look at it from the perspective of, if work or response by the controller for a process falls outside of the tolerable time window and results in a malfunction or failure, then the controller must be a “hard real-time” device. Alternatively, if missing a response results in something less than malfunction or failure, and is acceptable, then the controller is “soft real-time.”

As important as a real-time response can be for industrial systems, any discussion on latency and performance must include jitter. As an example, for the most demanding industrial applications with hard real-time requirements latencies may be tolerable in the 200 microsecond range. A simple way to look at it is, for every input, the device responds with an output in 200 microseconds. However, in a typical system, if a sample of inputs and outputs were measured, there would be a delta in time that is slightly different for each input. For example, some of the outputs could be much less than 200 microseconds while others could be greater.

This difference, or jitter, can have a huge impact on the ability of a controller to meet performance requirements. For industrial systems, latency and jitter are critical to meet performance requirements across the factory floor. Industrial devices are connected to networks that are used to transmit and receive critical data that is subsequently used to both synchronize and control devices. Just as an RTOS is required to meet system performance for a device, an industrial protocol is needed for device control and synchronization in the factory.

To that end, EtherCAT is one of the most efficient Ethernet-based industrial communication protocols available. It is based on standard Ethernet hardware to provide real-time communication for industrial applications. “Processing on-the-fly” is a key feature of EtherCAT. As network traffic is generated from the Master EtherCAT controller, EtherCAT slave devices process each frame “on-the-fly” without stopping them. Data reads and writes can be extracted and inserted by each slave device as the frame navigates throughout the network without losing any overhead. As the required control loop period can change depending on the control function required, EtherCAT offers flexibility – there can be longer cycles for I/O updates, or ultra-short cycle times for synchronizing robotic arms, for example, on the same wire.

Because EtherCAT can be deployed on existing networks it is easy to see why it has been so widely embraced. Mentor Graphics’ Nucleus RTOS has been recently integrated with Koenig-PA’s EtherCAT Master stack. Because Nucleus is a light weight, high performance RTOS, we were expecting extremely low latency and jitter across the network. When measured on a Xilinx Zynq SoC-based platform, the results were downright impressive: 100 microsecond cycle times with a jitter of less than 5%. As the real-time debate continues, the bar has just been raised.