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
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
- Messaging protocol
- Communication objects
- General object library
- Device profiles
- Device configuration
- Services
- Data management
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:
- MAC ID - assigned to each node on a CIP network
- Class ID - assigned to each class of object on the network
- Instance ID - assigned to a specific instance (object) of a class
- Attribute ID - assigned to an attribute of a class or object
- Service Code - identifies a specific behaviour of a class or object
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
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
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
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 (found in many different devices)
- Application specific objects (exclusive to a specific application)
- Network specific objects (exclusive to one type of network)
General use objects:
- Identity Object
- Message Router Object
- Assembly Object
- Connection Object
- Connection Manager Object
- Parameter Object
- Parameter Group Object
- Acknowledge Handler Object
- Connection Configuration Object
- Port Object
Application Specific Objects:
- Discrete Input Point
- Register Object
- Discrete Input Point Object
- Discrete Output Point Object
- Analog Input Point Object
- Analog Output Point Object
- Presence Sensing Object
- Group Object
- Discrete Input Group Object
- Discrete Output Group Object
- Discrete Group Object
- Analog Input Group Object
- Analog Output Group Object
- Analog Group Object
- Position Sensor Object
- Position Controller Supervisor Object
- Position Controller Object Block
- Sequencer Object
- Command Block Object
- Motor Data Object
- Control Supervisor Object
- AC/DC Drive Object
- Overload Object
- Softstart Object
- Selection Object
- S-Device Supervisor Object
- S-Analog Sensor Object
- S-Analog Actor Object
- S-Single Stage Controller Object
- S-Gas Calibration Object
- Trip Point Object
Network Specific Objects:
- DeviceNet Object (specific to DeviceNet)
- ControlNet Object (specific to ControlNet)
- ControlNet Keeper Object (specific to ControlNet)
- ControlNet Scheduling Object (specific to ControlNet)
- TCP/IP Interface Object (specific to EtherNet/IP)
- Ethernet Link Object (specific to EtherNet/IP)
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.
| Mandatory | Optional |
|---|---|
| Vendor ID | State |
| Device Type | Configuration Consistency Value |
| Product Code | Heartbeat Interval |
| Revision | Languages Supported |
| Status | |
| 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:
- Generic Device
- AC Drives
- Motor Overload
- Limit Switch
- Inductive Proximity Switch
- Photoelectric Sensor
- General Purpose Discrete I/O
- Resolver
- Communication Adapter
- ControlNet PLC - Position Controller
- DC Drives
- Contactor
- Motor Starter
- Soft Start
- Human Machine Interface
- Mass Flow Controller
- Pneumatic Valves
- Vacuum Pressure Gauge
- ControlNet Physical Layer
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:
- Printed data sheet - configuration tools prompt the user for configuration information and relay the information input by the user to the device.
- Parameter Objects and Parameter Object Stubs - parameter objects provide a full description of all of the device's configurable data, allowing the configuration tool to access all parameters. For smaller devices, an abbreviated version of the parameter object called a parameter object stub may be used. The stub still provides the configuration tool with access to the device parameters, but does not provide any semantics.
- Electronic Data Sheet (EDS) - the electronic data sheet supplies all of the semantic information provided by a full parameter object, and can be used together with a parameter object stub to provide the full functionality of a parameter object without burdening the device itself with all of the overhead.
- Configuration Assembly - a configuration assembly can be used in conjunction with any of the previously described methods to perform device configuration before uploading the configuration parameters to the device, or to download an existing set of configuration parameters.
Services
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.