Having concluded the first round of requirements capturing for vertical integration of Common Industrial Protocol (CIP) devices to cloud applications, the Common Industrial Cloud Interface (CiCi) Special Interest Group (SIG) has determined that a key element of an overall solution is an OPC UA companion specification for CIP devices.

Based on this conclusion, a plan is currently under development between OPC Foundation and ODVA for a joint working group to produce this companion specification. In order to ensure that this companion specification meets the requirements of both ODVA members, and of users of CIP technologies the CiCi SIG is now refining those requirements to specifically address companion specification relevant use cases.

This article explores user stories and use cases against which that OPC UA companion specification will be developed. It recaps the work done and benchmarks it against the Device Integration model best practices. It will take advantage of recent lessons learned within OPC Foundation that are being addressed in their Harmonization Working Group and will propose a harmonization model to allow CIP Technologies to integrate seamlessly with the latest OPC UA specifications.

Related work

The goal of this initiative is to deliver an open, cohesive approach to implement OPC UA including TSN and associated application profiles. This will advance the OPC Foundation providing vendor independent end-to-end interoperability into field level devices for all relevant industry automation use-cases. The OPC Foundation vision of becoming the worldwide industrial interoperability standard is advanced by integrating field devices and the shop floor. A new set of working groups is identifying, managing and standardizing the OPC UA relevant topics focused on industrial automation including:

• harmonization and standardization of application profiles like IO, motion control, safety, system redundancy
• standardization of OPC UA information models for field level devices in online and offline scenarios e.g. device description including diagnostics
• mapping of OPC UA application profiles related to real-time operations on Ethernet networks including TSN
• definition of certification procedures

Megatrend in global manufacturing

Commonly called Industry 4.0, end users of automation products, machine builders and component suppliers are seeing new opportunities to integrate the automation value chain, reduce costs through new business models and implement new techniques for process optimization. The key technology that makes this possible is the internet, coupled with mass data storage and securable real-time global access to this stored data.

This megatrend is most visibly demonstrated from two angles; national governments are implementing smart manufacturing initiatives to enable competitiveness of their local manufacturing base; bottom up corporations are providing delivery platforms to monetize digitization domain expertise.

Two examples from the multiple government led smart manufacturing initiatives, together with their core claims are listed below:

• Plattform Industrie 4.0 in Germany: “For Industrie 4.0, it is not the computer that is the core technology, but rather the Internet. Digitalising production is gaining a new level of quality with global networking across corporate and national borders: the Internet of Things, machine-to- machine communication and manufacturing facilities that are becoming ever more intelligent are heralding a new era: the fourth industrial revolution, Industrie 4.0.”
• Industrial Value Chain Initiative in Japan: “The Industrial Value chain Initiative (IVI) is targeting to turn linked factories and connected manufacturing into reality. In some cases, the result that developing a new system at the enterprise as a whole or at its manufacturing site is needed. In other cases, the challenge may be solved through small improvement efforts by applying IoT tools.”

Similarly, two examples of corporate delivery programs and their goals are:

• The Connected Enterprise from Rockwell Automation: “New insights that are revealed through better data access can help you reduce bottlenecks, implement demand-based decisions, and improve maintenance.”
• Azure IoT from Microsoft “Organizations across all industries are using Azure IoT to invent new lines of business, improve productivity, and reduce waste by using AI and machine learning to quickly process massive quantities of data from IoT devices.”

Common factors of all these initiatives are:

• Enterprises need to consolidate information across multiple plants
• Supply chain and value chain partners need to share information during the operational phase of a plant
• Cloud technologies must be used to secure and distribute information, abstracted from local assets

Common Industrial Cloud Interface

At the ODVA Annual Meeting in 2017, the CiCi SIG proposed a reference architecture as a basis for their work. In addition, the CiCi SIG presented a number of use cases, which are not duplicated in this document, although some are extended.

