CIP – The Common Industrial Protocol

CIP is a term I don’t like because it’s one of those terms that industrial communication technology nerds (like me) throw around that a lot of other people don’t understand. Every industry has them, and I abhor them everywhere. In real estate they use terms like encumbrance, deed-in-lieu and convertible arm that I think I understand, but couldn’t adequately explain to a real estate professional. The worst is NASA where sentences are 70% arcane acronyms – not exactly as bad as some nerd throwing the term CIP around.

CIP is the core of everything Rockwell does around industrial connectivity. It’s the fundamental technology for ControlNet, DeviceNet, CompoNet and EtherNet/IP. It provides the underpinnings that they all use to achieve the commonality they proclaim is the key benefit of all those CIP-based protocols.

CIP is like an operating system, but much less functional. An OS provides the core functionality designers can use to create a cell phone application, web server or the check-in terminal at the airport. CIP is not that generic, but it does provide the core functionality that can be used to transfer information around the factory floor from devices like scales, motor drives and valve blocks.

CIP is really two things: an object oriented model for the data in a device and a set of messages that interact with the object model. The object model part is what sometimes confuses people. The object model is a virtual model of the device. Objects mean something to anybody that’s studied computer science, but CIP objects have nothing to do with implementation of an industrial device.

Say you have a device like a flow meter. The flow meter may have only two data values: a flow and a temperature. If the flow meter is a CIP device, those two data values appear to the outside world as elements of one or more objects. There may be one object with two attributes: flow and temperature. Or there may be two objects, each with a single attribute. In either case, the implementation is irrelevant. A CIP device simply presents these data values to the outside world as if they are part of an object structure. The programmer may have implemented them that way or may not. It doesn’t matter – CIP defines the virtual representation.

Construction of the object model is probably the most important step in building an EtherNet/IP , DeviceNet, or any other CIP device. The object model is how the end user is going to interact with the device. It is how the end user is going to move data in and out of the device. If the object model is confusing or uses unsupported data types or data sizes that aren’t common to the end user, the device will be difficult for the end user to implement, and the product may fail in the marketplace.

CIP Object Model design requires the expertise of the device owner who understands the data and expertise from a designer familiar with how programmable controllers use that data. One without the other is a recipe for failure. The device owner must communicate what data is to be exposed over the CIP network, and the CIP expert must communicate the best practices to organize that data to effectively design a CIP Object Model.

In the next article in this series, I’ll discuss the required objects that are present in every CIP device.