EtherNet/IP Interoperability Test Procedures
Publication PUB00095
Version 9
April 10, 2018

Published by:Roundtable for EtherNet/IP Implementors

EtherNet/IP Interoperability Test Procedures

Table of Contents
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Introduction .......................................................................................................................................... 1
Normative Reference Documents ........................................................................................................ 2
Abbreviations & Definitions.................................................................................................................. 3
Software and Tool Versions .................................................................................................................. 4
Proposed Test Configurations............................................................................................................... 5
EDS File Verification Test ....................................................................................................................10
EtherNet/IP Protocol Conformance Test ............................................................................................13
Network Interoperability Test............................................................................................................. 14
Common Interoperability Test............................................................................................................ 21
Explicit Message Server Interoperability Test.....................................................................................23
Explicit Message Client Interoperability Test......................................................................................23
Adapter Interoperability Test ............................................................................................................. 24
Scanner Interoperability Test.............................................................................................................. 36
System Interoperability Test...............................................................................................................39
Device Performance Test ....................................................................................................................43

Table of Figures
Figure 1 Proposed Network Interoperability Test Setup .............................................................................. 5
Figure 2 Proposed Setup for EDS test ........................................................................................................... 6
Figure 3 Proposed test configuration for single port device ........................................................................ 6
Figure 4 Proposed test configuration for multi port device ......................................................................... 7
Figure 5 Proposed Common Interoperability Test Setup ............................................................................. 7
Figure 6 Proposed System Interoperability Test Setup ................................................................................ 8
Figure 7 Proposed Performance Test Setup ................................................................................................. 8
Figure 8 Proposed Scanner Interoperability Test Setup ............................................................................... 9

Table of Tables
Table 1 Connection Combinations Attempted with the DUT ..................................................................... 32
Table 2 Behavior of 2nd I/O Connection..................................................................................................... 33
Table 3 Traffic Amounts for Performance Tests .........................................................................................44
Table 4 Document Revision Log..................................................................................................................47

Publication PUB00095

i

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

Contributors
Name
Brian Batke
Brian Campbell
Jim Gilsinn
Perry Green
Kevin Knake
Greg Majcher
Ray Romito
Viktor Schiffer
Doug Stanton
Dave VanGompel
Gary Workman
Dan Zaniewski
Joakim Wiberg
Darren Klug
Rick Blair
Emmanuel Lude
Bjorn Otterdahl

Publication PUB00095

Company
Rockwell Automation
Rockwell Automation
NIST
Pyramid Solutions
HMS Industrial Networks
Rockwell Automation
Rockwell Automation
Rockwell Automation
Rockwell Automation
Rockwell Automation
General Motors
Rockwell Automation
HMS Industrial Networks
Rockwell Automation
Schneider Electric
Molex
HMS Industrial Networks

ii

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

1

Introduction

This document identifies test procedures for interoperability testing of EtherNet/IP devices. The test
procedures are derived from a series of documents that have been produced by ODVA and the North
American EtherNet/IP Implementors Workshop.
This document is one of a set of documents that will lay out the test plans, procedures, and logistics for
performing interoperability testing on EtherNet/IP devices. This document consists of a specific set oftest procedures that describe the way to perform interoperability testing for EtherNet/IP devices. Other
documents may describe the specific way in which the tests will be conducted at a particular event. Test
results will be recorded in a test results document that will be provided only to the vendor. If the
product has a valid Declaration of Conformance (DoC), upon successfully completing the advisory test
followed by PlugFest Completion at a TSP, the product’s DoC will be updated to indicate that it has
passed the Advisory Test for EtherNet/IP Interoperability. Devices that do not have a valid Declarationof Conformance may use the Interoperability Advisory Test results in the future (within 6 months ofcompleting the Interoperability Advisory test) if the same device revision passes the ODVA Conformanceand PlugFest Completion tests at a TSP.
The EtherNet/IP Interoperability Advisory Test will consist of testing products for compliance to thefollowing recommendations:•
Recommended IP Addressing Methods for EtherNet/IP Devices, see Section 2, Normative
Reference Documents, item [4] for publication number and revision.
•
Recommended Functionality for EtherNet/IP Devices, see Section 2, Normative Reference
Documents, item [5] for publication number and revision.
•
Address Conflict Detection per Appendix F, see Section 2, Normative Reference Documents,
item [2].
•Performance Test Methodology for EtherNet/IP Devices, see Section 2, Normative Reference
Documents, item [7] for publication number and revision.
This document describes both required and informational interoperability test cases. A device must
pass all of the required test cases in order to have successfully completed the EtherNet/IP
Interoperability Tests. Some of the test cases in this document are informational. These are test casesthat have been determined to aid interoperability but are not required for it. A device may attempt tocomplete these steps, but the device will not fail the EtherNet/IP interoperability tests for unsuccessfullycompleting those steps. Unless specifically noted in this document, all test cases presented are
required.

Publication PUB00095

1

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

2

Normative Reference Documents

The following list contains a set of normative references that are the basis for these test procedures.
The test procedures in this document refer to the particular test plan line items.
1.
2.
3.
4.

CIP Common Specification, Edition 3.13, November 2012 or later.
EtherNet/IP Adaptation of CIP, Edition 1.14, November 2012 or later.
EtherNet/IP Terms and Definitions, Revision 0.3, April 3, 2002.
Recommended IP Addressing Methods for EtherNet/IP Devices, Version 1.0, June 10, 2003,
PUB00028R0.
5. Recommended Functionality for EtherNet/IP Devices, Version 4, February 19, 2013,
PUB00070R4.
6. Performance Test Terminology for EtherNet/IP Devices, Version 1.1, March 14, 2005,
PUB00080R1.1.
7. Performance Test Methodology for EtherNet/IP Devices, Version 1.0, March 14, 2005,
PUB00081R1.

Publication PUB00095

2

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

3

Abbreviations & Definitions
CIP
DOC
DLR
DUT
EDS
EO
I/O
IO
IP
LO

Common Industrial Protocol
Declaration of Conformity
Device Level Ring
Device Under Test
Electronic Data Sheet
Exclusive Owner
Input/Output
Input Only
Internet Protocol
Listen Only

Exclusive Owner (EO) Connection
A connection where the Originator opens a connection to both the input and output connection pointsof the Target (both O→T and T→O directions).
Heartbeat Connection
A special type of CIP connection where a small message is sent over the connection at regular intervals
to allow either the Originator or Target of a connection to monitor the connection status even if theactual data only flows in one direction (either O→T or T→O).
Input Only (IO) Connection
A connection where the Originator opens a connection to the input connection point of the Target (T→O
direction) and an O→T connection to the IO heartbeat connection point.
Listen Only (LO) Connection
A connection where the Originator opens a connection to the input connection point of the Target (T→O
direction) and an O→T connection to the LO heartbeat connection point. A Listen Only connection
differs from an Input Only connection in that it cannot initiate a connection to a device or remain active
if a connection is terminated, it can only monitor an existing connection.
IP Frame
An Ethernet frame containing IP address information in contrast to other frames that do not containsuch information, e.g. a Beacon frame within the DLR protocol.

Publication PUB00095

3

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

4

Software and Tool Versions

This document mentions several tools and software packages. The following minimum revisions are
required to perform a complete set of the tests described in this document. All links were validated on
April 30, 2014.
 EZ-EDS (ODVA) version 3.21 or latero https://secure.odva.org/forms/ez-eds.htm
 RSLinx Classic Lite (Rockwell Automation) version 3.60 or latero http://compatibility.rockwellautomation.com/Pages/MultiProductDownload.aspx?Keyw
ord=Free&crumb=112
 EIP-CT (Molex) version 3.1 or latero http://www.molex.com/molex/products/datasheet.jsp?part=active/1121065011_SOFT
WARE_DEV_KITS.xml
 EDITT (Pyramid Solutions), version 1.23 or latero http://network.pyramidsolutions.com/software-products/development-testingtools/ethernetip-interoperability-editt/ Molex EtherNet/IP Tool, latest version 2.3(ODVA) or later (EIPTools.exe)o http://www.molex.com/molex/common/staticLoader.jsp?fileName=/mx_upload/superf
amily/iccc/EtherNet_IPTool.html
 Wireshark, any version will sufficeo http://www.wireshark.org/download.html
 At least 1 PC with Windows is needed for most tests. Make sure that VPN and firewall is shut
down as it will interfere with most tests
 DHCP Server is needed for many tests. Any such server will suffice CIP Tool – a CIP Explicit client that allows the user to build CIP explicit messages. A tool such as
Pyramid Solutions’ EIP Scan will suffice.
o http://network.pyramidsolutions.com/software-products/development-testingtools/ethernetip-scanner-simulator-eipscan/ ODVA Example Code application – use current version on ODVA website
 ACD Test Tool (HMS) v1.13.0.1 or latero https://marketplace.odva.org/products/1812-address-conflict-detection-test-tool Molex Plugfest Performance Packet Generator v1.1 or later (for comparison only; the official
injection tool is TCP replay as compiled by NIST) NIST Industrial Ethernet Network Performance (IENetP) Test Tool v1.1.2 or later.
o http://sourceforge.net/projects/ienetp/
 TCP replay files as provided through http://ienetp.sourceforge.net/EtherNet-IP_Testing.zip
 Hilscher netAnalyzer PCI-card (NANL-C500-RE) installed in a Microsoft Windows PC.
o http://hilscher.com/products_details_hardware.html?p_id=P_474ae22a48950&bs=14

Publication PUB00095

4

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

5

Proposed Test Configurations

Figure 1 Proposed Network Interoperability Test Setup

Publication PUB00095

5

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

Figure 2 Proposed Setup for EDS test

For the ACD test configurations (see below), the infrastructure device used shall be an Ethernet Hub or
Ethernet Switch. If an Ethernet Switch is used it must support port mirroring and be capable oftransmitting data from the Test Tool thru the mirroring port. In addition, the Ethernet Switch shall be
configured to mirror traffic from the port connected to the DUT to the port connected to the PC running
the IPv4 ACD Test Tool.

Ethernet
Hub or Switch

DUT

IPv 4 ACD Test Tool
Packet Sniffer

Figure 3 Proposed test configuration for single port device

For multi port devices an additional Ethernet device is required in order to perform some of the ACD
tests. The only use for this additional Ethernet device is to establish a link between itself and the DUT,
meaning that any device could be used.

Publication PUB00095

6

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

Ethernet
DeviceEthernet
Hub or Switch

DUT

IPv 4 ACD Test Tool
Packet Sniffer

Figure 4 Proposed test configuration for multi port device

Figure 5 Proposed Common Interoperability Test Setup

Publication PUB00095

7

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

Figure 6 Proposed System Interoperability Test Setup

Figure 7 Proposed Performance Test Setup

Publication PUB00095

8

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

EIP Example
Code
Device Under
Test

Adapter
with
Run/Idle
indication

ManagedSwitchPC for tools
Reference Adapters

Figure 8 Proposed Scanner Interoperability Test Setup

Publication PUB00095

9

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

6

EDS File Verification Test

This test is intended to verify that the EDS file for the EtherNet/IP device conforms to the appropriate
requirements. This test MUST be successfully completed before proceeding to further tests.
A proposed test setup is shown in Figure 2. The software required for this test is listed below. See
Section 4, Software and Tool Versions for specific version information.


EZ EDSRSLinxEIP-CT from Molex

P6
EDS File Verification Test Procedure
P6.1
Offline EDS File Verification with EZ-EDS
P6.1.1
P6.1.2P6.1.3P6.1.4P6.1.5

P6.2

Open EDS of DUT with EZ-EDS. Minor deficiencies can be fixed at this stage if the missing
information is available.
Check for the I/O capacity section and verify that the section exists and is correctly
formatted. (The performance numbers presented in the I/O capacity section will not bevalidated.)
NOTE: This does not apply to messaging only devices.
Verify that the EDS file includes the specification of the format of the I/O connection
assembly object in the [Assembly] section if the DUT is an Adapter. “Format” in thiscontext means that assembly members are described by parameters (e.g. ParamN,
AssemN, etc. entries): assembly members that resolve to pad bits/bytes alone withnothing else are not regarded as “format”.
NOTE1: This does not apply to rack-based, technology enabler, or explicit messagingonly devices. Or devices with user-defined I/O data content (e.g. EtherNet/IP to othernetwork gateway, target connections of a PLC).
NOTE2: Devices that support symbolic tags rather than assembly objects may not havean [Assembly] section, but shall have “SYMBOL_ANSI” specified in the ConnectionN
entries of the [Connection Manager] section.
Verify that the EDS file includes the [Connection Manager] section with appropriate
ConnectionN entries if the DUT is either an Adapter or a Scanner that accepts CIP
transport class 1 connections.
NOTE: This does not apply to messaging only devices.
Verify that the EDS file includes the specification of the format of the configurationassembly in the [Assembly] section if the DUT is an Adapter and supports configuration
data with the Fwd_Open. “Format” in this context means that assembly members aredescribed by parameters (e.g. ParamN, AssemN, etc.); assembly members that resolve
to pad bits/bytes alone with nothing else are not regarded as “format”.
Online EDS File Verification with RSLinx and EIP-CT

Publication PUB00095