These use cases are organized under different phases of a device’s life cycle. The use case explored in this document will be extended to consider the life cycle of more complex automation assets, i.e. a machine or collection of machines. Finally, the use case titles were followed by references to a set of communication patterns between a cloud application and a target gateway device.

Reference architecture

The use cases and technical requirements for data transfer white paper proposed a Reference Architecture for a CiCi gateway solution. This reference architecture assumes that within a plant (on-premises) the user is concerned with only one communications technology. This article will expand the reference architecture to assume a need to support information coming from multiple communications technologies.

The assumption is that OPC UA is a critical partner technology and that joint work will be performed in order to deliver a companion specification. Through the rest of this paper it is assumed that:

• the cloud interface will use an OPC UA information model
• the cloud interface will use OPC UA transport mechanisms (MQTT, AMQP or HTTPS)
• the cloud interface will use OPC UA defined cybersecurity roles, authentication and encryption The use cases/user stories below will attempt to explain why these are reasonable assumptions.

Industrial Value Chain

In this section, we define the stakeholders, both from the perspective of the types of organization, companies and other entities that add value to an EtherNet/IP device through its supply chain, together with the human roles fulfilled across those entities.

Stakeholders represent the legal entities who have interest in a particular story. There may be multiple legal entities who hold a stake in a particular story

Optimizing Production Processes by Role

As a Plant Manager I want to enable my Data Scientist to be able to access data from my assets, so this data can be analyzed and used to optimize production.

As a Data Scientist, I want to be able to discover my assets and their associated devices that may provide useful data for analysis, so these devices can be further queried for the data they may contain.

As a Product Developer, I want to expose only data that are useful for optimizing the specialized asset, so data collection is simplified for customers and plant operators.

As a Business Manager at a Device Vendor, I want to enable my Data Scientist to be able to access some data from my Devices, so that my Data Scientists/specialists can make recommendations that result in operational improvements.

As a Plant Manager, I want to only expose data that will not disrupt the operation of my assets, so that downtime can be avoided.

As a Process Engineer, I want to assign data reading resources, so that there is adequate bandwidth for operating my facility and providing data for analytics.

As a Security Officer, I want to guarantee that only authorized connections can be made to my assets and only authorized devices can be discovered and authorized data can be read.

The native protocols of the devices in these use cases are not important to achieving the desired outcomes. In most operations, there are mixtures of vendors and protocols in use. What is important is enabling these actors to have access to data contained in their assets. The “shape” or context of the data is also very important to the value of the data. More context makes it easier to provide valuable insights. Also, data scientists use different tools that are aligned with cloud technologies, largely due to the significant amounts of data storage and process power required. These technologies are evolving to be able to take advantage of computing power on the “edge,” but they still require services or mechanism that will discover devices on the network, specifically for CIP devices, pull information from the data available and present that data in a standardized way to applications on-premise and on the cloud.

Machine/Skid Builder/Integrator offering remote service of own supply

As the business manager of a machine builder, I want to offer value added annualized services to my customers. In the long term, this will be leasing machines on a usage basis, but the next step my users are prepared to take is outsourcing maintenance.

To deliver these services, I am prepared to invest significantly in instrumentation from multiple vendors and software in machines I deliver. I want to create parts of the information model in controllers that is only available for me to access. I consider this information to be mine and not my customers and not for use by service providers. In order to simplify access, I want to be able to deploy a single gateway function (standalone compute appliance or embedded in the controller I select) which will provide connectivity to my own historical cloud storage.

I want this gateway to securely deliver my proprietary information together with standardized and vendor specific information from the components, together with application specific information in controllers and information from discrete devices in the machines. For the machine builder, supporting the native protocol required at a plant is critical to their business – essentially the same machine will be delivered using both CIP and third-party protocols to the different plants – it is only in hybrid plants that the machine builder may have any autonomy.

