Extending EtherNet/IPTM to Resource-Constrained
Industrial Things
Dayin XU
Senior Research Engineer
Rockwell Automation
Paul BROOKSBusiness Development Manager
Rockwell Automation
Presented at the ODVA2015 ODVA Industry Conference & 17th Annual Meeting
October 13-15, 2015
Frisco, Texas, USA
Abstract
The Industrial Internet of Things (IIoT) is exploding. The manufacturing enterprise is experiencing theconvergence between Operational Technologies (OT) and Information Technologies (IT). ODVA
EtherNet/IP, using “Unmodified Ethernet” and IP protocol, is a fundamental network infrastructure for thisconvergence. Control and supervisory level devices in an industrial automation and control system, suchas HMIs, controllers, drives and I/O modules, have already been connected into the IIoT system via
EtherNet/IP. Field level industrial things, such as sensors, actuators, and process instruments, are being
pushed to have network capabilities to improve the data visibility and operational efficiency of devices,
machines and systems. However these field level industrial things usually have constrained resources,
such as limited computational capability, limited memory, limited communication rate or limited power,
and have very low cost and small form-factor requirements. Today’s implementations of EtherNet/IP
hardware and stack cannot meet the demands of adding EtherNet/IP connectivity into these resourceconstrained industrial things due to requirements for relatively more resources, higher cost and bigger
size. This paper examines the potential EtherNet/IP hardware cost and form-factor reductions with theusage of IEEE standard single pair Ethernet technology. Detailed analysis shows that the cost and sizeof the EtherNet/IP hardware and stack could be significantly reduced. This paper also proposes anextension of UDP-capable unconnected messages to the EtherNet/IP protocol so that a much simpler
UDP-only Ethernet/IP stack implementation that can better meet requirements of resource-constrained
industrial things is accomplishable. With these changes, EtherNet/IP would be able to be expanded into
field level resource-constrained industrial things, enabling a powerful, totally-connected OT infrastructure
for converging with IT and generating innovations of new applications and services.

Keywords
EtherNet/IP, Single Pair Ethernet, UDP-capable Unconnected Message, UDP-only EtherNet/IP Stack,Resource-constrained Industrial Things, Industrial Internet of Things

2015 ODVA Industry Conference

1©2015 ODVA, Inc.

Acronyms
CoAP: Constrained Application Protocol
IoT: Internet of Things
IIoT: Industrial Internet of Things
IT: Information Technology
OT: Operational Technology
PoDL: Power over Data Line

1. BackgroundThe development and deployment of low cost sensing, computation, communication, and networking
technologies are enabling smart things to be connected into IP network. It is predicted that 50 billion ofthings will be connected by 2020 year, and the things from the manufacturing sector will contribute asignificant portion. Country-level initiatives, such as America’s Advanced Manufacturing, Germany’s
Industrial 4.0, and China’s China Manufacturing 2025, would drive investments, create programs, andexecute modeling projects to retransform/evolve the manufacturing to the next level by using Information
Technologies into the industrial automation space. To minimize operation risks, reduce the time tomarket and utilize assets better, the convergence of OT and IT is taking place. Connecting a machine, aworking cell, or a factory to the enterprise network is becoming a demand to improve the data visibility
and operation efficiency of devices, machines, and systems.
As a well-accepted, widely-deployed, standard-based industrial Ethernet technology, ODVA’s CIP and
EtherNet/IP is naturally becoming a fundamental network infrastructure for this convergence of OT and
IT. Control and supervisory level devices in an industrial automation and control system, such as HMIs,
controllers, drives and I/O modules, have already been connected into the Industrial IoT system via
EtherNet/IP. ODVA may not be able to drive EtherNet/IP exclusively for IIoT usage because this protocol
is for real time automation applications, and is likely not fitted for other applications that will have theirown open and vendor specific protocols. However, ODVA should ensure that IIoT vendors that want toexpand their devices and solutions into the industrial automation area can easily get these devices
implemented with, and then connected to an EtherNet/IP system.
Besides, the industrial IoT is pushing the field level industrial things, such as sensors, actuators, andprocess instruments, to have network capabilities. However these field level industrial things usually
have constrained resources, such as limited computational capability, limited memory, limited
communication rate or limited power, and have very low cost and small form-factor requirements.
Today’s implementations of EtherNet/IP hardware and stack cannot meet the demands of adding
EtherNet/IP connectivity into these resource-constrained industrial things due to requirements for
relatively more resources, higher cost and bigger size.
This paper examines the potential EtherNet/IP hardware cost and form-factor reductions with the usageof IEEE standard single pair Ethernet technology as one example of IoT physical layer technologies likely
to be selected by IIoT vendors. Detailed analysis shows that by taking advantage of these emerging
physical layers, the cost and size of the EtherNet/IP hardware and stack could be significantly reduced.
This paper also proposes an extension of UDP-capable unconnected messages to the EtherNet/IP
protocol so that a much simpler UDP-only Ethernet/IP stack implementation that can better meetrequirements of resource-constrained industrial things is accomplishable.