10

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP6.2.1
Verification of DUT’s EDS file with RSLinx
P6.2.1.1
When launching RSLinx you must instantiate the proper communications driver.
From the main menu select “Communications” then “Configure Drivers”; pick
EtherNet/IP Driver from “Available Drivers” and select “Add New”. You can keep thedefault name (AB_ETHIP-x) or choose new name. Also, to avoid any confusion, makesure that the “Ethernet devices” driver is not listed in the “Configured Drivers” list. If
it is, select the driver and then select “Stop” or “Delete”.
P6.2.1.2
Install the EDS of the DUT using the Hardware Installation Tool. This is typicallyinstalled as Programs → Rockwell Software →RSLinx→ Tools →EDS Hardware
Installation Tool. Warnings during the install process are ok as long as no essential
parts of the EDS, e.g. ConnectionN entries are severely affected, i.e. removed. It isadvisable to assign an icon to the DUT, either a vendor-supplied icon or an icon fromthe ones that come with the tool.
P6.2.1.3
Power up the DUT and run the RSWho utility in RSLinx.Open the RSWho window
within RSLinx (Connections →RSWho) and browse the network with the DUT using
the EtherNet/IP driver. Verify that the DUT is discovered by RSWho and is displayedcorrectly. NOTE: The requirement is that the device is displayed as a recognizeddevice type based on the EDS; the device should not be displayed as a question
mark. If the DUT does not show up with this driver but can be detected when the
RSLinx Ethernet driver is used, then this either means there is something wrong with
the Ethernet settings of the test PC (Firewall, VPN etc.) or the DUT does not properly
support the List Identity request.
Shut down RSLinx before proceeding to the next step.
P6.2.2
Verification of DUT’s EDS file with EIP-CT
P6.2.2.1
Check existing configuration of EIP-CT for usability or create a new configuration by
right-clicking in the Configurations pane to open the Configuration Manager. Fromthe list, select an EIP_DiagnosticScanner Type. If the existing configuration is okapart from the IP address of the scanner, then this address can be changed bydouble-clicking on “EIP_DiagnosticScanner” in the Configuration pane.
P6.2.2.2

P6.2.2.3

Install the EDS using the Library → Add function (or use icon). The EDS must
install without errors; warnings may be displayed during the install process. If the
EDS file has previously been installed with the same major revision, remove it andinstall the new version. NOTE: the EIP-CT configuration software may indicate
warnings during the installation; the requirement is that the installation completes
without errors.
Select the interface to use to communicate on EtherNet/IP using Network → Choose
Network Adapter (or use iconside)

Publication PUB00095

in the “Network Detection” pane on the left

11

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP6.2.2.4

Power up the DUT and go online using the File → Go Online function (or use icon
) and start the Network Detection process using Network → Read Network

Configuration… (or use icon). The EIP-CT must detect the DUT and associate itwith the proper EDS. NOTE: The requirement is that the device is displayed as arecognized device type based on the EDS; the device should not be displayed as an
unrecognized device. If the device does not appear at all, this could be an indicationof a ListIdentity issue (which is a Protocol Conformance issue).
P6.2.3(Informational):
P6.2.3.1
When the above required test procedure with the EIP-CT has completed

P6.2.3.4

successfully, go offline using the File → Go Offline function (or use icon).
Drag and drop the newly detected device from the Network Detection pane to themain window (or right-click on the device and select “Insert in Configuration”).
Go to the “Connections” tab, check whether the desired connection has beenchosen and hit “Ok” when this is the case.
Save the configuration.

P6.2.3.5

Go online using the File → Go Online function (or use icon

P6.2.3.2
P6.2.3.3). Start the

Diagnostic Scanner Tool using Devices -> Diagnostic function (or use icon
set it on RUN mode by Devices -> Run function (or use icon
Wireshark to check the I/O frames on the wire.
P6.2.3.6

The target module should be displayed with a green check mark

) and). You can use. If a red check

mark is displayed, there may be a problem with the connection.
P6.2.3.7
Check functionality of the other available connections (Exclusive Owner and Input
Only) by removing the existing connection and inserting others. To do so, use thefollowing procedure:
Stop diagnostics in EIP-CT, go OfflineDouble-click on target device in EIP-CT and go to the Connections tabMark existing connection and remove it
Add new connection and pick one that has not been used so far
Close the configuration window by hitting “Ok”
Save this configuration

Go Online then start Diagnostic
Check if the new connection is ok
Repeat the above until all connections have been verified
P6.2.3.8
Stop Diagnostics and go Offline before testing another device.
P6.2.4On the Test Results form, record the O→T and T→O connection information (Conn
Points, Sizes & RPI range) used for each connection tested in P6.2.3. These numbers will

Publication PUB00095

12

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
be used in the Adapter Interoperability test (section P12) and System Interoperability
test (section 0). If the device supports more than one of each type, pick the one(s) the
vendor wants to use with the above noted tests. Also record the connection names for
those scanner tools that only allow picking connections by name.
If the device was previously tested at the Adapter Interoperability test station andcomes to this station with the connection values filled in on the test results form, verify
that the values recorded correspond to the entries in the EDS file. The goal is that EDS
file has valid information and that information is used in the other testing at Plugfest toverify that it is correct.

7

EtherNet/IP Protocol Conformance Test

This test is intended to verify that the DUT meets the minimum requirements to be considered an
EtherNet/IP device per Section 2, Normative Reference Documents [1] and [2]. This establishes abaseline that the other tests in this document use for the additional interoperability tests. In mostcases, this test procedure will be conducted before the other test procedures as part of the pre-test
qualification for a particular event.
It is recommended that all EtherNet/IP devices have passed a self-administered protocol conformance
test at the latest revision of the EtherNet/IP Protocol Conformance Test Software Tool.

P7
EtherNet/IP Protocol Conformance Test Procedure (Informational)
P7.1
Verify that the DUT has passed the EtherNet/IP conformance self-test. The vendor shall haverun the latest version of the conformance test prior to Plug Fest attendance. The results ofthis test (log file) shall be presented upon request.

Publication PUB00095

13

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

8

Network Interoperability Test

This test is intended to determine if the DUT meets the minimum recommended behavior for network
functionality. A proposed test setup is shown in Figure 1. For multiport devices the following tests will
be performed on two ports. For devices with more than two ports, the tester will choose which two
ports will be tested.
Software needed for this test. See Section 4, Software and Tool Versions for specific version information:







RSLinxCIP Tool
Wireshark
DHCP server
A tool that can configure the managed switch for different duplex/baud
settings. Tool is provided by the switch manufacturer

P8
Network Interoperability Test Procedure
P8.1
Verify that the DUT has the Ethernet MAC address visible on the outside of the device.
NOTE: The address may be hidden after the device is installed. A device with an integral
display (e.g.: an HMI) that can be made to display the MAC address is an acceptable
alternative to a label in devices where a label is not practical (e.g.: PC-based software).

P8.2

P8.2.1P8.2.2P8.2.3P8.2.4P8.2.5P8.2.6P8.2.7

Initial Test Setup
On the DHCP server, setup a static MAC-to-IP mapping for the DUT.
Put the DUT in an “out-of-box” state with auto-negotiation, then power cycle the DUT
while it is disconnected from the switch.
Setup at least 1 port on the network switch to auto-negotiate its speed and duplex.
Setup at least 1 port on the network switch to 100 Mbps and full duplex.
Setup at least 1 port on the network switch to 10 Mbps and full duplex.
Attach the DUT to the auto-negotiate port on the network switch.
Prepare a PC with the traffic sniffer software and connect it to the network switch. Set
up the network switch so that all traffic to/from the DUT can be monitored via the port
where the sniffer is connected.

P8.3

IP Address Configuration
P8.3.1
Verify that the DUT has reached its steady state operation.
P8.3.2Connect one of the DUT’s Ethernet ports to the port on the switch configured for autonegotiation.
P8.3.3Using a packet sniffer, verify that the DUT issues a BOOTP/DHCP request at initial powerup from an ‘out-of-box’ configuration state. Record which request is used on the test
results form for use in step P8.3.5.

Publication PUB00095

14

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP8.3.4

Verify that the DUT obtained the pre-configured IP address from the BOOTP/DHCP
server.
P8.3.4.1
Ping the DUT and verify that it responds correctly.
P8.3.4.2
Using RSLinx, refresh the RSWho utility to send a ListIdentity message and verify
that the DUT responds correctly.
P8.3.5
Verify that Configuration Control attribute of the TCP/IP object indicates either BOOTP
or DHCP and that the request issued in P8.3.3 is of the indicated type.
P8.3.5.1
Use a Get_Attribute_Single to read class 0xF5, attribute 3 and verify that bits 0-3 areeither 1 (BOOTP) or 2 (DHCP).
P8.3.6Using the packet sniffer, verify that the device has stopped issuing BOOTP or DHCP
requests.
P8.3.7
Send the DUT a CIP message to make its IP address permanently stored in non-volatilememory via the TCP/IP interface object
P8.3.7.1
Use a Set_Attribute_Single to set class 0xF5, attribute#3 to a value of zero (usepreviously stored value or hardware switch value).
P8.3.8
Shut down the DHCP server.
P8.3.9Power down the DUT, start the traffic sniffer then reapply power to the DUT.
P8.3.10
Verify that the DUT retained its IP address.
P8.3.10.1 Ping the DUT and verify that it responds correctly.
P8.3.10.2 Using RSLinx, refresh the RSWho utility to send a ListIdentity message and verify
that the DUT responds correctly.
P8.3.11
Using the packet sniffer, verify that the device has not issued any BOOTP or DHCP
requests.
P8.3.12Send the DUT a CIP message to make its IP address volatile again
P8.3.12.1 Use a Set_Attribute_Single to set class 0xF5, attribute #3 to a value of 1 or 2 (1 =BOOTP; 2 = DHCP) and reboot the device.
P8.3.13
Using the packet sniffer, verify that the device is issuing BOOTP or DHCP requests again.
P8.3.14
Ping DUT to verify that it does not use its previous IP address any more.
P8.3.15
For DUTs with multiple Ethernet ports: Repeat test P8.3 with at least one other port andrecord which ports were used.

P8.4

P8.4.1

P8.4.2P8.4.3P8.4.4P8.4.5

Speed & Duplex Configuration Tests (not required for optical Ethernet ports)
Determine whether the DUT requires a reset to change interface settings by using a
Get_Attribute_Single to read the Ethernet Link Object (class 0xF6), attribute 2. Note thevalue of bit 5 on the test results form for later.
Verify that auto-negotiate is enabled. Use a Get_Attribute_Single service to read the
Ethernet Link Object (class 0xF6), attribute 6 and verify that bit 0 is set.
Verify that the DUT properly auto-negotiated its speed and duplex to 100/full using theswitch configuration tool.
Set the DUT to 100 Mbps and full duplex. Use a Set_Attribute_Single to the Ethernet
Link object (class 0xF6), attribute 6 and set the value to 02 00 64 00.
If the value from test P8.4.1 was 1, power cycle the DUT now.

Publication PUB00095

15

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP8.4.6P8.4.7P8.4.8P8.4.9P8.4.10P8.4.11P8.4.12P8.4.13P8.4.14P8.4.15
P8.4.16
P8.4.17
P8.4.18

Attach the DUT to the 100 Mbps and full duplex port on the network switch.
Using RSLinx, refresh the RSWho utility to send a ListIdentity message using broadcast
UDP and verify that the DUT responds properly.
Power cycle the DUT and repeat step P8.4.7 to make sure it retained the 100 Mbps &full duplex settings.
Set the DUT to 10 Mbps and full duplex. Use a Set_Attribute_Single to the Ethernet Link
object (class 0xF6), attribute 6 and set the value to 00 00 0A 00.
If the value from test P8.4.1 was 1, power cycle the DUT now.
Attach the DUT to the 10 Mbps and full duplex port on the network switch.
Using RSLinx, refresh the RSWho utility to send a ListIdentity message using broadcast
UDP and verify that the DUT responds properly.
Power cycle the DUT and repeat set P8.4.12 to make sure it retained the 10 Mbps & full
duplex settings.
Return the DUT to auto-negotiate. Use a Set_Attribute_Single to the Ethernet Link
object (class 0xF6), attribute 6 and set the value to 01 00 00 00.
If the value from test P8.4.1 was 1, power cycle the DUT now.
Attach the DUT to the auto-negotiate port on the network switch.
Using the switch configuration tool, verify that the DUT properly auto-negotiated its
speed and duplex to 100/full.
For DUTs with multiple Ethernet ports: Repeat test P8.4 with at least one other port andrecord which ports were used.

P8.5

IP Address Conflict Detection Tests
This section provides test cases for the ACD mechanism specified in Appendix F of Volume 2. The
applicable test setups are shown in Figure 3 and Figure 4. The DUT shall be configured using a static IP
address in all ACD tests. The ACD Test Tool (see Section 4, Software and Tool Versions) may be used toperform these tests.
All timing verifications will allow for an extra 10% in each direction.
P8.5.1
Verification that no IP frames are sent until IP address has been successfully probed
P8.5.1.1
Assign a static IP address to the DUT
P8.5.1.2
For multi-port devices: Only have one Ethernet port connected
P8.5.1.3
Power up the DUT
P8.5.1.4
Capture all traffic until the DUT sends its second ARP announce
P8.5.1.5
Verify that the DUT does not use the IP address in any frames other than ARP
probes until the first ARP announce has been sent

P8.5.2
Verification of ACD probe timing and ACD announce timing
P8.5.2.1
Power cycle the DUT
P8.5.2.2
Verify that the DUT sends out 4 ARP probes
P8.5.2.3
Verify that the delta time between two ARP probes is between 180 ms and 220 ms
P8.5.2.4
Verify the contents of each ARP field for all ARP probes

