As technology continues to advance, the industrial landscape is becoming increasingly connected and automated. To facilitate seamless communication between devices and systems, a standardized protocol is essential. Again, a one size fits all solution is not possible considering the vast possibilities of application scenarios and processing/response requirements. When we have touched up on many protocols like Modbus, Profibus, PROFINET, once another important protocol that finds wide adoption is the Common Industrial Protocol (CIP), a powerful and versatile communication protocol developed by the Open DeviceNet Vendor Association (ODVA). In this comprehensive guide, we will delve deep into the world of the Common Industrial Protocol and explore its various aspects, from its basic definition to its varied implementations.
At its core, the Common Industrial Protocol is a protocol that enables different industrial automation devices to communicate with each other effectively and efficiently using an Object-oriented approach. By bringing in this well proven design methodology via the Common Industrial Protocol, ODVA modernized the industrial automation and control systems significantly. The Common Industrial Protocol enables transfer of control-oriented data as well as the configuration and diagnostics information. With peer-to-peer communication, sensors and actuators can be monitored and managed by the controllers seamlessly. Being independent of underlying media and communication technology, it provides a unified framework for data exchange, device control, and configuration in industrial environments. By clearly defining a common set of rules and structures and ensuring it via compliance suites, the Common Industrial Protocol allows devices from different manufacturers to seamlessly interact with each other. As a foundational industrial network protocol, CIP underpins several ODVA-defined network adaptations including EtherNet/IP, DeviceNet, ControlNet, and CompoNet. Organizations looking to deploy Embien's cross-domain embedded services across industrial verticals will find the Common Industrial Protocol at the heart of most modern factory communication stacks.
The Common Industrial Protocol sits primarily at the higher application layer of the standard OSI layer model. By defining only above the transport layer, it effectively enables implementation to be done on any communication interface. In fact, ODVA defines many protocols for the lower layers too as depicted in the below diagram.
CIP OSI Layer Mapping
EthernetIP: EthernetIP has revolutionized the way industrial devices communicate. By leveraging the power of Ethernet technology and proven TCP/UDP communication, it provides a high-speed and reliable communication solution for transferring Common Industrial Protocol data. DeviceNet: DeviceNet is a widely adopted protocol that offers a cost-effective solution for industrial communication by leveraging the popular CAN (Controller Area Network) protocol. DeviceNet utilizes a simple and robust network architecture, making it easy to install and maintain. CompoNet: CompoNet adapts the Common Industrial Protocol to TDMA (Time Domain Multiple Access) on a simple 2-wire physical layer. Derived from RS485 specifications and leveraging the Manchester signal coding technology along with a pulse transformer in the physical layer, CompoNet enables reliable communication even over inexpensive lines. ControlNet: ControlNet runs on RG-6 coaxial cable and in some applications over the optical fibers. With speeds reaching up to 5 Mbps, ControlNet supports different bus topologies such as trunkline, dropline, star or tree. It supports fully redundant cables and communication is highly deterministic and scheduled enabling reliable throughputs.Though not defined, it is technically possible to run the Common Industrial Protocol over any other physical layers and may get defined as well in the future.
In the Common Industrial Protocol, every participating entity is called a Node. Each node contains a collection of objects. Each object in turn represents a particular functional component in the node. CIP Object Model elements are organized as classes, instances, and attributes.
CIP Node, Classes and Objects
As with the Object-oriented programming (OOP) concept, the CIP Object Model uses classes to represent the same kind of system component. Each object is an instance of a particular class. Objects represent the actual implementation of the physical component. Like the OOP members, each characteristic of an object is called an Attribute. While the object attribute values are unique to the object instance, there are some class-specific attributes too. The services are equivalent to the OOP method. Just like all objects in OOP extending the base class's methods, there are common services to be supported by all CIP Object Model objects while some are defined specific to the object.
Let us see with an example. Consider the case of the Analog Input Point Object as depicted in the above picture. It has a Class attribute called 'Revision' which determines the attributes/services supported by its instances. Some of the Instance Attributes includes 'Value' that gives the current value of the input, 'Input Range' that gives an idea about the possible range of the input, and 'Value Data Type' that specifies the data type of the 'Value' i.e., whether it is uint16_t, int16_t, float, uint32_t etc. Some of the attributes will be mandatory for implementation while others are optional to be defined as needed by the OEM.
Some of the common services are Get_Attribute_Single to fetch a given instance attribute, Get_Attributes_All to fetch all attributes etc. Many objects do not have object-specific services. The CIP Object Model is one of the most powerful aspects of the Common Industrial Protocol, enabling a consistent programming interface across vastly different device types.
The Common Industrial Protocol is essentially a connection-oriented protocol. Each CIP connection, once established, is assigned a Connection ID (CID). If it is a bi-directional data transfer, then 2 CIDs are assigned. There are 2 connection types supported in the CIP Messaging Protocol — Explicit and Implicit. Explicit messages are message-based and are used for asynchronous data transfer to/from a device. Implicit message connections (I/O messages) are used for transferring control information. There is typically a Connection Class/Object in the node that originates/accepts connections from other nodes and manages the entire life cycle of each connection.
A server is an object that provides services to another object, which is the client that is an initiator of the message. Similarly, a producer node transmits data while the consumer receives the same. A server or client could be a producer or a consumer and is use-case dependent. The CIP Messaging Protocol distinguishes between these roles at connection setup, giving the Common Industrial Protocol its flexibility across different topologies.
The CIP Messaging Protocol also defines the exact packet structures and error codes that all Common Industrial Protocol implementations must conform to. By standardizing CIP Messaging Protocol behavior, ODVA ensures that devices from different vendors interoperate without custom integration work. Teams working on electronic manufacturing services for CIP-enabled products rely on this predictability to streamline PCB bring-up, protocol stack integration, and conformance testing.
Each class, object, and attribute is defined with a predefined numerical value specified by the CIP Object Model standard. By having these standard values, it is possible for both the server and client to speak in the same language. For example, class code of 0x01 represents the Identity Object (information about the node) while 0x0a represents Analog Input Point. Similarly, within the Analog Input Point, class attribute value of 0x01 represents 'Revision' while Instance Attribute value of 0x03 represents the value. The Get_Attribute_Single service is represented by a value of 0x0E.
ODVA has defined 100+ objects covering most of the physical components being used in the industrial automation systems. Within each of these objects all the necessary attributes and services are defined with a very high level of clarity. With these specified Common Industrial Protocol objects, developers can define any actuator, sensor, or controller. In case any new features or custom components need to be defined, it is possible to extend them as with any true OOP implementation.
Further extending the concept of the CIP Object Model, the Common Industrial Protocol standard also specifies ODVA CIP device profiles. As many of the commonly used devices share common traits, ODVA CIP device profiles are created as a predefined collection of supported objects along with the data format through which other nodes can interact. Any device implementing a particular profile among the ODVA CIP device profiles will exhibit the same behavior and will have the same set of configurable attributes.
CIP Device Profile
Some of the entries among the ODVA CIP device profiles include a Photoelectric Sensor device, AC/DC Drive Device, Barcode Scanner Device, and Encoder Device. While the number of instances will vary between two devices of the same profile, the object attributes and services supported will be the same for both. The existence of well-defined ODVA CIP device profiles is what makes the Common Industrial Protocol a truly plug-and-play industrial network protocol across a wide range of application categories.
While the CIP Object Model defines the device profile to the detail of underlying object attributes, practically there is a need for a standard format to be consumed by the device user or configuration tool. For this purpose, ODVA defines an ASCII text file format called the Electronic Data Sheet (EDS file). Manufacturers of each Common Industrial Protocol device must provide an EDS file that includes identity information (vendor ID, device type, etc.), communication parameters, supported objects, IO structure, etc.
These EDS files are consumed by the engineering tool that implements the scanner, configures the device as mentioned, and receives data in the specified format. With CIP electronic data sheets, users can easily configure devices by selecting the desired options from a user-friendly interface. The data sheets provide a comprehensive overview of a device's capabilities, allowing users to make informed decisions during the configuration process. Typically, the EDS file must be validated and approved by ODVA/partners when Common Industrial Protocol conformance for the devices is being obtained. Embien’s product engineering and RF system design services enable connected industrial products that leverage CIP for seamless communication and interoperability.
The Common Industrial Protocol is a foundational industrial network protocol that brings object-oriented design discipline to automation, enabling consistent behavior across ODVA CIP device profiles on any physical layer. The CIP Object Model and CIP Messaging Protocol together define a complete framework that ensures interoperability and scalability for modern connected factories.
Embien delivers Common Industrial Protocol-compatible embedded solutions across automotive, industrial, and medical domains, bridging hardware and protocol expertise for seamless device integration.
From PCB assembly to full-device manufacturing, Embien's electronics manufacturing services support CIP-enabled industrial devices built for reliability and conformance to ODVA CIP device profiles.
A practical deployment of wireless embedded communication for smart metering, demonstrating Embien's capability in industrial IoT device development.