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 isuseful 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 withthe use of "shall") and what is optional (specified with the use of "recommended") in order for adevice to adhere to the recommendations.
It should be understood that a device may be compliant to the EtherNet/IP specification yet notmeet 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 thefollowing sections:
Common Device

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

Explicit Message Server Device

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

Explicit Message Client Device

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

Adapter Device

This section explains the functionality that isrecommended for Adapter class devices over and abovethat in the Common Device section.

Scanner Device

This section explains the functionality that isrecommended for Scanner class devices over and abovethat 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 acrossmultiple 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 morethan 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 specificationin 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 “outof-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 othermeans of setting these parameters.
d) The device shall allow the user to make a valid IP address persistently stored in nonvolatile 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 otherprotocols (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 typicallytransmitted 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 thisrequirement 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 PhysicalThe following recommendations apply to each of the device’s externally exposed EtherNet/IPinterfaces.
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 toEthernet 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 Objectb) The Ethernet MAC address shall be visible on the device (e.g., on a label). Note thatthe 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
Link
StatusSingle Color LED
State
Description
Off
No linkOn
Link
Flashing
Port activityb) Devices with a two Indicators:
Indicator
Single Color LED
State
Description
LinkOff
No link
StatusOn
Link

Activity

Off
Flashing

No activity
Port activityc) Devices with a three Indicators:
Indicator
Single Color LED
State
Description
LinkOff
No link
Status
On
Link

2.4

Bi-Color LED
Description
Off
No link
Solid Green
Link
Solid Amber
Port disabledFlashing Green Port activity
Flashing Amber Collision
Solid Red
Major NIC Fault
e.g. POST error
State

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

Off
Flashing Green
Flashing Amber

No activity
Port activity
Collision

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

Transmit

Off
Flashing

No activity
Port activity

Off
Flashing Green
Flashing Amber

No activity
Port activity
Collision

Receive

Off
Flashing

No activity
Port activity

Off
Flashing GreenNo activity
Port activity

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.

2.6

List Identity Response/UDP< 250ms

List Services Response/TCP(assuming existing TCP connection)< 250ms

Unconnected explicit response - No TCP connection established(Specific internal object/attribute would be tested)< 500ms

Unconnected explicit response - TCP connection established(Specific internal object/attribute would be tested)< 100ms

Connected explicit response(Specific internal object/attribute would be tested)< 100ms

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

Duplicate IP Address Detection

The device shall support duplicate IP address detection as specified in the latest version ofVolume 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 productfamily.

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




3.2

Example Devices
Text Display device
Data Acquisition Input devices
Data Logger

CIP

No addition to Common Device Recommendations.

3.3

TCP/IP Suite

No addition to Common Device Recommendations.

3.4

Ethernet and PhysicalNo 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




4.2

Example Devices
Simple HMI
Data Logger
Diagnostic Tool

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 suchas 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 PhysicalNo 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 andabove that in the Common Device section.
There are several references in this section to "rack-based" devices. For the purpose of thisdocument, 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, inthe 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 thedevice.
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 unidirectional 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 atleast one multicast TO Input Only or Listen Only connection for the sameTO connection point, simultaneously
ii. a multicast TO and unicast OT Exclusive Owner connection with atleast one unicast TO Input Only or Listen Only connection for the sameTO connection point, simultaneouslyiii. 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 Devicese) 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 morethan 1 listener if the device has input data. Note that this is necessary regardless ofwhether 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 32bit 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 tosupport 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 theexisting 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, 201810

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 andsucceed when the connection is not active. Explicit messaging-based access to I/O Dataattribute(s) is not a requirement for rack-based devices. The I/O Data attributes shall notinclude 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 PhysicalNo 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 definedin the [Param] section.

November 28, 201811

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 backgroundtraffic 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
Gratuitous ARP Broadcasts
DHCP Request Broadcasts
ICMP (ping) Request Broadcasts
NTP Multicasts
EtherNet/IP ListIdentity Broadcast Requests
EtherNet/IP Connected Class 1 Multicast I/O

