Common Industrial Protocol

In the past, automation fieldbus protocols have tended to be application-specific, making them very efficient at what they do but limiting the roles for which they can be used, and making interoperability between the protocols used in different application areas difficult to achieve. The Common Industrial Protocol (CIP) forms the basis for a family of related technologies, and has numerous benefits for both device manufacturers and the users of industrial automation systems. The first of the CIP-based technologies, DeviceNet emerged in 1994, and is an implementation of CIP over CAN, which provides the data link layer for DeviceNet. The next major implementation was ControlNet, introduced in 1997, which runs over a high-speed coax or fibre physical layer, and uses Concurrent Time Domain Multiple Access (CTDMA) as its medium access layer, making it highly deterministic while extending the range of the bus (up to several kilometres, with repeaters) for more demanding applications. The most recent edition to the CIP family of technologies is EtherNet/IP (Ethernet/Industrial Protocol). The CIP protocol is also used in Rockwell Automation's ControlLogix product range. The diagram below shows the relationship between the layers of the various CIP family protocol stacks and the OSI reference model.

The CIP family of field bus protocols

The CIP family of field bus protocols

CIP was designed to suit the requirements of the automation industry. The specification (which is maintained by the Open Devicenet Vendors Association - ODVA) describes the following features:

Object modelling

CIP uses an object-oriented approach to modelling the nodes and communication services on a CIP network. Each node is modelled as a collection of objects. An object represents a particular element or component within a node. Each object belongs to a class of objects that share the same set of attributes, and implement the same behaviours. An object is an instance of that class, with its own unique set of attribute values. A node may contain more than one object of the same class. Nodes and the objects from which they are made up employ a standard addressing scheme comprising the following elements:

An example of how an object's unique address is determined

An example of how an object's unique address is determined

Messaging protocol

A CIP connection provides a path between multiple applications. When a connection is established, it is assigned a Connection ID. If the connection involves a bi-directional exchange of data, two Connection IDs are assigned. The relationship between Application Objects, Connection Objects and Connection IDs is illustrated below.

CIP connections and connection IDs

CIP connections and connection IDs

The format of the connection ID is network dependent. In DeviceNet networks, for example, it is based on the CAN Message ID. Most messaging on a CIP network relies on connections, and a process has been defined to establish connections between devices that do not have an established connection. The Unconnected Message Manager (UCMM) is responsible for connection establishment. Connections in a CIP network are either I/O connections or explicit messaging connections. I/O connections provide dedicated paths for application-specific I/O data between a producer application and one or more consumer applications. Explicit messaging connections provide generic communication paths between two devices for request-response oriented communication, and are often referred to simply as messaging connections.

A CIP I/O connection

A CIP I/O connection

Communication objects

CIP communication objects are used for the exchange of messages. Every communication object has a link producer part or a link consumer part or both. I/O connections may be producing only, consuming only or both. Explicit messaging connections are always producing and consuming.

A CIP Explicit Messaging connection

A CIP Explicit Messaging connection

The attribute values of a connection object describe the parameters of the connection. They specify its type, i.e. whether it is an I/O connection or an explicit messaging connection, the maximum size of message that can be exchanged across the connection, and the source and destination for the message. There will also be attributes that define the current state of the connection, the type of event that may trigger a message being sent (e.g. a change in the state of a device, or the elapse of a predetermined time interval), and any time-out value that applies to the connection.

General object library

The CIP family of protocols contains a large collection of commonly defined objects, which can be subdivided into the following three types:

General use objects:

Application Specific Objects:

Network Specific Objects:

A typical device object model

A typical device object model

A typical device will only implement a subset of the available objects, but will always have at least one Connection Object, an Identity Object, one or more network link related objects (depending on the type of network), and a Message Router Object. The other objects present in the model will depend on the functionality of the device being represented. Developers typically uses publicly defined objects (see table above), although there is scope for the creation of vendor-specific objects if necessary. The table below lists the attributes associated with the Identity Object. Typical devices do not change their identity, so all attributes (except the Heartbeat Interval attribute) are read-only.

Identity Object Attributes
Vendor IDState
Device TypeConfiguration Consistency Value
Product CodeHeartbeat Interval
RevisionLanguages Supported
Serial Number 
Product Name 

Device profiles

Similar products could have quite different internal structures and exhibit different behaviours. To make the application of CIP devices easier, devices with similar functionality are grouped into device types, each with an associated device profile. The profile contains a full description of the object?s structure and behaviour. The following device types and their associated profiles have been defined:

CIP Device Types:

Every profile consists of a set of objects (some mandatory, some optional), and a behaviour that is associated with the particular type of device. Most profiles also define one or more I/O data formats.

Device configuration

CIP allows a number of methods to be used for device configuration:


Service codes define the action to be taken when an object or parts of an object receive a message. Apart from basic read and write functions, a set of CIP Common Services has been defined that are supported by most objects. There are also a number of object-specific service codes that may have different meanings for different objects. It is also possible for vendors to define their own vendor-specific service codes, although such codes may not be universally understood.

Data management

The CIP Specification describes addressing models for CIP entities, and the data structures of the entities themselves. Addresses are referred to as segments and fall into two categories - logical segments and data types. The first byte of a CIP segment determines whether it is a logical segment (0x20-0x3F) or a data type (0xA0-0xDF). Logical segments are addressing segments that can be used to address objects and their attributes within a device, and are typically structured as shown below.

[Class ID] [Instance ID] [Attribute ID (if required)]

Each element of the structure may take up one, two or four bytes. This type of addressing is commonly used to point to assemblies, parameters, and other addressable attributes within a device. It is used extensively in electronic data sheets, and for unconnected messages. Data types can be either structured or elementary. Structured data types may be arrays of elementary data types, or any assembly of arrays or elementary data types. Elementary data types are used within electronic data sheets to specify the data types of parameters and other entities.

Benefits of CIP

CIP provides a common object-oriented language for describing the nodes and services on a CIP network, whether the network is implemented using DeviceNet, ControlNet, EtherNet/IP, or any other compatible technology. This makes existing knowledge and expertise transferable, facilitating the replacement or upgrading of existing systems, and reducing the cost of training development and support personnel. It also means that firmware or software written in a high-level language can be re-used with little or no re-coding necessary. The interconnection of systems that employ diverse CIP-based technologies is relatively easy to implement, since these systems already speak the same language and device profiles are identical from one system to another. CIP is highly scaleable, and the producer-consumer mechanisms and open object architecture used in the CIP family of protocols make efficient use of the bandwidth available on the underlying network.