Recommended Functionality for EtherNet/IP Devices

Version 10 PR001
November 28, 2018
PUB00070R10

Published by

Roundtable for EtherNet/IP Implementors

 Recommended Functionality for EtherNet/IP Devices

1 Introduction
1.1 Scope of Document
The purpose of this document is to recommend functionality related to the EtherNet/IP protocol
implementation in EtherNet/IP devices. The recommendations are a result of work generated by
the ongoing series of EtherNet/IP Implementors Workshops. The recommendations are being
made to help ensure interoperability between devices and provide a minimum level of capability
required for user applications.

1.2 Interpreting the Recommendations

The recommendations cannot be interpreted as “requirements” from the perspective of the
EtherNet/IP specification. However from the perspective of the Implementors Workshop, it is
useful to be able to state whether or not a device adheres to the Functionality Recommendations
(and future workshop recommendations) for the type of device. Therefore, this document uses
language similar to the EtherNet/IP specification to make clear what is required (specified with
the use of "shall") and what is optional (specified with the use of "recommended") in order for a
device to adhere to the recommendations.

It should be understood that a device may be compliant to the EtherNet/IP specification yet not
meet the minimum recommendations described in this document for the type of device. Such a
device is a valid EtherNet/IP device; however, the vendor will not be able to state that the device
meets the workshop recommendations.

1.3 Future Revisions of the Recommendations

Further revisions of the document are anticipated as work progresses in the Roundtable for
EtherNet/IP Implementors and ODVA SIGs.

November 28, 2018 1 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

1.4 Organization of the Document

This document is primarily organized by EtherNet/IP device classification, and includes the
following sections:

Common Device This section includes EtherNet/IP functionality

recommendations that are common across multiple types
of devices. The sections for the specific types of devices
will add recommendations to those described in this
section.

Explicit Message Server Device This section explains the functionality that is
recommended for explicit message server devices over
and above the Common Device section.

Explicit Message Client Device This section explains the functionality that is
recommended for explicit message client devices.

Adapter Device This section explains the functionality that is

recommended for Adapter class devices over and above
that in the Common Device section.

Scanner Device This section explains the functionality that is

recommended for Scanner class devices over and above
that in the Common Device and Adapter Device sections.

November 28, 2018 2 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

2 Common Device Recommendations

This section includes EtherNet/IP functionality recommendations that are common across
multiple types of devices. The succeeding sections for the specific types of devices may add
recommendations to those described in this section.

2.1 CIP
1. The device shall, at a minimum, provide support for:
a) 3 concurrent Encapsulation sessions.
b) 6 concurrent Transport Class 3 Explicit Messaging connections.
c) More than 1 Transport Class 3 connection per Encapsulation session.

Rationale: A server should be able to handle requests from 3 client nodes, 2 continuous and 1
transitory (e.g. controller, HMI, and commissioning tool). Some clients may require more
than 1 CIP Class 3 connection on a given Encapsulation session.

2. The device shall support both unconnected and connected messaging concurrently in an
Encapsulation session.

3. Use of Device Type Code 0x00 has been deprecated. New generic devices shall report the
keyable Generic Device Type Code (0x2B).

4. Transport Class 3 connections shall support priorities Low and High. This applies to Class 3
servers only.

2.2 TCP/IP Suite

1. The device shall support the TCP/IP features required by the latest EtherNet/IP specification
in Volume 2, Requirements for TCP/IP Support (e.g. section 9-3 in Ed. 1.20).

2. The device shall follow the recommendations put forth in the ODVA document
Recommended IP Addressing Methods for EtherNet/IP Devices, Version 1.0, June 10, 2003
(PUB00028). In summary, this document specifies the following features in regards to IP
addressing:
a) The device shall by default issue BOOTP or DHCP requests at initial power up “out-
of-box” (from the vendor).
b) The device shall facilitate enabling and disabling BOOTP or DHCP via the TCP/IP
Object (Class 0xF5).
c) The device shall allow its IP address (and other IP parameters) to be set using the
TCP/IP Object. This requirement does not prohibit the device from supporting other
means of setting these parameters.
d) The device shall allow the user to make a valid IP address persistently stored in non-
volatile memory, via attributes and services of the TCP/IP Object.

