The EtherNet/IP Address Space is the key to EtherNet/IP. Everything else is useless without an Address Space. The transport layer, connections, and services exist to provide a Scanner with access to the Address Space of an Adapter device. Understanding the Address Space model and how Objects are represented in the Address Space is an important key to understanding EtherNet/IP.
The Address Spaces used by most automation technologies are flat, meaning that there is no hierarchical structure to them. Modbus is the best example of a flat Address Space. Modbus has 64K of register space and 64K of coil (bit) space. There are no organizing elements that define any type of structure to all those registers and coils.
If you remember chemistry class, each element in the periodic table is a substance that cannot be decomposed into other elements. In the EtherNet/IP Address Space, that elemental structure is an object. All CIP devices (EtherNet/IP, DeviceNet, CompoNet and ControlNet) organize data as a series of objects. Each object is simply an assembly of the related data values in a device. It is the core element of not only the Address Space but also Explicit Message Services, I/O Messaging and all the other services that form an EtherNet/IP Address Space.
The object organization of an EtherNet/IP device reflects how the device designer wants to organize the data in the device. There is no right way or wrong way to organize data. For example, if you had an EtherNet/IP flow meter that measured two flows and two temperatures, you could organize your data in any of the following ways:
- A single Flow Meter object with the object containing two flow values and two temperature values.
- Two objects: a Temperature object containing the two temperatures and a Flow object containing the two flow rates.
- Two objects: a Flow 1 Object containing the first flow and temperature and a Flow 2 object containing the second flow and a temperature.
Objects are categorized in three ways:
Required objects are the set of standard objects found in every EtherNet/IP Scanner and Adapter. These objects make it possible for network tools to access common data, like the vendor of the device, its product name, or its link speed, in a standard way no matter what the device is.
Required objects include objects like the Identity Object, the Message Router Object, the TCP/IP Interface Object and the Ethernet Link Object. These objects all have predefined object numbers which Scanners use to access the data in these objects.
Application objects are the objects that organize the data encapsulated by the device. These objects are specific to the device’s type and function. For example, a Motor object might organize the frequency, current rating and motor size. An Analog Input object might organize the type, resolution and current input value.
In most cases, the designer of the Address Space is free to assign object numbers for each of the objects in the Address Space. Object numbers of 64 and above can be used to define a device’s application objects.
For a large number of common devices, the application layer object numbers and data in the objects are predefined. All CIP devices of a specific device type are required to support an identical series of application objects. The collection of application objects that comprise a particular device type is known as the device profile. The CIP library defines a large number of profiles for many common devices.
Supporting a device profile allows end users to easily integrate common devices. Motor drives are the best example of this. All major motor drive vendors support the motor drive profile. A controller configured to connect to a motor drive with that profile can use any drive supporting the series of objects defined in the profile with minimal reconfiguration. There are device profiles (libraries of application objects) for drive systems, motion control, valve transducers, and more.
Data within Application Layer Objects is grouped into assembly objects. These objects are objects containing data from one or more Application Layer Objects. Assembly objects form a convenient package for transporting data between an Adapter and a Scanner. There is an input assembly which delivers input data to a Scanner, and an output assembly which delivers outputs to an Adapter.
Assemblies are defined by the Adapter vendor and can be composed as desired by the device vendor. For example, a vendor of a Temperature Controller with multiple temperature loops may define assemblies for each of the temperature loops and an assembly with data from all temperature loops. The user can then pick the assembly that is most suited for the application and how often they wish to access each assembly.
Assemblies are usually predefined by the vendor, but CIP also includes a mechanism by which the user can dynamically create an assembly from Application Layer Object attributes. Few, if any, devices include that mechanism.
Vendor Specific Objects
Objects not found in the profile for a device class are termed Vendor Specific. These objects are included by the vendor as additional features of the device. The CIP protocol provides access to these vendor extension objects as either application or required objects. This data is strictly of the vendor’s choosing and is organized in whatever method makes sense to the device vendor. In addition to specifying how device data is represented to the network, the CIP protocol specifies a number of ways in which that data can be accessed such as cyclic, polled, and change-of-state.
The term describing the data items organized by Objects is “Attributes.” Attributes are the individual data items of an Object. An Attribute can have any one of the CIP predefined types which include all the standard types you would expect like Integer, Boolean, Float…etc.
Just as with Objects there are required attributes and application attributes. Required attributes are the attributes specified in the required objects. For example, Attribute 1 of Object 1 (Identity Object) is the integer vendor ID. Application attributes are the attributes which contain data values particular to the application.
To learn even more about EtherNet/IP, visit our EtherNet/IP technology page: