- By Isao Hirooka
- Connectivity & Cybersecurity
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.
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.
In the past, engineers made data meaningful by manually configuring and assigning engineering units. However, when trying to handle the enormous amount of data generated by the growing number of devices in an entire plant, this becomes impractical. Engineering costs and the risk of configuration errors for all these manual operations is too high.
The information model enables the system to discover and interpret data from each device, helping the host understand its meaning automatically. This significantly reduces engineering costs and eliminates setup errors. Also, the information model supports object-oriented programming methods that can be executed to perform a series of processes.
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.
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.
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.
Conventional process control and monitoring systems target process data (temperature, pressure, and flow) acquired from distributed control systems (DCSs), safety instrumented system (SISs), and other systems. However, these methods do not break through the “programmable logic controller (PLC) barrier,” meaning they do not reach directly to small controllers and field devices. This is changing, because OPC UA can exchange data with a variety of communication protocols. By providing many kinds of PLC drivers, it is possible to acquire data directly from the devices and systems used to monitor and control a variety of equipment and installations. This allows companies to manage the data in a plant at all levels from a central location, rather than through other systems (figure 3).
For example, by using PubSub, OPC UA can send temperature and vibration information from a large number of small IIoT-enabled sensors to the CI server directly. It can then combine this information with various types of process data and alarms from the DCS, turning this into big data, which can be analyzed using ML and AI. The CI server also provides graphics for operators, displaying the results of data analysis in real time. Ultimately, this information supports decision making and can be used to improve plant operations.
By integrating with many systems, a CI server builds ecosystems able to guide operational improvement efforts. OPC UA’s information models help ensure that building such ecosystems proceeds smoothly, including systems such as:
- 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.
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
“OPC UA: From Automation Pyramid to Information Network”
“OPC UA: IIoT Enabler and Conqueror of the Cloud”
“OPC UA: The United Nations of Automation”
We want to hear from you! Please send us your comments and questions about this topic to InTechmagazine@isa.org.