3. The device shall reserve, at a minimum, 3 concurrent TCP connections for CIP. If other
protocols (HTTP, FTP, etc.) are supported, the number of concurrent TCP connections
supported should account for these protocols in addition to the connections reserved for CIP.

November 28, 2018 3 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

4. The device shall provide support for UDP requests. The List Identity command is typically
transmitted as a UDP broadcast by network tools.

5. The device shall cease sending BootP/DHCP requests once an IP address has been obtained
from the BootP/DHCP server and has been successfully applied. It is understood that a
DHCP-configured device will attempt to renew its IP address at some point, but this
requirement is for the initial requests.

6. The device shall not issue BootP/DHCP requests when configured to use a static IP address
as indicated by the Startup Configuration bits being set to zero in the Configuration Control
Attribute of the TCP/IP Object.

2.3 Ethernet and Physical

The following recommendations apply to each of the device’s externally exposed EtherNet/IP
interfaces.

1. The device shall support Full Duplex.

2. The device shall support 10/100Mbps.

3. The device shall provide auto negotiation of duplex and data rate with a configurable manual
override. Auto Negotiation plus Manual Override provides support for the widest possible
range of network infrastructure devices, e.g. switches. The device shall store the link settings
(e.g. Auto-Negotiate, Fixed Speed & Duplex) in non-volatile memory such that they are
persistent through a cycle of power to the device.

4. The device shall follow the recommendations put forth in the ODVA document
Recommended IP Addressing Methods for EtherNet/IP Devices, Version 1.0, June 10, 2003
(PUB00028). In summary, this document specifies the following features in regards to
Ethernet and Physical Layer:
a) For 100Base-T devices, the device shall allow the user to select auto-negotiation or
manual setting of duplex mode and port speed, per the Ethernet Link Object
b) The Ethernet MAC address shall be visible on the device (e.g., on a label). Note that
the address may be hidden after the device is installed.

5. It is recommended that the device physical layer conform to the EtherNet/IP Industrial
Conformance Level. Note that this recommendation does not apply to PC-based or transitory
devices. This includes:
a) The latest EtherNet/IP industrial physical layer as specified in Volume 2,
Performance Levels (e.g. section 8.7 in Ed. 1.20,).
b) EtherNet/IP specific LED, or equivalent, indicators (Module Status, Network Status)
as specified in Volume 2, Indicators (e.g. section 9.4 in Ed. 1.20).

6. It is recommended that the device have LED, or equivalent, indication for Ethernet Link
Status, Transmit and Receive. It is recommended that LED behavior on all future
development follow the behavior described below.
a) Devices with a single indicator:

November 28, 2018 4 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

Indicator Single Color LED Bi-Color LED

State Description State Description
Link Off No link Off No link
Status On Link Solid Green Link
Flashing Port activity Solid Amber Port disabled
Flashing Green Port activity
Flashing Amber Collision
Solid Red Major NIC Fault
e.g. POST error

b) Devices with a two Indicators:

Indicator Single Color LED Bi-Color LED
State Description State Description
Link Off No link Off No link
Status On Link Solid Green Link
Solid Amber Port disabled
Solid Red Major NIC Fault
e.g. POST error

Activity Off No activity Off No activity

Flashing Port activity Flashing Green Port activity
Flashing Amber Collision

c) Devices with a three Indicators:

Indicator Single Color LED Bi-Color LED
State Description State Description
Link Off No link Off No link
Status On Link Solid Green Link
Solid Amber Port disabled
Solid Red Major NIC Fault
e.g. POST error

Transmit Off No activity Off No activity

Flashing Port activity Flashing Green Port activity
Flashing Amber Collision

Receive Off No activity Off No activity

Flashing Port activity Flashing Green Port activity

2.4 EDS File

The EDS file for the device shall include the [Capacity] section. This is used to declare the I/O
Connection capacity supported by the device. Definitions per Volume 1, Capacity Section (e.g.
section 7-3.6.13 in Ed. 3.19).

November 28, 2018 5 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

2.5 Performance

2.5.1 Response Times