Publication PUB00095

16

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP8.5.2.5
P8.5.2.6

Verify that the DUT sends out 2 ARP announcements
Verify that the delta time between the last ARP probe and the first ARP announce isbetween 180 ms and 220 ms
P8.5.2.7
Informational: Verify that the delta time between the two ARP announce is between
1800 ms and 2200 ms
P8.5.2.8
Verify the contents of each ARP field for all ARP announce frames
P8.5.3
Verification that ACD process is restarted when Ethernet cable is reconnected
Note: This test is dependent on that test P8.3.2 has been completed successfully.
P8.5.3.1
Disconnect and reconnect the Ethernet cable
P8.5.3.2
Verify that the DUT sends out 4 ARP probes
P8.5.3.3
Verify that the delta time between two ARP probes is between 180 ms and 220 ms
P8.5.3.4
Verify the contents of each ARP field for all ARP probes
P8.5.3.5
Verify that the DUT sends out 2 ARP announcements
P8.5.3.6
Verify that the delta time between the last ARP probe and the first ARP announce isbetween 180 ms and 220 ms
P8.5.3.7
Informational: Verify that the delta time between the two ARP announce is between
1800 ms and 2200 ms
P8.5.3.8
Verify the contents of each ARP field for all ARP announce frames
P8.5.4
Verification of ongoing ACD probe timing
Note to tester: Due to time constraints, skip this test on the first pass. If all other ACD
tests pass, perform a second pass and include this test.
P8.5.4.1
Power cycle the DUT
P8.5.4.2
Monitor ARP probes from the DUT for 10 minutes
P8.5.4.3
Verify that the delta time between two ARP probes is between 90 s and 150 s
P8.5.4.4
Verify the contents of each ARP field for all ARP probes
P8.5.5
Verification of semi-active state for multi port devices supporting ACD per Vol.2
P8.5.5.1
Power cycle the DUT and wait until the initial probe and announce phase has passed
P8.5.5.2
Connect a cable with an Ethernet device attached to one of the unconnected ports
P8.5.5.3
Verify that the DUT sends out 2 ARP probes
P8.5.5.4
Verify that the delta time between the two ARP probes is between 180 ms and 220
ms.
P8.5.5.5
Verify the contents of each ARP field for all ARP probe frames
P8.5.5.6
Repeat test P8.5.5 with at least one other port and record which ports were used
P8.5.6
Verification that multi port devices restart the ACD process on link up
P8.5.6.1
Power cycle the DUT (with cable on second Ethernet port connected) and wait until
the initial probe and announce phase has passed
P8.5.6.2
Disconnect and reconnect the second Ethernet cable
P8.5.6.3
Verify that the DUT sends out 2 ARP probes
P8.5.6.4
Verify that the delta time between two ARP probes is between 180 ms and 220 ms
P8.5.6.5
Verify the contents of each ARP field for all ARP probes
P8.5.6.6
Disconnect the second Ethernet cable
P8.5.6.7
Repeat test P8.5.6 with at least one other port and record which ports were used
Publication PUB00095

17

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP8.5.7
Verification of IP address conflict detection during probe phase – ARP announce
P8.5.7.1
Power cycle the DUT
P8.5.7.2
During the probe phase, between probe 1 and 4,test tool shall send an ARP
announce with Sender IP address equal to the IP address used by the DUT
P8.5.7.3
Verify that the DUT immediately stops sending ARP announces and/or probes
P8.5.7.4
Verify that the DUT exhibits IP conflict. If the DUT supports NS LED, verify that the
DUT sets the NS LED to solid red
P8.5.7.5
If the DUT supports MS LED, verify that the DUT flashes the MS LED red
P8.5.8
Verification of IP address conflict after probe phase
P8.5.8.1
Power cycle the DUT
P8.5.8.2
During the announce phase, between probe 4 and announce 1,test tool shall sendan ARP announce with Sender IP address equal to the IP address used by the DUT
P8.5.8.3
Verify that the DUT immediately stops sending ARP announces and/or probes
P8.5.8.4
Verify that the DUT exhibits IP conflict. If the DUT supports NS LED, verify that the
DUT sets the NS LED to solid red
P8.5.8.5
If the DUT supports MS LED, verify that the DUT flashes the MS LED red
P8.5.9Verification of LastConflictDetected attribute for devices supporting ACD per Vol.2,
Appendix F
P8.5.9.1
Power cycle the DUT
P8.5.9.2
Wait until the DUT has transmitted its second ARP Announce frame
P8.5.9.3
Use a Set_Attribute_Single to set class 0xF5 (TCP/IP Interface Object), instance 1,
attribute 11 (LastConflictDetected) to all zeros. Allow up to 60 seconds (or more) for
the DUT to become accessible via CIP messaging.
P8.5.9.4
Use a Get_Attribute_Single to read class 0xF5, instance 1, attribute 11 and verify
that it is all zeros
P8.5.9.5
Send an ARP announce with Sender IP address equal to the IP address used by theDUT
P8.5.9.6
Power cycle the DUT
P8.5.9.7
Wait until the DUT has transmitted its second ARP Announce frame
P8.5.9.8
Use a Get_Attribute_Single to read class 0xF5, instance 1, attribute 11 and verify
that the contents of the LastConflictDetected attribute match the ARP announce
used to generate the conflictP8.5.10
Verification that IP address conflict isn’t declared between announce frames
P8.5.10.1 Power cycle the DUT
P8.5.10.2 During the announce phase, between announce 1 and 2, send an ARP announcewith Sender IP address equal to the IP address used by the DUT
P8.5.10.3 Verify that the DUT keeps and defends its IP address
P8.5.10.4 Verify the contents of each ARP field in the defending ARP announce frame
P8.5.10.5 Verify that the DUT doesn’t declare a conflictP8.5.11
Verification of ACD defend
P8.5.11.1 Power cycle the DUT and wait until the initial probe and announce phase has passed
P8.5.11.2 Wait for 3s (so the DEFEND_INTERVAL has elapsed)
Publication PUB00095

18

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP8.5.11.3

Send an ARP announce with Sender IP address equal to the IP address used by theDUT
P8.5.11.4 Verify that the DUT sends ARP announce (defending its IP address)
P8.5.11.5 Verify that all fields in the ARP announce are correct
P8.5.11.6 Verify that the DUT doesn’t declare a conflictP8.5.12
Verification of IP address conflict after IP address successfully has been probed
P8.5.12.1 Power cycle the DUT and wait until the initial probe and announce phase has passed
P8.5.12.2 Send a gratuitous ARP with Sender and Target IP addresses equal to the IP addressused by the DUT
P8.5.12.3 Verify that the DUT defends its IP address
P8.5.12.4 Verify that all ARP fields in the defend packet are correct
P8.5.12.5 Wait for 3 s (so the DEFEND_INTERVAL has elapsed)
P8.5.12.6 Send a gratuitous ARP with Sender and Target IP addresses equal to the IP addressused by the DUT
P8.5.12.7 Verify that the DUT defends its IP address
P8.5.12.8 Verify that all ARP fields in the defend packet are correct
P8.5.12.9 Verify that the DUT doesn’t declare a conflictP8.5.12.10 Wait for 3s (so the DEFEND_INTERVAL has elapsed)
P8.5.12.11 Send a gratuitous ARP with Sender and Target IP addresses equal to the IP addressused by the DUT
P8.5.12.12 Verify that the DUT defends its IP address
P8.5.12.13 Verify that all ARP fields in the defend packet are correct
P8.5.12.14 Wait for 1s(so the next DEFEND_INTERVAL has not elapsed yet)P8.5.12.15 Send a gratuitous ARP with Sender and Target IP addresses equal to the IP addressused by the DUT
P8.5.12.16 Verify that the DUT exhibits IP conflict. If the DUT supports NS LED, verify that the
DUT sets the NS LED to solid red
P8.5.12.17 If the DUT supports MS LED, verify that the DUT flashes the MS LED red
P8.5.13
Verification that IP address isn’t used when conflict has been declaredP8.5.13.1 Power cycle the DUT and wait until the initial probe and announce phase has passed
P8.5.13.2 Generate a conflict so the DUT ceases using its IP address
P8.5.13.3 Send an ARP request to the DUT
P8.5.13.4 Verify that the DUT does not respond to the ARP request
P8.5.14
Verification that directed ARP during probe phase does not cause a conflictP8.5.14.1 Power cycle the DUT
P8.5.14.2 During the probe phase, between probe 1 and 4, send a directed ARP request with
Sender IP address equal to 0.0.0.0 and with the DUT’s MAC address as thedestination MAC address
P8.5.14.3 Verify that the DUT does not declare a conflictP8.5.15
Verification of directed ARP response in ongoing detection
P8.5.15.1 Power cycle the DUT
P8.5.15.2 Wait until the DUT has transmitted its second ARP announce frame
Publication PUB00095

19

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP8.5.15.3

Send a directed ARP request with Sender IP address equal to 0.0.0.0 and with the
DUT’s MAC address as the destination MAC address
P8.5.15.4 Verify that the DUT responds to the ARP request
P8.5.15.5 Wait for 1s (so the DEFEND_INTERVAL has not elapsed yet)P8.5.15.6 Send a directed ARP request with Sender IP address equal to 0.0.0.0 and with the
DUT’s MAC address as the destination MAC address
P8.5.15.7 Verify that the DUT responds to the ARP request
P8.5.15.8 Verify that the DUT does not declare a conflictP8.5.16
Verification of IP address conflict detection during probe phase – ARP probe
P8.5.16.1 Power cycle the DUT
P8.5.16.2 During the probe phase, between probe 1 and 4, test tool shall send a broadcast
ARP probe with Sender IP address equal to the IP address used by the DUT
P8.5.16.3 Verify that the DUT immediately stops sending ARP announces and/or probes
P8.5.16.4 Verify that the DUT exhibits IP conflict. If the DUT supports NS LED, verify that the
DUT sets the NS LED to solid red
P8.5.16.5 If the DUT supports MS LED, verify that the DUT flashes the MS LED red

Publication PUB00095

20

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

9

Common Interoperability Test

The test is intended to determine the minimum set of interoperability functional requirements for all
EtherNet/IP devices. A proposed test setup is shown in Figure 5. This test MUST be successfullycompleted before proceeding to further tests.
Software needed for this test. See section 4, Software and Tool Versions for specific version information:




P9

EDITT
DHCP Server
Optional – Wireshark (used if debugging is necessary)Common Interoperability Test ProcedureDefault Class 3 Connection Parameters
Class 3 connections in this section should be opened with the following parameters unless they
are specified in the test case:
RPI 250ms
Timeout multiplier 4
Priority Low

P9.1

Verify support for 3 concurrent encapsulation sessions.
Open 3 encap sessions to the DUT using 3 independent network interfaces.
Send a Get_Attribute_Single request to an Identity Object attribute over each encap
session and verify a successful response from each request.

P9.2

Verify support for concurrent connected and unconnected messaging on an encapsulation
session.
Open a class 3 connection to the DUT and send a Get_Attribute_Single command torequest an Identity Object attribute. Use a connection RPI of 250 ms and a timeout
multiplier of 4.
Send an unconnected CIP message over the same encap session containing a
Get_Attribute_Single request to the same Identity Object attribute. Repeat the request
every 500 ms.
Maintain the messaging and connection for 1 minute.
Verify that there are no connection or response timeouts.

P9.1.1P9.1.2P9.2.1P9.2.2P9.2.3P9.2.4

P9.3

Verify support for concurrent connected and unconnected messaging on multiple
encapsulation sessions.
P9.3.1
Using a Scanner or test tool, generate request messages to read attributes from the
Identity object of the DUT using the following configuration.
P9.3.1.1
Six separate, and concurrent, CIP transport class 3 connections from three
independent network interfaces of the reference Scanner to two separate attributes

Publication PUB00095

21

Version 9 PR002

EtherNet/IP Interoperability Test Proceduresfrom the Identity object of the DUT using a Get_Attribute_Single command. Use aconnection RPI of 250 ms and a timeout multiplier of 4.
P9.3.1.2
One unconnected CIP message to a third attribute from the Identity object. This
request should be repeated every 500 ms
P9.3.2
Maintain the messaging and connections for 1 minute.
P9.3.3
Verify that there are no connection or response timeouts.

P9.4

P9.4.1

P9.4.2P9.4.3P9.4.4

If another TCP-based protocol is supported by the DUT:
Connect to the DUT using the appropriate other protocol. Connection must be madefrom a different IP address than that running the CIP connections to guarantee that a
new TCP connection is established.
Run the test described in P9.3.
Verify that there is no connection or response timeouts and that the other protocol
responds properly.
Disconnect the appropriate other protocol from the DUT.

P9.5

If another protocol is supported by the DUT (HTTP, FTP, etc.),
Run the test described in P9.3.
Connect to the DUT using the appropriate other protocol while the test is in progress.
Connection must be made from a different IP address than that running the CIP
connections to guarantee that a new TCP connection is established.
P9.5.3
Verify that there is no connection or response timeouts and that the other protocol
responds properly.
P9.5.1
P9.5.2

P9.6

If the DUT supports Module Status and Network Status LEDs, verify visually that the DUT
conforms to the EtherNet/IP Industrial Conformance Level LED behavior. This behavior canbe handled with an equivalent indicator (e.g. HMI screen). NOTE: Does not apply totransitory or PC-based devices.
P9.6.1
Verify the module status indicator behavior referring to Section 2, Normative Reference
Documents [2].
P9.6.2
Verify the network status indicator behavior referring to Section 2, Normative Reference
Documents [2].

