MCUs and EtherCAT Gear Up for the Industrial Internet of Things

With many millions of control and process nodes in factories and processing plants around the world, industrial control automation is the next frontier for the Internet of Things (IoT)—and 32-bit MCUs will play an important role.

Ethernet is the obvious choice for connecting manufacturing nodes to create an Industrial Internet of Things (IIoT). By adopting Ethernet technology, the factory floor can be seamlessly integrated into the enterprise, which would allow for faster manufacturing response to changing business conditions, centralized maintenance and diagnostics, and superior factory automation generally.

However, standard Ethernet falls short of the critical factory-automation requirements for two basic reasons:

• Its MAC layer does not support real-time, low-latency data transfers. Standard Ethernet works for IT because it lets individual nodes take control of the network and transmit relatively large packets of data. Control networks common in industry need deterministic transfer of relatively small amounts of control or status data.
• Its star, switch-based topology is very dissimilar from networks found in manufacturing and processing plants.

To solve these problems, over 2,600 companies have endorsed EtherCAT (Ethernet for Control Automation Technology), which adds real-time and other capabilities to classic Ethernet and enforces configurations that make it a very efficient automation network technology while fully conforming to Ethernet specifications. The EtherCAT Technology Group maintains the standard, which is part of the International Electrotechnical Commission (IEC) body of standards.

EtherCAT allows any standard PC to be used as an EtherCAT master and communicate with EtherCAT slaves. Together, they can be used to connect all devices in the factory network – automation controllers, operator interfaces, remote input/output units, sensors, actuators, drives, and others.

Any viable industrial Ethernet solution must support hard real-time performance, which means EtherCAT requires a dedicated hardware interface. But unlike other solutions in the market, EtherCAT requires hardware only on the slave nodes. This simple precaution – not requiring dedicated hardware on the master – delivers optimal, predictable network performance because software stack delays do not impact overall performance. Keeping hardware only on the slave side also leads to lower costs.

There are numerous hardware strategies for designing an EtherCAT slave node. The German company Beckhoff Automation – which created EtherCAT before it entered the public domain as a standard, used FPGAs for its first EtherCAT Slave Controller (ESC). ASICs are another alternative and many EtherCAT device vendors use of the configurable EtherCAT IP-Cores for Altera and Xilinx FPGAs.

When an MCU is part of the overall system plan, however, using an MCU that supports EtherCAT slave-controller interfaces can reduce the bill of materials cost and save design time. This is particularly true for IIoT applications in which a wireless connection is either required or desired.

The Texas Instruments’ Cortex-A8_based Sitara™ MCUs support EtherCAT on-chip. Other companies such as Infineon, Renesas, Microchip Technology, Freescale, and Atmel also offer EtherCAT solutions that are integrated either on-chip or combine a simple FPGA or ASIC-based slave controller with a 32-bit MCU and an RF chip if the application calls for a wireless link.

EtherCAT basics

EtherCAT implements a technique called “on-the-fly” processing in which each node in the EtherCAT network reads frame data as it passes through. Frames originate at the EtherCAT master, which sends commands and data to the slaves. Any data sent to master is written by the slave into the frame as it passes through. This eliminates point-to-point exchange of small-sized frames between master and individual slaves and drastically improves communication efficiency.

On-the-fly processing means that slaves must have two Ethernet ports in order to be capable of reading from or writing to the frame as it is passing through. Therefore, slave devices require specialized hardware. As a result of this configuration, however, the usable bandwidth in a 100 Mbits/s network running EtherCAT exceeds 90 percent as compared to less than 5 percent for networks where the master communicates separately with each slave node.

EtherCAT maintains its compatibility with standard Ethernet by encapsulating an EtherCAT telegram in the Ethernet frame. The Ethernet frames use the EtherCAT type in the header or they can be packed with the IP/UDP header for consistency with Internet protocols. When the IP header is used, the EtherCAT protocol can also be used across network routers.

EtherCAT telegrams include one or more EtherCAT datagrams that are addressed EtherCAT slaves. Each EtherCAT datagram is a command that consists of a header, data, and a working counter. The header and data are used to specify the operation that the slave must perform, and the working counter is updated by the slave to let the master know that a slave has processed the command.

Figure 1 illustrates the relationship between Ethernet and EtherCAT telegrams and datagrams.

Figure 1: EtherCAT telegram encapsulation. (Courtesy of Texas Instruments)

Topologies and clocking

EtherCAT supports any topology – line, star, or tree – as well as the common fieldbus topologies. Because all the I/O devices have embedded EtherCAT interfaces, Ethernet-switching hardware is not required. With the 100 m range of copper links and even longer with optical links, EtherCAT can span over thousands of devices spread across a large geographical area. For short distances, such as on back-plane, EtherCAT uses E-bus, a differential signaling technology.

EtherCAT accomplishes clock synchronization by sampling the timestamps for the ingress and egress of an EtherCAT packet on every slave node as it traverses the network. The master uses the timestamp information provided by the slaves to calculate the propagation delay for each individual slave. The clocks in each slave node are adjusted based on this calculation. Clocks are synchronized to within 1 μs of each other. An additional advantage of synchronized clocks is that measurements required by the application can be linked to the synchronized time. This removes the uncertainty associated with the jitter in the communication between devices.

