Low-end, low-cost networks such as CAN and other Fieldbus interconnects are ubiquitous in distributed embedded systems, but many applications require more bandwidth these days – especially as multimedia moves into the embedded space and industrial applications. Ethernet-based networks can support the higher-bandwidth requirements and still support real-time application requirements via specialized network layers added to the baseline standard. Let's evaluate the available networks that can be applied in applications such as industrial control. We will also consider the microcontroller (MCU) and embedded-microprocessor technologies that can support such fast networks and how you can implement the protocols in an embedded application.
Fieldbus technologies, a family of industrial- and control-centric interconnects, have been used to link distributed controllers since MCUs and microprocessors invaded the industrial-control space. The trend started with point-to-point RS-232 links between processor nodes and evolved with Fieldbus standards such as PROFIBUS linking multiple nodes on one interconnect. Controller Area Network (CAN) arrived as an option coming from the automotive world, but none of these technologies afforded anywhere near the bandwidth of Ethernet and the constant ramp in bandwidth driven by the IT space.
Just as with other embedded-computing segments, the control space saw many reasons to pursue an Ethernet-based control network. The IT world was driving down the cost of supporting Ethernet and the IT world would guarantee faster physical-layer technology over time.
In reality, the embedded space has long used Ethernet as applications such as factory-control systems tied to the IT infrastructure. However, those uses are really just IT implementations in disguise. Many embedded systems need connections to the Internet or private networks, and you can find standard Ethernet support on relatively low-end MCUs these days.
The problem with Ethernet as a network to link distributed control systems is that the IT-centric media-access controller (MAC) layer does not support real-time, low-latency data transfers. Ethernet is designed to allow nodes to take control of the network and transmit relatively large packets of data. Control networks need deterministic transfer of relatively small amounts of control or status data.
Several different companies and organizations have set out to modify Ethernet, or rather, add optional layers such as real-time media-access control, to provide the feature set required in distributed-control applications. Generally the efforts attempt to leave the baseline Ethernet physical layer (PHY) and MAC capable of carrying traditional IT traffic or deterministic control commands and data gathered in real time. Most of these interconnects have come into the control segment relatively recently, so we will review the network options and implementation possibilities on MCUs.
PROFINET was perhaps the first Ethernet-derived control network and has been promulgated by the same organizations that pushed the PROFIBUS fieldbus technology. The creators added new transport- and network-layer alternatives to TCP/IP that provide better real-time support, although both stacks can coexist side by side. The PROFIBUS standard still relies on the Ethernet MAC. PROFIBUS circumvents that limitation by defining specific topologies for real-time-control deployments.
PROFINET actually comes in three flavors. The baseline technology provides some improvement over Ethernet, but does not support control cycle times below 100 ms. The PROFINET RT (Real Time) versions can support cycle times between 1 and 100 ms, and the PROFINET IRT (Isochronous Real Time) version can support cycle times under 1 ms with jitter less than 1 µs.
PROFINET runs atop standard Ethernet MAC layers, and many MCUs and processors that support Ethernet can host PROFINET protocol stacks. For example, Freescale
reported that any Power Architecture MCUs
and ColdFire MCUs
that include Ethernet can host the stack. The MPC5121e
is one specific MCU that Freescale targets to the industrial-Ethernet application. That 760-MIPS MCU has plenty of performance overhead to handle the network stack and the application at hand. It also includes an audio accelerator and a graphics engine.
There is a caveat to the broad claim of PROFINET support, however. An MCU such as the MPC5121e can certainly support PROFINET and PROFINET RT. Freescale acknowledges that you will need an FPGA or ASIC to accelerate the PROFINET IRT stack and meet the tighter timing requirements.
is another company that supports industrial-Ethernet technologies. The company recommends the AT91SAM9G45 MCU for PROFINET applications including the RT version. Atmel also recommends an FPGA or ASIC to support IRT low-latency response. Figure 1 depicts the general Atmel architectural strategy for low-latency industrial Ethernet including PROFINET IRT and other standards we will discuss shortly.
Figure 1: Atmel relies on an FPGA or ASIC as a complement to its MCUs when supporting the most-deterministic industrial-Ethernet flavors such as PROFINET IRT and EtherCAT.
EtherNet/IP and Ethernet Powerlink
EtherNet/IP (Ethernet Industrial Protocol) is another flavor of Ethernet that has been customized for control applications, although the modifications in this case are at the top layers of the network stack. There is very little in the standard to implicitly improve determinism other that the definition of a more precise clock for node synchronization. The benefits of EtherNet/IP really are based in the use of much faster processors.
Ethernet Powerlink is supported by the Ethernet Powerlink Standardization group and introduces a time-slicing mechanism that operates on top of the standard Ethernet MAC. The scheme supports control cycle times as low as 200 µs and jitter below 1 µs. Moreover the standard has the ability to host CAN protocols at the application layer making it a good choice for CAN applications that need to migrate to faster networks.
In terms of implementing Ethernet Powerlink, the good and bad news come courtesy of the same fact. The implementation is purely software based and is fully compatible with standard Ethernet. However, you need a powerful, communication-centric processor to realize the Powerlink benefits. For example, Freescale recommends its PowerQUICC processors
that integrate programmable communications engines. For now, the technology is beyond the capabilities of most MCUs.
The final technology we will discuss here is Ethernet for Control Automation Technology. EtherCAT seeks to get at a core problem of Ethernet in deterministic applications that we have not described earlier in the article. Generally, Ethernet relies on relatively large data frames that convey info from one node to another. If a controller needs to transmit data to multiple remote nodes, it must do so in sequential frames. In the case of many control applications, much of those frames would be empty because of the short nature of control information.
EtherCAT defines a master/slave topology on a network. The master can mix data for multiple slave nodes into a single frame. Moreover, the topology ensures deterministic response. The technology allows concurrent messaging to multiple nodes, as the EtherCAT Technology Group does not specify a single control-cycle minimum. However, the organization reported that you can update 1,000 I/Os in only 30 µs.
As with the other industrial-Ethernet flavors, EtherCAT technology has up and down sides. Freescale noted that its MPC5121e can easily handle the task as an EtherCAT master. Figure 2 depicts the typical Freescale approach to such a design. As you see, the implementation simultaneously supports legacy Fieldbus protocols.
Figure 2: Freescale supports EtherCAT master functionality across a broad range of MCU architectures, including those based on the Power Architecture and even ColdFire MCUs in some cases.
The slave implementation is another story, because the slave must dissect every frame in real time to find data directed to it. As with the PROFINET IRT technology, an FPGA or ASIC is required for the real-time frame processing.
Still, EtherCAT appears to be gaining momentum. With the escalation of MCU integration levels and performance, it is relatively easy to envision MCUs that integrate the EtherCAT slave functionality.
Support for the technology is also building. Earlier this year Texas Instruments
(TI), announced that it had licensed EtherCAT technology. The company plans to support EtherCAT in its Stellaris family
of ARM-based MCUs.
The task of deploying Ethernet-based networks in industrial-control applications may be a bit more difficult than utilizing CAN, PROFIBUS, or other Fieldbus standards. However, Ethernet can provide clear advantages in terms of data rate. Moreover, the industrial-Ethernet flavors generally maintain support for standard Ethernet traffic, so you may find it handy to mix control data with operations information and even multimedia content. You may need a more-powerful MCU or processor to support industrial Ethernet, or even an FPGA. Such a choice may prove to be the most viable option if you are experiencing bandwidth issues in a control application.