The performance values in this section are based on benchmark procedures originally created by
the Performance Working Group. The values listed below are recommendations based on an
absence of significant background traffic.

List Identity Response/UDP < 250ms

List Services Response/TCP < 250ms

(assuming existing TCP connection)

Unconnected explicit response - No TCP connection established < 500ms

(Specific internal object/attribute would be tested)

Unconnected explicit response - TCP connection established < 100ms

(Specific internal object/attribute would be tested)

Connected explicit response < 100ms

(Specific internal object/attribute would be tested)

Two back-to-back explicit message requests without dropping either ≥ 1ms

2.6 Duplicate IP Address Detection

The device shall support duplicate IP address detection as specified in the latest version of
Volume 2, Appendix F.

2.7 Testing of Product Families

The same products that will be or were used for basic conformance testing of an ODVA
Conformance-defined product family shall be submitted for PlugFest testing of the product
family.

November 28, 2018 6 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

3 Explicit Messaging Server Device Recommendations

This section explains the functionality that is recommended for explicit message server devices
over and above the Common Device section.

3.1 Example Devices

 Text Display device
 Data Acquisition Input devices
 Data Logger

3.2 CIP
No addition to Common Device Recommendations.

3.3 TCP/IP Suite

No addition to Common Device Recommendations.

3.4 Ethernet and Physical

No addition to Common Device Recommendations.

3.5 EDS File

No addition to Common Device Recommendations.

3.6 Performance
No addition to Common Device Recommendations.

November 28, 2018 7 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

4 Explicit Messaging Client Device Recommendations

This section explains the functionality that is recommended for explicit message client devices.

4.1 Example Devices

 Simple HMI
 Data Logger
 Diagnostic Tool

4.2 CIP
1. The device shall meet the minimum requirements defined in the CIP and EtherNet/IP
specifications for a messaging client, which includes certain explicit server functionality such
as Identity object support.

2. The device shall support the initiation of both connected and unconnected explicit messaging.

4.3 TCP/IP Suite

The device shall meet the minimum requirements defined in the CIP and EtherNet/IP
specifications for a messaging client.

4.4 Ethernet and Physical

No addition to Common Device Recommendations.

4.5 EDS File

The device shall meet the minimum requirements defined in the CIP and EtherNet/IP
specifications for a messaging client.

4.6 Performance
No addition to Common Device Recommendations.

November 28, 2018 8 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

5 Adapter Device Recommendations

This section explains the functionality that is recommended for Adapter class devices over and
above that in the Common Device section.

There are several references in this section to "rack-based" devices. For the purpose of this
document, a rack-based device is one that conforms to the Modular description in Volume 1 of
the CIP specification (e.g., section 7-3.7 Modular EDS File Requirements in Ed. 3.19).

5.1 Example Devices

 Block I/O
 Weigh Scale
 AC Variable Frequency Drive

5.2 CIP
1. The device shall support all CIP recommendations described in the Common Device
Recommendations section 2.1.

2. The device shall accept, at a minimum, 2 simultaneous Transport Class 1 I/O connections, in
the combinations outlined in 3.d) below. (Rationale: 1 Exclusive Owner or Input Only
connection for a controller and 1 Input Only or Listen Only connection for a monitoring
device, each connected to the same TO connection point.)
a) The device shall support the Class 1 and Class 3 connection requirements
simultaneously, i.e. the device must support 8 simultaneous connections (2 Class 1 +
6 Class 3)

3. The following recommendations pertain to Transport Class 1 connections supported by the

device.
a) The device shall support bi-directional connections, i.e. accept a Forward_Open with
non-null OT and TO connection types. The device may also support uni-
directional connections (with a null connection type in either OT or TO).
b) The device shall support Cyclic trigger type.
c) The device shall support the Change of State (COS) trigger type. Support for the
COS trigger type is optional for non-discrete devices and for rack connections on
rack-based devices.
d) The device shall support all of the following connection combinations:
i. a multicast TO and unicast OT Exclusive Owner connection with at
least one multicast TO Input Only or Listen Only connection for the same
TO connection point, simultaneously
ii. a multicast TO and unicast OT Exclusive Owner connection with at
least one unicast TO Input Only or Listen Only connection for the same
TO connection point, simultaneously
iii. a unicast TO and unicast OT Exclusive Owner connection with at least
one multicast TO Input Only or Listen Only connection for the same TO
connection point, simultaneously.
iv. a unicast TO and unicast OT Exclusive Owner connection with at least
one unicast TO Input Only or Listen Only connection for the same TO
connection point, simultaneously.
Input-only devices may substitute an Input Only connection for the Exclusive Owner
connection.