EtherCAT implementation strategies

As mentioned earlier, there are several ways to implement EtherCAT slaves in hardware.

For simple EtherCAT applications, digital I/O can be created using single FPGA or ASIC solutions. These implementations are good for cost-sensitive simple I/O nodes that do not require software and where functionality can be implemented entirely in hardware.

Ethernet slave-controller chips can also be used – as long as they have been modified to meet EtherCAT specifications such as dual Ethernet ports for reading and writing of the fly. When additional processing power is needed, an MCU can be connected to the ESC for handling the application-level processing. This solution is appropriate for sensor applications, for example, in which the MCU interacts with the sensor, implements the device driver and runs the EtherCAT protocol stack. It can also be used when wireless communications in involved.

Microchip Technology is among the MCU companies that offer an EtherCAT slave controller (ESC). The LAN9252 is a 2/3-port ESC with dual-integrated Ethernet PHYs, FMMUs, four sync managers, distributed clock support, and 4 Kbytes of DPRAM. It also integrates a host bus interface to enable connections to most 8/16/32-bit embedded controllers. When developing industrial automation applications using the LAN9252, a good MCU choice would be one from Microchip’s PIC32MX family. One with the required peripherals is the PIC32MX795F512LT. Figure 2 is a simple block diagram of a system that utilizes the LAN9252 with added detail on one slave node.

Figure 2: Utilizing Microchip Technology’s LAN9252. (Courtesy of Microchip Technology)

The first step in developing an application is to integrate Microchip’s LAN9252 software development kit (SDK) with an EtherCAT Slave Stack Code (SSC): Both are required to develop application code on Microchip’s EVB-LAN9252-HBI evaluation board.

The SDK can be downloaded from Microchip’s website. The preferred SSC was developed by Beckhoff Automation – the company that originated the EtherCAT specification. Design houses must be a member of the EtherCAT Technology Group (ETG) to gain access to the Beckhoff SSC. Once the SSC is integrated with the SDK, application code can be developed with the SDK to design the EtherCAT ESC.

If the application calls for a wireless connection to the IIoT, one of Microchip’s RN Wi-Fi modules, such as the RN171-I/RM, can be connected with the MCU and ESC system.

The MCU + ESC architecture is more expensive than FPGA or ASIC implementations but it has the advantage of giving designers the option of choosing a processor that suits their application’s needs and cost targets.

Integrated solutions

EtherCAT can also be implemented on devices with an integrated CPU – and not just on MCUs. FPGAs, for example, can be configured with an integrated processor and ASICs are available with both EtherCAT and processors on-chip. Depending on the CPU selection, there is a risk that meeting cost or operating frequency targets would be challenging. MCU implementations, on the other hand, have the advantage of utilizing a 32-bit CPU to satisfy all the application’s processing requirements.

Texas Instruments Inc. (TI) has integrated EtherCAT functionality into some of its Sitara AM335x ARM Cortex-A8 MCUs. The key peripheral is TI’s real-time PRU subsystem, which supports very-low-level interaction with the Media Independent Interface (MII) originally defined for connecting a 100 Mbit/s Ethernet MAC block to a PHY chip. A simplified block diagram of EtherCAT on Sitara is shown in Figure 3.

Figure 3: EtherCAT slave implemented on AM335x ARM MCU. (Courtesy of Texas Instruments)

Low-level interactions with MII enable the PRU subsystem to execute communication protocols such as EtherCAT. The entire EtherCAT MAC layer is encapsulated in the PRU subsystem through firmware. TI’s AM3359BZCZA80 is a typical Sitara MCU used in EtherCAT implementations.

The PRUs process EtherCAT telegrams on-the-fly, parse them, decode the address, and execute the EtherCAT commands. Interrupts are used for any communication required with the ARM processor where the EtherCAT stack (Layer 7) and the industrial application run.

The PRU subsystem also performs the frame forwarding in the reverse direction. Since the PRU subsystem implements all EtherCAT functionality, the ARM processor can be utilized for complex applications or a lower speed variant can be used for simpler and cost-constrained applications, such as distributed I/O.

To complete the EtherCAT solution with AM335x ARM MCUs, Ethernet PHY devices such as the TLK110PTR from TI are required. The TLK110 is optimized for low latency in between MII and PHY interfaces, which is an important attribute for EtherCAT performance. It also has advanced cable diagnostics features that can quickly locate cable faults. TI provides support for EtherCAT development by offering evaluation and development boards such as the TMDSICE3359.

Conclusion

The IIoT – in which many millions of industrial factory-automation nodes will be linked to the enterprise network – will be enabled by EtherCAT and other protocols that bridge the significant differences between the huge installed base of industrial networks and standard Ethernet. The two most prominent differences are (1) The requirement of most factory networks for hard-real-time response and (2) The short data payloads of factory automation, which make standard Ethernet’s large frames inefficient in industrial applications. EtherCAT’s on-the-fly processing scheme resolves these problems and eliminates protocol stack delays in slave controllers.  Several EtherCAT slave hardware implementations are possible, including FPGA, ASIC, and EtherCAT embedded in an MCU. The best choice is determined by the application.

For more information about the parts mentioned in this article, use the links provided to access product pages on the Digi-Key website.