Using Connectware as an OPC UA Server

How to integrate and configure the OPC UA server in Connectware, including setup, node definition, and data mapping.

This guide explains how to integrate and configure an OPC UA server within Connectware using the Cybus::Server resource. You will learn how to define the server as a resource, create and structure nodes, set up data mappings, and validate your configuration with an external OPC UA client.

By following this tutorial, you will:

Include the OPC UA server in your service commissioning file
Define server nodes and variable hierarchies
Configure mappings between OPC UA nodes and other protocols
Start and connect to the OPC UA server with a client

The guide assumes that your goal is to run an OPC UA server as a Connectware resource, enabling external OPC UA clients to connect and exchange data. If instead you want Connectware to act as an OPC UA client, see Using Connectware as an OPC UA Client.

Service Commissioning File Example

You can download the service commissioning file used in this example from the Cybus GitHub repository.

Prerequisites

To follow this guide, you will need the following:

A running instance of Cybus Connectware.
An external OPC UA client application to connect to the server for testing and validation. For example, Prosys OPC UA Client, FreeOpcUa's Simple OPC UA GUI client, or opcua-commander.
Access to the Admin UI with sufficient user permissions.
Basic knowledge of MQTT and the Connectware services concept (e.g. service commissioning files, connections, and endpoints).
It helps to be familiar with Connecting an MQTT Client to Publish and Subscribe Data.

Selecting the Tools

We will use the Prosys OPC UA Client for testing in this guide. However, you can choose any tool you prefer.

Alternatives include:

FreeOpcUa’s Simple OPC UA GUI client (open source, available for all major OSs)
Etienne Rossignon’s opcua-commander (for terminal use)
One-Way Automation’s OPC UA Web Client (online, free with registration, but cannot connect to local servers)

About the Connectware OPC UA Server

The server resource enables services to run servers within Connectware, with OPC UA as the first supported protocol. You can set up an OPC UA server to receive or provide data to devices or applications, mainly in industrial environments. Being fully integrated into Connectware, this feature reduces the overhead of selecting, deploying, maintaining, and integrating separate software for this purpose.

The OPC UA server is internally connected to Connectware's protocol mapper. This allows you to map your data from any other protocol supported by Connectware directly onto data nodes of the OPC UA server. In the service commissioning file, OPC UA server nodes can be handled just like any other endpoint. Therefore, you can use them in mappings by defining the data source and target.

Writing the Service Commissioning File

The service commissioning file contains all resource definitions and is read by Connectware.

Start by opening a text editor and creating a new file, e.g., opcua-server-example-commissioning-file.yml. The service commissioning file is in YAML format, which is readable for both humans and machines.

We will now go through the process of defining the required sections for this example.

Description and Metadata

These sections contain general information about the service commissioning file. You can give a short description and add metadata. Only the name is required. The rest is optional.

We will use the following set of information for this guide:

description: >

  OPC UA Server Example Commissioning File
  How to set up the integrated Connectware OPC UA server

metadata:
  name: OPC UA Server Example Commissioning File
  version: 1.0.0
  icon: https://www.cybus.io/wp-content/uploads/2019/03/Cybus-logo-Claim-lang.svg
  provider: cybus
  homepage: https://www.cybus.io

Resources

In the resources section, declare every resource needed for your application. The first required resource is the OPC UA server.

Cybus::Server::Opcua

resources:
  opcuaServer:
    type: Cybus::Server::Opcua
    properties:
      port: 4841
      resourcePath: /UA/CybusOpcuaServer
      alternateHostname: localhost
      applicationUri: 'urn:cybus:opcua:server:1'
      allowAnonymous: true
      securityPolicies: ['None', 'Basic256Sha256']
      securityModes: ['None', 'SignAndEncrypt']

We create the OPC UA server by defining the type of the resource (Cybus::Server::Opcua). Then we define its properties.

We set the port to 4841 to avoid conflicts with other possible OPC UA servers. You can also set values for resourcePath and applicationUri. However, in this case, we proceed with the default ones. Set the alternateHostname to the IP address of the Connectware host. We set allowAnonymous to true, so we can access the server without creating a user for this example (not recommended for production). With securityPolicies and securityModes, you can define the options supported by the server as arrays.

Cybus::Node::Opcua

The next resources needed are the OPC UA server nodes. Let’s extend our list with some resources of the type Cybus::Node::Opcua.

1_root:
   type: Cybus::Node::Opcua
   properties:
     nodeType: Object
     parent: !ref opcuaServer
     nodeId: ns=1;s=1_root
     browseName: "root"

 1.1_DataNodes:
   type: Cybus::Node::Opcua
   properties:
     nodeType: Object
     parent: !ref 1_root
     nodeId: ns=1;s=1.1_DataNodes
     browseName: "DataNodes"

The node resources of the OPC UA server build up a hierarchy of objects and variables. We create two levels of parent nodes here, which are of the nodeType Object. The first level is the root node, which has the server itself as a parent (referenced by !ref opcuaServer). The second level then has the root as a parent, also defined by referencing. In this way, you can build up a hierarchy in which you can then create your variable nodes.