November 28, 2018 9 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

e) The device shall support an Exclusive Owner connection if the device has output
data.
f) The device shall support a Listen Only or Input Only connection supporting more
than 1 listener if the device has input data. Note that this is necessary regardless of
whether the device has output data or not.
g) The device shall provide a "heartbeat" connection path to be used for connection
pairs where application data is only flowing in one direction. Note: Connections to
the heartbeat connect path are configured with 0 data length and do not include a 32-
bit Real-Time Header (Run/Idle Header).
h) The device shall support Electronic Keys in the Forward_Open connection path. The
device shall also support a Null key segment and no key segment.
i) The device shall support the 32-bit Real-Time Header (Run/Idle Header) in the OT
connection data. Note that the device may also support other connection data formats
as well.
j) The device shall support priorities High and Scheduled.

4. The device shall accept a Configuration path as part of the Forward_Open request. This is
not a requirement for rack-based devices.

Devices that support the data segment for configuration data shall accept Forward_Opens
with all 3 types of data segments: None, Null, or Non-Null. Devices that choose not to
support the data segment for configuration data shall still specify and accept a Configuration
path. This unused configuration path may be the same as the “heartbeat” path associated with
the I/O connection(s).

Devices not requiring configuration data shall only accept Forward_Opens with Null or No
data segments; Forward_Open requests containing Non-Null data segments shall be rejected.

Examples of data segment types:

Non-Null 0x80 0x01 0x12 0x34
Null 0x80 0x00
None -

A device shall retain its configuration even if all connections are terminated. Devices may
lose their configuration on a reset.

Rationale: It is stated in Vol 1, 3-6.2 that “If no data segment is specified the existing
configuration continues to be used.” The device may require configuration data with the
Forward_Open after initial power up. However, until the device is reset, the device must
accept Forward_Opens with no configuration data, in which case it would continue to use the
existing configuration.

5. The device shall support the Assembly object. Assembly object instances shall be used to
specify connection paths for Transport Class 1 connections. Path segments in the
Forward_Open shall use the compressed format in the following order: Configuration
instance, Consumed Data connection point, Produced Data connection point, and data
segment if present. This is not a requirement for rack-based devices.

6. The device shall provide access to configuration parameters/attributes via Explicit Messaging
(e.g. web-only access is not acceptable). Note that it is not necessary to utilize the Parameter
Object. This does not apply to rack-based, technology enabler devices, or devices with user-

November 28, 2018 10 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

defined I/O data content (e.g. EtherNet/IP to other network gateway, target connections of a
PLC).

7. The device shall provide access to its I/O Data attribute(s) via unconnected and/or connected
(Class3) explicit messaging, e.g. Assembly object, instance attribute 3. Write requests to
Output data shall be rejected when the assembly is linked to an active I/O connection and
succeed when the connection is not active. Explicit messaging-based access to I/O Data
attribute(s) is not a requirement for rack-based devices. The I/O Data attributes shall not
include the 32-bit Real-Time Header (Run/Idle Header).

8. The device shall not report the deprecated extended status codes of the Connection Manager
object as specified in Volume 1, Connection Manager Object Instance Error Codes (e.g.
section 3-5.6 in Ed. 3.19).

5.3 TCP/IP Suite

No addition to Common Device Recommendations.

5.4 Ethernet and Physical

No addition to Common Device Recommendations.

5.5 EDS File

1. The device shall support all EDS File recommendations described in the Common Device
Recommendations section 2.4.

2. The format of the I/O connection data shall be detailed in the EDS [Assem] section. This
does not apply to rack-based, technology enabler, or explicit messaging-only devices, or
devices with user-defined I/O data content (e.g. EtherNet/IP to other network gateway, target
connections of a PLC).