2. Resource-constrained IoT and IIoT Things
The IoT movement creates new resource-constrained IIoT things in the industrial space. These industrial
things could be IoT devices [1] which are originally not in the industrial space, but expanded into the2015 ODVA Industry Conference

2©2015 ODVA, Inc.

industrial space with new applications. These industrial things could also be industrial devices which do
not have a communication interface or have a field-bus communication interface now, but will add or
migrate to an IP-based communication interface.
These new resource-constrained Industrial things often have constraints in size, cost and power, andhave limited resources of computation, memory, energy, and communication rate or bandwidth.
A resource-constrained industrial thing such as a proximity sensor usually has less than 10cm2 area forthe hardware circuit. The incremental cost of adding an IP-based communication interface to a resourceconstrained industrial thing is usually limited to $1-2. The power budget for a resource-constrained
industrial thing is usually less than 100mA @24V otherwise it may cause a heating issue. For a wirelessindustrial thing powered by battery, there are more strict power management requirements.
A typical microcontroller for a resource-constrained industrial thing may have 100Mhz ARM Cortex-M3 orless capable core, and may only have 128 Kbyte flash and 32-64 Kbyte RAM.
A highly-integrated, low cost and small size hardware platform and a common firmware architecture that
consumes less resources of computation, memory, and communication bandwidth have gradually
evolved to adapt the above constrains in cost, size, and resources for the IIoT things. The hardware
platform may have a MCU with the communication transceiver integrated such as IEEE802.15.4
microcontroller or Ethernet microcontroller. The hardware platform may also have the power andcommunication interfaces combined into one interface such as power over Ethernet and wireless powertransmission over the antenna. The firmware architecture has a common IP network layer but most IoT
things only use UDP for transport and most IoT things may need IPv6 for future expansion [2][3][4]. Different
physical layer technologies are used for different physical environments, and different application
protocols are used for different domain applications.

Figure 1 Potential Hardware and Firmware Architecture for IIoT things

3. Approaches to Connect Resource-constrained IIoT Things to an EtherNet/IP System
ODVA may not drive EtherNet/IP for IoT usage because this protocol is for the industrial automation, notfor other industries that have their own protocols. However, ODVA should ensure that IoT vendors thatwant to expand their IoT devices and solutions into the industrial automation area can easily get these IoT
devices implemented and then connected to an EtherNet/IP system. Most IoT companies are small
venture companies. It is important for ODVA to ensure these companies can easily support EtherNet/IP
with their hardware and with less investments so that they can become a part of an EtherNet/IP echosystem. So EtherNet/IP needs to be based on the evolving IoT hardware platform and needs to have a
protocol stack that is ready to be ported to the common IoT firmware platform without any change of IoT
hardware and without any change of IoT lower layers network and communication protocols.
2015 ODVA Industry Conference

3©2015 ODVA, Inc.

