OPC UA Momentum Continues to Build

The Growth of OPC UA

OPC UA has become the key technology for several next-generation automation standards, including Industry 4.0, NAMUR NOA, the Open Process Automation Forum, and Ethernet APL (which represents the next generation of process field-level communications). OPC UA thus is extending to become a harmonized process and factory automation interoperability solution, including Safety, Motion, and Real-time. Automation end users benefit from:

• A vast ecosystem working for greater interoperability
• OPC UA as a single framework for secure interoperability and information exchange
• Standardized information models and semantics via OPC UA Companion Specifications
• The combination of Ethernet APL and OPC UA providing a common interoperability technology from cloud service providers all the way to process field devices

OPC UA has begun to appear in many new areas and applications and its growth is outpacing other industrial interoperability technologies. A major advancement in market position for OPC UA came from its inclusion in the European Industry 4.0 interoperability roadmap for industrial manufacturing. This brought OPC UA awareness to a much broader set of decision makers. As part of Industry 4.0, software developers in many areas needed to learn about and use OPC UA. As the Industrial Internet of Things (IIoT) emerged, OPC UA became a common part of industrial factory-to-cloud technology and also industrial edge software applications.

Today, OPC UA is on a path to further increase its scope to include field measurement devices in the process industries (and for that matter in factory automation as well) and this move will further cement the importance of OPC UA, both in the process industries and throughout the landscape of industrial automation. OPC UA has become the most important interoperability technology in today's industrial landscape, and it appears poised to extend this lead even further in the next three to five years.

This report will provide an executive overview, which examines the reasons behind the growing importance of OPC UA versus other industrial interoperability technologies, especially for the process industries. First, we will examine the reasons behind the continued success of OPC UA, then we discuss the value of the semantic interoperability, extensibility, and collaborations that OPC UA (and the governing OPC Foundation) provide. We then examine the ongoing work to extend OPC UA to process field devices. Finally, we will look at the opportunities and challenges that the growth of OPC UA presents to manufacturing end users, especially those in the process industries.

Reasons for the Recent Growth of OPC UA

There are several reasons behind the recent success and growth of OPC UA. These factors contribute in an important way to the unique market position of OPC UA today. These include:

Vendor Independence

OPC originated as a technology that made it the “second language” of industrial devices, whose primary language was an industrial Ethernet or device network protocol. No major automation supplier promoted OPC as its primary interoperability strategy. Rather, OPC was a product requirement (but not a product differentiator) for the major automation suppliers.

In this sense, OPC stands in stark contrast with industrial Ethernet and device network technologies, which were heavily promoted by industrial automation suppliers as a means of differentiating their own products and solutions. In the world of industrial Ethernet, a handful of networking and interoperability technologies evolved but each of these was dominated by a major automation supplier. The organizations that promoted and developed these technologies were likewise dominated by a single supplier, who provided most of the funding and technical support for the effort. Because of this, such organizations provided little opportunity for major competitors to collaborate on interoperability.

In contrast, all the major automation suppliers have supported OPC UA. As the industrial internet of things emerged and cloud computing began to be concerned with industrial assets, many software suppliers realized that OPC UA was an interoperability technology with widespread support and so IT suppliers began to include OPC UA in their products. Over time, OPC UA and the OPC Foundation that develops and supports it have become the broadest interoperability organization in the industrial automation space, addressing both factory and process automation. Included in its membership are all the major suppliers of both process and factory automation systems and any number of independent software vendors.

OPC UA is also independent from any single transport layer. This is critically important as OPC UA is able to provide end-to-end secure transport via multiple (also combined) underlying technologies such as TCP, UDP, MQTT, and 5G.

Standardization, Security, Scale

Beginning in 2015, OPC UA has been available as an IEC standard (IEC 62541). Unlike many other interoperability technologies, OPC UA was initially created with a secure architecture as opposed to “adding on” a layer of security to a formerly unsecured technology. This was one major advantage of OPC UA being newer than the original industrial Ethernet protocols, which originated before ICS security was an important concern. Finally, the ability of OPC UA to be used anywhere in a vertical device-to-cloud application stack has attracted commercial cloud companies such as Amazon Web Services, Google Cloud Platform, and Microsoft Azure, as well as many other software vendors and end users.

The scale of the overall OPC UA ecosystem is also unique in the industrial automation space. It is, arguably, the largest ecosystem for secured industrial interoperability. Besides support from roughly 80 percent of the automation market, it includes the aforementioned hyperscalers as well as hardware suppliers such as Intel, NXP, and MicroChip.

Openness and Accessibility

Many industrial Ethernet and device network consortiums sell their specifications to their own members and to the public. Since 2016, the OPC Foundation has taken a different policy; one that is much more aligned with today’s open-source model of technology development and deployment.

All the specifications defining OPC UA and its Companion Specifications are freely available, as is a reference implementation. The OPC Foundation’s policy is to make its specifications freely available to all and to also provide open-source reference implementations for developers. The complete specifications and reference implementations are available, free of charge, at the OPC Foundation website.