3. The EDS file shall include the [Connection Manager] section. This will allow easy
configuration of connections from scanners supporting the Connection Configuration object.

4. If the device supports configuration data with the Fwd_Open, the format of the configuration
data shall be detailed in the EDS [Assem] section and associated parameters shall be defined
in the [Param] section.

November 28, 2018 11 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

5.6 Performance
1. The device shall support all Performance recommendations described in the Common Device
Recommendations section 2.5.

2. The device shall conform to the following I/O performance measures under no background
traffic for 60 seconds:

Minimum Supported Connection RPI ≤ 100ms

Mean measured packet interval (MPI) with respect to reported API < ±10%

Standard Deviation of the MPI < ±10%

Maximum jitter of the MPI < ±50%

3. The device shall conform to the following I/O performance measures under a steady-state
amount of background traffic for 30 seconds:

Mean MPI with respect to reported API < ±10%

Standard Deviation of the MPI < ±25%

Maximum jitter of the MPI < ±100%

The background traffic will consist of the following:

ARP Request Broadcasts 180 packets/s

Gratuitous ARP Broadcasts 180 packets/s
DHCP Request Broadcasts 100 packets/s
ICMP (ping) Request Broadcasts 100 packets/s
NTP Multicasts 10 packets/s
EtherNet/IP ListIdentity Broadcast Requests 10 packets/s
EtherNet/IP Connected Class 1 Multicast I/O 1800 packets/s

The EtherNet/IP Connected Class 1 I/O only applies to the test cases where IGMP is
disabled, representative of the use of unmanaged switches.

4. The device shall conform to the following I/O performance measures under a burst of
background traffic during the same steady-state amount of background traffic:

Return to within this percentage of the mean MPI with respect to < ±10%
reported API within the test period

Maximum jitter of the MPI < 400%

The burst of background traffic will consist of the following 240 ARP Request packets in a
60 ms period, for an effective rate of 4000 packets/s.

November 28, 2018 12 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

6 Scanner Device Recommendations

This section explains the functionality that is recommended for Scanner class devices over and
above that in the Common Device section. The Scanner device recommendations are for any
device that originates Transport Class 1 connections.

6.1 Example Devices

 Programmable Controller
 Soft Controllers
 Robot

6.2 CIP
1. The device shall support all CIP recommendations described in the Common Device
Recommendations section 2.1.

2. The device shall support, at a minimum, origination of 8 Transport Class 1 I/O connections.
Although the actual number of connections supported is application specific, support for 64
or more is recommended.

3. The following recommendations pertain to originated Transport Class 1 I/O connections.

a) It is recommended that the device support the Change of State trigger type with
Production Inhibit Timer (PIT).
b) The device shall support the Cyclic trigger type.
c) The device shall support the Listen Only and Input Only connection types.
d) The device shall support the Exclusive Owner connection type.
e) The device shall support multicast TO and unicast OT. The device shall also
support unicast TO.
f) The device shall support the 32-bit Real-Time Header (Run/Idle Header) in the OT
connection data. OT connections to the Heartbeat connection path with 0 data
length shall not include the Real-Time Header. Support for connections without the
Real-Time Header (according to specifications in [Connection Manager] section of
the adapter's EDS file) is recommended.

4. The device shall be able to deliver a device Configuration Assembly (of ≤ 400 bytes) as part
of Forward_Open/Large_Forward_Open.

5. The device shall provide access to I/O data collected as a result of its “scan list” via Explicit
Messaging, e.g. Assembly object instance attribute 3. The I/O data collected shall not
include the 32-bit Real-Time Headers (Run/Idle Header).

6. It is recommended that the Connection Configuration object be supported. This will provide
a standard means of configuring the scanner.

7. It is recommended that the device accept (be a target of), at a minimum, 2 Transport Class 1
I/O connections. If this functionality is supported, the connections shall support the
Transport Class 1 connection features defined for the Adapter class device (section 5.2, items
2-5).
8. It is recommended that the device support the Extended Symbolic path segment in the
Forward_Open as an originator and a target. This would provide interoperable peer-to-peer
communication with current EtherNet/IP scanners.

November 28, 2018 13 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

6.3 TCP/IP Suite

1. The device shall support all TCP/IP Suite recommendations described in the Common
Device and Adapter Device Recommendations section 2.2.

2. The device shall support IGMP V2 with the following behavior:

a) Upon receiving a Forward_Open response to a multicast connection request, an
IGMP Membership Report shall be issued to join the multicast group.
b) Upon closing the multicast connection, an IGMP Leave Group shall be issued.