However, like the data scientist the machine builder will have a strong preference for a single cloud-friendly protocol to deliver consistent information from all of the plants.
This story brings a new requirement which is around role-based security – that the provision of information to the cloud is controlled by the machine builder and not by the user of that machine. Further delivery requires input from the plant network engineer who will be responsible for creation of firewall rules. The fewer technologies deployed, the less work and more importantly, the less risk created.

Increased service delivery

As I increase the number of machines on which I deliver these services, I will want to adjust the information that is delivered to my cloud storage based on experience gained. I must be able to make these changes without physical access to the gateways. I must be able to document and enforce a service agreement with my users about changes that can be made to the running system. Also, like the data scientist, they will have a preference to be able to select variables for monitoring long after commissioning – to avoid replicating the entire machine database in the cloud.

Provide information from inside a machine for Data Analysis

As a data scientist working for a Plant Owner, I want to get “important” or pre-selected data and context from my assets so that I don’t have to understand or learn each asset in my enterprise. Extending from Optimizing Production Processes, the data scientist will prefer technologies supported by their cloud vendor, with no concern for the technologies supported by the Device Vendor. The selection of cloud drives communications and not the other way round!

More importantly, the data scientist cannot be assumed to have any domain expertise in either field level devices or communications technologies. Consistent semantics across components, technologies, machines and plants are critical to their success. This means that in the CIP driven plants, all devices must present their metadata using common and well-defined terms and meanings/interpretations. But for the data scientist, whether the plant is CIP driven or third party driven is irrelevant – they want to see the same semantic definitions presented in both cases. This is even more true for the hybrid plant.

To facilitate this device discovery, services to collect the metadata available in each device, and a method to build the metadata into an information model without manual configuration, will be important for adoption.

It is worth noting that the OPC Foundation has a program running called “Harmonization” to address this problem within their own family of companion specifications. Our objective should be to minimize the pain to our users and that we do not increase it.

Device vendor offering remote service

As a Business Manager at a Device Vendor I want to connect to devices when then are used by either machine builders or end users, so that I can offer remote services to ensure the devices I have supplied are operating properly.

For this purpose, a plant operator needs to grant access to the installed devices for the device vendor but only to the devices of interest. As a device vendor, I want to setup an ad-hoc and exclusive connection to the device and I also may setup a continuous monitoring routine. As a plant operator, in order to allow remote access to devices, I want full control on the permission levels and time, when the access occurs (is allowed to happen). As plant operator, I need to be able to notify the subscribers of a device’s data about the potential un-availability of function.

In many ways, this story is identical to the machine builder stories, but with completely different cloud suppliers and information flows involved. Our objective must be to ensure a single approach supports both stakeholders.

A key value is that plant maintenance technicians cannot be practically expected to have expertise in every device in their plant. This support may be delivered in an ad-hoc manner, rather than the programmed and scheduled manner of machine builder support.

Asset management of installed base

As a plant owner I want to be able to establish an asset management system in my plant, which is able to read the asset management and identification parameters from each device/component (hardware/software) that is installed in my plant, so that it is possible:

• to search for components for which a recall action, Software termination or a hotfix/update exists.
• to create a complete inventory list of all installed and communicating components (hardware/software) for easier root cause analysis in case of failure.

Asset management is typically performed across multiple plants with common identification approaches needed for all devices. Again, this means commonality between CIP and third-party technologies to deliver the anticipated value. It should also be noted that the security officer is a key stakeholder in the asset management use case, having a responsibility to respond to vulnerability notifications from vendors and put in place remediation plans.

Anyone has access to data in devices

As a product developer of a new and innovative software application, running on a blade server (on-premises or in-cloud) I want to be able to find all of the components (controllers or devices) that have potentially useful information using off-the-shelf browse mechanisms. I do not expect the original developers to have planned for my use. I know that some of those devices will provide me information directly and some will be represented by aggregators or other edge-gateway type devices.

