Part of the autumn of 2018, I spent by implementing Ethernet/IP protocol into the D2000 KOM process.
This blog describes key features of the protocol and pitches in with some subjective opinions.
Introduction
In the Ethernet/IP protocol, the IP means industrial protocol. According to Wikipedia, the Ethernet/IP is one of the most widespread communication protocols in the United States. In the beginning, the protocol was developed by the Rockwell company; nowadays, there is the ODVA association (Open DeviceNet Vendor Association) which develops the CIP protocol (Common Industrial Protocol) and its specific adaptations on the Ethernet bus (Ethernet/IP), CAN (Device Net), Fieldbus (ControlNet) and a four-wire industrial bus derived from RS485 (CompoNet).
Currently, application specific extensions of the CIP protocol exist – the CIP Safety (communication resistant to outages), the CIP Motion (movement control) and the CIP Sync (very precise time synchronization on a level less than 100 ns).
The ODVA association has more than 300 members. Companies such as Rockwell, Honeywell or Schneider Electric are among them.
Standards
The CIP standard has almost 1,300 pages. It defines not only protocol but also describes the object model, object and attributes libraries, and device profiles.
The Ethernet/IP standard has another ca. 160 pages and contains specifications of the CIP protocol and objects for the Ethernet bus.
The CIP standard contains definitions of several tens of object Classes. Within one class (e.g. Analog Input), several Instances can be defined that are determined by their numbers. And every specific instance has defined Attributes, again addressed by their numbers. The standard states about each of them, whether the attribute is mandatory or optional, whether it is read-only or writable, and also defines its data type. Attributes can be simple (integers, strings, real numbers, and others), arrays of values, structure or arrays of structures.
So, the standard addressing contains the trio Class/Instance/Attribute.
Moreover, every class has also so-called Classwide Attributes. These are common for all objects within the Class. These attributes are addressed by entering a zero number of an instance.
The standard takes into consideration not only extensibility but also the need of particular producers, thus it defines numerical intervals of classes and also attributes, which are designated for a further extension of the protocol, and well as for classes and attributes specific for individual producers (vendor-specific).
… and complications
What kind of problems and complications had to be solved while implementing the protocol?
1. Independent attributes in every class
Every class has an independently defined list of attributes. If we want to implement the configuration tool, it is necessary to keep the list of possible attributes (in fact two lists – attributes of instances and attributes of a class) for every class. When I compare this with the BACnet protocol – there was one list of attributes (with almost 200 items) and while defining the types of objects (equivalent of classes in the Ethernet/IP protocol), it was only enumerated which attributes are mandatory and which are optional.
2. Non-consecutive numbering of attributes
The CIP standard defines attributes for more object classes in such a way that it omits some numbers of attributes (sometimes from historical reasons and sometimes it leaves a reserve for further extensions). However, sometimes there are too many attributes omitted. For example, there are several tens of attributes defined by numbers from 1 to 1585 for the class Motion Axis Object. To compare, the BACnet protocol has the attributes numerically in order consecutively.
3. Revision of objects... and others
Most of the classes (but not all) in the CIP standard have also the Revision attribute. Depending on this attribute, objects can have various attributes, or else their attributes have different numbering. Besides revisions, attributes differ in some cases depending on individual Subclasses of one class or they depend on other specifics of particular classes.
4. Types of attributes
The attribute type can depend on something else for some attributes. For example, in the S-Analog Sensor Object class, the Value attribute is standardly INT, but it might also be different according to the value of the Data Type attribute if this attribute is supported. So, in the configuration dialogue, it is necessary to implement the possibility of setting the type of attribute just in case.
Services
The standard defines standard services (CIP Common Services) – the most important ones for us were Get_Attribute_Single (0x0E) and Set_Attribute_Single (0x10), which are designated for reading and writing of attributes. Similarly as with object classes and with attributes, the reserve for a standard extension also for services specific for individual producers is defined here too.
Browsing
The possibility to read the list of objects while the communication is functional is a useful feature. Protocols such as OPC, OPC UA or BACnet support browsing. What about the Ethernet/IP?
The list of classes can be easily read from the Object List attribute of the Message Router class. That is great – but what about the list of instances in individual classes? The majority of classes contain classwide attributes Number of Instances and Max Instance, which contain the number of instances, meaning the number of the maximal instance. Complications – standardly, these attributes are of the UINT type (16-bit unsigned number); in some classes, they are of the UDINT type (32-bit unsigned number).
The theory versus practice
When I supported standard reading and writing and tested it against the OpENer software server, I tried the borrowed Micro820 manufactured by the Rockwell company.
There was a surprise: the list of supported classes was quite short and I couldn’t even find hardware inputs/outputs, nor variables defined by software. What to do with that?
After consulting this with specialists from the Rockwell company who were helpful above the standard, I found out that Rockwell took a different road – they practically don’t use the standard addressing Class/Instance/Attribute, but their own so-called Symbolic address (text addressing of objects). Moreover, instead of standard services Get_Attribute_Single and Set_Attribute_Single, they use their own proprietary services for reading and writing:
- Read Tag Service [0x4C]
- Write Tag Service [0x4D]
- Read Tag Fragmented Service [0x52]
- Write Tag Fragmented Service [0x53]
These services offer several improvements in comparison with standard services:
- They enable to specify the number of elements of the array while reading and writing, so it is possible to work also with a part of the array
- They require specifying the type of values while reading and writing so a wrong interpretation of data won’t happen.
- They enable work also with big arrays (‘Fragmented’ version of commands) when the arrays are read or written in fragments.
What I personally find surprising and odd – why does the biggest implementer of the Ethernet/IP protocol use proprietary services for reading and writing? Moreover, what is the deal with other producers? Will we have to implement for each of them their proprietary services?
We need to look for the answer to the first question in history (and discussion forums). Even though addressing with the use of text names is user-friendly, it has smaller performance and requires transmission of more bytes while addressing. That is why it was used less in the past and there existed also other undocumented services which Rockwell used for communication between their devices, or else between devices and their OPC server RS Linx. What is the advantage of the proprietary and undocumented service? On one hand, it enables the development of their own OPC server which will obviously be faster and more efficient than something the competition can offer. On the other hand, it enables adjustments and optimizations of these unpublished services without the need to report these changes in advance (moreover, this way, the compatibility with the competing solutions will be broken).
According to several discussion threads found on the Internet, five years ago, there was an abandoning of proprietary services enabling data reading from particular memory offset and there was an introduction of new CIP services enabling a conversion of the symbolic name to so-called Symbol Instance ID. The change concerns the CompactLogix firmware, version 21 and newer.
For comparison, also BACnet uses standardly similar numeral addressing (Object Type+Instance) and Siemens (unlike other producers) uses text addressing of objects. However, it uses for the conversion of the object name to the combination Object Type+Instance the Who-Has service of the BACnet protocol, which is defined by the standard. And for reading and writing, standard services are used which address the objects using Object Type+Instance. So, in this case, it was necessary only to support the conversion of the object name – moreover, this conversion was also a part of the BACnet standard.
Rockwell and browsing
When we already know that Rockwell uses proprietary services for reading and writing of objects with the symbolic addressing, another question arises – is the browsing of these objects supported?
Fortunately, the answer is yes. In the available documentation, the method of querying objects with symbolic names is described. It is again a proprietary service that returns text names of objects, their types and also the 32-bit ID of every object. This is the already mentioned Symbol Instance ID, which can be used in addressing and is thus optimizing the communication – the transfer of ID and probably also searching based on it is faster than work with text identifiers. Unfortunately, on the Micro820 PLC, which we had at disposal, this optimized mode was not supported and it was possible to work only with text addresses. Only the next tested device, CompactLogix 5370 Controller, enabled to test this optimization.
In D2000, version 12, the work with symbolic addressing, optimized work with the use of Symbol Instance ID, and also browsing of objects with text addresses is supported.
Conclusion
The Ethernet/IP protocol is a wide topic which we have only lightly touched upon in this chapter in chosen points. Thanks to the support of producers, it is and probably will be a widely used protocol. During the implementation of the protocol driver into the D2000 system, I couldn’t help comparing it with other standards such as BACnet or OPC. I have a feeling that, unlike these standards, the Ethernet/IP protocol pushes through the proprietary approaches considerably. These approaches force you to buy from a particular producer also the OPC server and to communicate through it. At the same time, it decreases interoperability of devices and makes harder the possibility of its replacement for a device from the competition. Basically, by using (and preferring) proprietary services and objects that the standard permits, the dependency on a particular producer arises in spite of the openness of the protocol itself. This feels like a competitive disadvantage compared with other protocols, especially concerning vertical communication on a higher level (SCADA).
On the other hand, the CIP and Ethernet/IP standards define also fast communication between devices (the CIP Motion and CIP Sync extensions). Those are areas in which protocols such as OPC UA can’t compete with this protocol.
Anyway, D2000, version 12, supports the Ethernet/IP protocol and adds it to the growing list of supported and implemented protocols.