6.4 Ethernet and Physical

No addition to Common Device and Adapter Device Recommendations.

6.5 EDS File

1. The device shall support all EDS File recommendations described in the Common Device
Recommendations section 2.4.

2. If the device accepts Transport Class 1 connections from other devices, the EDS file shall
include the [Connection Manager] section. This will allow easy configuration of connections
from scanners supporting the Connection Configuration object.

6.6 Performance
1. The device shall support all Performance recommendations described in the Common Device
Recommendations section 2.5.

2. If the device supports Adapter functionality, then the device shall support all the Performance
recommendations described in the Adapter Device Recommendations section 5.6.

November 28, 2018 14 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

Document Revision Log

Revision Sections Remarks Date Author RT TRB
S
0.3 Release for review in Workshop #11 3/15/2004 Perry Green
0.4 Update after Workshop #11 4/2/2004 Perry Green
comments
0.5 Update after comments received from 6/4/2004 Perry Green
group review
0.6, 0.7 Last minute updates. 6/7/2004 Perry Green
0.8 Update after Workshop #12 6/8/2004 Perry Green
comments
1.0 First release after Workshop 6/10/2004 Perry Green
acceptance
1.0a Update after Workshop #16 9/27/2005 Perry Green
discussion
1.0b Further suggestions for change 09/29/2005 Viktor
Schiffer
1.1 Cleanup after review 10/12/2005 Perry Green
1.2 Changes after Plug Fest #4 2/14/2006 Perry Green
1.3 Updated after Workshop #24 8/12/2008 B Campbell
discussion
2.0 Added Performance 10/7/2008 Jim Gilsinn
Recommendations
2.1 5.2 Clarification on how the I/O Data 3/1/2011 Joakim
attribute can be accessed. Wiberg/
2.2 Grammar correction Darren Klug
2.3, 2.4, 5 Spec reference corrections
2.6 Made(new) Appendix F version of
ACD the preferred implementation.
5.2 Clarified cross reference in item 1.
Clarification of I/O Data in item 7.
5.5 Clarified cross reference in item 1.
5.6 Clarified cross reference in item 1.
6.2 Clarified cross reference in item 1.
Clarification re Large_Forward_Open
in item 4.
Clarification of I/O Data in item 5.
Corrected cross reference.
Replaced Fwd_Open with
Forward_Open.
6.3 Clarified cross reference in item 1.
Clarified cross references.

November 28, 2018 15 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

6.4
2.2 5.2-2 & 1. Clarified that device must support 2/8/2012 Darren Klug
PR001 5.2-3 multiple, unicast connections for
the same connection point.
2. Added requirement that Generic
2.1 devices report Device Type 0x2B.
3. Clarified that config rules apply
to f_open-based config.
5.2-4 4. Clarified that a device may
require a f_open with a non-null
data segmentfor unowned targets.
5.2-4 5. Added proposals to require TaCL
and recommend that deprecated
f_open extended status codes no
longer be used.
2.1 6. Removed reference to June 2006
IPv4 Address Conflict Detection
for EtherNet/IP Devices
document.
2.6 7. Updated spec references.
3 PR001 2.1, 5.2, 1. Moved Target Connection List 2/23/2012 Darren Klug
6.2 recommendation to Adapter and
Scanner sections (vs. Common).
2. Moved updated status code
2.1, 5.2 recommendation to Adapter
section (vs. Common).
3. Reversed item 4 in Rev 2.2
5.2-4 PR001. Clarified that a device
shall retain its configuration even
if all connections are terminated.
4. Cleaned up formatting.