As mentioned, it is unlikely that EtherNet/IP can be driven to be an open IoT protocol. It is also unlikely
to use an open IoT protocol to replace EtherNet/IP for the industrial control. When IoT things want to bein an EtherNet/IP system or an EtherNet/IP device want to be in an open IoT system, there are two
approaches to make them connected.
3.1 Proxy Approach
Special gateways are required to connect the IIoT things into an open IoT system or connect the IoT
things into an industrial automation system.
Putting a gateway in between to translate between the industrial protocols and the open IoT protocols is
not a desired way but sometime is the most common way to get the industrial devices to participate in the
IoT system today.
However this approach may present challenges to IoT vendors who want to connect their IoT devices tothe industrial automation system. IoT vendors usually have no competence to develop the complex
gateway. IoT vendors also have no skills to configure and program the gateway for operation in theindustrial automation system even if the gateway is available from other companies. Technically the endend connectivity between devices is lost. These challenges may become real burdens for IoT vendors toparticipate in the ODVA community.
3.2 Direct Connect Approach
The IoT movement is gradually evolving a highly-integrated hardware platform and a common firmware
architecture as described in Section 2.
In this approach industrial protocols (e.g. EtherNet/IP) and open IoT protocols (e.g. CoAP) would both be
implemented over this highly-integrated hardware platform and this common firmware architecture in the
IIoT or IoT devices.
If the IoT devices’ firmware can be changed to add an EtherNet/IP protocol implementation without any
change of their hardware and without any change of their lower layers network and communication
protocols and if the IP infrastructure devices (switch, router, not special gateway) can be used to connect
these IoT devices to the EtherNet/IP system directly, it will make EtherNet/IP very attractive for IoT device
vendors because only changing firmware to add an EtherNet/IP protocol implementation may not be a big
concern for IoT device vendors. (You don’t change the IoT device’s hardware, you don’t need a special
complex gateway, you have end-end connectivity, and it is easy to deploy the system).
While outside the scope of this paper, it is also worth noting that an advantage EtherNet/IP device
vendors have today is that their device hardware and stacks are likely ready to have open IoT protocol
support (e.g. CoAP) added as a firmware upgrade

4. Barriers in Extending EtherNet/IP to Resource-constrained IIoT Things
The barriers in extending EtherNet/IP to resource-constrained industrial things are analyzed and thepotential technical solutions to the barriers are discussed in this section. The analysis and discussion are
made from the aspects of the communication interface hardware and the communication protocol
firmware for the IoT or IIoT things.

2015 ODVA Industry Conference

4©2015 ODVA, Inc.

4.1 Communication Interface hardware
There are a number of physical layer communication technologies (e.g. LoWPAN, WiFi, Ethernet, TSN
and Bluetooth) that have been and are being adopted by resource-constrained IoT things. This paper
analyzes the barriers of standard Ethernet used in EtherNet/IP and proposes single pair Ethernet as one
example of IoT physical layer technologies for EtherNet/IP’s extended usage for resource-constrained
industrial things. This does not exclude the possibilities of using other physical layer technologies as
EtherNet/IP physical layers for the resource-constrained industrial things.
4.1.1

Cable and Connector

Barrier: EtherNet/IP uses the RJ45 connector for the in-cabinet application and the M12-D connector forthe on-machine application. The size of the RJ45 connector or M12-D connector is usually too large forthe field level industrial sensors and actuators. The RJ45 connector or M12-D connector are also too
expensive for the field level industrial sensors and actuators.
Potential Solution: A smaller, cheaper, and simpler 2-pin single pair Ethernet connector could
potentially meet requirements of the field level industrial sensors and actuators. In addition, a lower cost
single pair Ethernet cable (100BASE-T1’s advanced signal processing function degrades the requirementof the communication channel, so potentially reduce the cost of the cable) and 24V power over the same
single pair Ethernet cable would further reduce the cost and size of the EtherNet/IP system.
4.1.2

PHY and Its Accessories

Barrier: The hardware circuit of 100Mb/s Fast Ethernet usually contains a PHY chip, a Ethernet
transformer, a connector, EMC protection components and other passive resistor and capacitor
components. The cost and size of 100Mb/s Fast Ethernet hardware circuit are not acceptable for the fieldlevel industrial sensors and actuators. In addition, the height of the Ethernet transformer sometimes
cannot meet the field level sensors or actuators’ requirements.
Potential Solution: A single pair Ethernet hardware circuit only needs a half of components of 100Mb/s
Fast Ethernet hardware circuit, this will obviously reduce the cost and size to a half in principle. In
addition, the usage of capacitive coupling can further reduce the cost and size by removing the expensive
and large Fast Ethernet transformer for applications that have no high voltage isolation requirement. The
reduced MII between MAC and PHY is recommended to be used to reduce the size of the Ethernet
hardware.