This openness policy dramatically lowers barriers to using OPC UA for IT software firms, academia, researchers, experimenters, and others. This has catalyzed the more widespread use of OPC UA, especially in multinational initiatives.

Extensibility

At its core, OPC UA can be described as an information model hosted by a server (see figure). Clients interact with the model through a set of services. Services are provided in the context of a session, which, in turn, occurs within a secure channel that maintains the integrity and confidentiality of interactions.

The Information models follow a layered approach. The building blocks (Meta Model) and the Core Information Models are pre-defined as parts of the OPC UA specification. All models are based on a small set of basic rules. Clients that implement these rules can thus discover and process far more complex information models, navigate through the server address space, read or write variables, execute methods, or receive notifications.

As the figure indicates, the same information model building blocks and rules can be employed by Companion Information Models and by Vendor Specific Extensions. This model extensibility is a critical property of OPC UA and gives the technology its broad applicability and market success. New Information Models can be created based on the OPC UA Data Model. The specifications of such Information Models are called OPC UA companion specifications.

A significant number of companion specifications have already been created and the list continues to grow rapidly. The OPC Foundation allows three ways of producing companion specifications:

• Internal – The companion specification and models are created by OPC-internal working groups.
• Joint – These are the most common cases. The companion specification and models are created in a joint working group between the OPC Foundation and another organization.
• External - These companion specifications are developed independently of the OPC Foundation.

Companion specifications include definitions, test cases, and test scripts for automated testing. Thus, products built in compliance with companion specifications can be tested and validated.

Collaboration

The extensibility of the base OPC UA specifications is a necessary attribute for its widespread deployment but it is the diverse and numerous collaborations between the OPC Foundation and a wide variety of other organizations that is extending the value of OPC UA beyond that of other interoperability technologies. The OPC Foundation has over 63 ongoing collaborations with many different organizations (see figure below). The nature of these collaborations varies. In general, the collaborating organization specifies and standardizes the content provided (the “what”) and employs OPC UA technology to specify the means (the “how”). Many of these collaborations involve the development of companion specifications, while others specify standardized mappings for common fieldbus technologies.

Companion specifications are defined in all the different domains of the figure. These are descriptions that contain domain-specific information expressed using the resources of OPC UA modeling. Thus, an OPC UA client should be able to understand an asset of a particular type by means of this representation, regardless of which manufacturer supplied the asset.

Automation end users should examine the full range of organizations and technologies represented by OPC collaborations and be aware of the collaborations that overlap with the technologies they use in their operations. These collaborations have delivered standardized yet vendor-independent interfaces that can dramatically reduce engineering efforts, especially for applications such as Machine Learning (ML). This moves away from non-recurring engineering toward a “plug and produce” model of deployment.

We will discuss process automation in more detail later, but a good example of the value of this collaboration in manufacturing is the effort by the VDMA, the Mechanical Engineering Industry Association. As part of the Industry 4.0 effort, VDMA is managing the development of over 32 OPC UA companion specifications.

Reaching the Process Industries

At present, there are three notable initiatives proceeding simultaneously in the realm of process automation. ARC believes the realization of these initiatives will profoundly change the system architecture and perhaps the industry structure of process automation. OPC UA plays a role in each of these. They are 1) Ethernet-APL, the advanced physical layer, 2) NAMUR Open Architecture (NE 175), or NOA, 3) The Open Process Automation Forum, or OPAF.

Simultaneously, the OPC Foundation is in the third year of a multi-year initiative to extend OPC UA to controllers and field devices of all types and for all use cases. This is properly called the “Field Level Communications Initiative” of the OPC Foundation. While the scope of this initiative includes both factory and process automation, it will certainly have a major impact on the future of process automation. Let’s examine each of these initiatives in order.

Ethernet APL

Process field devices have never been truly networked, despite decades of effort. Instead, they have relied on serial device networking technologies dating from the 1980s and 1990s. The reasons for this are that IT networking could not support this combination of requirements that process manufacturing demanded:

• 24V device power combined with signal over shielded twisted-pair cable
• Long cable runs (up to roughly 1 km)

• Certifiable devices for operation in hazardous locations

Overcoming the first two requirements has been accomplished through standardization by IEEE 802. The hazardous location issue is being addressed by the Ethernet APL group of suppliers. In 2021, process end users will be able to specify and purchase field devices with standardized Ethernet interfaces, whereupon field devices will be full-fledged members of IP networks. This will represent a major change for the process industries. It will mean that for the first time such field devices can be capable of true IP communications and can also use OPC UA. Ethernet connectivity via APL also enables Layer 2 protocols (direct mapping of OPC UA to Layer 2) that increase the efficiency in the communication between a DCS and a field device. The OPC Foundation joined the Ethernet APL project group as a part of their strategy to extend OPC UA to the field level in both discrete and continuous manufacturing. This work is being executed by the Field Level Communications initiative.

NAMUR Open Architecture