Througho
ut
3 PR002 5.2 1. Clarified combinations of 3/2/2012 Darren Klug
multicast and unicast connections
required.
Througho 2. Replaced “->” with “”
ut
3 PR003 5.2 Further clarifications to mc/uc 5/23/2012 Darren Klug
required cnxn combos.
3 PR004 5.2 A few more tweaks based on internal 5/24/2012 Darren Klug
RA feedback. Changed support for
CoS from recommendation to
requirement.
3 PR005 Througho 1. Changed spec reference format 6/4/2012 Darren Klug
ut (so updates are not required every
time spec is updated).
2. Clarified that Device Type 0x00
has been deprecated.

November 28, 2018 16 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

2.1 3. Changed recommendation to

requirement that deprecated
5.2 f_open extended status codes no
longer be used starting with
PF#17 (spring 2013).
4. Removed recommendation that
devices support TaCL (until at
least a test is available).
5.2, 6.2

3 1.4, 2.5, 1. Clean up heading editing glitches 7/2/2012 Darren Klug

5.6 reported by Quinton.
6.2 2. Applied “bold” face to a “shall”
that lacked it.
4 PR001 5.2 1. Added missing connection 9/10/2012 Darren Klug
combination.
4 PR002 1.3 1. Corrected document rev. 2/18/2013 Darren Klug
4 PR003 Updates during WS#37: 2/19/2013 Darren Klug
5.2.6 1. Clarified requirement for exp msg
access to config params.
5.5.2 2. Clarified requirement for EDS I/O
connection data member
definition.
4 - As approved at WS#37; all changes 2/19/2013 Darren Klug
accepted.
5 PR001 - Improved consistency of CIP spec 7/31/2013 Darren Klug
references and verified section
numbers vs. Apr 2013 spec release.
Added future work item section with
1.3 1 item: TCP Socket Cleanup.
Removed references to pending
updates by Performance Working
2.5 Group.
Added Startup Behavior to
Performance section.
Clarified that explicit messaging
access to I/O Data attribute(s) shall be
5.2, item limited to read access.
7
5 PR002 1.3, 2.2, Editorial cleanups. 8/5/2013 Joaakim
5.2 Wiberg
5 PR003 5.2-4 Made support for data segment-based 8/8/2013 Darren Klug
configuration required for devices
with less than 400 bytes of
configuration data. Recommend use
of multiple attributes/assemblies for
devices with larger amounts of
configuration data.
5 PR004 Updates based on discussion at EIP 8/30/2013 Darren Klug
WS#38:

November 28, 2018 17 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

1.3 Added 2 items for future

consideration (DHCP, 10 Mbps).
2.5 Removed (understood) startup
behavior requirement; test to be
incorporated in Network tests.
2.7 Added rule re: testing of ODVA
Conformance recognized product
families.
5.2, item Reverted to allowing explicit write
7 access I/O Data attributes.
Reverted except for editorial changes.
5.2, item Updated Performance section to
4 include test duration and traffic
descriptions.
5.6
5 Pre WS#40 Cleanup 3/10/2014 Darren Klug X X
1.3 Removed future work item re: ESE-
050-006 “TCP Socket Cleanup” (new
Encapsulation Inactivity Timeout
attribute (13) is required).
Added future worked item re:
improving Explicit Messasing
Client/Scanner requirements.
6 2.2, item Clarified that TCP connections for 10/22/1014 Perry Green X X
3 CIP are reserved not just supported.
7 5.5, item Added requirement for configuration 2/17/2016 Perry Green X X
4 assembly details in the EDS.

Clarified behavior of explicit write to

output data
5.2, item
7
8 2.1 Added Class 3 priority support 3/30/2017 Perry Green X X
requirements

5.2, item Added simultaneous class 3/1

2 connection requirements

Added Listen Only to Unicast

5.2, item connection options
3
Added Class 1 priority support
requirements
5.2, item
3 Added rationale for no/null data
segment in Fwd-Open

5.2, item Moved to end of document

4

November 28, 2018 18 PUB00070R10

 Recommended Functionality for EtherNet/IP Devices

This table
9 2.3, item Removed Half Duplex requirement 4/20/2018 Perry Green X X
1
10 1.3 Remove sentence with document 11/28/2018 Perry Green X X
version in it.

2.3 Clarify that Ethernet requirements are

for all devices regardless of interface
count.

November 28, 2018 19 PUB00070R10