New products will evolve over time, but existing technologies can be adapted now to leverage the massive installed base of CIP-enabled products around the world. One such technology that is gaining acceptance is OPC UA. Many vendors, end users, and industry consortia have converged on OPC UA as a vendor-neutral mechanism to exchange data. ODVA and OPC Foundation are jointly developing a CIP Companion Specification to support this data exchange.

This article documents the approach taken by that joint working group to map the CIP information model to the OPC UA information model. With this mapping, applications utilizing OPC UA and its associated companion specifications can obtain data from CIP devices without the need to understand CIP. This solution will easily bring value to end users seeking to extract more data from existing installations for their evolving application needs.

Introduction

The original OPC standard was born out of a need to “abstract PLC-specific protocols into a standard interface”. That need still exists today. End users choose field level protocols based on application specific needs, but there is an increasing desire to collect and use data from devices on all those disparate fieldbuses. The users of that data may not understand the details of each field level protocol and they wish to get data consistently across all of them. Many are choosing OPC UA to achieve that. ODVA’s Common Industrial Cloud Infrastructure Special Interest Group (CICI SIG) was formed to enable interactions between cloud applications and ODVA CONFORMANT™ devices that support EtherNet/IP. At ODVA’s 2020 Industry Conference, members of the CICI SIG presented a paper documenting use cases for a CIP Companion Specification for OPC UA. This article outlines the progress towards meeting some of those use cases.

What is OPC UA?

OPC UA is an open, royalty free set of standards designed as a universal communication protocol. It makes use of standard internet technologies, like TCP/IP, HTTP, and Web Sockets. It defines sets of core services and a basic information model framework. That framework allows vendor-specific information to be exposed in a standard way using metadata. This enables OPC UA Clients to discover and use that vendor-specific information without prior knowledge of it.

Information Modeling in OPC UA

The elemental modeling concept in OPC UA is the “Node”. Everything is implemented using Nodes: objects, methods, variables, references, etc. All Nodes are described by a set of required attributes such as the NodeId, NodeClass, and BrowseName. Different node classes have additional attributes – for example, Variable nodes have a Value, DataType, and other attributes which describe the contents of the data. These attributes are the metadata that allows clients to discover the information that a server has to offer. OPC UA uses inheritance, and each new, derived type can add required and optional attributes, or require an optional attribute from a base class be mandatory in the derived class, but cannot remove support for inherited attributes. This technique is used by all information modeling elements used in OPC UA.

Much like CIP, OPC UA uses Objects to represent complex information. The information modeling framework defines a textual representation and a graphical representation that is similar to UML. A simple information model shows how a drill press might be modeled in OPC UA.
You can see from the figure that the DrillPressType inherits from the BaseObjectType. The BaseObjectType is defined by OPC UA 10000 – 5 Information Model. OPC UA’s Part 5 is a core specification that defines the required attributes that all Object Types must support for consistency.

The newly defined DrillPressType object has components (an object representing the motor, a method to control operation, Speed, Direction, and Height) and properties (Manufacturer and DeviceRevision). The object also includes an OPC UA “Interface”. Two of the optional properties from the interface (Manufacturer and DeviceRevision) are defined as mandatory for this object so they are specifically shown in the drawing.

The textual representation for this model is shown in Table 1. Each element of the object definition is further defined in this table. References indicate the relationship between the object and each element. The Node Class tells you which fundamental modeling construct (Node Type) is used.

Table 1 – Drill Press Object Type Definition

ataTypes can either be fundamental data types defined in the core specifications, or derived types. To help readers identify where something is defined, namespaces are included in the definition. If a number and a colon precede an element, it means that it is defined elsewhere. Specifications are required to supply a namespace table containing an index and a URI of any referenced type definitions. The “Other” column documents the need in implementation. Mandatory (M) and Optional (O) are shown here, but OPC UA defines additional classifications not demonstrated in this simple example.

Finally, you will recognize that all the elements have a BrowseName. The BrowseName is a required attribute of all elements in OPC UA. The BrowseName is human-readable, but its primary use is for clients to build paths of BrowseNames. Clients gain access to a server’s address space through some known entry point and then start navigating using BrowseNames and references between the elements. Once the client finds the specific information it needs, it invokes a service on the server to translate a BrowsePath into a NodeId. Once the client has the NodeId, it will use that to access the information in the future. This whole model is very similar to the directory structure on a computer.

What is a Companion Specification

