This website uses cookies primarily for visitor analytics. Certain pages will ask you to fill in contact details to receive additional information. On these pages you have the option of having the site log your details for future visits. Indicating you want the site to remember your details will place a cookie on your device. To view our full cookie policy, please click here. You can also view it at any time by going to our Contact Us page.

Cost-effectively bringing Ethernet to the edge

30 May 2017

Control Engineering Europe reports on how the Ethernet interface can be reduced in size, power, and cost to allow it to be incorporated into edge devices such as sensors and actuators. 

Recent advances in communication technology have changed the landscape for Ethernet and today the concept of low-complexity Ethernet is being used to bring EtherNet/IP communication to edge devices. 

An Ethernet node consists of both a hardware and a software architecture. On the hardware side, the architecture can either be a processor-MAC-PHY (Media Access Controller) (Physical Layer Device) or a processor-MAC-switch-MAC-PHY in the case of multi-port devices. No matter what processor is used, it will be paired with an Ethernet MAC. And in many cases, the PHY is not integrated on-chip due to power dissipation, chip die area, and cost considerations. Also, PHY performance in real-time applications is critical, so leaving the PHY separate allows the designer to choose the right PHY for the application. In all cases where the PHY is not integrated with the MAC, the interface to the PHY is MII (IEEE 802.3) or RMII (RMII Specification) for 10/100BASE-TX (10/100 Mb/sec) Ethernet and GMII (IEEE 802.3) or RGMII (IEEE 802.3) for 1000BASE-TX (1 Gb/sec) Ethernet. These interfaces involve many high-speed signals consuming numerous pins and additional board space due to layout considerations. 

Scaling an Ethernet node 
To reduce the cost, size, power, and complexity of hardware in an EtherNet/IP edge device, it is important to target small-scale single-chip processing solution by reducing processor speed/performance, flash memory size and RAM size. Other areas to focus on include a reduction interconnect complexity from processor to network interface and a reduction in pin-count and complexity of the network interface. 

The addition of an Advanced MAC to the network interface (PHY/switch chip) will accomplish most of the size reduction goals. The Advanced MAC performs intelligent/dynamic frame filtering and buffering before any frames are communicated to the processor chip. This prioritises protocols, and surges in frame receipt. The intelligent filtering reduces overall buffer space and reduces the amount of data that has to be transferred to and processed by the application processor. 

The reduction in frame communications allows a simpler interface to be used for communication. The Serial Peripheral Interface (SPI) bus provides a common interface with low pin count and frequency based on the capabilities of the processor chip, and ease of electrical isolation between the application and the network communications. The SPI interface and frequency is unchanged, whether the device is communicating at 10 Mbit, or 1000 Mbit, just as the application communication requirements of an edge device are not changed by the network bandwidth. This interface also allows for very low power and low frequency processors that cannot manage the load necessary to manage a standard MII interface. The frequency and timing of the interface can be managed to avoid noise issues in critical application interfaces, whereas a MAC receive operation is asynchronous to the application operation. 

Additional features can be added to the Advanced MAC for common and well understood functions such as synchronisation (e.g. IEEE802.1AS), further reducing processor frame processing and RAM/Flash requirements. Functions associated with can also be incorporated into the Advanced MAC, although this requires work to select appropriate approaches for the data and security characteristics of edge devices as opposed to standard SSL/TLS. 

Further reduction of Flash requirements (and the associated elimination of external ROM for the processor and reduction of cost/complexity of the edge device) requires elimination and/or simplification of protocols that are required for more complex devices. 

Many protocols that make sense for a full-purpose node may be costly for a small node. For example, LLDP transmitter is a simple protocol easily managed in a constrained device. LLDP receiver is somewhat more complex, but not generally too difficult for a node with only one or two Ethernet ports. The complexity comes with support for protocols like SNMP that are used to query LLDP receivers. Single-port devices can benefit from being connected to infrastructure switches that support LLDP receive function, thus the single-port low cost node only needs to be an LLDP transmitter. For two-port devices in a line topology, another solution is necessary. 