P9.7

Support for class 3 connection priority High.
P9.7.1
Open a class 3 connection to the DUT with a priority of High and send a
Get_Attribute_Single command to request an Identity Object attribute. Use aconnection RPI of 250 ms and a timeout multiplier of 4.
P9.7.2
Maintain the messaging and connection for 30 seconds.
P9.7.3
Verify that there are no connection or response timeouts.

Publication PUB00095

22

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

10

Explicit Message Server Interoperability Test

This is a list of additional tests above and beyond the Common Interoperability Test for explicit message
server devices.

P10 Explicit Message Server Interoperability Test Procedure
P10.1
No additional tests are required.
11

Explicit Message Client Interoperability Test

This is a list of additional tests above and beyond the Common Interoperability Test for explicit message
client devices. The same test setup as shown in Figure 8 Proposed Scanner Interoperability Test Setup
can be used for this test. One of the reference adapters can be used as the explicit target node.
No software other than the software provided by the DUT manufacturer to configure its explicit
message subsystem is needed.

P11 Explicit Message Client Interoperability Test Procedure
P11.1
Unconnected Messaging
P11.1.1
P11.1.2
P11.1.3

P11.1.4

Send an unconnected explicit request from the DUT to another CIP device to retrieve
information from a suitable object within the scope of the target device's function.
Repeat the read request every 500 ms for 1 minute. Verify that there are no response
timeouts.
Send an unconnected explicit request from the DUT to another CIP device to set
information in a suitable object within the scope of the target device's function. NOTE:This test can only be performed on a target device that supports settable attributes.
Repeat the set request every 500 ms for 1 minute. Verify that there are no response
timeouts.

P11.2

Connected Messaging
Originate a CIP transport class 3 explicit connection from the DUT to the message routerof another CIP device. Use a connection RPI of 250 ms and a timeout multiplier of 4.
NOTE: The target device must support class 3 connections.
P11.2.2
Send an explicit request across the connection to retrieve information from a suitableobject within the scope of the target device’s function.
P11.2.3
Maintain the connection with the read request for 1 minute. Verify there are noconnection timeouts.
P11.2.4
Send an explicit request across the connection to set information in a suitable object
within the scope of the target device’s function. NOTE: This test can only be performed
on a target device that supports settable attributes.
P11.2.5
Maintain the connection with the set request for 1 minute. Verify there are noconnection timeouts.
P11.2.1

Publication PUB00095

23

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

12

Adapter Interoperability Test

This is a list of additional tests above and beyond the Common Interoperability Test for adapter devices.
Software needed for this test. See Section 4, Software and Tool Versions for specific version information:





EDITT
DHCP Server
Optional – Wireshark (used if debugging is necessary)

The tester shall use the connection point, RPI range and connection size info recorded in test P6.2, EDS
File Verification Test for the tests in this section. If any of the connections fail to work because theinformation derived from the EDS file in Test P6.2 was incorrect, note the discrepancy in the appropriate
test comments, and remark the EDS section “Failed”. The device may return to the EDS station with acorrected EDS file, to be retested.
If the device has not yet been to the EDS station, record the connection point information used in thistest in the EDS section of the test results form.

P12

Adapter Interoperability Test ProcedureDefault Connection Parameters
Class 3 connections in this section should be opened with the following parameters unless they
are specified in the test case:
RPI 250ms
Timeout multiplier 4
Priority Low
Class 1 connections in this section should be opened with the following parameters unless they
are specified in the test case:
RPI 100ms
Timeout multiplier 4
Priority Scheduled

P12.1

Target of CIP Transport Class 1 I/O Connections, 32-bit Real Time Header (Run/Idle Header).
P12.1.1
Bidirectional Connections, Multicast T→O and Unicast O→T, Cyclic Trigger, 32-bit RealTime Header
P12.1.1.1 For devices supporting output data
P12.1.1.1.1 Open an exclusive owner connection from the reference Scanner to the DUTwith a multicast T→O, unicast O→T, a cyclic trigger type, and a 32-bit Real Time
Header in the O→T direction. Use a connection RPI of 100ms with a timeout

Publication PUB00095

24

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
multiplier of 4 and a connection priority of Scheduled. Include appropriate
configuration data in the fwd_open data segment.
P12.1.1.2 For input-only devices
P12.1.1.2.1 Open an input only connection from the reference Scanner to the DUT with amulticast T→O, a cyclic trigger type. Use a connection RPI of 100ms with atimeout multiplier of 4 and a connection priority of Scheduled. Include
appropriate configuration data in the fwd_open data segment.
P12.1.1.3 Verify that the connection is established with no errors and can send data.
P12.1.1.4 Maintain the connection for 30 seconds and verify there are no connection
timeouts.
P12.1.1.5 For devices supporting output data
P12.1.1.5.1 Put the connection in Idle state by clearing bit 0 of the 32-bit Real Time Header.
P12.1.1.5.2 Verify that the DUT exhibits Idle state behavior.
P12.1.1.5.3 Put the connection in Run state by setting bit 0 of the 32-bit Real Time Header.
P12.1.1.5.4 Verify that the DUT exhibits Run state behavior.
P12.1.1.5.5 Return the connection to Idle state by clearing bit 0 of the 32-bit Real Time
Header.
P12.1.1.5.6 Verify that the DUT exhibits Idle state behavior.
P12.1.2
Change of State (COS) Connections. (Optional for non-discrete devices and for rackconnections on rack-based devices)
P12.1.2.1 For devices supporting output data
P12.1.2.1.1 Open an exclusive owner connection from the reference Scanner to the DUTwith a multicast T→O, unicast O→T, a COS trigger, non-zero PIT, and a 32-bit
Real Time Header in the O→T direction. Use a connection RPI of 100ms with atimeout multiplier of 4. Include appropriate configuration data in the fwd_open
data segment.
P12.1.2.2 For input-only devices
P12.1.2.2.1 Open an input only connection from the reference Scanner to the DUT with amulticast T→O, a COS trigger, non-zero PIT. Use a connection RPI of 100ms witha timeout multiplier of 4. Include appropriate configuration data in the
fwd_open data segment.
P12.1.2.3 Verify that the connection is established with no errors and can send data.
P12.1.2.4 Maintain the connection for 30 seconds and verify there are no connection
timeouts.
P12.1.2.5 For devices supporting output data
P12.1.2.5.1 Put the connection in Idle state by clearing bit 0 of the 32-bit Real Time Header.
P12.1.2.5.2 Verify that the DUT exhibits Idle state behavior.
P12.1.2.5.3 Put the connection in Run state by setting bit 0 of the 32-bit Real Time Header.
P12.1.2.5.4 Verify that the DUT exhibits Run state behavior.
P12.1.2.5.5 Return the connection to Idle state by clearing bit 0 of the 32-bit Real Time
Header.
P12.1.2.5.6 Verify that the DUT exhibits Idle state behavior.
Publication PUB00095

25

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP12.1.3

Bidirectional Connections, Unicast T→O and Unicast O→T, Cyclic Trigger, 32-bit RealTime Header
P12.1.3.1 For devices supporting output data
P12.1.3.1.1 Open an exclusive owner connection from the reference Scanner to the DUTwith unicast T→O and unicast O→T, a cyclic trigger type, and a 32-bit Real Time
Header in the O→T direction. Use a connection RPI of 100ms with a timeout
multiplier of 4. Include appropriate configuration data in the fwd_open data
segment.
P12.1.3.2 For input-only devices
P12.1.3.2.1 Open an input only connection from the reference Scanner to the DUT withunicast T→O, a cyclic trigger type. Use a connection RPI of 100ms with atimeout multiplier of 4. Include appropriate configuration data in the fwd_open
data segment.
P12.1.3.3 Verify that the connection is established with no errors and can send data.
P12.1.3.4 Maintain the connection for 30 seconds and verify there are no connection
timeouts.

P12.2

Target of 2 CIP Transport Class 1 I/O Connections, Exclusive Owner Connection, Listen Onlyor Input Only Connection
P12.2.1
Multicast T→O on all connections
P12.2.1.1 For devices supporting output data
P12.2.1.1.1 Open a CIP transport class 1 I/O Exclusive Owner connection from one interfaceof the reference Scanner to the DUT with multicast T→O and unicast O→T. Usea connection RPI of 100ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.2.1.2 For input-only devices
P12.2.1.2.1 Open a CIP transport class 1 I/O Input Only connection from one interface of thereference Scanner to the DUT with multicast T→O and unicast O→T. Use aconnection RPI of 100ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.2.1.3 Open a CIP transport class 1 I/O Input Only or Listen Only connection from anotherinterface of the reference Scanner to the same input connection point as used by
the Exclusive Owner (or Input Only) connection above on the DUT with multicast
T→O and unicast O→T. Use a connection RPI of 100 ms with a timeout multiplier of
4. Include appropriate configuration data in the fwd_open data segment. NOTE:
The choice of Input Only or Listen Only depends on the capabilities of the DUT.
P12.2.1.4 Verify that both connections are established with no errors and can send data.
P12.2.1.5 Maintain both connections for 30 seconds and verify there are no connection
timeouts.
P12.2.2
Multicast T→O on owning connection, Unicast T→O on second connection
P12.2.2.1 For devices supporting output data

Publication PUB00095

26

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP12.2.2.1.1

Open a CIP transport class 1 I/O Exclusive Owner connection from one interfaceof the reference Scanner to the DUT with multicast T→O and unicast O→T. Usea connection RPI of 100 ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.2.2.2 For input-only devices
P12.2.2.2.1 Open a CIP transport class 1 I/O Input Only connection from one interface of thereference Scanner to the DUT with multicast T→O and unicast O→T. Use aconnection RPI of 100 ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.2.2.3 Open a CIP transport class 1 I/O Input Only or Listen Only connection from anotherinterface of the reference Scanner to the same input connection point as used by
the Exclusive Owner (or Input Only) connection above on the DUT with unicast T→Oand unicast O→T. Use a connection RPI of 100 ms with a timeout multiplier of 4.
Include appropriate configuration data in the fwd_open data segment.
P12.2.2.4 Verify that both connections are established with no errors and can send data.
P12.2.2.5 Maintain both connections for 30 seconds and verify there are no connection
timeouts.
P12.2.3
Unicast T→O on all connections
P12.2.3.1 For devices supporting output data
P12.2.3.1.1 Open a CIP transport class 1 I/O Exclusive Owner connection from one interfaceof the reference Scanner to the DUT with unicast T→O and unicast O→T. Use aconnection RPI of 100 ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.2.3.2 For input-only devices
P12.2.3.2.1 Open a CIP transport class 1 I/O Input Only connection from one interface of thereference Scanner to the DUT with unicast T→O and unicast O→T. Use aconnection RPI of 100 ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.2.3.3 Open a CIP transport class 1 I/O Input Only or Listen Only connection from anotherinterface of the reference Scanner to the same input connection point as used by
the Exclusive Owner (or Input Only) connection above on the DUT with unicast
T→Oand unicast O→T. Use a connection RPI of 100 ms with a timeout multiplier of
4. Include appropriate configuration data in the fwd_open data segment.
P12.2.3.4 Verify that both connections are established with no errors and can send data.
P12.2.3.5 Maintain both connections for 30 seconds and verify there are no connection
timeouts.
P12.2.4
Unicast T→O owning, Multicast T→O on second connection
P12.2.4.1 For devices supporting output data
P12.2.4.1.1 Open a CIP transport class 1 I/O Exclusive Owner connection from one interfaceof the reference Scanner to the DUT with unicast T→O and unicast O→T. Use aconnection RPI of 100 ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
Publication PUB00095

27

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP12.2.4.2 For input-only devices
P12.2.4.2.1 Open a CIP transport class 1 I/O Input Only connection from one interface of thereference Scanner to the DUT with unicast T→O and unicast O→T. Use aconnection RPI of 100 ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.2.4.3 Open a CIP transport class 1 I/O Input Only or Listen Only connection from anotherinterface of the reference Scanner to the same input connection point as used by
the Exclusive Owner (or Input Only) connection above on the DUT with multicast
T→Oand unicast O→T. Use a connection RPI of 100 ms with a timeout multiplier of
4. Include appropriate configuration data in the fwd_open data segment.
P12.2.4.4 Verify that both connections are established with no errors and can send data.
P12.2.4.5 Maintain both connections for 30 seconds and verify there are no connection
timeouts.

Publication PUB00095