A companion specification uses OPC UA’s information modeling framework to describe common information found in an industry vertical (e.g., Plastics and Rubber), or standard types of machines (e.g., Pumps and Vacuum Pumps). These specifications attempt to harmonize the representation of the information in that vertical or machine by defining objects, variables, data types, methods and references specific to their operation. Simply put, companion specifications define a common interface to information represented by the model that could be supported in any instantiation of that model.

The CIP Companion Specification

CIP does not represent any one industry vertical or specific machine. It is used everywhere throughout industry. The purpose of the CIP Companion Specification is to provide a translation that would allow information found in CIP devices to be represented in the form needed by existing and future OPC UA client applications regardless of what companion specifications those applications use. An example of the translation that is needed is presented in this article.

The translation rules defined by the CIP companion specification can be implemented in any device that has an OPC UA server, however the most efficient and expedient way to enable this capability in existing installations would be for it to exist in a gateway appliance, or gateway function in a product already on the network.

The result is that an industrial network can be accessed by an OPC UA Client Application. OPC UA clients can discover OPC UA Servers and browse their address spaces. In this figure either the controller or the gateway appliance could contain the gateway functionality that would gather data from devices and translate it for the OPC UA client. This could be done for EtherNet/IP devices as well as non-CIP field devices integrated through CIP’s Integration Volumes 7A-C. The client could see each proxied device as an individual OPC UA server as if it were communicating directly with it.

Figure 2 – Industrial Network Accessed by OPC UA Client Application

CIP Device Information Model

To build our model we considered the elements that are common to all CIP devices: an identity, a network interface, and a collection of device-specific application objects. We created a standard representation for the Identity Object and CIP network interfaces by defining several OPC UA object and interface types. For all other device-specific application objects we plan to create OPC UA types that could model any CIP object generically.

Many of the use cases outlined in [1] deal with asset management. For OPC UA this kind of information is defined in OPC 10000-100 (Devices). While there is considerable overlap between the information in OPC’s Devices specification and CIP’s Identity Object, we decided to model both. We wanted to preserve all the attributes of the Identity Object in a lossless way and be able to represent a CIP device as modeled in OPC’s Part 100: Devices.

CIP Identity Model

Figure 3 – Modeling the Identity Object

To model the CIP Identity information, we defined a CipIdentityType Object. The object inherits from OPC UA’s BaseObjectType; the root for all object definitions. Each required CIP attribute is modeled as a property of the CipIdentityType. In addition to this ObjectType, we also defined an identical InterfaceType so that existing models could expose the CIP Identity Object attributes simply by including the interface. Interfaces are an OPC UA modeling construct that enables you to build object functionality by referencing the interface (i.e., composition). When referencing an interface, the source object must include mandatory elements in the interface and can optionally include any optional elements.

The optional attributes of the Identity Object were also added to OPC UA Interfaces. We grouped optional attributes into five interfaces: common, uncommon, HART, IO Link, and ModBus. This was a tradeoff between defining many interfaces and one very large interface that contained everything the Identity Object defines. This grouping should allow for more sensible implementations. For example, CIP can model the Identity of HART, IOLink, or ModBus devices. The optional interfaces needed for these attributes can be applied only where needed to represent devices on those networks.

Figure 4 – Optional Functionality Modeled using Interfaces

OPC UA’s Part 100: Devices specification defines information for the identification of devices. Those properties are contained in two interfaces, IVendorNamplateType and ITagNameplateType. Figure 5 shows the CIPDeviceType inheriting from the ComponentType which is defined in Part 100. The CIPDeviceType further mandates several optional properties from the Part 100 interfaces to align with many existing companion specifications (e.g., PA-DIM). This collection of OPC UA properties and CIP Identity Object Attributes represents all the identification functionality from both specifications.

Figure 5 – CipDeviceType Derived from Part 100 Types

Some CIP attributes have a close equivalent property in an OPC UA object, while others require significant translation. For example, OPC UA makes extensive use of string data types in many properties that have numeric equivalents in CIP attributes.

CIP Network Interface Model

OPC UA 10000 – 22 Base Network Model defines a very basic InterfaceType to be used by all networks. We defined object types that referenced that InterfaceType and new InterfaceTypes that model the information for the specific CIP network of the device. Part 22 defines a well-known location in the server’s address space for network interfaces. Our new types will be located there so that any client can learn about a device’s interface to its network.

Figure 6 – CIP Network Types derived from Part 22

Figure 7 – CIP EtherNet/IP Device Information Model

Generic CIP Object Model