4.2 Communication Protocol Firmware
4.2.1

Network

Barrier: EtherNet/IP does not support IPv6 while IPv6 support is a common requirement for IoT things
due to its large address space, high efficiency, simplicity, security and mobility.
Potential Solution: IP stack used in EtherNet/IP device should support IPv6, and should be able to be
configured to IPv4 only, IPv4&IPv6, or IPv6 only working mode. EtherNet/IP stack should migrate tosupport IPv6. In addition, to minimize the usage of the memory resources, the IP stack should be able tobe configured to run without Operating System for the resource-constrained industrial things.
4.2.2

Transport

Barrier: EtherNet/IP requires TCP for explicit messages while not supporting TCP is a common
requirement for IoT things. TCP is connection-oriented, is more reliable but consumes much moreresources than UDP. TCP is used to transfer large amount of data but with slow transaction rate while
2015 ODVA Industry Conference

5©2015 ODVA, Inc.

UDP is used to transfer small packets with fast transaction rate. UDP is more suitable for resourceconstrained industrial things.
Table 1 Comparison between TCP and UDP
Connection-oriented
Reliable (ACK, stream control, sequencecontrol)
Transaction rate
Resource (Computational capability, energy,
storage, comm. bandwidth)
Amount of data
Multicast support
Code size of protocol stack

TCP
YES
YES

UDP
NO
NO

Slow
More

Fast
Less

Large
NO
Large

Small
YES
Small

Potential Solution: The TCP/UDP/IP stack used in an EtherNet/IP device should be able to be
configured to the UDP-only operation mode. The EtherNet/IP stack should add the UDP transport for
explicit messages. The EtherNet/IP stack should be able to be configured to the UDP-only operation
mode too.
4.2.3

CIP Transport Protocol

Barrier: CIP explicit messages rely on TCP and EtherNet/IP Session while TCP is not suitable forresource-constrained industrial things. Connected explicit messages may consume too much resources
for the resource-constrained industrial things.
Potential Solution: Extend EtherNet/IP to be able to transport explicit messages over UDP. Only use
CIP unconnected explicit messages for the resource-constrained industrial things that have few
parameters to be configured or monitored. The EtherNet/IP stack implementation should support thefunction of compiling Class 3 connection, EtherNet/IP session off for a UDP-only configuration.

5. Details on Potential Solutions to Barriers
5.1 Single Pair Ethernet Hardware
A variety of IEEE standard-based communication technologies, such as IEEE802.15.4 wireless personalarea network technology, IEEE802.11 WiFi technology, and IEEE802.3 Ethernet technology, are being
adopted in the Industrial IoT for different applications and environments. Although IEEE802.3 Ethernet
was historically defined as EtherNet/IP’s physical layer, other communication technologies likeIEEE802.15.4, may need to be embraced in future for industrial IoT applications. Even for IEEE802.3
Ethernet, there are many types of Ethernet technologies for multiple types of media, multiple speeds andmultiple distances. The scope of this paper is limited to discuss the new emerging single pair Ethernet
technology in IEEE as an example of an emerging technology likely to be selected by IIoT devices. The
key feature of single pair Ethernet is that it runs a full-duplex Ethernet communication over unshielded,balanced single pair twisted cable. This single pair Ethernet technology is promising to overcome thecost and size barriers in today’s 100Mb/s Fast Ethernet hardware to extend EtherNet/IP to the emerging
resource-constrained industrial things.
5.1.1

Introduction

The single pair Ethernet technology and standard development is driven by the automotive industry. It
was predicted that the number of Ethernet nodes for the automotive industry would be 270M per year by
2020. It is also clear that the single pair Ethernet technology is gaining larger community supports fromthe whole automotive value chains (OPEN Alliance [5] has more than 150 members). The potential huge2015 ODVA Industry Conference