180 packets/s
180 packets/s
100 packets/s
100 packets/s
10 packets/s
10 packets/s
1800 packets/s

The EtherNet/IP Connected Class 1 I/O only applies to the test cases where IGMP isdisabled, 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 toreported API within the test period< ±10%

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, 201812

PUB00070R10

Recommended Functionality for EtherNet/IP Devices

6 Scanner Device Recommendations
This section explains the functionality that is recommended for Scanner class devices over andabove 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 theReal-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 partof 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 notinclude 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 theTransport 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, 201813

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 PhysicalNo 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 Performancerecommendations described in the Adapter Device Recommendations section 5.6.

November 28, 201814

PUB00070R10

Recommended Functionality for EtherNet/IP Devices

Document Revision Log
Revision

Sections

0.3
0.4
0.5
0.6, 0.7
0.8
1.0
1.0a
1.0b
1.1
1.2
1.3
2.0
2.1

5.2
2.2
2.3, 2.4, 5
2.6
5.2
5.5
5.6
6.2

6.3

November 28, 2018

Remarks

Date

AuthorRelease for review in Workshop #11
Update after Workshop #11
comments
Update after comments received fromgroup review
Last minute updates.
Update after Workshop #12
comments
First release after Workshop
acceptance
Update after Workshop #16
discussion
Further suggestions for change

3/15/2004
4/2/2004

Perry Green
Perry Green

6/4/2004

Perry Green6/7/2004
6/8/2004

Perry Green
Perry Green

6/10/2004

Perry Green

9/27/2005

Perry Green

09/29/2005

Cleanup after review
Changes after Plug Fest #4
Updated after Workshop #24
discussion
Added Performance
Recommendations
Clarification on how the I/O Dataattribute can be accessed.
Grammar correction
Spec reference corrections
Made(new) Appendix F version of
ACD the preferred implementation.
Clarified cross reference in item 1.
Clarification of I/O Data in item 7.
Clarified cross reference in item 1.
Clarified cross reference in item 1.
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.
Clarified cross reference in item 1.
Clarified cross references.

10/12/2005
2/14/2006
8/12/2008

ViktorSchiffer
Perry Green
Perry GreenB Campbell

10/7/2008

Jim Gilsinn

3/1/2011

JoakimWiberg/Darren Klug

15

RT
S

PUB00070R10

TRB

Recommended Functionality for EtherNet/IP Devices

2.2
PR001

6.4
5.2-2 &
5.2-3

2.1

5.2-4

5.2-4

2.1

3 PR001

2.6
2.1, 5.2,
6.2

2.1, 5.2

5.2-4

3 PR002

Throughout
5.2

3 PR003

Throughout
5.2

3 PR004

5.2

3 PR005

Throughout

November 28, 2018

1. Clarified that device must support
multiple, unicast connections forthe same connection point.
2. Added requirement that Genericdevices report Device Type 0x2B.
3. Clarified that config rules apply
to f_open-based config.
4. Clarified that a device may
require a f_open with a non-nulldata segmentfor unowned targets.
5. Added proposals to require TaCL
and recommend that deprecatedf_open extended status codes nolonger be used.
6. Removed reference to June 2006
IPv4 Address Conflict Detection
for EtherNet/IP Devices
document.
7. Updated spec references.
1. Moved Target Connection List
recommendation to Adapter andScanner sections (vs. Common).
2. Moved updated status code
recommendation to Adapter
section (vs. Common).
3. Reversed item 4 in Rev 2.2
PR001. Clarified that a device
shall retain its configuration even
if all connections are terminated.
4. Cleaned up formatting.

2/8/2012

Darren Klug

2/23/2012

Darren Klug

1. Clarified combinations ofmulticast and unicast connections
required.
2. Replaced “->” with “”

3/2/2012

Darren Klug

Further clarifications to mc/uc
required cnxn combos.
A few more tweaks based on internal
RA feedback. Changed support for
CoS from recommendation torequirement.
1. Changed spec reference format(so updates are not required every
time spec is updated).
2. Clarified that Device Type 0x00
has been deprecated.