The CIP specifications define dozens of application objects and vendors are free to define more of their own. There are several alternatives to modeling these for OPC UA. We could provide a translation for only the most common publicly defined objects. That would provide some benefit but would neglect some applications due to the missing translations and it does not address vendor specific objects. We could provide a translation for all publicly defined objects. That would take a long time and still would not address vendor-specific objects. The most comprehensive solution is to provide some type of generic mapping of the CIP object model to OPC UA.

Fig 7 shows that the EthernetIpDeviceType has an “Optional Placeholder” for CIP Objects. OPC UA uses the Optional Placeholder modeling rule for open-ended situations. It allows you to place any number of objects with an unspecified BrowseName at that point in the model. We will use this to represent all other CIP objects in a device.

The details behind the GenericCipObjectType are still being developed. Figure 8 demonstrates how this generic type might be used. It shows a device that supports two instances of the Discrete Input Point Object. It supports Class Attribute 1, and Instance Attributes 3 and 4. The gateway would use some algorithm to generate unique BrowseNames for each Node in the model. In this case we used the pattern “CIP Class X Instance Y Attribute Z”. For brevity the pattern could have been “CXIYAZ”. The important part is that the name is unique within the path. Using this generic object, we believe we can represent any CIP object in OPC UA.

Figure 8 – Generic CIP Object Information Model

Example Integration with Other Information Models

Let’s finish with an example to understand how this model might be used. The Downright Delicious Doughnut Corporation is a multinational company with production facilities around the world. They buy machines and control equipment locally where their production facilities exist. As such they need to manage equipment from many different suppliers. They want to harmonize their asset management function so that it can be performed and accessed from any location. In Figure 9 we see a model of their operations.

The high-level processes at DDD’s locations are similar: dough is formed, cooked, drilled (likely the best way to make the holes in donuts), dressed, and packed in continuous batches. Some equipment used at both factories is identical, while other equipment is different. The Fried Division has standardized on EtherNet/IP, while the Baked Division uses Inferior Netz. The two network technologies use different information to represent the identity of products even for identical pieces of equipment. EtherNet/IP uses the numerical attribute values defined in the Identity Object. Inferior Netz uses all string datatypes with a heavy use of animal names to differentiate products. For both networks there are vendors that produce OPC UA gateway products.

Figure 9 – Multinational Company Managing Assets from a Centralized Location

The Quality Assurance department at the Jibulger plant has recently reported uneven baking resulting in raw and burnt donuts that are out of specification. Plant engineers researched the issue and determined that it could be addressed with a firmware update available for the oven. Following this update, product is produced within specifications. When headquarters learns of this issue and resolution, they order the asset management team to find all the firmware updates available for their equipment.

The asset management team maintains a database of all equipment in DDD’s facilities using an OPC UA application. The application was built using the Donut Industry Companion Specification (fictional, but certainly needed). That specification defines object types to represent all the equipment used in the donut-making process (e.g., DrillPressType) and as shown in Figure 1, those types are built referencing interfaces defined in OPC’s Part 100.
The asset management team finds a security bulletin from the drill press vendor indicating that attackers could change the direction of motion during operation. This attack would lead to imperfect holes of varying sizes. The remedy is a firmware update from the vendor. This vendor uses EtherNet/IP controls and has identified the affected products using the Vendor ID, Device Type, Product Code and Revision. The team first searches the database for this Vendor’s products. It uses the Manufacturer property from Part 100.

CIP products will have their numeric Vendor ID mapped to a vendor name. Once all occurrences of this vendor are found in the database, the asset management team can filter for the Device Type and Product Code. Both values are available because the gateway used at the Hackensack plant uses the CIP Companion Specification to incorporate common OPC data with CIP data. All devices are represented with the CipIdentityType which includes both the Identity Object information as well as the Part 100: Devices model.

This example demonstrates the merging of data from core OPC UA specifications, industry companion specifications, and the CIP object model.

Conclusion

OPC UA continues to gain momentum as a vendor-independent mechanism to collect data. The publication of an ODVA companion specification will be essential to help end users realize the potential of their intelligent devices. This article discussed progress that has been made towards an OPC UA Companion Specification for CIP. There are still many challenges that need to be addressed like offline and online representation of all the data a device has to offer, metadata that fully describes CIP attributes, handling of complex data and services, and adoption of the UAFX asset model. All these issues still need to be investigated to achieve a feature rich solution that satisfies all the use cases we envision. The material we have today provides good coverage for many asset management functions and will provide immediate benefit if released as a first version while we continue to develop the model to cover more diverse use cases.

Gregory Majcher, Principal Engineer, Rockwell Automation, Inc.