6©2015 ODVA, Inc.

market space and the strong and wide community support would ensure/secure resources andinvestments on single pair Ethernet technologies of chips, cables, connectors, and tools.
Automotive applications have requirements of strict operational environment, high reliability (low bit errorrate), and high performance (fast start-up time, low latency and jitter). Automotive applications will
potentially drive high volume, low cost, and high performance Ethernet. The extended usage of single
pair Ethernet into the industrial automation area is considered to be most likely feasible and desirable,similar to CAN that was first adopted in the automotive industry, then widely used in the industrial
automation area.
Two types of single pair Ethernet 100BASE-T1 (802.3bw) and 1000BASE-T1 (802.3bp) are underdevelopment in IEEE from the year of 2013. 100BASE-T1 is more suitable for the IIoT things considering
the cost and size. IEEE 100BASE-T1 standard is based on OPEN Alliance’s one pair Ethernet
specification which was first released in 2012 and now initially deployed in cars. IEEE 100BASE-T1 istargeted to be published in 2016. A 100Mb/s single pair Ethernet chip is now available from chip
vendors.
5.1.2

Operation Principle

IEEE 100BASE-T1 PHY uses the standard MII/RMII interface but redefines the PHY and the physicalmedia interface. The PHY utilizes 1000BASE-T Gigabit Ethernet technology to achieve full-duplex
communication on a degraded communication channel of a single pair twisted cable. The simple Pulse
Amplitude Modulation 3 (PAM-3) coding is used to achieve better EMI performance with a lower operation
frequency bandwidth. The PHY works in a pre-managed MASTER or SLAVE mode for a communication
link where one PHY is configured as MASTER and the other is configured as SLAVE. MASTER initiates
the link-startup process. Fast link startup is supported and auto-negotiation is optionally supported. A
two-pin connector or two pins of a multiple-pin connector are specified as Medium Dependent Interface(MDI). Rather than specifying the cable and connector, 100BASE-T1 defines the electric specification forthe communication channel. Any type of cables and connectors could be used for the communication
channel as long as they meet the electrical specification of the communication channel.
IEEE 100BASE-T1 standard only specifies 15 meters communication distance with the focus on
automotive applications. The 15 meters distance is relatively short, but may be applicable for last hop
industrial sensors and actuators in an automation machine or system. A longer distance in an automation
application could be achieved by using a better communication channel (e.g. less inline connectors andshielded cable), or by increasing the TX power of the PHY chip, or by degrading the data rate (e.g.
10Mb/s).
A separate 1-pair Power over Data Line (PoDL) standard (802.3bu) is under development in IEEE. PoDL
will enable the power delivery and Ethernet communication over a single pair twisted cable. With PoDL,
only a two-pin connector is required for IIoT things’ power and communication interfaces. This potentiallysave the cost and size of IIoT devices’ hardware. Another key difference between PoDL and other Powerover Ethernet technologies is that PoDL defines 24VDC as one voltage type.
5.1.3

Hardware Experimental Result

A hardware prototype was built for the proof of concept evaluation. Figure 2 shows the block diagram of
single pair Ethernet PHY hardware circuit.

Figure 2 Single Pair Ethernet Hardware Block Diagram
2015 ODVA Industry Conference

7©2015 ODVA, Inc.

From the size’s perspective, the single pair Ethernet circuit may reduce the size by 50% compared to the
100BASE-TX Ethernet implementation in an industrial automation product. The major size reduction liesin the signal coupler, the connector, and the EMC protection components. The signal transformer would
be replaced by a capacitor and a common mode choke. A smaller two-pin connector can save the size alot too. Only 1/3 EMC protection components and a half of resistor and capacitor components are
required.
From the cost’s perspective, the experimental implementation shows that it is possible to reduce the costby 40% compared to the 100BASE-TX Ethernet implementation. The cost reduction points are: acommon mode choke is much cheaper than an Ethernet transformer, a number of component reductions
reduces the cost, and a two-pin connector is cheaper than a RJ45 or M12-D connector.
5.2 UDP-only EtherNet/IP Stack
5.2.1

