What Is the CIP Object Model?
Every EtherNet/IP or DeviceNet device you configure is, internally, a collection of objects arranged the same way regardless of vendor. Understanding that structure is what lets you read a device manual, decode an explicit message, and know exactly where a value lives. This page explains the CIP object model - the class, instance, attribute, and service scheme that the Common Industrial Protocol uses to describe every device on the network.
CIP Object Model in one line: The CIP object model organizes every device into objects, where a class is a type of thing (for example the Identity object), an instance is one specific occurrence of that class, an attribute is a data value inside the instance, and a service is an action such as Get_Attribute_Single. Addressing a value means naming its class, instance, and attribute.
How Class, Instance, Attribute, and Service Fit Together
The Common Industrial Protocol describes a device as a set of objects, and every object is an instance of a class. A class is the abstract definition of a kind of thing - the Identity object class, the Assembly object class, the TCP/IP Interface object class - and it carries a numeric class code. An instance is one concrete occurrence of that class inside a particular device, numbered from 1. A device with four analog input channels might expose four instances of an input object, each holding one channel's data. Instance 0 is a special case that addresses the class itself rather than any single occurrence, which is how you read class-level attributes like how many instances exist.
Inside each instance are attributes, the actual data values. An attribute has an attribute ID and holds something concrete - a serial number, a status word, a configuration setting, a process value. To name any single piece of data in a CIP device you therefore give three numbers: class, instance, attribute. This triple is the address, and it is identical whether the device is on EtherNet/IP, DeviceNet, or another CIP network, which is the whole point of a network-independent object model.
Services are the verbs. A service is an operation you invoke against a class, an instance, or an attribute - Get_Attribute_Single to read one attribute, Set_Attribute_Single to write one, Get_Attribute_All to read a defined block at once, plus object-specific services a vendor may define. An explicit message is, at bottom, a service code plus a path to the class, instance, and attribute it acts on. When you build a MSG instruction in a controller you are filling in exactly those fields.
Required Objects Every CIP Device Carries
CIP defines a small set of objects that every conforming device must implement, and knowing them makes an unfamiliar device readable on sight. The Identity object (class code 0x01) holds vendor ID, device type, product code, revision, serial number, and status - it is what electronic keying and the browse tools read. The Message Router object routes explicit requests to the target object inside the device. The Assembly object groups scattered attributes into the single blocks of I/O data that implicit messaging moves. The Connection Manager object sets up and tears down the connections that carry that I/O.
For EtherNet/IP specifically, two more objects matter constantly. The TCP/IP Interface object holds the device's IP configuration, and the Ethernet Link object holds per-port link status, speed, and duplex. When you commission a device or diagnose a duplex mismatch, those are the objects you are reading, even if the configuration tool hides the class and instance numbers behind a friendly screen. The vendor manual lists them precisely, and the EtherNet/IP protocol overview shows how these objects ride on standard TCP and UDP.
Why the Object Model Matters in Practice
The object model is not academic. When a device manual tells you to read status from class 0x66, instance 1, attribute 3, it is handing you a CIP path, and a MSG instruction or explicit-message tool reads it directly without any special driver. When an integration guide says a sensor exposes its process value in the Assembly object, you know that value will arrive in the implicit I/O connection rather than needing a separate poll. The model turns vendor documentation into something you can act on mechanically.
It also explains why a CIP MSG instruction can reach data that never appears in the cyclic I/O. Implicit messaging moves only what the Assembly object collects; everything else - diagnostics, configuration, event counters - lives in other objects reachable only by explicit request. A monitoring platform such as Merobix reads the digitized tags a controller has already gathered from these objects; it does not itself open CIP connections to the raw device. The controller resolves the object model into named tags, and the SCADA layer trends those tags.
Frequently Asked Questions
What is the difference between a class and an instance in CIP?
A class is the type definition - for example the Assembly object class - and carries a fixed class code shared across all devices. An instance is one specific occurrence of that class inside a particular device, numbered from 1. Reading data means naming both: the class says what kind of object, the instance says which one of them, and the attribute says which value inside it.
How do I address a single value in a CIP device?
You give three numbers plus a service. The class code identifies the object type, the instance number identifies which occurrence, and the attribute ID identifies the value. A service such as Get_Attribute_Single then reads it. That class/instance/attribute path is exactly what you enter into a MSG instruction or an explicit-messaging tool, and it is the same on EtherNet/IP and DeviceNet.
Which CIP objects does every device have?
At minimum the Identity object, the Message Router object, the Connection Manager object, and usually an Assembly object. EtherNet/IP devices add the TCP/IP Interface object and the Ethernet Link object. These required objects mean an unfamiliar device is still readable: the Identity object always tells you what it is, and the Assembly object always holds its I/O data block.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.