You buy an EtherNet/IP AC drive from Rockwell Automation. It works with your ControlLogix PLC. You later buy a different AC drive from a different manufacturer — say, Yaskawa or ABB — and it works with the same PLC too. Why? Because both drives implement the CIP AC Drive Device Profile (Device Type 0x02). They expose the same objects in the same way, produce the same kinds of I/O data, and accept the same configuration mechanisms. The PLC doesn’t care which vendor built the drive — it knows how to talk to any “AC Drive” because the AC Drive profile is publicly defined.
This is the value of CIP device profiles: interoperability and interchangeability among devices of the same type, regardless of manufacturer. Defined in ODVA Volume 1 Chapter 6, device profiles specify the minimum standards a product must meet to claim a particular device type — what objects it must implement, what I/O data format it must produce, what configuration it must accept.
This article explains how CIP device profiles work, what they specify, the complete catalog of profiles, and how they relate to EDS files and electronic keying. For broader CIP context, see the CIP Protocol Complete Guide and the CIP Object Model Explained article.
Table of Contents
What CIP device profiles are in one paragraph
A CIP device profile is a formal specification of the minimum standards a product must meet to claim a particular device type — what CIP objects it must implement, what I/O data format it produces and consumes, what configuration data it accepts. Per Volume 1 Chapter 6, every device profile contains three parts: an object model specifying which CIP objects must be present, the I/O data format specifying what assemblies and connections the device exposes, and the configuration data specifying what attributes can be set. Each profile is identified by a Device Type number — a 16-bit value carried in the device’s Identity Object (Class 0x01, Attribute 2). Common Device Types: 0x02 (AC Drive), 0x07 (General Purpose Discrete I/O), 0x0C (Communications Adapter), 0x22 (Encoder), 0x25 (CIP Motion Drive). The Device Type lets engineering tools recognize what kind of device they’re talking to and apply appropriate configuration screens.
Why CIP device profiles exist
Per Volume 1 Section 6-1, device profiles address two distinct industrial requirements:
Interoperability
The ability for different vendors’ products to work together on the same network. When Rockwell’s PLC talks to Yaskawa’s drive, both must agree on:
- What objects the drive exposes
- What I/O data the drive produces and consumes
- What format that I/O data uses
- What configuration mechanisms the drive accepts
Without a shared definition, every vendor would do these things differently and cross-vendor systems would be impossible. Device profiles standardize the interface contract between any compliant device and any compliant controller.
Interchangeability
The ability for one vendor’s product to be replaced by another vendor’s without engineering changes. When the Rockwell AC drive at a plant fails after 8 years and Rockwell no longer makes that model, an engineer should be able to install a different vendor’s AC drive and have it work without major reconfiguration.
This requires more than interoperability — it requires that the replacement device produce identical behavior. The CIP AC Drive profile defines the behavior precisely enough that any compliant drive can replace any other compliant drive from any vendor. In practice, configuration details vary somewhat between vendors, but the basic functional substitution is possible.
The spec puts it directly: “To provide interoperability and promote interchangeability by like device types, there must be some consistency between devices of the same type. That is, there must be a core ‘standard’ for each device type.”
What a device profile contains
Per Volume 1 Section 6-1, every CIP device profile shall contain:
- An object model for the device type
- The I/O data format for the device type
- Configuration data and the public interface(s) to that data
Engineers can adopt existing profiles, extend them with vendor-specific additions, or define entirely new profiles (typically through ODVA committees) for novel device types.
The Standard Object Model
Per Volume 1 Section 6-2 and Table 6-2.2, every CIP device — regardless of profile — must implement these minimum objects:
| Object Class | Status | # of Instances | Required when |
|---|---|---|---|
| Identity Object (0x01) | Required | 1 | Always |
| Message Router Object (0x02) | Required | 1 | Always |
| DeviceNet Object (0x03) | Conditional | 1 | CIP network = DeviceNet |
| Ethernet Link Object (0xF6) | Conditional | 1+ | CIP network = EtherNet/IP |
| TCP/IP Interface Object (0xF5) | Conditional | 1 | CIP network = EtherNet/IP |
| ControlNet Object | Conditional | 1 | CIP network = ControlNet |
| CompoNet Link Object | Conditional | 1 | CIP network = CompoNet |
| Connection Object (0x05) | Conditional | 2 | If device supports connections |
| Connection Manager Object (0x06) | Conditional | 1 | If device supports connections |
The pattern: every device has Identity + Message Router (always), plus the network-specific link objects (one per CIP network type), plus Connection objects if the device participates in connections.
These minimum objects are what gives every CIP device a baseline of functionality:
- Identity Object — every device can be identified (read its Vendor ID, Product Code, etc.)
- Message Router Object — every device can route CIP messages to its internal objects
- Network-specific link objects — every device has appropriate network configuration
- Connection objects — devices that exchange I/O can do so
For deeper coverage on each:
- CIP Identity Object Explained
- CIP Connection Manager Object Explained
- CIP TCP/IP Interface Object Explained
- CIP Ethernet Link Object Explained
Beyond these minimums, each device profile adds application-specific objects appropriate to the device type. An AC Drive profile adds drive-specific objects. An Encoder profile adds position-feedback objects. A CIP Motion Drive profile adds motion-related objects (including the Motion Axis Object, Class 0x42).
Required vs Optional vs Conditional objects
Per Volume 1 Section 6-2.1, the spec uses three classifications for objects in a profile:
| Designation | Meaning |
|---|---|
| Required | Must be implemented in every device of this type |
| Optional | May be implemented; the device works without it but doesn’t have whatever feature the object provides |
| Conditional | Required IF a specific condition is met (e.g., “if device supports connections,” “if CIP network is EtherNet/IP”) |
The Optional category is important: it allows vendors to add functionality beyond the device profile minimum without breaking compliance. A vendor can add a Custom Configuration Object to their drive — making it more capable — and still ship a “CIP AC Drive Device Type 0x02” product.
Critically, the spec requires that Optional behavior defaults appropriately at power-up: per Section 6-2.1, “At power up, this additional behavior shall default in a manner such that the device’s behavior appears to be identical to the basic behavior defined for that device type.” So even with vendor extensions, a fresh-out-of-box device behaves identically to the standard profile — only once configured does the vendor-specific functionality activate.
Device Profile Numbering Scheme
Per Volume 1 Section 6-6 and Table 6-6.1, Device Type numbers are allocated in distinct ranges:
| Range (hex) | Allocation | Quantity |
|---|---|---|
| 00 – 63 | Publicly Defined | 100 profiles |
| 64 – C7 | Vendor Specific | 100 profiles |
| C8 – FF | Reserved by CIP | 56 profiles |
| 100 – 2FF | Publicly Defined | 512 profiles |
| 300 – 4FF | Vendor Specific | 512 profiles |
| 500 – FFFF | Reserved by CIP | 64,256 profiles |
Publicly Defined profiles are documented in ODVA specifications. Any vendor can build a product claiming a publicly-defined profile and get interoperability with any compliant controller.
Vendor Specific profiles let manufacturers create proprietary device types without publishing the specification. A vendor can use a Vendor Specific Device Type number for their custom product — but customers cannot use that product as a direct replacement for a competitor’s similar product, and competitors cannot interoperate with it without proprietary integration.
Per the spec: “Even vendor specific device profiles are required to support the minimum objects listed in section 6-2.1.” So vendor-specific devices still implement Identity, Message Router, network link objects, etc. — they just don’t follow a standardized profile for the application-specific objects.
ODVA encourages vendors to adopt publicly-defined profiles whenever possible because it benefits everyone: customers get interchangeability, vendors get easier integration with multi-vendor systems, and the industry as a whole gets a healthier ecosystem.
Complete catalog of CIP device profiles
Per Volume 1 Table 6-7.1, the active device profiles are:
Publicly defined profiles
| Device Type (hex) | Profile Name | Section |
|---|---|---|
| 00 | Generic Device | 6-8 |
| 02 | AC Drive | 6-15 |
| 03 | Motor Overload | 6-19 |
| 04 | Limit Switch | 6-9 |
| 05 | Inductive Proximity Switch | 6-10 |
| 06 | Photoelectric Sensor | 6-11 |
| 07 | General Purpose Discrete I/O | 6-12 |
| 09 | Resolver | 6-22 |
| 0C | Communications Adapter | 6-13 |
| 0E | Programmable Logic Controller | 6-33 |
| 10 | Position Controller | 6-18 |
| 13 | DC Drives | 6-15 |
| 15 | Contactor | 6-25 |
| 16 | Motor Starter | 6-27 |
| 17 | Softstart Starter | 6-28 |
| 18 | Human-Machine Interface (HMI) | 6-30 |
| 1A | Mass Flow Controller | 6-31 |
| 1B | Pneumatic Valves | 6-26 |
| 1C | Vacuum Pressure Gauge | 6-32 |
| 1D | Process Control Valve | 6-35 |
| 1E | Residual Gas Analyzer | 6-37 |
| 1F | DC Power Generator | 6-38 |
| 20 | RF Power Generator | 6-39 |
| 21 | Turbomolecular Vacuum Pump | 6-36 |
| 22 | Encoder | 6-21 |
| 23 | Safety Discrete I/O Device | See Volume 5 (CIP Safety) |
| 24 | Fluid Flow Controller | 6-40 |
| 25 | CIP Motion Drive | 6-41 |
| 26 | CompoNet Repeater | See Volume 6 (CompoNet) |
| 27 | Mass Flow Controller, Enhanced | 6-42 |
| 28 | Modbus Device | See Volume 7 (Modbus Integration) |
| 32 | ControlNet Physical Layer Component | 6-34 |
Several historical Device Type numbers have been obsoleted and reassigned over time per Volume 1 Table 6-7.2:
| Obsolete Device Type | Previous Profile |
|---|---|
| 0x01 | Control Station (was reassigned) |
| 0x08 | Encoder (reassigned to 0x22) |
| 0x0A | General Purpose Analog I/O (now Type “Not yet assigned”) |
| 0x0D | Barcode Scanner (now Type “Not yet assigned”) |
| 0x11 | Weigh Scale (now Type “Not yet assigned”) |
| 0x12 | Message Display (now Type “Not yet assigned”) |
| 0x14 | Servo Drives (now Type “Not yet assigned”) |
| 0x19 | Pneumatic Valves (reassigned to 0x1B) |
Engineering tools sometimes encounter old devices reporting obsoleted Device Types — modern tools handle these by falling back to the Generic Device profile (0x00) when the reported Device Type is unrecognized.
The most-deployed profiles in EtherNet/IP installations
Three profiles dominate real-world EtherNet/IP networks:
0x07 — General Purpose Discrete I/O
The bread-and-butter profile for digital input/output blocks. Point I/O blocks, Block I/O modules, discrete I/O adapters — all use this profile. Defines basic input and output assembly structures, fault behavior, status reporting.
0x0C — Communications Adapter
Used by EtherNet/IP adapters that bridge between the EtherNet/IP network and a backplane of modules. The 1734-AENT Point I/O adapter, the 1738-AENT, and similar products all use Device Type 0x0C. The adapter doesn’t have its own I/O — it’s a bridge to modules behind it.
0x02 — AC Drive
Variable frequency drives, both V/Hz and vector control. PowerFlex 525, PowerFlex 755, third-party drives from Yaskawa/ABB/Schneider — all use Device Type 0x02. The profile defines speed reference, frequency feedback, drive enable/disable, fault status, and the basic configuration parameters every AC drive needs.
These three Device Types alone account for the vast majority of EtherNet/IP devices deployed in industry.
How profiles relate to EDS and electronic keying
Device profiles and EDS files are tightly coupled:
| Concept | Where it lives | What it specifies |
|---|---|---|
| Device Type | Identity Object Attribute 2, EDS [Device] ProdType | What kind of device this is |
| Device Profile | ODVA spec (Volume 1 Chapter 6) | What that device type must do |
| Vendor ID | Identity Object Attribute 1, EDS [Device] VendCode | Who made the device |
| Product Code | Identity Object Attribute 3, EDS [Device] ProdCode | Which model from that vendor |
| EDS File | Manufacturer-provided | Specific device’s capabilities |
When Studio 5000 (or any CIP configuration tool) connects to a device, it reads the device’s Identity Object to learn the Device Type, then looks up the matching EDS file. The EDS file tells the tool what assemblies are available, what parameters can be configured, and what connections can be opened.
Electronic keying in Forward_Open validates that the actual device matches expected values. The Device Type is one of the four values checked (along with Vendor ID, Product Code, and Revision). Per our CIP Forward_Open Service Explained article, electronic keying mismatches return:
- 0x0114 — Vendor ID or Product Code mismatch
- 0x0115 — Device Type mismatch
- 0x0116 — Revision mismatch
So when you configure your PLC for “1734-AENT” (a Communications Adapter, Type 0x0C) and the actual device responds as “1734-AENTR” (different Product Code) or different revision, the Forward_Open fails with electronic keying error. The Device Type itself rarely mismatches in production because you’d see it immediately during initial device discovery.
For more on EDS structure, see our EDS Files Explained article.
I/O Data Format in profiles
Per Volume 1 Section 6-3, each device profile defines the I/O data format that devices of that type produce and consume. This includes:
- Required Assembly Instances — which Assembly Object instances must exist
- Required data within each assembly — what bits/bytes carry what meaning
- Optional data extensions — additional data devices may include
For an AC Drive (Type 0x02), the profile specifies:
- An Output Assembly carrying at minimum: Drive Run, Drive Stop, Forward/Reverse, Speed Reference
- An Input Assembly carrying at minimum: Running, At Reference Speed, Faulted, Speed Feedback
A vendor implementing AC Drive 0x02 must produce these data items at the specified positions. They can add vendor-specific data after the required items, but the required items must be present in the specified positions.
This is what lets a controller communicate with any AC drive: the first 4 bytes are always Drive Run + Stop + Direction + Speed Reference, regardless of which vendor made the drive.
For more on Assembly Objects and how they carry I/O data, see our CIP Assembly Object Explained article.
Configuration data in profiles
Per Volume 1 Section 6-4, each profile specifies configuration data the device accepts. For an AC Drive, this includes:
- Acceleration time
- Deceleration time
- Maximum speed limit
- Minimum speed limit
- Direction of rotation
- Motor parameters (V/Hz curve points, base voltage/frequency, etc.)
Configuration may be delivered via:
- Explicit Set_Attribute_Single messages on individual attributes
- A Configuration Assembly (an Assembly Object instance carrying multiple configuration parameters)
- A Parameter Object (Class 0x0F) — older approach but still common
- The EDS file — applied automatically during device commissioning
The profile defines which mechanisms apply for each device type. Some profiles require Configuration Assemblies; others rely on individual attribute writes.
Extended Device Profiles
Per Volume 1 Section 6-5, an Extended Device Profile is a device profile that extends or combines existing profiles. Examples:
- A motion-capable AC drive might claim both AC Drive (0x02) and CIP Motion Drive (0x25)
- A safety drive might claim both AC Drive and Safety Drive
Extended profiles let devices that span multiple categories claim all relevant profile compliance. The device’s Identity Object Attribute 2 contains one primary Device Type, but the EDS file and product documentation indicate the additional profiles supported.
How to read what a device implements
When troubleshooting or commissioning, engineers often need to check what profile a device implements:
- Read the Identity Object Attribute 2 (Device Type) via Get_Attribute_Single
- Cross-reference the returned value against Table 6-7.1 above
- Open the device’s EDS file and look at the
[Device]ProdTypeStr field for human-readable text
If the device returns Device Type 0x02, you know it’s an AC Drive and you can apply standard AC Drive operations. If it returns 0x07, it’s General Purpose Discrete I/O. If it returns 0x0C, it’s a Communications Adapter and you need to query its modules separately. If it returns an unfamiliar Device Type, consult the device’s manual or contact the vendor.
For reading Identity Object content, see our CIP Identity Object Explained article.
Common profile-related issues
| Symptom | Likely cause | What to check |
|---|---|---|
| Forward_Open Extended Status 0x0115 (Device Type mismatch) | Wrong Device Type in your configuration | Verify Device Type in EDS matches actual device |
| Studio 5000 doesn’t recognize the device | EDS for this Device Type not registered | Register the device’s EDS file |
| Device shows as “Generic” in browser | Device’s Identity Object returns Type 0x00 | This is intentional — Generic Device profile |
| Replacement drive doesn’t work | Profile mismatch despite same vendor | Different product within profile category — check Product Code |
| Cross-vendor drive replacement fails | Vendor-specific extensions in original config | Configuration relies on optional extensions — verify replacement supports them |
| Device reports obsolete Device Type | Old firmware reporting historical type | Modern tools fall back to Generic Device; update firmware if possible |
How device profiles compare across protocols
For context across industrial networks:
| Protocol | Profile mechanism | Defining body |
|---|---|---|
| CIP (EtherNet/IP, etc.) | Device Type numbers + profile specs in Volume 1 Chapter 6 | ODVA |
| PROFINET | Generic Station Description (GSD) + PROFINET profiles (Drives PA, PROFIenergy, etc.) | PI (PROFIBUS & PROFINET International) |
| EtherCAT | Device profiles via CANopen + ETG specifications | EtherCAT Technology Group |
| Modbus TCP | No formal profile system; vendor-specific implementation | Modbus Organization |
| OPC UA | Information models for specific industries (companion specs) | OPC Foundation |
CIP’s device profile mechanism is one of the more mature systems — it’s been refined over 20+ years, covers 30+ device categories, and has strong adoption across multiple vendors. The Modbus side has historically lacked formal profiles, which is why Modbus device interchangeability is much weaker than CIP interchangeability.
For broader comparison with PROFINET, see our PROFINET vs EtherNet/IP article.
Frequently asked questions
What is a CIP device profile?
A CIP device profile is a formal specification that defines what a particular type of device must implement to be considered compliant — what CIP objects it must expose, what I/O data format it produces and consumes, and what configuration it accepts. Profiles enable interoperability and interchangeability among devices of the same type from different manufacturers. Defined in ODVA Volume 1 Chapter 6.
What is the Device Type for an AC Drive in CIP?
The Device Type for an AC Drive is 0x02 (decimal 2). Any product claiming to be an AC Drive must implement the AC Drive Device Profile per ODVA Volume 1 Section 6-15. The Device Type appears in the device’s Identity Object Attribute 2 and in the EDS file’s [Device] ProdType field. Common related types: DC Drive = 0x13, Servo Drive = “Not yet assigned” (historically 0x14, now obsoleted), CIP Motion Drive = 0x25.
Why does CIP have device profiles?
Device profiles solve two industrial needs: interoperability (different vendors’ products work together) and interchangeability (replacing one vendor’s product with another’s). Without profiles, every vendor would implement devices differently and cross-vendor systems would require custom integration. Profiles standardize the interface contract between any compliant device and any compliant controller, enabling multi-vendor systems and product substitution.
What is the difference between required, optional, and conditional objects in a profile?
Required objects must be implemented in every device of that profile type. Optional objects may be implemented — the device works without them but lacks whatever capability the object provides. Conditional objects are required IF a specific condition is met (e.g., “if device supports connections” or “if CIP network type is EtherNet/IP”). Every CIP device, regardless of profile, must implement the minimum objects from Volume 1 Section 6-2.1: Identity, Message Router, and network-specific link objects.
How are CIP Device Type numbers allocated?
Per Volume 1 Table 6-6.1, Device Type numbers fall in three ranges: Publicly Defined (00-63 hex and 100-2FF hex) for ODVA-standardized profiles, Vendor Specific (64-C7 hex and 300-4FF hex) for proprietary device types, and Reserved by CIP for future expansion. Publicly Defined profiles are documented in Volume 1 Chapter 6. Vendor Specific profiles let manufacturers create custom device types without publishing the specification — but they sacrifice interchangeability.
What is the most-deployed CIP device profile?
The three most-deployed profiles in EtherNet/IP installations are: General Purpose Discrete I/O (0x07) for digital I/O blocks, Communications Adapter (0x0C) for EtherNet/IP-to-backplane adapters, and AC Drive (0x02) for variable-frequency drives. These three profiles account for the vast majority of devices in production EtherNet/IP networks.
What is the difference between a device profile and an EDS file?
A device profile is an ODVA-published specification that defines what a device type must do (e.g., “an AC Drive must implement these objects and produce these I/O data items”). An EDS file is a specific device’s electronic data sheet — a manufacturer-provided text file describing the actual capabilities of one specific product (e.g., “the PowerFlex 525-D is an AC Drive that exposes assembly instances 70, 71, 72 with these specific data layouts”). The profile is the rulebook; the EDS is one device’s compliance documentation.
What does Device Type 0x00 mean?
Device Type 0x00 is the Generic Device profile. It represents a device that doesn’t fit any specific publicly-defined profile but implements the minimum CIP objects required of every device. The Generic Device profile is often used by configuration tools as a fallback when they don’t recognize the actual Device Type — the device can still be communicated with at the minimum-object level even without specific profile knowledge.
Can a device implement multiple device profiles?
Yes — per Volume 1 Section 6-5, Extended Device Profiles combine or extend existing profiles. A motion-capable AC drive might claim both AC Drive (0x02) and CIP Motion Drive (0x25). A safety drive might claim both Drive and Safety profiles. The device’s Identity Object Attribute 2 carries one primary Device Type, but the EDS file and product documentation list additional profiles supported. Each profile’s required objects and data must be implemented.
What happens if a device reports an unrecognized Device Type?
Modern configuration tools handle unrecognized Device Types by falling back to the Generic Device profile. The device can still be queried for its Identity Object content, basic objects (Message Router, link objects), and any vendor-specific objects documented in its EDS file. The tool won’t be able to apply profile-specific UI screens (like “AC Drive Configuration” or “Encoder Setup”) but basic communication still works.
How do device profiles relate to electronic keying in Forward_Open?
Electronic keying validates four Identity Object values: Vendor ID, Device Type, Product Code, and Revision. Device Type mismatch during Forward_Open returns Extended Status 0x0115. So if your configuration expects an AC Drive (Device Type 0x02) and the actual device responds as something else (e.g., a Generic Device 0x00), the Forward_Open fails. Device Type mismatches are rare in production because the mismatch is usually caught earlier during device discovery — but they can occur when wrong EDS files are registered for similar-named devices.