Concept Description

The idea of adding the UDP transport for EtherNet/IP unconnected messages is proposed so that a UDPonly EtherNet/IP stack could be implemented for the industrial IoT things. A UDP-only EtherNet/IP stack
is more suitable for the IIoT things because it consumes less memory and has simplified transaction flow
for the IIoT things.
Proposed Changes on EtherNet/IP Specification
Two changes are proposed to support UDP-capable CIP unconnected explicit messages. One change isto add a UDP transport way to transfer the CIP unconnected explicit messages. The other change is to
add the “capability report information” in the ListService response data item to indicate the transport typeof UDP or TCP or both for the CIP unconnected explicit messages. Based on this “capability report
information”, the client can know whether it chooses UDP or TCP for the CIP unconnected explicit
messages to communicate with the server.
In particular, the SendRRCommand command will be able to be received or transmitted by using UDP
socket with EtherNet/IP explicit port number(0xAF12) which has already been used by receiving ortransmitting other EtherNet/IP encapsulation commands (e.g. ListIdentity).
Table 2 Comparison between TCP-based and UDP-based CIP Unconnected Explicit Message
Transport
EtherNet/IP
Encapsulation

CIP Unconnected
Message

TCP-based CIP unconnected explicit
message
TCP, EtherNet/IP Explicit Port (0xAF12)
SendRRData command (0x6F) over an
EtherNet/IP Session
NULL Address Item (0x00)
Unconnected Data Item (0xB2)
Message Router Request/Response data

UDP-based CIP unconnected explicit
message
UDP, EtherNet/IP Explicit Port (0xAF12)
SendRRData command (0x6F) without an
EtherNet/IP Session
NULL Address Item (0x00)
Unconnected Data Item (0xB2)
Message Router Request/Response data

The ListService response has a field named Capability Flags as defined in Table 3. Bit 8 has alreadybeen used to indicate the support of CIP transport class 0 or 1 UDP-based connections. Bit9 could be
expanded to be used to indicate the support of UDP-based CIP unconnected explicit messages. Bit10
could be expanded to be used to indicate the support of TCP-based CIP unconnected explicit messages.
This ListService response could be returned as a data item together with ListIdentity response data item
to a ListIdentity request to save one ListService transaction.
Table 3 EtherNet/IP Encapsulation Capability Flag Definition
Flag Value
Bits 0 - 4

Description
Reserved for legacy usage 12015 ODVA Industry Conference

8©2015 ODVA, Inc.

Flag Value
Bit 5

Description
If the device supports EtherNet/IP encapsulation of CIP this bit shall be set (=1);
otherwise, it shall be clear (=0)
Bits 6 - 7
Reserved for legacy usage 1
Bit 8
Supports CIP transport class 0 or 1 UDP-based connections
Bit 9
If the device supports UDP-based CIP unconnected explicit message this bit
shall be set (=1); otherwise, it shall be clear (=0)
Bit 10If the device supports TCP-based CIP unconnected explicit message this bit
shall be clear (=0); otherwise, it shall be set (=1)
Bit 11 - 15
Reserved for future expansion
Table Footnotes
1. Flags marked as “Reserved for legacy usage” indicate flags that were defined prior to the
publication of this specification. Their usage is undefined in this specification. Devices should
not use these flags without prior knowledge of the legacy usage. If a device receives areserved flag that it does not understand, the reply shall be processed and the flag ignored.

There is no other change on the EtherNet/IP encapsulation protocol message format, there is also nochange on the Class 0/1/3 connection. The function of sending and receiving CIP unconnected explicit
messages via TCP connection and EtherNet/IP session is kept, but not intend to be used for the
resource-constrained IIoT things.
One shortage of using UDP is lack of reliability that TCP has, but this is not an issue for CIP unconnected
explicit message client/server applications. The failure of delivering a request or response will be
detected by the CIP client via a timeout and will be notified to the application. The client will decide thefurther action based on applications (for example, may retry the packet or may stop the communication).
Simplified Transaction Flow
With UDP-cable CIP unconnected explicit messages, the transaction for reading or writing explicit
parameters between the client and server is simplified as shown in Figure 3.

