Industrial Communication Data-Sharing Standard : OPC UA

Introduction

Open Platform Communications United Architecture (OPC UA), released in 2008, is a platform-independent industrial communication data-sharing standard (machine-to-machine or PC-to-machine communication) that integrates all the functionality of the individual OPC Classic specifications into one extensible framework.

Semantic interoperability is important for implementing Industry 4.0, according to experts. In this article, we will learn what OPC UA, an open communication standard, is all about and how it can be used to build standardized and secure communication from the field device to the cloud. This available interface standard is independent of the application’s manufacturer or system supplier, the programming language in which the respective software was programmed, and the operating system on which the application runs.

OPC Classic Architecture

Before UA, the protocols that were included in the classical OPC model were DA (Data Access), AE (Alarm and Events), HAD (Historical Data Access), XML DA (XML Data Access), AND DX (Data Exchange).

A common bridge for different window-based software applications and process hardware gave rise to OPC or, more specifically, OPC DA(OPC Data Access). OPC DA was built on COM (Component Object Model) and has existed since 1995.

It is important to note that OPC DA and COM are built around the concept of an interface. An interface specifies which properties and functions can be used and what they do. Due to DA, the developer can create their software product, and the software users will know what functions are available and how to call them. The interface ensures the user and developer have a common ground for developing their products.

Thus, to provide access to their brand of PLC, a vendor needs to provide a driver that implements the OPC DA interface. At this point, all SCADA, HMI, and other software that understands how to call OPC DA can access that PLC, and the SCADA vendor does not require to write a new driver to talk to the PLC.

Hence, almost all SCADA vendors support it, and hundreds of OPC DA servers are available to communicate with every process control device imaginable.

Figure 1 : OPC DA architecture

Say an OPC client needs data for a tag (an item in SCADA or DCS) from a PLC; this item is requested from the OPC Client by name. The server grabs the data from the device, and if all goes well, the data is returned to the OPC Client. To improve the accuracy and reliability of the data, OPC sends the data as a “VQT” item where V is the actual item value, Q is the quality of the data (unavailable, stale, or another issue arose from trying to read the data) and T is the timestamp when the data was read. Other features include the ability to browse items the server has access to, specify a scan rate (how often the server reads the data), and read/write items as a group. Various OPC interfaces that were no longer operating at the device driver level were developed, e.g., A&E to handle Alarms and Events and HDA to handle Historical Data Access.

Need for OPC UA

The main reason for OPC’s evolution to OPC UA is the lack of security on COM interfaces and its difficulty managing security on DCOM interfaces. A few more shortcomings of OPC DA are

• Cross-platform communication is not possible. It is a Windows product.
• The returned data is in the Least Common Denominator format, generally a character string, leading to data conversions.
• The protocol was not designed for Industry 4.0, i.e., not meant for the internet.
• OPC has a layered structure that negatively affects performance.
• There is limited data type handling.

To address these shortcomings, OPC UA came into existence. The modern OPC UA uses a layered approach with an abstract data model and builds layers from there. This approach means the upgradation of new features, data types, and more upon existing OPC UA architecture.

The main features of OPC UA are

• OPC UA is built on standard protocols, not Windows-centric technologies such as COM and DCOM. The initial specification defined an optimized binary TCP protocol for on-premises data access. Based on this, Web Services, XML, HTTPS, and other internet communications were implemented with firewall-friendly access from off-premises. OPC UA uses an Endpoint URL to specify the protocol, e.g., opc.tcp://Server and http://Server is for Web Service (SOAP). Instead of having DA, A&E, and HDA specifications, a single access point to OPC UA exists. All OPC UA servers must implement the same base services and API, irrespective of the platform.
• Based on industry standards, OPC UA uses internet security standards such as X.509 certificates. Authentication, authorization, and encryption are done via familiar methods of SSL
• OPC UA allows vendors to build their data information model that fits the OPC world.
• The specification of OPC is free. The OPC Foundation has free documents and examples on how to build OPC clients and servers.

OPC UA models

There are two mechanisms for exchanging data among devices in OPC UA:

• A client-server model.
• A publisher-subscriber model.

The client/Server Model is the traditional communication model in OPC UA. The steps involved are.

1. Client connects with the server

• Create a session.
• Security context.

2. Browse the address space

• To check available data to read.

3. Read/Write variable values or call methods.

4. Read History

5. Disconnect

Figure 2: Client-server model OPC UA

The PubSub model is entirely different from the Client/Server model, but in this context, there are similarities between the two models.

In the PubSub model, a Publisher defines DataSets that contain Variables or EventNotifiers. The Publisher publishes DataSetMessages, which contain DataChanges or Events. Essentially the transmitted data is similar to the Client/Server Subscriptions. But it is arranged in a bit different manner.

Figure 3: Publish-Subscribe model

The steps involved in this model are

1. Create Dataset with

• Variables
• Event Notifiers

2. Publish data messages to Network with

• Data Changes
• Events

3. Subscriber filters the necessary messages.

PubSub Networks

OPC UA defines two types of Networks for PubSub.

• Local Network – It uses Ethernet APL or UDP Broadcast (or Unicast in some circumstances). The messages follow the OPC UA standards’ definition of optimized binary UADP. Thus, the communications can only be interpreted by OPC UA Subscribers.
• Message Queue Broker – It can be an MQTT or AMQP broker. Normally, JSON messages are used in this situation, but UADP might be utilized for better performance. The messages have a standard content structure established by the OPC Foundation, although practically any JSON subscriber can understand them.

Figure 4: Pub Sub scenario with MQTT or AQMP broker

In the Local network, a Security Key Server exists for all publishers and subscribers that provides shared keys for them to encrypt and decrypt messages. Without Key Server to authenticate the applications, there is no authentication.

In Broker networks, SSL/TLS-based security is implemented, which the brokers may enable for the transport. They can also be defined in an application-level authentication.

PubSub Scenario for Edge to Cloud

The world is slowly moving to Industrie 4.0 from Industrie 3.0, where all components in the factory are connected to the production network.  The Client/Server Model has been very suitable for the old world, where the number of smart components (i.e., computers) and their connections was limited. In the new world, the connectivity issue may explode when the number of components that want to produce and consume information for the shared network increases. The PubSub model should be more suitable for the present world scenario, but at least in the meantime, we will use both to complement each other.

One-way data delivery, non-reversible JSON encoding for non-OPC UA subscribers, and Secure SSL connection are the salient feature of the Edge to Cloud PubSub scenario.

Figure 5: Edge to Cloud PubSub Scenario

Conclusion

The OPC UA Client/Server model is still useful for

• Synchronous Read/Write/Method call etc.
• Information Models.

OPC UA Publisher/Subscriber model improves scalability towards smart manufacturing networks and connectionless data delivery, i.e., edge to the cloud. In this context, OPC UA is achieving readiness for industry 4.0 by using the PubSub model with a TLS/SSL compliable MQTT client and connectivity with the cloud.

About CloudThat

CloudThat is also the official AWS (Amazon Web Services) Advanced Consulting Partner and Training partner and Microsoft gold partner, helping people develop knowledge of the cloud and help their businesses aim for higher goals using best in industry cloud computing practices and expertise. We are on a mission to build a robust cloud computing ecosystem by disseminating knowledge on technological intricacies within the cloud space. Our blogs, webinars, case studies, and white papers enable all the stakeholders in the cloud computing sphere.

Drop a query if you have any questions regarding OPC UA and I will get back to you quickly.

To get started, go through our Consultancy page and Managed Services Package that is CloudThat’s offerings.