OPC UA and Industry : A demonstration with AWS IoT Core

Overview

This blog demonstrates how to send data to AWS IoT Core from an OPC UA server. For the demonstration purpose, we are using an OPC UA simulator named “ProSys OPC UA Simulation Server” running at a PC on port 53530. Node-Red is used to acquire data from the simulator and sending it to AWS IoT Core. 

OPC Fundamentals

The OPC Unified Architecture consists of different building blocks that fall into one of two categories

1. Information model layer and
2. Communication layer.

Figure 1.1 Layers of OPC UA (courtesy Unified automation gmbh)

The information model layer consists of

• OPC UA Meta Model

OPC UA information models are developed using the OPC UA Meta Model. It lays out the fundamental ideas of the information model layer and the guidelines for exposing an object-oriented address space. Objects contain variables, methods, and the functionality to trigger events. The address space is exposed for all kinds, and all information is typed. Typically, an address space has multiple information models, such as one for device administration, one for the device’s functioning (such as an RFID reader), and one for the device’s alerts and conditions.

• Built-In Information Models

It provides the structure for all information models using OPC UA. It defines

1. The entry points to the address space used by clients to navigate through the instances and types of an OPC UA server
2. The base types build the root for the different type hierarchies
3. The Server Object provides the capability and diagnostic information.

• Companion Information Models

Companion information models are designed for a specific device, machine, or use case. Collaborative working groups develop them between domain expert organizations and OPC UA specialists from the OPC Foundation. This might be Programming languages such as the PLCopen model (IEC 61131-3), XML, or other meta-models such as AutomationML or ISA 95 communication protocols such as BACnet, IEC 61850, or field bus systems, and device descriptions such as FDI (Field Device Integration) or FDT (Field Device Tool).

• Vendor Specific Information Models.

The communication layer consists of

• OPC UA Services for Client/Server: The client-server communication with Services follows a request-response pattern.
• Service Protocol Binding: A protocol binding for client-server Services consists of encoding, message security, and message transport using OPC UA Binary, JSON, and XML.
• Messaging Model for PubSub: In the PubSub method, publishers are configured to send data and events independent of the number of subscribers. A Publisher sends a message with data or events once to the network and the infrastructure like network switches. The message brokers are responsible for distributing the messages to interested Subscribers.
• PubSub Protocol Binding: PubSub uses the following mappings.

1. UADP message mapping – OPC UA binary encoded messages with headers defined for UADP (UA Datagram Protocol)
2. JSON message mapping – JSON encoded messages with optional headers in JSON encoding.

The address space in OPC UA can be summarised as.

• Object Model: The OPC UA address space’s main goal is to give servers a uniform means of representing objects to clients.  It describes objects in terms of variables and methods. It also facilitates the representation of relationships with other objects.
• Node Model: In the address space, objects and their components are represented by a collection of nodes (e.g., object, variable, and method nodes). Attributes are used to characterize nodes, and references are used to connect them.

Figure. 1.2 (a) OPC object model, (b) Node and references (Courtesy Unified automation gmbh)

• Variables: Values are represented by variables. Properties and DataVariables are the two types of variables that are defined.

OPC UA uses namespaces to create distinctive identifiers among various naming authorities that define OPC UA information models.

A NamespaceIndex and an Identifier are present in the NodeId and the QualifiedName (DataType used for BrowseName). The NamespaceIndex indexes the OPC UA server’s namespace table. The namespace table is a property with an array of strings as the value. The server uses a namespace URI for each string. The NamespaceIndex used in NodeId and QualifiedName is the index in this array.

Demonstration with AWS IoT Core

To demonstrate the OPC UA server to Cloud connectivity using an MQTT client, an OPC server simulator named “ProSys OPC UA Simulation Server” is used. The protocol chosen here is TCP-IP. By default, the TCP Server starts at port 53530 and HTTPS at 53443, OPC UA standards. The Server (UATCP) address is copied after running the server, as shown below.

Figure 2.1. Prosys OPCUA simulation server UATCP address

A counter variable is used here as the node for data acquired by Node-Red on the same device.

Figure.2.2. NodeId of the counter variable.

Node-Red running on windows is used here as an OPC UA client with MQTT communication capability with AWS IoT Core. After running Node-Red using the command in dos as C:\Users\RishiRaj>node-red and accessing it via web browser as http://localhost:1880, the MQTT and OPC UA IIoT nodes are ready to be configured. Below, the proposed architecture is shown.

Figure.2.3. Proposed Architecture

The proposed flow is shown below after launching Node-Red.

Figure.2.4. (a)Node-Red flow built, (b)command prompt command to launch Node-Red.

The palettes used in the flow are “OPCUA-IIoT-Inject”, “OPCUA-IIoT-Node”, “OPCUA-IIoT-Read”, “OPCUA-IIoT-Response”, and “mqtt out”.

1. OPCUA-IIoT-Inject subpalette is used only as a trigger.
2. The OPCUA-IIoT-Node palette contains node details like NodeId and namespace index and identifier.
3. OPCUA-IIoT-Read subpalette is configured for OPCUA TCP address and authentication like certificate-based (SSL/TLS) or username password configuration.

Figure.2.5. (a)OPCUA-IIoT-Node configuration (b) & (c) OPCUA-IIoT-Read configuration.

4. The mqtt-out palette is configured with the required AWS endpoint and SSL/TLS certificates.

Figure.2.6. (a)mqtt out palette SSL/TLS configuration (b) mqtt out endpoint configuration.

Result and Conclusion

On deploying the flow, the MQTT nodes connect to the AWS IoT Core and the OPCUA-IIoT-Read palette, ready to acquire data. The data sent to AWS IoT Core can now be used to make datasets or for further processing.

Figure. 3.1 Received data at AWS IoT Core.

It can be noticed that the data received in AWS IoT Core is properly formatted JSON, and it contains all the metadata and nodeId of the resource and executed operation and datatype with value.

The demonstration done here leads to two conclusions

1. OPC UA PubSub model or Client-Server model can be used as communication models until and unless the client device or gateway has MQTT capability for connecting to a broker.
2. The use of an SSL/TLS OPC UA Client as a gateway device further adds an extra layer of security to data communication.

About CloudThat