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.
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:
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:
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.
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.
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.
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.
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 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 |
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.
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.
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.
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.
This article was first published on the TechnologyUK.net website in January 2009.