Network management protocols are another burden for small nodes and can typically be eliminated from two-port devices as long as the rules for setting up a network are carefully worked out. Specific work to develop widely accepted protocols for line topologies is needed. Other areas that can be excluded include security (SSL/TLS), device management (DHCP, BOOTP, ICMP) and application interfaces (Berkeley sockets). This reduces memory usage by a small amount but takes with it some convenience in system configuration and management. 

The answer?
The answer for EtherNet/IP to the edge lies somewhere between a current full-up device and a hardware-only device. While some advocate only a limited set of protocols to reduce footprint, it would be better to select from a wide range of protocols only those that are required by the application. In other words, if an application doesn’t need to support, say, ICMP, then it should be optimised out of the TCP/IP stack. By advancing the capabilities of an Ethernet MAC and an Ethernet Switch the processor, Flash, and RAM requirements can be significantly reduced. It also allows for a ‘reallocation’ of the Ethernet function out of the processor and into the PHY. 

An example 
Perhaps one of the most area and power constrained devices in automation systems is the temperature transmitter which takes signals from a temperature probe and converts the information into a 4-20mA signal to transmit temperature to the automation system. HART can also be overlaid onto the 4-20mA signal to control set points or change calibration variable as well as receive diagnostic information. The temperature transmitter could also do this via Ethernet, but there are issues putting Ethernet in such a constrained environment. Assuming there will be a means to get Ethernet to a temperature transmitter, we still need a low power, reduced area, cost-effective way to put Ethernet inside the transmitter. 

The architecture of a temperature transmitter currently uses a microcontroller for temperature calibration, control, and diagnostics and a microcontroller for communication. The microcontroller on the communication side interfaces to the 4.20mA interface through a Digital-to-Analogue Converter (DAC). If HART is used, a HART modem is also connected to the microcontroller and DAC. The microcontroller used for communication is also connected to the microcontroller performing the temperature calibration, control, and diagnostics. This communication path is isolated to keep the two sides electrically independent. 

It is possible to replace the microcontroller used for communication, the DAC, the HART modem, and EEPROM with a low-complexity Ethernet Device (LED) with PHY. This can either be a one-port or a two-port device depending on the topology of the Ethernet network. Given the low-complexity of the temperature transmitter communication variables, it is possible to scale the EtherNet/IP communication down to one implicit message and three explicit messages. By using a space optimised version of the EtherNet/IP stack along with a minimum TCP/IP stack implementation executing on the microcontroller, it is possible to have a software footprint for the communication software on the order of 128Kbytes of Flash and 64 Kbytes of RAM. 

The concept of low-complexity Ethernet holds the promise of cost-effective, low power, reduced area connectivity for simple EtherNet/IP devices. Such a concept can be realised in an open manner coupled with advanced features in next generation Ethernet MACs and Ethernet switches. By scaling a device’s communication software it is possible to fulfill the connectivity requirements of EtherNet/IP systems while minimising the software footprint. This scaling, in turn, reduces the Flash and RAM hardware requirements to the point where a single chip processor with memory can be utilised in the design of a field device. 

Further, by taking advantage of advanced features in next generation Ethernet MACs and Ethernet Switches, it is possible to reallocate the Ethernet function from the processor into the PHY creating a low-complexity Ethernet device. Such a device provides the processor with a simple SPI interface to the Ethernet network. Not only does this SPI interface have the advantage that it is easier to electrically isolate from the other circuitry in the design, but it also eases the processing requirements since the controller no longer has to process every Ethernet message from the network. Rather than needing an A-class ARM processor to execute application and network software, a single chip processor with memory can be a simple, low-cost M-class controller. It is through this combination of hardware partitioning and software tailoring that we can achieve the concept of bringing EtherNet/IP to the edge. 

This article was created from a presentation given by Innovasic at the 2017 ODVA Industry Conference. A copy of the original presentation paper can be downloaded from www.odva.org


Contact Details and Archive...

Most Viewed Articles...

Print this page | E-mail this page