28

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP12.2.5
Support of 6 Class 3 connections simultaneously with 2 Class 1 connections
P12.2.5.1 For devices supporting output data
P12.2.5.1.1 Open a CIP transport class 1 I/O Exclusive Owner connection from one interfaceof the reference Scanner to the DUT with multicast T→O and unicast O→T. Usea connection RPI of 100ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.2.5.2 For input-only devices
P12.2.5.2.1 Open a CIP transport class 1 I/O Input Only connection from one interface of thereference Scanner to the DUT with multicast T→O and unicast O→T. Use aconnection RPI of 100ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.2.5.3 Open a CIP transport class 1 I/O Input Only or Listen Only connection from anotherinterface of the reference Scanner to the same input connection point as used by
the Exclusive Owner (or Input Only) connection above on the DUT with multicast
T→O and unicast O→T. Use a connection RPI of 100 ms with a timeout multiplier of
4. Include appropriate configuration data in the fwd_open data segment. NOTE:
The choice of Input Only or Listen Only depends on the capabilities of the DUT.
P12.2.5.4 Open 6 separate, and concurrent, CIP transport class 3 connections from three
independent network interfaces of the reference Scanner to two separate attributes
from the Identity object of the DUT using a Get_Attribute_Single command. Use aconnection RPI of 250 ms and a timeout multiplier of 4.
P12.2.5.5 Verify that all 8 connections are established with no errors and can send data.
P12.2.5.6 Maintain all connections for 1 minute and verify there are no connection timeouts.
P12.2.6
Support for Class 1 connection priority HighP12.2.6.1 For devices supporting output data
P12.2.6.1.1 Open a CIP transport class 1 I/O Exclusive Owner connection from one interfaceof the reference Scanner to the DUT with multicast T→O and unicast O→T. Usea connection RPI of 100ms with a timeout multiplier of 4 and a connection
priority of High. Include appropriate configuration data in the fwd_open data
segment.
P12.2.6.2 For input-only devices
P12.2.6.2.1 Open a CIP transport class 1 I/O Input Only connection from one interface of thereference Scanner to the DUT with multicast T→O and unicast O→T. Use aconnection RPI of 100ms with a timeout multiplier of 4 and a connection priorityof High. Include appropriate configuration data in the fwd_open data segment.
P12.2.6.3 Verify that connection is established with no errors and can send data.
P12.2.6.4 Maintain all connections for 30 seconds and verify there are no connection
timeouts.

Publication PUB00095

29

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

P12.3

Electronic Keys
P12.3.1
Non-Null Electronic Key
P12.3.1.1 Open a connection from the reference Scanner to the DUT with an exact match
electronic key segment.
P12.3.1.2 Verify that the connection is established with no errors and can be maintained for
15 seconds.
P12.3.1.3 Close the connection
P12.3.1.4 Open a connection from the reference Scanner to the DUT with an electronic key
segment with invalid (non-matching) information.
P12.3.1.5 Verify that the connection is rejected.
P12.3.2
Null Electronic Key
P12.3.2.1 Open a connection from the reference Scanner to the DUT with a null electronic key(all key field values are 0) segment.
P12.3.2.2 Verify that the connection is established with no errors and can be maintained for
15 seconds.
P12.3.2.3 Close the connection
P12.3.3
No Electronic Key
P12.3.3.1 Open a connection from the reference Scanner to the DUT with no electronic key
segment.
P12.3.3.2 Verify that the connection is established with no errors and can be maintained for
15 seconds.
P12.3.3.3 Close the connection

P12.4

Configuration Path – NOTE: Informational for rack-based devices.
P12.4.1
Non-Null Configuration Data
P12.4.1.1 For devices supporting configuration data, verify acceptance of configuration data
P12.4.1.1.1 For devices supporting output data
12.4.1.1.1.1 Open an Exclusive Owner connection from the reference Scanner to the DUTwith a non-null configuration data segment. The size and content of the data
shall be valid for the device configuration requirements.
12.4.1.1.1.2 Verify that the connection is established with no errors and can be maintainedfor 15 seconds.
12.4.1.1.1.3 Close the connection
P12.4.1.1.2 For devices supporting an Input Only connection
12.4.1.1.2.1 Open an Input Only connection from the reference Scanner to the DUT with a
non-null configuration data segment. The size and content of the data shall bevalid for the device configuration requirements.
12.4.1.1.2.2 Verify that the connection is established with no errors and can be maintainedfor 15 seconds
12.4.1.1.2.3 Close the connection
P12.4.1.2 For all devices, verify rejection of invalid configuration data size
P12.4.1.2.1 For devices supporting output data

Publication PUB00095

30

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
12.4.1.2.1.1 Open an Exclusive Owner connection from the reference Scanner to the DUTwith a non-null configuration data segment. The size of the data is non-zeroand arbitrary but must be invalid for the device.
12.4.1.2.1.2 Verify that the connection is rejected.
P12.4.1.2.2 For devices supporting an Input Only connection
12.4.1.2.2.1 Open an Input Only connection from the reference Scanner to the DUT with a
non-null configuration data segment. The size of the data is non-zero andarbitrary but must be invalid for the device.
12.4.1.2.2.2 Verify that the connection is rejected.
P12.4.2
Null Configuration Data
P12.4.2.1 For devices supporting output data
P12.4.2.1.1 Open an Exclusive Owner connection from the reference Scanner to the DUTwith a null configuration data segment (e.g. data size of zero). A configuration
path must be present in the fwd_open.
P12.4.2.1.2 Verify that the connection is established with no errors and can be maintainedfor 15 seconds
P12.4.2.1.3 Close the connection
P12.4.2.2 For devices supporting an Input Only connection
P12.4.2.2.1 Open an Input Only connection from the reference Scanner to the DUT with anull configuration data segment (e.g. data size of zero).A configuration pathmust be present in the fwd_open.
P12.4.2.2.2 Verify that the connection is established with no errors and can be maintainedfor 15 seconds.
P12.4.2.2.3 Close the connection
P12.4.3
No Configuration Data
P12.4.3.1 For devices supporting output data
P12.4.3.1.1 Open an Exclusive Owner connection from the reference Scanner to the DUTwith no configuration data segment. A configuration path is optional in the
fwd_open.
P12.4.3.1.2 Verify that the connection is established with no errors and can be maintainedfor 15 seconds.
P12.4.3.1.3 Close the connection
P12.4.3.2 For devices supporting an Input Only connection
P12.4.3.2.1 Open an Input Only connection from the reference Scanner to the DUT with noconfiguration data segment. A configuration path is optional in the fwd_open.
P12.4.3.2.2 Verify that the connection is established with no errors and can be maintainedfor 15 seconds.
P12.4.3.2.3 Close the connection

P12.5

P12.5.1

Series of CIP Transport Class 1 I/O Connections, Heartbeat Connection, multicast T→O only
Using the table below, open a connection from one interface of the reference Scannerto the DUT with the connection type listed in the first column of the table. Include

Publication PUB00095

31

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP12.5.2

P12.5.3

appropriate configuration data in the fwd_open data segment. NOTE: Use a heartbeat
connection in the O→T direction for IO and LO connections. Use a connection RPI of
100 ms and a timeout multiplier of 4.All T→O connections are multicast. NOTE: Inputonly devices that do not support EO connections will only utilize rows of the tablewithout EO entries.
Open a connection from another interface of the reference Scanner to the same input
connection point of the DUT with the connection type listed in the second column of thetable. Use a connection RPI of 100ms and a timeout multiplier of 4. All T→O connections
are multicast. Include appropriate configuration data in the fwd_open data segment.
NOTE: Use a heartbeat connection in the O→T direction for IO and LO connections.
NOTE: Input-only devices that do not support EO connections will only utilize rows of
the table without EO entries.
Verify that the connection establishment success matches that indicated in thefollowing table.
Table 1 Connection Combinations Attempted with the DUT

1st Connection
IO
IO
IO
EO
EO
EO
LO

P12.5.4
P12.5.5

2nd Connection
w/ Same Input Point
EO
IO
LO
IO
LO
EO
-

Expected Result
Success
Success
Success
Success
Success
Error
Error

If connections were established, maintain the connections for 30 seconds and verify
there are no connection timeouts.
Referring to the following table, test the DUT behavior when the first connection isclosed, and when it is timed out. Verify that the second connection in the DUT behaves
as indicated in the following table.

Publication PUB00095

32

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Table 2 Behavior of 2nd I/O Connection

1stConnection
IO

2nd Connection
w/ Same Input
Point
EO

IO

IO

IO

LO

EO

IO

EO

LO

EO
LO

EO
-

Expected Behavior of 2nd Connection When:
1st Connection TimesOut 1stConnectionIs Closed
EO stays open
(Data continues)
2nd IO stays open
(Data continues)
LO closes(Data stops)
IO closes(Data stops)*
LO closes(Data stops)
Not Applicable
Not Applicable

EO stays open
(Data continues)
2nd IO stays open
(Data continues)
LO closes(Data stops)
IO stays open
(Data continues)
LO closes(Data stops)
Not Applicable
Not Applicable* The IO connection is closed to guarantee that the owner of the EO is no longer
receiving multicast data; making it clear to the owner that the output data is not making
it to the adapter. (Refer to specification Edition 3.1, section 3-6.4.3)

P12.6

Configuration Parameters via Explicit Messaging
NOTE: This does not apply to rack-based, technology enabler, or devices with user-defined
I/O data content (e.g. EtherNet/IP to other network gateway, target connections of a PLC).
P12.6.1
Send an explicit request from the CIP tool to the DUT to retrieve data from several
configuration parameters. NOTE: These may, or may not, be accessible via theParameter object. Parameters used for the test will be specified by the vendor andshould be in the EDS.
P12.6.2
Send an explicit request from the CIP tool to the DUT to set data for several writableconfiguration parameters. Read the parameters back and verify that the value iscorrect. NOTE: These may, or may not, be accessible via the Parameter object.
Parameters used for the test will be specified by the vendor and should be in the EDS.

P12.7

I/O Data Attributes via Explicit Messaging
P12.7.1
For devices supporting output data
P12.7.1.1 Open an Exclusive Owner I/O connection from the reference Scanner to the DUT.
P12.7.2
For input-only devices
P12.7.2.1 Open an Input Only connection from the reference Scanner to the DUT.
P12.7.3
Send an explicit read request (using unconnected or connected class 3) from thereference Scanner to the DUT to retrieve data from the I/O assembly objects associatedwith the connection established above. (Attribute 3).
P12.7.3.1 Input Data
P12.7.3.2 Output Data (only for devices supporting output data)

Publication PUB00095

33

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP12.7.4

Verify that the data is consistent between the class 1 connection and the explicit
request.
P12.7.4.1 Input data must be the same size
P12.7.4.2 Output data must be the same size and same data content
P12.7.5
For devices supporting output data
P12.7.5.1 Send an explicit request (using unconnected or connected class 3) from thereference Scanner to the DUT to write data to the output assembly object
associated with the connection established above.
P12.7.5.2 Verify that an error response is returned to the explicit request.
P12.7.6
Close the class 1 connection.
P12.7.7
For devices supporting output data
P12.7.7.1 Send an explicit request (using unconnected or connected class 3) from thereference Scanner to the DUT to write data to the output assembly object.
P12.7.7.2 Verify that the write request succeeds. Verify that the DUT responds accordingly tothe data written.

P12.8
P12.9

DeletedVerify that connection information recorded on the Test Results form from the Online EDS
file test (section P6.2.4) is valid for this test. If they are not valid, the device vendor must
repair the misinformation in the EDS and repeat the EDS file test. Record on the test results
form, the actual values used, if different than what was recorded in section P6.2.4. NOTE: If
the EDS section of the Test Results form has not yet been filled in, enter the connection
information used in the Adapter test.

Publication PUB00095

34

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP12.10Connection Handling through Ethernet Link Loss
P12.10.1.1 For devices supporting output data
P12.10.1.1.1 Open a CIP transport class 1 I/O Exclusive Owner connection from one interfaceof the reference Scanner to the DUT with multicast T→O and unicast O→T. Usea connection RPI of 100ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.10.1.2 For input-only devices
P12.10.1.2.1 Open a CIP transport class 1 I/O Input Only connection from one interface of thereference Scanner to the DUT with multicast T→O and unicast O→T. Use aconnection RPI of 100ms with a timeout multiplier of 4. Include appropriate
configuration data in the fwd_open data segment.
P12.10.1.3 Open a CIP transport class 1 I/O Input Only or Listen Only connection from anotherinterface of the reference Scanner to the same input connection point as used by
the Exclusive Owner (or Input Only) connection above on the DUT with multicast
T→O and unicast O→T. Use a connection RPI of 100 ms with a timeout multiplier of
4. Include appropriate configuration data in the fwd_open data segment. NOTE:
The choice of Input Only or Listen Only depends on the capabilities of the DUT.
P12.10.1.4 Open 6 separate, and concurrent, CIP transport class 3 connections from three
independent network interfaces of the reference Scanner to two separate attributes
from the Identity object of the DUT using a Get_Attribute_Single command. Use aconnection RPI of 250 ms and a timeout multiplier of 4.
P12.10.1.5 Verify that all 8 connections are established with no errors and can send data.
P12.10.1.6 Maintain all connections for 10 seconds and verify there are no connection
timeouts.
P12.10.1.7 Disconnect the Ethernet cable from the DUT for 5 seconds and reconnect.
P12.10.1.8 Verify that all 8 connections resume.
P12.10.1.9 Maintain all connections for 10 seconds and verify there are no connection
timeouts.
P12.10.1.10Disconnect the Ethernet cable from the DUT for 30 seconds and reconnect.
P12.10.1.11Verify that all 8 connections resume.
P12.10.1.12Maintain all connections for 10 seconds and verify there are no connection
timeouts.
P12.10.1.13Disconnect the Ethernet cable from the DUT for 3 minutes and reconnect.
P12.10.1.14Verify that all 8 connections resume.
P12.10.1.15Maintain all connections for 10 seconds and verify there are no connection
timeouts.

Publication PUB00095

35

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

13

Scanner Interoperability Test

This is a list of additional tests above and beyond the Common Interoperability Test for scanner devices.
If the scanner device includes adapter functionality, then the adapter interoperability tests MUST be
performed first. A proposed test setup is shown in Figure 8 Proposed Scanner Interoperability Test
Setup.
Suggested Target Adapters
Seven of the target adapters are HMS Anybus Communicator modules. These so-called Reference
Adapters are used in this test and can be used as general purpose target adapters or explicit servers inother tests, as needed.
At least one of the target adapters to be used for the following test procedure must have the following
abilities:
Indication of connection establishment and loss
Indication of Run/Idle status
Ability to change input data being sent to the scanner
Ability to display output data being received from the scanner
Additional/alternative adapters that can satisfy these requirements are acceptable.
Software needed for this test. See section 4, Software and Tool Versions for specific version information:



P13

Wireshark
CIP Tool

Scanner Interoperability Test Procedure

The proposed setup for this test is shown in Figure 8 Proposed Scanner Interoperability Test Setup.
Software needed for this test is listed below. See Section 4, Software and Tool Versions for specificversion information:

Optional – Wireshark
Software to configure the managed switch, provided by the switch vendor.

P13.1

Originator of CIP Transport Class 1 I/O Connections, 32-bit real time Header(Run/Idle
Header)P13.1.1
Bidirectional Connections, Multicast T→O and Unicast O→T, Cyclic Trigger, 32-bit realtime Header

Publication PUB00095

36

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP13.1.1.1

Open a connection from the DUT to the reference Adapter with a multicast T→Oand unicast O→T, a cyclic trigger type, and a 32-bit real time Header. Use aconnection RPI of 100ms and a timeout multiplier of 4.
P13.1.1.2 Verify that the connection is established with no errors
P13.1.1.3 Have the DUT put the connection in a Run state using the 32-bit real time Header.
P13.1.1.4 Verify data changes at the DUT are reflected in the target adapter output data.
Verify data changes in the target adapter input data are reflected at the DUT.
P13.1.1.5 Maintain the connection for 30 seconds and verify that there are no connection
timeouts.
P13.1.1.6 Have the DUT put the connection in an idle state using the 32-bit real time Header.
P13.1.1.7 Verify that the reference Adapter exhibits idle behavior.
P13.1.2
Unidirectional Connections, currently not tested
P13.1.3
Informational: Change of State (COS) with Production Inhibit Timer (PIT).
P13.1.3.1 Open a connection from the DUT to the reference Adapter with a COS trigger and
PIT set to non-zero. Use a connection RPI of 100 ms and a timeout multiplier of 4.
P13.1.3.2 Verify that the connection is established with no errors and can send data.
P13.1.3.3 Maintain the connection for 30 seconds and verify that there are no connection
timeouts.
P13.1.4
Bidirectional Connections, Unicast T→O and Unicast O→T, Cyclic Trigger, 32-bit realtime Header
P13.1.4.1 Open a connection from the DUT to the reference Adapter with unicast T→O andunicast O→T. Use a connection RPI of 100 ms and a timeout multiplier of 4.
P13.1.4.2 Verify that the connection is established with no errors and can send data.
P13.1.4.3 Have the DUT put the connection in a Run state using the 32-bit real time Header.
P13.1.4.4 Verify data changes at the DUT are reflected in the target adapter output data.
Verify data changes in the target adapter input data are reflected at the DUT.
P13.1.4.5 Maintain the connection for 30 seconds and verify that there are no connection
timeouts.
P13.1.4.6 Have the DUT put the connection in an idle state using the 32-bit real time Header.
P13.1.4.7 Verify that the reference Adapter exhibits idle behavior.

P13.2

Originator of 8 CIP Transport Class 1 I/O Connections, Exclusive Owner Connection, Listen
Only or Input Only Connection, Explicit Messaging
P13.2.1
Open 8 CIP transport class 1 I/O connections from the DUT to the reference Adapter(s)with a cyclic trigger type, 100 ms RPI, and 32-bit real time header. Use a connection RPIof 100 ms and a timeout multiplier of 4. The connections should be as follows:
P13.2.1.1 1 CIP transport class 1 I/O Exclusive Owner connection with a configuration data
segment (size to be determined by the target device, ≤ 400 Bytes).
P13.2.1.2 2 CIP transport class 1 I/O Input Only or Listen Only connections with heartbeat
connections in the O→T direction.
P13.2.1.3 5 additional transport class 1connections. Note that these connections can be of
any format and data size.

Publication PUB00095

37

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP13.2.2
P13.2.3

Verify the connections are established with no errors.
Maintain the connections for 30 seconds and verify that there are no connection
timeouts.
P13.2.4
While the connections are active, send an explicit message from the CIP tool to the DUT
requesting the data being scanned in the above connections. NOTE: The class, instance,
and attribute for this message are to be specified by the scanner vendor.
P13.2.5
Adapter reset tests
P13.2.5.1 Maintaining all connections and messages from P13.2.1, reset all 8 reference
adapters by powering them off and back on.
P13.2.5.2 Verify that all connections and messages resume after the adapters come backonline.

P13.3

IGMP v2
P13.3.1
Attach a packet sniffer to a mirror port on the network switch. Setup the packet sniffer
to filter on IGMP packets.
P13.3.2
Clear the multicast group table in the network switch.
P13.3.3
Open a CIP transport class 1 multicast I/O connection from the DUT to the reference
Adapter.
P13.3.4
Verify that the DUT issued a join to the network switch for the appropriate multicast
group.
P13.3.5
Close the connection.
P13.3.6
Verify that the DUT issued a leave to the network switch for the appropriate multicast
group.

P13.4

If the DUT has adapter capabilities, run the Adapter Interoperability Test Procedure as
described in section P12.

Publication PUB00095

38

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

14

System Interoperability Test

This test is intended to determine if the DUT behaves properly in a system of EtherNet/IP devices. A
proposed setup is shown in Figure 6.
If the device passes the Common Interoperability Test and the relevant additional tests, it will be tested
along with a set of other devices in a larger System Interoperability Test. This test may uncoverproblems that did not occur during the individual device testing due to the larger number of devices andEtherNet/IP network traffic, or different vendor’s implementations. A device can pass all of the relevant
individual tests but may still fail the System Interoperability Test. The EtherNet/IP Interoperability
Advisory Test will be considered failed if any problem occurs during the System Interoperability Testingthat prevents interoperability with other devices.
The test procedure and system model outlined below is provided as a general guideline. The actual
configuration will be determined by the Plug Fest Committee after event registration is closed andbefore the event. The Committee will make a best effort configuration for coverage of interoperability
concerns. The resulting configuration will be sent to all scanner vendors, who will be responsible forcreating their part of the documented configuration. Scanner vendors are expected to arrive at theevent as prepared as possible for the documented configuration and any changes that may take place.
The flow of the system test for each system test configuration follows this general process:1) Configure all nodes for multicast and turn off IGMP Snooping (P14.1)

a. Run sustained tests at fastest RPIs allowed (P14.3)
b. Run disturbance tests (P14.4-P14.7)
2) If any devices fail tests with IGMP Snooping off, reconfigure switch to turn on IGMP Snooping(P14.8)a. Repeat sustained tests at fastest RPI settings (P14.3)
b. Run disturbance tests (P14.4-P14.7)

3) Configure all nodes for unicast (P14.9)

a. Repeat sustained tests at fastest RPI settings (P14.3)
b. Run disturbance tests (P14.4-P14.7)
Software needed for this test is listed below. See Section 4, Software and Tool Versions for specificversion information:Optional – Wireshark
Software to configure the managed switch, provided by the switch vendor
Other software specific to the DUTs, as necessary. Provided by DUT vendors.

Publication PUB00095

39

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

P14 System Interoperability Test Procedure
P14.1“Out-of-Box” network startup
P14.1.1
P14.1.2
P14.1.3

P14.1.4

Return all EtherNet/IP devices to their “out-of-box” configuration.
Configure the DHCP server for all EtherNet/IP devices on same subnet.Power-cycle all
EtherNet/IP devices.
Verify that all EtherNet/IP devices obtained the correct IP address from the DHCP
server. Suggested procedure: Use RSWho to verify that all devices appear on the
network at the expected IP addresses.
Configure infrastructure switch(es) to disable IGMP Snooping

P14.2

Group devices into cells (The actual configuration to be determined by the Plug Fest
Committee prior to the initiation of the system test.)
P14.2.1
Only one scanner per cell group. Figure 6 shows three scanners: Scanner A, Scanner B,
and Scanner C. NOTE: It may be necessary to have multiple identical scanners if thenumbers of adapters exceeds the maximum number of adapters per cell group.
P14.2.2
No more than 8 adapters per cell group. At least one group with the full 8 adapters.
Figure 6 shows three groups of adapters associated with the three scanners: Group X1Xn, Group Y1-Ym, and Group Z1-Z8. Groups X and Y may have less than or equal to 8
adapters associated with them (n ≤ 8 & m ≤ 8).

P14.3

System messaging tests
P14.3.1
Inside-group system testingP14.3.1.1 Scanner opens connections to all adapters in its cell group in a step wise manner. It
is suggested that connections be added to each target one at a time to aid indetermining any problems that may occur with an individual device.
P14.3.1.1.1 CIP transport class 1 I/O exclusive owner connections to input and output
connection points. Use the fastest connection RPI supported by the device as
indicated in the device’s EDS file. Note: May need to limit RPIs so as not toexceed the capacity of the scanners in use. Devices must support 100ms or
faster to pass the system test.
P14.3.1.1.2 CIP transport class 3 connections to message routers (If the scanner supports
class 3 connections). Use a connection RPI of 250 ms and timeout multiplier of4.
P14.3.1.2 Verify that all connections are established with no errors and can send data.
P14.3.2
Outside-group system testingP14.3.2.1 Maintain connections from inside-group system testing.
P14.3.2.2 Scanner opens connections to all adapters in the next group in a step wise manner.
It is suggested that connections be added to each target one at a time to aid indetermining any problems that may occur with an individual device.
P14.3.2.2.1 CIP transport class 1 I/O input only or listen only connections to the input
connection points. Use the fastest connection RPI supported by the device, as
indicated in the device’s EDS file. Note: May need to limit RPIs so as not to

Publication PUB00095

40

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
exceed the capacity of the scanners in use. Devices must support 100ms or
faster to pass the system test.
P14.3.2.3 Informational: Scanner sends an unconnected message to each adapter in the nextgroup. Message to be repeated every 500 ms.
P14.3.2.4 Verify that all connections are established with no errors.
P14.3.3
Maintain all connections and repeated messaging for 10 minutes. Verify that there areno connection timeouts or response timeouts.

P14.4

Scanner reset tests
P14.4.1
Maintaining all connections and messages from the previous test, reset a scanner bypowering it off and back on.
P14.4.2
Verify that all connections and messages resume within 60 seconds after the scannerreceives its IP address.
P14.4.3
Repeat for each scanner in the system test.

P14.5

Adapter reset tests
Maintaining all connections and messages from the previous test, reset an adapter bypowering it off and back on.
P14.5.2
Verify that all connections and messages resume within 60 seconds after the adapter
receives its IP address.
P14.5.3
Repeat for each adapter in the system test.
P14.5.1

P14.6

Cable pull tests
P14.6.1
Maintaining all connections and messages from the previous test, disconnect the cablefrom a scanner for approximately 2 seconds then reconnect.
P14.6.2
Verify that all connections and messages resume within 120 seconds after the cable isreconnected.
P14.6.3
Repeat for each scanner in the system test.
P14.6.4
Repeat P14.6.1 through P14.6.3 but disconnect the cable for 2 minutes.

P14.7

Switch reset tests
P14.7.1
Maintaining all connections and messages from the previous test, reset an Ethernet
switch by powering it off and back on.
P14.7.2
Verify that all connections and messages resume after the switch comes back online.
P14.7.3
Repeat for each switch in the system test.

P14.8

If any devices failed P14.3 through P14.7, configure infrastructure switch(es) to enable IGMP
Snooping. If all devices passed, skip to P14.9.
P14.8.1
Repeat tests P14.3 through P14.7.

P14.9

Configure all devices for unicast I/O connections. Use the fastest connection RPI supportedby the device, as indicated in the device’s EDS file. Note: May need to limit RPIs so as not toexceed the capacity of the scanners in use. Devices must support 100ms or faster to pass
the system test.

Publication PUB00095

41

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP14.9.1

Repeat tests P14.3 through P14.7.
NOTE: The outside-group tests of section P14.3.2 may not be usable with all target
devices since they may not support concurrent unicast I/O connections. Such target
devices fail during the adapter device tests (Tests P12.2.2 and P12.2.3).

P14.10Change group assignments (Group configuration to be determined by the Plug Fest
Committee.)P14.10.1 Change scanner configuration to next group assignment.
P14.10.2 Repeat test procedures P14.3 through P14.9 for the new group assignments. NOTE: This
is to test interoperability of adapters on different scanners.

P14.11Other testing, as time permits, tests are TBD by local Plugfest committee on test day.

Publication PUB00095

42

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

15

Device Performance Test