1.1.1_Boolean:
   type: Cybus::Node::Opcua
   properties:
     nodeType: Variable
     parent: !ref 1.1_DataNodes
     operation: serverProvides
     nodeId: ns=1;s=1.1.1_Boolean
     browseName: Boolean
     dataType: Boolean
     initialValue: false

 1.1.2_Int32:
   type: Cybus::Node::Opcua
   properties:
     nodeType: Variable
     parent: !ref 1.1_DataNodes
     operation: serverReceives
     nodeId: ns=1;s=1.1.2_Int32
     browseName: Int32
     dataType: Int32
     initialValue: 0

 1.1.3_String:
   type: Cybus::Node::Opcua
   properties:
     nodeType: Variable
     parent: !ref 1.1_DataNodes
     operation: serverProvidesAndReceives
     nodeId: ns=1;s=1.1.3_String
     browseName: String
     dataType: String
     initialValue: "initial"

The variable nodes are also of the type Cybus::Node::Opcua, but their nodeType is Variable. As a parent for our variables, we choose !ref 1.1_DataNodes. The operation for these nodes can be one of three types: serverProvides, serverReceives, and serverProvidesAndReceives. serverProvides is a node which provides data and can be read by the OPC UA client. serverReceives is a node that receives data from an OPC UA client, while serverProvidesAndReceives nodes can be used in both ways. Furthermore, we choose a dataType for every variable and an initialValue, which is the value present on the node after the server has started.

For all nodes in this section, we defined a nodeId and a browseName, which can be used to address the nodes. The node ID must be unique on the server. The browse name can be used multiple times, but any browse path derived from it must be unique. However, explaining the OPC UA address space is out of scope for this guide.

Cybus::Mapping

At this point, you would already be able to read and write values to the OPC UA server using OPC UA clients. However, to transfer data from devices or applications using other protocols to the OPC UA server, you have to create a mapping. This allows you to forward data from any other protocol to be provided through the OPC UA server, or conversely, forward data received through the OPC UA server to any other protocol.

MqttMapping:
  type: Cybus::Mapping
  properties:
    mappings:
      - subscribe:
          topic: 'opcua/provides/boolean'
        publish:
          endpoint: !ref 1.1.1_Boolean
      - subscribe:
          endpoint: !ref 1.1.2_Int32
        publish:
          topic: 'opcua/receives/int32'
      - subscribe:
          endpoint: !ref 1.1.3_String
        publish:
          topic: 'opcua/receives/string'
      - subscribe:
          topic: 'opcua/provides/string'
        publish:
          endpoint: !ref 1.1.3_String

In this case, we want to provide the boolean values published on the MQTT topic opcua/provides/boolean, which will be provided on the OPC UA server node 1.1.1_Boolean. We achieve this by referencing the node using !ref. Furthermore, we want the values received by the OPC UA node 1.1.2_Int32 to be published on the MQTT topic opcua/receives/int32. To use 1.1.3_String in both directions, we need to create two mappings: one to publish received values on opcua/receives/string and one to provide values published on opcua/provides/string to the OPC UA clients.

Instead of publishing or subscribing to MQTT topics, you could also reference endpoints on connections of other protocols in the same way as for the OPC UA server nodes.

Installing and Enabling the Service

You can now install and enable the service.

Install the service commissioning file. See Installing Services.
Enable the service. See Enabling Services.

After enabling the service, all the resources we just defined will be created: the OPC UA server, the server nodes, and the mapping.

After enabling this service, you can verify that everything works correctly.

Verifying the Data

Now that your OPC UA server is running, go to the Data Explorer. The Data Explorer provides a centralized interface to visualize, monitor, and troubleshoot MQTT messages in Connectware. Messages are organized into topics, enabling structured data flow between publishers and consumers.

You can now use the OPC UA client to connect to your server on port 4841. Since we configured it to accept anonymous clients, you can just go ahead. If you wanted to allow access only to registered users, you would create them in the Connectware user management. For now, after connecting to your OPC UA server anonymously, you can send data to the receiving variable nodes. In the Data Explorer, you can then see this data being published on the MQTT topics to which we mapped the OPC UA variable nodes.

Additionally, by utilizing an MQTT client, you can now subscribe to this data or also publish data on the topic which is mapped to the providing variable nodes to send it to OPC UA clients. An easy way to experiment with these possibilities is the Workbench. There you can also easily configure MQTT nodes for quick prototyping.

Summary

Setting up an OPC UA server with a service commissioning file is quite simple. To adjust the server to suit your needs, the configuration with the service commissioning file offers various additional options, which are described in the Connectware documentation.

Being integrated into Connectware, this OPC UA server can also be directly connected to the protocol mapper and, through it, to systems using other protocols.

PreviousUsing Connectware as an OPC UA Client NextElasticsearch Integration

Last updated 1 day ago

Was this helpful?