Figure 3 Comparison between TCP-based and UDP-based CIP Unconnected Explicit Message
Sequence
Compared to the transaction using TCP-based CIP unconnected explicit messages, the transaction using
UDP-based CIP unconnected explicit messages does not need the processing of opening or closing TCP
2015 ODVA Industry Conference

9©2015 ODVA, Inc.

connection and registering or unregistering EtherNet/IP sessions. The client directly communicates withthe server without pre-established communication channel bindings.
As shown in Figure 4, for opening or closing I/O connections, the originator directly sends a UDP-based
ForwardOpen or ForwardClose request to the target without establishing TCP connection andEtherNet/IP session.

Figure 4 Comparison between TCP-based and UDP-based CIP Unconnected Message Sequence forCreating I/O Connections
For those IIoT things that do not need real-time communication, UDP-based CIP unconnected explicit
communication pattern is the only communication pattern that needs to be implemented.
The simplified message sequence makes differences for the IIoT things. It makes the CIP unconnected
explicit communication stateless, which is much easier and simpler to be implemented by the IIoT things.
Scalable EtherNet/IP Stack
By adding UDP-capable CIP unconnected explicit messages, a scalable firmware stack including both
EtherNet/IP and TCP/IP stack could be developed for more wide applications as shown in the left
diagram of Figure 5. The firmware stack with the TCP function could be used for the relatively complex
EtherNet/IP devices. The firmware stack could be configured to the UDP-only stack for the resourceconstrained IIoT things as shown in the right diagram of Figure 5. If the firmware stack is configured as
the UDP-only stack, the code and data memory size will be reduced significantly by compiling off the TCP
in the TCP/IP stack, the session and TCP encapsulation server in the EtherNet/IP stack, and the class 3
connection function in the EtherNet/IP stack. In addition the UDP-only EtherNet/IP stack still have thecapability of opening I/O connections for the real-time I/O data communication.

2015 ODVA Industry Conference

10©2015 ODVA, Inc.

Figure 5 Firmware Structure of a Scalable EtherNet/IP Stack
5.2.2

Impacts on EtherNet/IP Products

A new implemented client MUST support both UDP and TCP methods to send or receive CIP
unconnected explicit messages. A legacy client needs to be upgraded to have the UDP-cable CIP
unconnected explicit message function to communicate with the new resource-constrained IIoT things.
A new implemented server MUST support at least one of UDP and TCP methods to send or receive CIP
unconnected explicit messages. A new implemented resource-constrained industrial thing may only
support the UDP method. A new complex system level device may support the TCP method, and may
optionally support the UDP method. A legacy server will operate in a hybrid system with no modifications.
The client retrieves the server’s capability by using the ListService or ListIdentity command, and thenchooses the UDP or TCP method to communicate with the server. If the server supports both UDP and
TCP methods, the client will pick either way based on the user’s implementation (TCP preferred). If theclient cannot get the server’s capability with all above methods, then it may first try the TCP method andthen try the UDP method.
5.2.3

Impacts on Advanced CIP Applications

Advanced CIP applications, such as CIP SafetyTM, CIP SyncTM and CIP MotionTM, are usually notresource-constrained, so these applications should work with the TCP-based firmware stack.
Even with UDP-only firmware stack, these advanced applications are still achievable. All safety I/Opackets, time-sync packets, and motion I/O packets are UDP packets. Creating safety connections andmotion connections could be done via UDP-based unconnected messages just as creating standard I/Oconnections.
5.2.4

Firmware Experimental Result