Once I have found useful information I want to be able to read it whenever I want using off-the-shelf mechanisms. While my task will be made easier with devices because of the consistency of their information models, I do not expect to have knowledge of any specific mechanisms (state machine, application relationships etc.) to read that information.

The value of a project is derived from application of software and not directly by the device or automated system. In this case, the communication technology will be determined solely by the software developer and it is the responsibility for CIP devices to provide data for these applications in the desired mechanism(s).

These software applications will be customized based on the installed base of devices and equipment, so discoverability of information contained in CIP devices will be needed. In addition, both on-line and off- line enumeration of information may be needed as some applications may require configuration prior to delivery. The following applications may be considered applicable to this story:

• IoT Gateways
• HMI, SCADA or MES
• Analytics, including Machine Learning
• Energy Management
• Predictive Maintenance

Browsing network for optional information

A story where user wants to browse network to find information – to identify all instruments whose calibration date expires in next 6 months. Not every device has this information.

Common diagnostic view

As a process operator of a machine at a manufacturing plant I want the diagnostics for all of the components in my system to be automatically aggregated into a single user view. I want to be able to filter this view to isolate network diagnostics, component diagnostics and application diagnostics. Where there is time available, in the device (and I know that not all devices will support time), I want it to be presented as a common wall clock time and I want any timestamps to be generated at the lowest level in the architecture where time is available in the system and for that time to be maintained with the diagnostic.

This story requires a significant level of integration between the CIP plant level technology and the OPC UA ‘up-link’ technology. Some of this integration may require extensions to the CIP protocol to be made possible and others may result in conformance-testable gateway functionality.

Minimize number of Security Servers

As an Engineering Director at a system integrator, I want to deploy the smallest number of security technologies and servers possible to cover all of the sub-systems that I am delivering, of which industrial automation is a subset. Proliferation of security technologies across communications technologies is already becoming a source of pain for many users, generating a need to manage authentication and key servers for each. As the companion specification is developed, it must address the needs for integration of security across technologies as well as the integration of information.

A Common and Consistent Security Policy

As the Security Officer, my role is to minimize the security risk to the operations of my organization. I want to ensure that the desire for access to production information is achieved in a way that protects the intellectual property of the organization. As well as considering both the IT and OT domains on-premise, I will want to ensure that any off-site storage of my organization’s proprietary data is managed in a way that minimizes the chances of it being compromised.

As part of my role, I need to ensure that tools are in place to allow the organization to define and implement rules for access and authentication, whilst providing accounting capabilities so that access can be monitored and reviewed. I will define policies – based on a risk assessment – that need to be implemented to mitigate against these risks.

A specification for cloud connectivity therefore needs to reflect industry best practice, allowing a solution to build on the strengths of each domain, while preserving end-end security. It needs to address aspects such as the interaction between internal and external technologies and policies – as well as to provide the means to address practical aspects such as defining policies and procedures for the management of servers. Definition and rights of roles needs to be consistent from device to cloud.

Alarmable Conditions and Scenarios

As a Process Operator at a manufacturing plant, I need to be able to monitor all devices, including edge devices and cloud interfaces such that if they go into alarm, I need to have a common troubleshooting procedures to be able to know what I can do myself, or when to alert a supervisor. If devices create an actionable event, such as a confirmable message on a process control system, I need the content the message to provide clear instructions to take the proper action.

Common Maintenance Activity

As a Maintenance Technician, I need to be able to replace equipment based on regular maintenance schedules, or in the case of faulty equipment, and I need to have clear indications (via logs, alarms or maintenance recommendations) as to which devices need replacing. This could be equipment such as an edge gateway or a cloud interface hardware. I need to have access to spare parts in a timely fashion from a storage depot or maintenance back office. The replacement of this equipment should be intuitive, or clear replacement procedures readily available online, or physically printed on site.

Brownfield Installation with Regulations

As a Plant Manager responsible for a pharmaceutical production operation that is currently validated by the Food & Drugs Agency (FDA) I am being tasked to provide additional data of my processes to support Good Manufacturing Practices (GMP)facilitate an energy management campaign for ISO 50001, and other overall operational improvements.