This test is intended to verify that the DUT behaves is capable of handling network traffic under possible
conditions that may occur on a plant-floor EtherNet/IP network. A proposed test setup is shown in
Figure 7 Proposed Performance Test Setup. All devices with Adapter functionality are subject to thistest.
When setting up the performance test system, either a hardware or software scanner can be used. If a
software scanner is chosen, it is important that the scanner software not be run on the same computeras the background traffic generator. The Molex traffic generator and the EIPScan software have beenshown to load down a computer to the point of causing connection issues with the DUT.
The performance analysis tool can run on either the computer housing the network tap card or thecomputer used for the background traffic generator. If using a software scanner, the performance
analysis tool should not be run on that computer due to the process intensive analysis that will run
extremely slow while the scanner is running.
The performance tests conducted during the PlugFests are representative of some situations that may
occur on a plant floor, but are not intended to be exhaustive. More complex and rigorous testing needs
more time than allowed at the PlugFest.
The traffic amounts that were chosen for the PlugFest represent three basic categories with a total of
five tests. The first test simulates benchtop testing of a device with no extra background traffic. This isrepresents the best performance for the device and provides a baseline for the additional performance
testing being conducted. The second two tests use different amounts of background traffic in a steadystate case. This represents the case where a device is operating on a plant-floor network with a certain
number of other devices on the network. The two steady-state cases both reflect a large, flat plant-floor
network, one that uses managed switches (IGMP turned on) and one that uses unmanaged switches(IGMP turned off). The last two tests represent the situation where the managed and unmanaged
networks above have a random incident occur that causes a short spike in the network traffic load. The
incident chosen in this case is a laptop being plugged into the network with RSLinx installed andoperating. The laptop will send out an EtherNet/IP ListIdentity broadcast to every device on the
network. The devices, unless they have their ARP cache pre-populated, will respond back on the
network with an ARP request for the laptop. The result will be a short burst of ARP requests on the
network that may affect a device’s ability to maintain its Class 1 I/O connections. The burst tests also
use the managed and unmanaged steady-state background traffic.
Table 3 shows the traffic patterns for the different test cases.

Publication PUB00095

43

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

ARP Request Broadcasts
Gratuitous ARP Broadcasts
DHCP Request Broadcasts
ICMP (ping) Request Broadcasts
NTP Multicasts
EtherNet/IP ListIdentity Requests
EtherNet/IP Connected Class 1 I/O
ARP Request Burst

Burst,
Unmanaged

Burst,
ManagedSteady-State
Unmanaged

Rate

Steady-StateManagedTraffic TypeBaseline

Table 3 Traffic Amounts for Performance Tests

180 packets/s
180 packets/s
100 packets/s
100 packets/s
10 packets/s
10 packets/s
1800 packets/s
240 packets @4000 packets/s =60 ms burst

The different amounts of background traffic used during the performance tests were chosen for specificreasons. The large, flat network was assumed to have around 200 industrial devices. The number 180
was chosen during the test development to allow for simulated devices used by the performance test
system. For the burst test, the number 240 was chosen based on input from both users and vendors
given situations they had seen occur on real plant-floor networks.
The tests in this section conform to the basic methodology in the cyclic accepted packet interval(API)/jitter test as described in the Performance Test Methodology document, sections 3.2 and 3.3 (seeSection 2, Normative Reference Documents, item [7]).

P15 Device Performance Test Procedure
P15.1
Baseline Performance Test
P15.1.1
P15.1.2

P15.1.3
P15.1.4
P15.1.5
P15.1.6

Start capturing traffic using the network tap card.
Establish a Connected Class 1 I/O connection from the scanner to the DUT at theminimum RPI (fastest RPI speed) that the DUT supports and at the desired connection
size. NOTE: The connection multiplier should be set as high as possible (512x multiplierrecommended) to allow the analysis software to measure potential 4x multiplierconnection timeouts without the scanner actually shutting down and reestablishing theconnection.
Maintain the connection with the DUT for a minimum of 60 seconds.
Stop capturing traffic on the test network.
Export the captured network traffic to a Wireshark pcap file using the network tap card
software.
Using Wireshark, review the connection establishment sequence to determine the RPI
and API.

Publication PUB00095

44

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
P15.1.7
P15.1.8
P15.1.9

Analyze the capture file using the performance analysis tool.
Record the analyzed performance results.
If any of the following conditions is met, increase the RPI (decrease the production rate)
and repeat the Baseline Performance Test.
P15.1.9.1 The mean of the device’s measured packet interval (MPI) is not within 10% of thedevice’s API.
P15.1.9.2 The standard deviation jitter of the device’s MPI is not within 10% of the mean MPI.
P15.1.9.3 The maximum jitter of the device’s MPI is not within 50% of the mean MPI.

P15.2

Steady-State Managed Background Traffic Test
P15.2.1
Start capturing traffic using the network tap card.
P15.2.2
Using the background traffic generator tool, start the steady-state managed traffic set.
P15.2.3
If the connection established in the previous performance test(s) was terminated after
testing, reestablish the Connected Class 1 I/O connection at the fastest RPI that passed
the previous test(s). NOTE: The connection multiplier should be set as high as possible
again.
P15.2.4
Maintain the connection with the DUT for a minimum of 30 seconds.
P15.2.5
Stop capturing traffic on the test network.
P15.2.6
Export the captured network traffic to a Wireshark pcap file using the network tap card
software.
P15.2.7
Analyze the capture file using the performance analysis tool.
P15.2.8
Record the analyzed performance results.
P15.2.9
If any of the following conditions is met, increase the desired RPI (decrease theproduction rate) and repeat the Steady-State Managed Background Traffic Test.
P15.2.9.1 The device’s mean MPI is not within 10% of the device’s API.
P15.2.9.2 The standard deviation jitter of the device’s MPI is not within 25% of the mean MPI.
P15.2.9.3 The maximum jitter of the device’s MPI is not within 100% of the mean MPI. NOTE:This makes sure that the DUT does not drop packets due to a steady-state amountof background traffic.

P15.3

Steady-State Unmanaged Background Traffic Test
Repeat the test procedure fromP15.2Steady-State Managed Background Traffic Test
using the steady-state unmanaged background traffic set instead in step P15.2.2.
P15.3.2
If any of the following conditions is met, increase the desired RPI (decrease theproduction rate) and repeat the Steady-State Unmanaged Background Traffic Test.
P15.3.2.1 The device’s mean MPI is not within 10% of the device’s API.
P15.3.2.2 The standard deviation jitter of the device’s MPI is not within 25% of the mean MPI.
P15.3.2.3 The maximum jitter of the device’s MPI is not within 100% of the mean MPI. NOTE:This makes sure that the DUT does not drop packets due to a steady-state amountof background traffic.
P15.3.1

P15.4

Burst Managed Background Traffic Test
P15.4.1
Start capturing traffic using the network tap card.

Publication PUB00095

45

Version 9 PR002

EtherNet/IP Interoperability Test ProceduresP15.4.2

If the connection established in the previous performance test(s) was terminated after
testing, reestablish the Connected Class 1 I/O connection at the fastest RPI that passed
the previous test(s). NOTE: The connection multiplier should be set as high as possible
again.
P15.4.3
Verify that the connection is operational and stable before proceeding any farther.
NOTE: This will probably be verified using the scanner software or by visually verifyingthat the device has not faulted.
P15.4.4
Using the background traffic generator tool, start the burst managed traffic set.
P15.4.5
Maintain the connection with the DUT for a minimum of 30 seconds.
P15.4.6
Stop capturing traffic on the test network.
P15.4.7
Export the captured network traffic to a Wireshark pcap file using the network tap card
software.
P15.4.8
Analyze the capture file using the performance analysis tool.
P15.4.9
Record the analyzed performance results.
P15.4.10 If any of the following conditions is met, increase the desired RPI (decrease theproduction rate) and repeat the Burst Managed Background Traffic Test.
P15.4.10.1 The device’s mean MPI does not return to within 10% of the device’s API by the endof the test time.
P15.4.10.2 The maximum jitter of the device’s MPI is greater than 400% of the mean MPI at any
time during the test.

P15.5

Burst Unmanaged Background Traffic Test
P15.5.1
Repeat the test procedure fromP15.4Burst Managed Background Traffic Test using the
burst unmanaged traffic set instead in step P15.4.4.
P15.5.2
If any of the following conditions is met, increase the desired RPI (decrease theproduction rate) and repeat the Burst Unmanaged Background Traffic Test.
P15.5.2.1 The device’s mean MPI does not return to within 10% of the device’s API by the endof the test time.
P15.5.2.2 The maximum jitter of the device’s MPI is greater than 400% of the mean MPI at any
time during the test.

P15.6

ReportingP15.6.1
Give the vendor copies of all the packet capture files and test data collected during theseries of tests, especially failed tests.
P15.6.2
Report the minimum RPI (fastest RPI speed) that passed all the tests.

Publication PUB00095

46

Version 9 PR002

EtherNet/IP Interoperability Test Procedures

Table 4 Document Revision Log

Rev.

SectionRemarks

Date

Editor

1.0d4

AllJan 7, 2005

Jim Gilsinn

1.0d5

All

Jan 20, 2005

Jim Gilsinn

1.0d7
1.0d8
1.0d8a1.0d8b
1.1

5
Various
Various6
VariousFeb 8, 2005
Sep 27, 2005
Sep 29, 2005
Sep 30, 2005
Oct 7, 2005

Kevin Knake
Perry Green
Viktor Schiffer
Viktor Schiffer
Perry Green

1.2
1.3

Various

Reorganized document to split out test plan andtest procedure into multiple documents.
Incorporated comments from Plug-Festplanning committee
Delete tests P5.2.4 and P5.2.5.
Updated after Workshop #16 review.
Further suggestions for change
Reworded participation requirements
Updates after Plug Fest Planning Committee
review
Updates after Plug Fest #4 and Workshop #18
 Updated Normative References.
 Updated Figures 1 thru 3.
 Removed references to Test Plan document.
 Add several clarifications/new criteria/new
tests to: P6, P7, P11, P12& P13.
 Modified System Interoperability test.
 Update Table 1, associated text and added
Table 2.
 Misc. typos & misspellings
 Mods to Network Interop. Test to clarify
methods and expected results.
 Change hierarchy of P8 tests.
 Make multiport device changes
 Add address conflict detection tests
 A few typo corrections
Added unicast T→O tests
Minor edits
 Added Performance Testing Procedures
 Formatting & typos fixedMore details for the ACD tests

Mar 24, 2006
Apr 24, 2007

Perry GreenRay Romito

Mar 19, 2008

Ray Romito

Aug 18, 2008

Ray Romito

Sep 23, 2008
Sep 24, 2008
Oct 7, 2008

Viktor Schiffer
Viktor Schiffer
Jim Gilsinn

Oct 14, 2008

Viktor Schiffer

Oct 31, 2008

Viktor Schiffer

Nov 10, 2008
Dec 18, 2008

Viktor Schiffer
Viktor Schiffer

1.4

2.0

2.0WD2
2.0WD3
2.0WD4
2.0WD5
2.0WD6

2.0final
2.1WD1

Perform.
4, 7.513.3
4 8.5

Added new chapter: Software and Tool
Revisions More details for the ACD tests
 Various other edits
Accepted all edits, removed all comments
8, 8, 12 & Fixed some inconsistencies (incorrect13
references) in the document

Publication PUB00095

47

RT
Appr

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Rev.

SectionRemarks

2.1 WD2

6 & 12

12

2.1 WD3

4
13
All
5
6

2.1 WD4

1
2
5
6
12
13

2.1 WD5581213

2.1 WD6

12

Publication PUB00095

Add test steps at several places toassure that: EDS values forconnection points,
size &RPI are usedin the adapter andinteroperability tests
 If EDS values do notwork properly in theadapter and/orinteroperability tests,
that the corrected
EDS and the device
return to the EDS test
station for retesting.
 Remove Test P12.1.2
 Changes to software tools required fortesting.
 Remove Unidirectional test fromscanner test
 Added section for software
requirements to each test
 Added Figure 7
 Added new test steps to EDS test
 Added cross reference to Normative
Reference Documents for document
number and revision Add pub revision to pub number 70
 Changes to Figure 7, Scanner test
configurationo Issues to resolve
 Added a missing clause to EDS test
 Added remarks to adapter testo Issues to resolve
 Added remarks to scanner testo Issues to resolve
 Changed Figure 7, Scanner test
configuration to resolve issue with Example
Code PC
 Added note on devices with opticalinterface Added note on connection with no keying
segmento Issue to resolve
 Added detail concerning Example Code toscanner test to resolve issue with Example
Code PC
Added clarification concerning unicast/multicast
testing of Class 1 connections

48

Date

EditorJan 19, 2010

Ray Romito

Feb 26, 2010

Ray Romito

Mar 22, 2010

Schiffer,
Romito,
VanGompel

Jul 28, 2010

Viktor Schiffer

Aug 12, 2010

Viktor Schiffer

RT
Appr

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Rev.

SectionRemarks

Date

Editor

2.1

Front
page,
footer,general14Aug 17, 2010

Viktor Schiffer

Sept 13, 2010

Viktor Schiffer

12Mar 1, 2011

JoakimWiberg/Darren
Klug

Apr 12, 2011

Darren Klug

May 4, 2011

Perry Green

2.2
2.3
PR001




1

2
7
P8.5



P9.2.1
P9.5
11
P12.2.2

P12.3.2

2.3
PR002



P8.5









2.3
PR003

P9




Removed “WD6” and cleaned up alledits for publication
Referenced the latest editions of CIP
Specs Volumes 1 & 2
Corrected system test reference in tests
14.4 through 14.7
Updated tests in 12.7 (updated against
version 2.1 of the Recommended
Functionality document)
Updated ACD requirement (Appendix F
preferred).
Updated spec and Recommended
Functionality for EtherNet/IP Devices
document revisions
Clarified that CIP Spec is source ofminimum requirements for EtherNet/IP
devices
Updated ACD Test Procedure fordevices that support Appendix F (draft)
Grammar correction
Clarified spec reference
Grammar correction
Clarification to sync with Input Only
possibility in PF12.2.1
Clarified Null Electronic Key
Integrated updated ACD Test
Configurations and Procedure from
Joakim Wiberg
Added EO/EO Rejection verification toP12.5.3
Added preliminary test cases
Removed “informational” from LED test
case