Experiments are done on two EtherNet/IP stacks from two companies, one of which is Adapter only for anembedded device, the other one is SCANNER for a PC-based software application. Only 2-days havebeen spent on adding UDP transport for unconnected messages into the Adapter-only EtherNet/IP stack,and also making the Stack scalable to be configured as a UDP-only EtherNet/IP stack. Only 3-days
have been spent on adding UDP transport for unconnected messages in the SCANNER EtherNet/IP
stack. The changes on the code itself are very minor and easy for an EtherNet/IP stack developer. Thechanged EtherNet/IP SCANNER is able to communicate with the changed EtherNet/IP Adapter with
UDP-only explicit messages. The changed EtherNet/IP SCANNER can also open/close class0/1 I/O
connections through UDP-based ForwardOpen or ForwardClose messages. All UDP-based messages
including ForwardOpen and ForwardClose are able to be well interpreted by the traffic analyzer tool
WireShark.

2015 ODVA Industry Conference

11©2015 ODVA, Inc.

Further analysis was made on the memory consumption of the whole experimental firmware including
hardware drives, OS, TCP/UDP/IP stack, EtherNet/IP adapter stack, and an example application. The
firmware is compiled in the release version with a medium optimization level. The EtherNet/IP sample
application supports 3 explicit message clients with maximum 446 bytes explicit message size and 4 I/O
connections with maximum 18 bytes I/O data size. The results are compared under the combination of
firmware configuration of “with OS and with TCP” and “without OS and without TCP”. The analysis showsthat 30.54% code (38.8Kbytes) and 51.99% RAM (39.3Kbyte) could be saved from the configuration of“with OS and with TCP” to the configuration of without OS and without TCP. The total UDP-only, Non-OS
firmware consumes around 88Kbytes Flash and 36Kbytes RAM providing 40Kbytes Flash and 28Kbytes
RAM for the application firmware for a MCU with 128Kbytes flash and 64Kbytes RAM.
Table 4 Memory Consumption Analysis for EtherNet/IP Firmware
Flash (Kbytes)

EtherNet/IP
TCP/UDP/IP
OthersTotal

W/ OS,
W/ TCP
25,95843,64518,65988,262

W/o OS,
W/o TCP
32,867
71,68322,513127,063

RAM (Kbytes)

Reduction
21.02%
39.11%
17.12%
30.54%

W/ OS,
W/ TCP
12,847
5,804
17,67736,327

W/o OS,
W/o TCP
42,85812,663
20,14875,669Reduction
70.02%
54.17%
12.26%
51.99%

6. Conclusion
Industrial IoT will create new eco-systems of devices and suppliers to the industrial space. This paper
identifies the likely attributes and constrains of these new devices, the enhancements to the EtherNet/IP
adaptation of CIP required to allow these devices to integrate with a control system and these suppliers toparticipate in the ODVA community. The introduction of single pair Ethernet to EtherNet/IP is proposed topotentially and partially resolve the cost and size barrier in the Ethernet hardware for IIoT things, and theimplementation of UDP-only EtherNet/IP stack is proposed to potentially and partially resolve theresource constrains in the communication protocol firmware. With these enhancements, EtherNet/IP
would be able to be expanded into the field level resource-constrained industrial things, enabling a
powerful, totally-connected OT infrastructure for converging with IT and generating innovations of new
applications and services.

References
1. IPSO Alliance: http://www.ipso-alliance.org/
2. IETF IPv6 over Networks of Resource-constrained Nodes (6lo):
https://datatracker.ietf.org/wg/6lo/charter/
3. IETF Constrained RESTful Environments (core): https://datatracker.ietf.org/wg/core/charter/
4. IETF IPv6 over Low power WPAN (6lowpan) : https://datatracker.ietf.org/wg/6lowpan/documents/
5. OPEN Alliance link: http://www.opensig.org/******************************************************************************************************************************************************The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible useof ODVA technologies and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because ODVA technologies
may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader andthose responsible for specifying ODVA networks must determine for themselves the suitability and the suitability of ideas, opinions,and recommendations expressed herein for intended use. Copyright ©2015 ODVA, Inc. All rights reserved. For permission to
reproduce excerpts of this material, with appropriate attribution to the author(s), please contact ODVA on: TEL +1 734-975-8840
FAX +1 734-922-0027 EMAIL odva@odva.org WEB www.odva.org. CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP
Safety, CIP Sync, CompoNet, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc. All other trademarks areproperty of their respective owners.

2015 ODVA Industry Conference

12©2015 ODVA, Inc.