This data includes asset, diagnostic and process data. Asset data can include device type codes, revisions, catalog, and serial numbers. Diagnostic data may include alarms, fault codes, memory faults, etc. Process data would be values such as pressure, flow, temperature, etc.

My current system has CIP devices with interesting data that I can use. I may also need to add a third-party device (non-CIP) to my network for additional data. I would need a gateway to collect this data, possible contextualize the data, and send it to a cloud for monitoring and analysis.

A variance to the risk assessment for validation protocol can be written since we are not modifying/changing the control program, any devices or functionality to the production operation. It is important that we do not have to undergo revalidation to save time, costs while retaining optimal uptime.

It is necessary to have a gateway that is secure, does not receive inputs from the cloud, only pulls data from devices and pushes it to the cloud. It should have an ability to contextualize data before sending to the cloud if needed. This should not impact the validated process and equipment, and, provide a risk-free way of data collection for analysis. There must be no programming or commissioning changes required at the PLC/DCS.

Thin-slice approach

The premise was that Cloud vendors have “preferred gateways” that can be used by a “User” application to send data to/from cloud. Therefore the task of ODVA is to provide an <interface> that “User” applications could use with the following functions:

• Browsing / Discovery of CIP devices on the local subnet
• Provide Identity Object information from discovered CIP devices
• Provide Connected/Not-Connected status of any valid CIP device address
• Return EDS file from device, if it exists
• Return values of parameters that are defined in an EDS file
• Return values for parameters or assemblies as defined in a Device Profile

The CiCi SIG concluded that a well-defined “interface” would eventually require similar basic functionality as an OPC UA Server for security, diagnostics, discovery as well as data types and the production of data – functionality that does not exist within the CIP suite today in a directly applicable format. Review of several OPC UA companion specifications confirmed that similar “thin slice” functionality has been defined for other standards i.e. IO-Link.

A CiCi Service should be scoped to provide functionality similar to other OPC UA companion specifications, combined with work to represent any CIP objects in an OPC UA Server
Increasing functionality of the “interface” beyond what could be defined in an OPC UA companion specification would likely be “device management” functions that may be defined by xDS or other SIGs.

OPC companion specifications

“Scope of OPC UA within an Enterprise” demonstrates OPC Foundation’s self-declared goal. As can be seen, the focus is primarily on vertical integration from the device to software applications, both on-premise and cloud-based.

However, they recognized that the consumer of information used in devices is unlikely to have detailed knowledge of the field level protocols used in the interaction between controller and device. In April 2019, the Foundation published specification Part 100: Device Information Model to provide the harmonized interface called for to create the north side interface.

Conclusions of CIP requirements

In order to validate the assumptions made in section 3 Reference Architecture, we must address two questions: Do use cases require technologies not available in the CIP family of specifications? Are these technologies readily available within OPC UA and are they acceptable to our actors?

Our conclusion from this is that there is a compelling case for generation of an OPC UA companion specification for CIP to OPC UA Gateways, based on the assumptions:

• the cloud interface will use an OPC UA information model
• cloud interface will use OPC UA transport mechanisms (MQTT, AMQP or HTTPS)
• cloud interface will use OPC UA defined cybersecurity roles, authentication and encryption

This is because almost all of the functionality missing from CIP is available already in UA; it is a far simpler task to integrate CIP using a companion specification, potentially supplemented with enhancements to the CIP specifications than creating a competing approach from scratch. The functionality which is missing from OPC UA is typically device centric functionality long-standing in CIP specifications and ODVA core competency.

Paul Brooks Manager, Technology Business Development, Rockwell Automation; Ken Hopwood Software Architect, ProSoft Technology; Frank Latino, Product Manager, Festo Corporation; and Steven Roby, Sr. Principal S/W Engineer, Honeywell HPS.