RT
Appr

P12







Publication PUB00095

Broke out input-only test logic so that it’s
clearer how input-only devices should betested.
Added more Run/Idle testing to P12.1.1 –this recommendation wasn’t really being
testedAdded test for non-matching key to P12.3.1
Removed “not tested” note from P12.3.3
Added tests to P12.4.1 to verify
configuration data handling for Input Only
connections
Clarified how input only devices should be
handled in the tables in P12.5

49

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Rev.

SectionRemarks

Date

Editor

2.3
PR004

P12



Jul 13, 2011

Perry Green

2.3
PR005

variousAug 18, 2011

Viktor Schiffer

Aug 26, 2011

Viktor Schiffer

Sept 9, 2011

Darren Klug

Sept 13, 2011

Darren Klug

Accepted all changes; removed reviewed Sept 19, 2011
commentsUpdated 2nd paragraph to better reflectcurrent mode of operation, noting that adevice that has not been officiallyconformance tested may still receive theinteroperability mark provided the sameversion is conformance tested within 6months.

Added entry for ACD Test ToolUpdated intro to ACD test.
Updates to P8.5.7 and P8.5.8
Addressed comments received from Schneider: Sept 26. 2011

Added abbreviations

Carried forward a couple of comments
re: ACD (P8.5.4.1 and P8.5.9)
Corrected APR typos in P8.5.11-P8.5.13
Made Null (P12.4.2) and No (P12.4.3)
config tests Informational (pending
further discussion)

Darren Klug







2.3
PR006
2.3
PR007

2.3
PR008
2.3
PR009

P6.2.3



Section 5



pp. 4-5

All
Section 1

Section 4
Section
8.5
2.3
PR010

Section 3

Publication PUB00095

Added clarification that configuration
data should be included in the fwd_open
unless Null or No data segment isrequired.
Cleaned up document in a couple ofareas (typos, formatting)Updated CIP spec dates
Added one normative reference
Added explanation of heartbeat use in IO
and LO connections
Added definition of IP frame
Added one more test step in IP Address
Configuration test
Added several details to ACD test to
make it easier to understand for a newbie
Modified details with respect to the
Molex scanner tool
Corrected formatting of paragraphcontaining Figure 3 so it doesn’t show up
in Table of Contents
Updated all “Table of …” fields
Workshop 33 feedback



50

RT
Appr

Darren Klug

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Rev.

Section

2.3
PR011

2.3
Section 4
P8.5.4P8.5.9P8.5.11.1

2.4
PR001
2.4
PR002
2.4
PR003
2.4
PR004
2.4
PR005
2.4

Section
P8.5
Section
P8.5
Section
8.4
All

3.0
PR001

P12.1.2
P12.2

Section
P8.5
VariousPublication PUB00095

Remarks

Date

EditorUpdates based on feedback from Viktor
Schiffer:Updated text in P8.5 to make it clear that
ACD is not optional.

Added some suggested improvements re:ongoing SCD probe time (P8.5.4)
requirement and corrected typo from
PR010
Made Null (P12.4.2) and No (P12.4.3)
config tests Informational only for
products that require config with each
fwd_openClarified that config path must be
specified in fwd_open with null data
segment (P12.4.2)
Clarified that config path is optional in
fwd_open with no data segment(P12.4.3)
Incorporated Joakim’s comments:
 Added source/rev re: ACD Test Tool
 Added note recommending skip ofongoing ACD probe timing test in firstpass Updated sequence for
LastConflictDetected test
 Corrected step in Verification of ACD
DefendUpdates to make the ACD test sequence easier
to automate
Clarify IP Conflict Detection with NS and MS
LEDs test cases
Added text that a 10% variance in timing
measurements is allowed.
Removed comments and accepted all changes tocreate document for PlugFest #14
Corrections to ACD Test section to reflect theactual behavior of the ACD Test Tool
Added in Low-Cost Performance Test Suitechanges.
 Added test suite to Section 4, Software
and Tool Versions.
 Replaced figure in Section 5, Proposed
Test Configurations.
 Updated Section 15, Device
Performance Test to reflect all thechanges necessary for the low-cost
performance testing system
Updates based on Recommendations v3:
 Made COS connections required Expanded two connection tests to include
all combinations of multicast and unicast
connections.

Sept 26. 2011

Darren Klug

Sept 27, 2011

Darren Klug

Oct 19, 2011

Joakim Wiberg

Oct 21, 2011
Oct 21, 2011

Emmanuel
Lude
Joakim Wiberg

Oct 21, 2011

Viktor Schiffer

Apr 10, 2012

Joakim Wiberg

Apr 10, 2012

Jim Gilsinn

Aug 31, 2012

Perry Green

51

RT
Appr

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Rev.

SectionRemarks

Date

Editor

3.0
PR002
3.0
PR003
3.0
PR004
3.0

P12.2

 Added wording for consistency
 Modified footer to read “3.0”Updates based on latest EIP-CT (version 3.1)

Sept 6, 2012

Viktor Schiffer

Sept 14, 2012
Sept 21, 2012
Sept 26 2012

Viktor Schiffer

3.0.1
PR001

4, P8.5

Normative References, Software and Tools
Versions
Accepted all edits, changed to rev. 3.0 for PDF
creation Updated version for ACD Test Tool
 Corrected timings related to
DEFEND_INTERVALL as this value haschanges from 10s to 2s in EtherNet/IP
Adaptation of CIP, Edition 1.13
 Added text to make it clear that the DUT
shall have an static IP assigned for all ACD
tests
Accepted all edits and set the revision to 3.0.1
 Updated version for ACD Test Tool
 Tightened span for OngoingProbe in P8.5.4
from 80s between 165s to 90s between 150s
 Added tests to P8.5.9 to allow for the test to
be run standalone and not be dependent on
P8.5.8
 Extended P8.5.12 to verify that the DUT
returns to OngoingDetection state
Accepted all edits and set the revision to 3.0.2
Clean-up based on PF#16 and addedsuggestions for extensions
P6.1.3 – Clarified definition of Format
P6.1.4 – Clarified that CM section of EDS shallhave appropriate ConnectionN entries for
Adapters and Scanners that support Class 1
connections
P8.3, P8.4, P8.5.5 – Updated ACD tests to betested on two ports of multiport devices.
P8.5.9.3 – Clarify that device should be allowed
up to 60 secs to recover from set of TCP
LastConflictDetected attribute (5)P12.6 – Clarified that P12.6 is informational for
devices that do not support Config Params.
P14.8.2 – Corrected which test procedures need
to be repeated after regrouping.
P15.1.8, P15.6.2 – Removed notes indicatingthat results are not official until finalized with
PlugFest Completion.
Editorial clean up.

Emmanuel
LUDE
Viktor Schiffer

Sept 27 2012

Joakim Wiberg

Sept 27 2012
Sept 28 2012

Viktor Schiffer
Joakim Wiberg

Sept 28 2012
Jan 31 2013

Viktor Schiffer
Viktor Schiffer

Feb 1, 2013

Darren Klug

Editorial clean up

Feb 6, 2013

Viktor Schiffer

3.0.1
3.0.2
PR001

P6.2.2
2, 4

4, P8.5

3.0.2
4.0
PR001

4.0
PR002
4.0
PR003

Publication PUB00095

52

RT
Appr

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Rev.

Section

4 PR0042
P6.1.3

Remarks

Updated normative references.
Clarified that rule 6.1.3 does not apply totechnology enabler devices.
2, 8.5
Clarified that device must support Vol 2, Appdx
F ACD.
4 PR005
Updates made during WS#37 review:P6.1.3
1. Clarified requirements for specifying
EDS I/O details.
2. Clarified instructions to repeat
multiport tests (P8.3.14, P8.4.18,
P8.5.9.3
P8.5.5.6, P8.5.6.7).
3. Changed requirement to note regarding
P12.6
device recovery time.
4. Clarified requirements regarding
P12.7.3,
explicit messaging access toP12.7.5.1,
configuration data.
P12.7.7.1
5. Clarified that explicit requests can beP14.6
either connected or unconnected(device must support both).
6. Added requirement to conduct ad hoc
cable break testing to system test.
4 PR006
Reconstructed from 4 PR005. As approved at
WS#37; all changes accepted.
4 PR007
Updates per feedback from Viktor on PR006:
P8.3.2
1. Corrected cross reference.
P8.5
2. Corrected some missing spaceP14.3.4
characters.
Header
3. Removed “Note:” from last statement.
13
4. Corrected text.
5. Updated comment re: use of example
code.
4
Accepted all changes. As approved at WS#37.
4.1 PR001 8.2 andAdded power up test case to Network tests.
8.3
4.1 PR002 Figure 8
Changed PC icons in Figure 8 to resolve pdf
conversion issue
5
Pre Workshop 40 Cleanup
Aligned version with Recommendations Doc
1.1
Added future work items section (1.1).
8.5.1
Updated ACD test per ESE-090-015 ACD
13Clarification II.
Removed reference to EtherNet/IP Example
Code.
6 PR0014
Added URL for as many tools as I could find on
the web.
6 PR0024
Added URL to ACD Test Tool.
Updated version for ACD Test Tool.
6 PR003
4
Changed RSLinx URL to point to the freedownloads link, also changed the version to thelatest.

Publication PUB00095

53

Date

Editor

Feb 18, 2013

Darren Klug

Feb 19, 2013

Darren Klug

Feb 19, 2013

Darren Klug

Feb 21, 2013

Darren Klug

Feb 22, 2013
Aug 30, 2013

Darren Klug
Darren Klug

Oct 7, 2013

Darren Klug

Mar 10. 2014

Darren Klug

Apr 30, 2014

Jamin Wendorf

May 14, 2014

Joakim Wiberg

May 27, 2014

Ray Romito

RT
Appr

X

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Rev.

Section

69, 12
Added DHCP server to software list
Oct 22, 2014
P9.4, P9.5 Specified non-CIP connection details
P12.2.4
Added Unicast-Multicast connection
combination
P12.6
Clarification that config parameters should bein the EDS
P12.8
Removed TBD – it was handled by P12.2.4
P12.9
Added note about filling in EDS test resultsfrom adapter test station
7
Changed passing of conformance test to
recommended.
Removed clause on relationship and timing ofInterop and conformance testing.
P7.1
Made test informational
4
Changed ‘Windows XP’ requirement to just‘Windows’
P12.4.2, 3 Remove informational clause allowing device to Feb 17, 2016
require configuration data with every
Fwd_Open

7

Remarks

Date

P6.1.5

Added EDS check for configuration assembly
formatP12.7.4

Clarified data consistency check between
explicit and I/O connection data.
Corrected web address for ACD Test Tool
software.
Added tests to ACD test to match test tool
operation

7.1

4

8

P8.5
P9.2
P9.7

Added tests for support of class 3 priorities inclass 3 server tests

P12.1.1
P12.2.6

Added test for support of class 1 priorities in
Adapter tests

P12.2.2
P12.2.3
P12.2.4

Added Listen Only as an option for Unicast
connections

P12.2.5

Added test for simultaneous class 3 and class 1
connections

P12
P9

Added default connection parameter
specification to be used for all class 1 and class
3 connections in each section unless specified

This table

Moved to end of document

Publication PUB00095

54

EditorRT
Appr

Perry GreenX

Perry GreenX

Nov 16, 2016

Perry GreenMar 30, 2017

Perry GreenX

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Rev.

Section

8.1

4

Remarks

Date

Updated link to EZ EDS
April 10, 2017
Corrected name of RSLinx Classic Lite
14
Added system test steps to introductorymaterial
P14.1.3
Added enable IGMP Snooping
P14.3.1
Removed (Multicast I/O) from heading because
test is now entered multiple times during thecourse of testing, not all are multicast
P14.3.1.1. Changes to the RPI specified for this test
1
P14.3.2
Removed (Multicast I/O) from heading because
test is now entered multiple times during thecourse of testing, not all are multicast
P14.3.2.2. Changes to the RPI specified for this test
1
P14.3.4
Moved to P14.9
P14.4
Changed section references since this test isP14.5
now entered multiple times during the course
P14.6
of testingP14.6.4
Removed section
P14.7
Changed section reference since this test is
now entered multiple times during the courseof testingP14.8
Added this for the “Multicast with IGMP off”
P14.8.1
test
Added disturbance testing step
P14.9
Material relocated from P14.3.4
P14.9.1
Added disturbance testing stepP14.10.2 Changed which tests are included in this test
step
P14.11
Removed tests that are either part of earlier
tests or no longer tested
Added table caption to Document Revision Log
so it shows up in the list of tables at the front of
the document
Added note that COS is optional for nonJune 14, 2017
P12.1.2
discrete
14
Changed system test to disable IGMP snooping
P14.1
on first configuration, then only run with it
P14.8
enabled if any devices failed.
4
Updated required software versions
Sept 12, 2017
Removed ‘Future’ section as it has been
1.1
handledPublication PUB00095

55

Editor
Ray Romito

RT
Appr
X

Perry Green

Perry Green

Version 9 PR002

EtherNet/IP Interoperability Test Procedures
Rev.

SectionRemarks

Date

Editor

9

P8.2
P8.4

Removed half duplex requirements from
Network Test
New ACD test for ARP probe during probe
phase.
New Adapter test for handling of Ethernet link
loss.

April 10, 2018

Perry Green

P8.5.16
P12.10Publication PUB00095

56

RT
Appr
x

Version 9 PR002