Introduction to EtherNet/IP

EtherNet/IP is an Industrial Ethernet protocol implementing the Common Industrial Protocol (CIP) over Ethernet in combination with the standard protocols IP, TCP and UDP. This protocol is maintained by the ODVA. The association also manages other implementations of the CIP protocol, e.g. DeviceNet (CIP over CAN).

Scanner

A Scanner is the master in an EtherNet/IP network. Usually it is the originator of a request.

Adapter

The Adapter is an EtherNet/IP slave. It creates responses to requests from a Scanner.

Encapsulation Protocol

On EtherNet/IP networks CIP messages are encapsulated by the Encapsulation Protocol. The Encapsulation Protocol defines an Encapsulation header, address items and a data items. It provides several commands for device identification, session management and CIP message transport. A session corresponds to a TCP connection between two endpoints.

CIP Object Model

The Common Industrial Protocol groups functionalities, attributes and behavior into classes. Each class has a class ID that is used to address a class. The ODVA manages the lists of classes that are officially defined. Vendors can also implement their own classes within a certain range of class IDs.

A class can have class attributes that describe the class and class services that influence the behavior of the class. An object is an instance of a CIP class. Each instance has its own set of instance attributes. All instances share the same instance services.

The CIP protocol addresses a certain service by specifying the class ID, instance ID and service ID. If a service is only applicable to an attribute, its attribute ID is also specified in the request. Class attributes are addressed via instance ID 0.

CIP Messages

Explicit Messages

Explicit Messages are sent acyclically. A client issues a request that explicitly addresses the resource of a server. The server sends a response. Explicit Messages only allow Point-to-Point connections. An Explicit Message can be either unconnected or connected. A connected message requires an established connection. An unconnected message can be sent without establishing a connection beforehand. On EtherNet/IP networks Explicit Messages are used for acyclic access to CIP attributes and to invoke CIP services.

The Encapsulation Protocol for unconnected Explicit Messages consists of the Encapsulation header, the Null Address Item and the Unconnected Data Item. The Unconnected Data Item contains the actual CIP message. A connected Explicit Message has an Encapsulation Header a Connected Address Item and a Connected Data Item. The Connected Address Item contains the Connection ID associated with this Explicit Connection.

Implicit Messages

Implicit Messages are sent cyclically. A producer sends messages that can be consumed by one or multiple consumers, i.e. they are sent over Point-to-Point or Multicast connections. Implicit Messages contain a message ID that indicates the meaning of the data conveyed in these messages. Thus it can never be unconnected. On EtherNet/IP networks Implicit Messages are used to send cyclic IO data. These messages do not have an Encapsulation Header but have a Sequenced Address Item and a Connected Data Item. The Sequenced Address Item contains a sequence number and a Connection ID used to implicitly map the message data to a resource.

CIP Connections

For EtherNet/IP devices CIP connections are established via the CIP service “ForwardOpen” of the Connection Manager Object. This service is invoked by an unconnected Explicit Message.

Transport Class 3 Connections

The ForwardOpen service can open a Class 3 connection. This is a connected Explicit Message. Each message is prepended with a sequence count to detect duplicate messages. The Connection Path for Explicit Messages points to the Message Router Object.

Transport Class 0 & 1 Connections

The ForwardOpen service can also open Class 0 or Class 1 connections. Both classes are used for Implicit Messages. The ForwardOpen service usually opens two connections, one in the Originator-To-Target direction (for data consumed by the Adapter) and the other in the Target-To-Originator direction (for data consumed by the Adapter). Class 0 connections only contain the raw connection data. Class 1 connections prepend a sequence count to the connection data. This sequence count is independent from the one of the Sequenced Address Item in the Encapsulation Protocol. The Connection Path for Implicit Messages points to instances of the Assembly Object class. The Connection Path may contain instances for a producing Assembly, a consuming Assembly or a configuration Assembly. The data attributes of the assembly instances define the data layout of the consumed and produced IO data and of the configuration data. The configuration data is sent with the ForwardOpen request to configure the application.

Connection Timing

