OPC UA Makes IIoT Implementations Possible

Summary

The kind of communication necessary to support the “fourth industrial revolution” demands a protocol able to tie everything together. It’s here today.

For some years now, people involved in manufacturing industries have stopped referring to the industrial revolution as a singular event. There have been four phases, each reflecting major advances in technology:

• Phase 1: Water and steam power facilitates mechanized production.
• Phase 2: Electric power enables mass production.
• Phase 3: Electronics, computers, and information technology (IT) automate production.
• Phase 4: Digital integration fuses physical, digital, and biological spheres.

The fourth phase, or the “fourth industrial revolution,” is discussed in an article, “The Fourth Industrial Revolution: what it means, how to respond,” by Klaus Schwab, the founder and executive chairman of the World Economic Forum. As the title suggests, Schwab describes this revolution, along with challenges and opportunities, and its impact on business.

The expectation is that connecting millions of things to the Internet, often referred to as the Industrial Internet of Things (IIoT), will be a key driver in this fourth industrial revolution. The IIoT comprises huge numbers of industrial sensors, each creating data about manufacturing processes. The “big data” gathered from these connected sensors can be analyzed by machine learning (ML) and artificial intelligence (AI) to predict equipment malfunctions and abnormalities, while improving overall plant operations.

As promising as it is, implementing IIoT solutions using fourth industrial revolution concepts is easier said than done. However, many companies are trying to leverage the technologies and data to improve operational decision making. As sensors become more miniaturized and cheaper, companies can deploy them throughout a plant to do the kind of data collection required for IIoT implementations.

This demands a high degree of connectivity with mechanisms to easily send, receive, and use the data. In addition to the data from small sensors, there are many more complex devices that generate large volumes of data. Effectively handling this mix of high- and low-volume data requires bundling and abstracting on a device-by-device basis. What is the best way to facilitate this?

Overview of OPC UA

OPC UA has emerged as a key technology for smooth data exchange. It predates the IIoT, because it was released as a standard in 2008, built on the success of OPC Classic (DA, A&E, and HDA). Companies implementing IIoT programs are turning to it because it has four critical characteristics necessary to send and receive data securely and efficiently:

• The OPC UA governing body, the OPC Foundation, certifies equipment to ensure interoperability when devices from different vendors are interconnected.
• OPC UA uses an information model to easily send and receive data for many kinds of devices.
• Its communication method effectively connects devices using a range of data requirements for a variety of applications.
• It applies different proven cybersecurity tools taken from information technology and operational technology environments to ensure a high level of security.

What should a company think about when considering an OPC UA implementation? How should network designers put those four capabilities to work?

Testing and certification program

End user companies will not adopt OPC UA without assurances that they will not be driven to any specific vendors or be forced to create workarounds to overcome incompatibilities. Supported and certified devices, regardless of vendor, must interoperate out of the box.

To avoid interoperability issues, the OPC Foundation has a certification and conformity program for its more than 800 members to provide proof that a device conforms to OPC specifications, and that it also has sufficient quality to perform reliably in actual operation. It guarantees that certified devices meet the compliance requirements listed below, thus minimizing problems for the user when integrating them, and enabling smooth connections. Testing for certification must be performed in an OPC test laboratory, and devices must meet the following conditions:

• compliance with OPC specifications
• problem-free interoperability with other vendors’ OPC products
• robustness and reliability—enough to recover from common communication abnormalities
• general functionality in accordance with widely accepted best practices
• effective and efficient resource management (e.g., CPU, memory, free disk space).

When a device passes the series of tests, its manufacturer can certify it for use in OPC UA networks.

Information models

A critical element to support multivendor interoperability is OPC UA’s use of information models (Figure 1). Because information for a particular device can be handled in meaningful chunks following a prescribed format, it is possible to monitor operation among devices from multiple vendors without complex engineering. For example, it is impossible to handle data from a robot or centrifugal pump without programming to identify each piece of data.

Companion information models

The OPC Foundation has a mechanism for building information models tailored to specific industries and processes, called companion information models. The OPC Foundation describes these thusly:

“New Information Models can be created based on the OPC UA Data Model and eventually derived from OPC UA Base Information Models. The specifications of such information models (“industry standard models” because they typically address a dedicated industry problem) are called Companion Specifications. The synergy of the OPC UA infrastructure to exchange such industry information models enables interoperability at the semantic level.”

For example, there are information models for master control station and distributed control system interface standardization (MDIS), which supports subsea oilfields. There is also IEC 61850, which supports the integration of an automation host system with power control. An information model for communication between multiple control systems is also available.

Guidelines and templates for creating new companion information models, as well as specifications of those already developed, are published on the OPC Foundation’s website. When a particular industry adopts these models, vendors can create ecosystems specific to those industries.

Communication formats

OPC UA supports two communication methods: the original client-server approach, and the more recent publish-subscribe (PubSub) approach. The client-server method has been used since the first versions of OPC Classic. Here, data can be exchanged after two devices establish communication. If there is a communication problem, it is possible to minimize the impact by resending the transmission or issuing an alarm. Accordingly, process data, alarms, and other information can be saved without loss, making this information suitable for subsequent analysis.

In contrast, PubSub is a one-to-many communication method. A publisher device broadcasts its data to an unspecified number of subscribers on the network, and target subscribers acquire only relevant portions of the data. Publishers only send and subscribers only receive, so if communication fails, no resending or other actions are required. Subscribers always work with the latest data they have received.

PubSub fully integrates into existing OPC UA technology, enabling further adoption of OPC UA at the shop-floor device level where controllers, sensors, and embedded devices typically require optimized, low-power, and low-latency communications via local networks. OPC UA does not rank either client-server or PubSub above the other, but supports both depending on the application.

Cybersecurity

OPC UA incorporates proven IT security technologies for both IT- and control device–related communication. The OPC UA specification defines its security concepts for communication between equipment:

• confidentiality: encryption
• integrity: signatures
• availability: denial-of-service measures
• authentication: electronic signatures
• authorization: access rights
• accounting: audit trail history.

OPC UA covers a wide area from control equipment to information and core systems, and it uses multiple methods, because the security requirements for each objective are different. This way, OPC UA can respond flexibly by adhering to whichever requirement is necessary. For example, does a given situation call for encryption, signatures, or other cyber-techniques? These can be selected on a device-by-device basis, and if used, the strength of a given tool can also be adjusted.

Collaborative information server

So far, we have concentrated on OPC UA itself, but now we will look at how it can be implemented on a plant- or company-wide basis using a collaborative information server (CI server). A CI server is designed to support an environment where information and data obtained from various equipment, systems, and devices across multiple sites and plants can be easily integrated (Figure 2). OPC UA is one of the CI server’s major communication protocols, and it supports both client-server and PubSub communication methods. It also provides a way to construct information models.

• DCS
• SIS
• power control
• quality management
• plant information management
• manufacturing operation management
• manufacturing execution.

There are two main ways a CI server uses OPC UA. The first involves the clients or the subscribers on the data acquisition side. By using the information model of the devices, plant personnel can access information easily, efficiently and securely.

The second involves using the server as the data publisher. All data related to plant instrumentation, such as control systems, safety systems, power control systems, equipment, and devices, can be integrated, abstracted as an information model, and used in secure communication.

Future developments

OPC UA is an important technology for implementing the fourth industrial revolution and realizing its full potential. It has become successful in this regard because it incorporates many methods to facilitate and secure data communication among devices and controllers in different applications and from different vendors.

All figures courtesy of Yokogawa

This feature was originally published in the February 2022 edition of InTech magazine.