5/23/2012

Darren Klug

5/24/2012

Darren Klug

6/4/2012

Darren Klug

16

PUB00070R10

Recommended Functionality for EtherNet/IP Devices
2.1
5.2

3. Changed recommendation torequirement that deprecatedf_open extended status codes nolonger be used starting with
PF#17 (spring 2013).
4. Removed recommendation thatdevices support TaCL (until atleast a test is available).

5.2, 6.2
3

1.4, 2.5,
5.6
6.2

4 PR001

5.2

4 PR002
4 PR003

1.3
5.2.6
5.5.2

4

-

5 PR001

-

1.3

2.5

5 PR002
5 PR0035.2, item
7
1.3, 2.2,
5.2
5.2-4

5 PR004

November 28, 2018

1. Clean up heading editing glitches
reported by Quinton.
2. Applied “bold” face to a “shall”
that lacked it.
1. Added missing connection
combination.
1. Corrected document rev.
Updates during WS#37:
1. Clarified requirement for exp msg
access to config params.
2. Clarified requirement for EDS I/O
connection data member
definition.
As approved at WS#37; all changes
accepted.
Improved consistency of CIP spec
references and verified section
numbers vs. Apr 2013 spec release.
Added future work item section with
1 item: TCP Socket Cleanup.
Removed references to pending
updates by Performance Working
Group.
Added Startup Behavior to
Performance section.
Clarified that explicit messaging
access to I/O Data attribute(s) shall belimited to read access.

7/2/2012

Darren Klug

9/10/2012

Darren Klug

2/18/2013
2/19/2013

Darren Klug
Darren Klug

2/19/2013

Darren Klug

7/31/2013

Darren Klug

Editorial cleanups.

8/5/2013

Made support for data segment-based
configuration required for devices
with less than 400 bytes ofconfiguration data. Recommend useof multiple attributes/assemblies fordevices with larger amounts ofconfiguration data.
Updates based on discussion at EIP
WS#38:

8/8/2013

Joaakim
WibergDarren Klug

8/30/2013

Darren Klug

17

PUB00070R10

Recommended Functionality for EtherNet/IP Devices
1.3
2.5

2.7

5.2, item
75.2, item
4

Added 2 items for future
consideration (DHCP, 10 Mbps).
Removed (understood) startup
behavior requirement; test to beincorporated in Network tests.
Added rule re: testing of ODVA
Conformance recognized productfamilies.
Reverted to allowing explicit write
access I/O Data attributes.
Reverted except for editorial changes.
Updated Performance section to
include test duration and traffic
descriptions.

5.6
5
1.3

6
7

2.2, item
35.5, item
4

Pre WS#40 Cleanup
Removed future work item re: ESE050-006 “TCP Socket Cleanup” (newEncapsulation Inactivity Timeout
attribute (13) is required).
Added future worked item re:
improving Explicit Messasing
Client/Scanner requirements.
Clarified that TCP connections for
CIP are reserved not just supported.
Added requirement for configurationassembly details in the EDS.

3/10/2014

Darren Klug

X

X

10/22/1014

Perry GreenX

X

2/17/2016

Perry GreenX

X

3/30/2017

Perry GreenX

X

Clarified behavior of explicit write tooutput data

8

5.2, item
7
2.1

5.2, item
2

5.2, item
3

Added Class 3 priority support
requirements
Added simultaneous class 3/1
connection requirements
Added Listen Only to Unicast
connection options
Added Class 1 priority support
requirements

5.2, item
3

5.2, item
4

November 28, 2018

Added rationale for no/null data
segment in Fwd-Open
Moved to end of document

18

PUB00070R10

Recommended Functionality for EtherNet/IP Devices

910This table
2.3, item
1
1.3

2.3

November 28, 2018

Removed Half Duplex requirement

4/20/2018

Perry GreenX

X

Remove sentence with document
version in it.

11/28/2018

Perry GreenX

X

Clarify that Ethernet requirements arefor all devices regardless of interface
count.

19

PUB00070R10