The ForwardOpen service contains Requested Packet Intervals (RPI) for both directions. The Adapter’s response contains the Actual Packet Intervals (API). The API is the RPI adjusted to the Adapter’s timer resolution. These intervals are used for multiple timers that maintain the connections.

Transmission Trigger Timer

This Timer is loaded with the API value for the Target-To-Originator direction. Whenever the timer expires production of new connection data is started and the timer is reloaded.

Inactivity/Watchdog Timer

This timer is is used for consuming connections. The timer is loaded with the API of the Originator-To-Target direction multiplied by the Connection Timeout Multiplier. The timer is reset whenever valid connection data was consumed. If the timer expires the connection is considered timed out and will be closed. For the first reception the timer is set to at least 10 seconds.

Production Inhibit Timer

This timer is started for Implicit Messages whenever new data was produced because of a change of state or a trigger signal from the application. A new production request shall be delayed as long as this timer has not expired. The Production Inhibit Time loaded into the timer is received via the ForwardOpen service as a Network Segment.

Production Triggers

The production Trigger of a CIP connection determines when connection data is produced.

Cyclic

Data is sent cyclically whenever the Transmission Trigger Timer expires.

Change-of-State

Data is sent if the Application detects a change of state for its produced data. Also the Transmission Trigger Timer can invoke the production of new data to keep the connection alive.

Application Object Triggered

The application decides when to produce new connection data. Also the Transmission Trigger Timer can invoke the production of new data to keep the connection alive.

Application Connection Types for Implicit Messages

When the ForwardOpen service is used to create a class 0 or class 1 connection it opens two connections. One in the Originator-To-Target direction the other in the Target-To-Originator direction. The Application Connection Type defines the relationship between these two connections. The Adapter can recognize the Application Connection Type by the Connection Path of the ForwardOpen request. This means a combination of a producing Assembly and a consuming Assembly can always have only one Application Connection Type.

Listen Only

This connection produces data in the Target-To-Originator direction. The originator only sends a heartbeat. A Listen Only connection always depends on the existence of a non-Listen Only connection with the same Target-To-Originator connection path. Thus this Application Connection Type can be used to “listen” to data produced for other devices, e.g. a supervisor tool.

Input Only

This connection produces data in the Target-To-Originator direction. The originator only sends a heartbeat. It does not depend on any other connection. This Application Connection Type is suitable for connections that produce data that does not depend on other data consumed from other devices.

Exclusive Owner

This connection produces data in both directions, i.e. an Adapter produces data and consumes data. The originator that sends the data consumed by the Adapter is the connection owner. There can only be one active connection to the consuming connection path, i.e. it is exclusive. This Application Connection Type is suitable for connections that produce data that depends on other data consumed from other devices.

Redundant Owner

This Application Connection Type corresponds to Exclusive Owner connections with the exception. that multiple originators can try to claim ownership of this connection. All redundant owners receive the data produced by the Adapter. However the Adapter only consumes data from the current connection owner. If the connection to the current owner is closed or times out another redundant owner can take over the ownership. The current owner of a connection is determined by values in the header of the Originator-To-Target message.

Real time formats for Implicit Messages

As described in previous chapters an Implicit Message for EtherNet/IP consists of a Sequenced Address Item, a Connected Data Item an optional sequence count (for class 1 connections) and the actual connection data. The layout of the data is determined by the Assembly ID in the Connection Path. The Real time format defines how to interpret the data. An Adapter knows from the Connection Path what real time format both directions have. Some Application Connection Types require a certain real time format for a direction.

Modeless Format

The connection data does not indicate any idle information. Only the raw data is transmitted.

Zero Length Data Format

The connection data indicates idle mode if its length is zero. Otherwise it indicates run mode.

Heartbeat Format

The connection data always has the length 0. This format is required for the Originator-To-Target direction of Listen Only and Input Only connections.

32-Bit Header Format

This format prepends a 32 bit header to the connection data. For class 1 connections the header is inserted in between the sequence count and the connection data. The header has a status bit to indicate run mode or idle mode. Other fields of the header can be used to determine the ownership of a connection. Thus this format must be used Redundant Owner connections in the Originator-To-Target direction.