Partly in response to Industry 4.0, NAMUR (the influential European process industry end user organization) developed a recommendation for an open architecture to be adopted by existing process automation systems. This is NAMUR Recommendation “NE 175: NAMUR Open Architecture – NOA Concept”. This involved a more open “second channel” through which the “core process control” function of automation systems could securely share richer information about their operational state and conditions with other applications yet do so without interfering in any way with the core process control functions of the system.

This development is a challenge to automation suppliers; although both suppliers and NAMUR have agreed that the mandatory way to standardize such solutions for this second channel is to use OPC UA, which NAMUR would prefer to use throughout its entire NAMUR Open Architecture. Ethernet-APL enables this new communication between process controller and process field devices. While Ethernet APL is a neutral Ethernet technology, which can support many industrial protocols (for example EtherNet/IP, HART-IP, PROFINET, and OPC UA), the ability of OPC UA to reach vertically (and securely) as a single technology, serving from a field device to the cloud, is a unique capability.

OPAF and The Open Group

Initiated by ExxonMobil, The Open Group formed the Open Process Automation Forum (OPAF). This is an international forum working to develop “a standards-based, open, secure, and interoperable process control architecture.” The initiative is adopting a “standard of standards” approach, and OPAF has chosen to use OPC UA in three key areas already: its basic Connectivity Framework, its Information and Exchange Models, and its Alarms and Event models. At the 2021 ARC Americas Forum, OPAF Co-chair Don Bartusiak, reported that the reasons for selecting OPC UA were:

• Widespread support among OPAF member companies
• Equivalent usage rights between the OPC Foundation and The Open Group

• OPC UA had the ability to deliver their desired attributes such as interoperability, security, discovery, portability, and interchangeability

OPC UA FX and the Field Level Communications Initiative (FLC)

At the SPS event in November 2018, the OPC Foundation launched their Field Level Communications Initiative. This initiative aims to extend OPC UA to the field level to achieve open, unified, standards-based communication between sensors, actuators, controllers, and cloud, while addressing the requirements of both factory and process automation. Vendor independent end-to-end interoperability between field devices is provided for all relevant use cases: real-time, functional safety, and motion.

Perhaps what is most impressive about the OPC UA FLC Initiative is that it has signed up virtually all the leading process automation suppliers to its governing board. Members include ABB, Emerson, Mitsubishi, Rockwell Automation, Schneider Electric, Siemens, Yokogawa, and many others. This is the broadest supplier support for any initiative in the process industries – and that is merely at the high level of the governing board.

This is a multi-phased initiative, due to its broad scope. The important points to keep in mind as it is executed are these:

• The resulting specifications are designated as “OPC UA FX” (Field eXchange). While the overall initiative is named Field Level Communication (FLC).
• The initial release candidate specification, which was completed in November 2020, facilitates the standardization of Controller-to-Controller (C2C) connectivity. It lays the foundation for future specification enhancements covering the Controller-to-Device (C2D) and Device-to-Device (D2D) use cases.
• The initiative will address field device management workflows during both engineering and operations. This is critical because device information and parameters need to be sharable during plant design as well as during operations (for example, when a failed device is replaced).
• The initiative will extend existing OPC UA information models to address field communications, which involves new collaborations and new OPC UA companion specifications.
• A recent companion specification (PA-DIM) co-developed between the OPC Foundation and the FieldComm Group, addresses information models for process field devices.
• OPC UA FX will address mapping to field protocols and physical layers, including APL, TSN, and 5G plant networks.

Recommendations for End Users

This period of accelerating standardization and technical development (especially for the process industries) offers opportunities of which forward-looking firms will need to take advantage. So much of process automation technology has been static for so long that end users may not anticipate the speed with which these changes will materialize. Here are ARC’s recommendations for process manufacturers with regard to OPC UA:

• Create an inventory of where, how, and why your firm uses OPC UA at present, the types and sources of the information models you are using, and the software and engineering suppliers relevant to your deployments of OPC UA.
• Review the base OPC UA technology but, especially, become more familiar with the OPC UA Companion Specifications from process-related collaborations such as DEXPI, MDIS, PA-DIM, ProdML, WITSML, and the VDMA Companion Specifications (such as those for weighing, pumps, mining, and machinery).
• Learn the OPC UA strategies and roadmaps of both your incumbent and potential equipment suppliers, including field devices, automation systems, I/O systems, machines, and mechanical/rotating equipment.
• Work with your incumbent Independent Software Vendors (ISVs) and OPC toolkit suppliers to gain familiarity with their OPC UA products and applications.
• Develop and maintain an internal strategy for using OPC UA in your firm. Such a strategy should encompass both IT and OT domains and cover all relevant use cases, workflows, applications, and internal organizations.
• Identify the relevant OPC UA companion specifications (both existing and those under development) to evaluate them in comparison with your existing practices. Your choices in these matters will become increasingly important as this technology progresses.

 

 

ARC Advisory Group clients can view the complete report at  ARC Client Portal  

If you would like to buy this report or obtain information about how to become a client, please  Contact Us

Keywords: Device Management, Industry 4.0, Interoperability, OPC UA, OPC UA FX, Process Industries, ARC Advisory Group.