Handling Advantech Wise 710 OPC-UA telemetry using OPCPublisher

Microsoft has an extensive IoT platform based on Azure.

It provides so many features, this can be overwhelming for customers. Therefore, Microsoft provides Azure IoT solution accelerators, based on the Azure IoT reference architecture.

Some of the original accelerators (it started with Azure IoT suites) like Remote Monitoring are now outdated or even archived. These are replaced by excellent Azure IoT Central apps which demonstrate the capabilities of the IoT platform for numerous markets and verticals:

There is still one original accelerator alive-and-kicking: the Connected Factory. This one demonstrates the use of OPC-UA protocols on the edge and in the cloud.

More than two years ago, I already wrote about this accelerator and the OPC publisher module, the backbone of this accelerator. Since then, a lot has changed. Some functionality is (temporarily) deprecated so I got a lot of questions based on the old blogs.

So it’s time to update it a little and see how the OPC Publisher is doing these days.

The OPC-UA solution is open source and covers a lot:

diagram

I limit this blog to the scope of my very first blog, extracting OPC-UA messages and send them to the cloud using a ‘published nodes’ file.

We just need an OPC-UA server to get some sample data from. For this, I used an Advantech Wise 710 as an industrial protocol gateway.

The data I actually extract is coming from an Advantech Wise 4012E IO module which communicates using the Modbus protocol:

Note: this IO module is designed for testing purposes (this one runs on a USB connection). It is on par with the features of the industrial versions.

We need to expose the data coming from the wise 4012E module using an OPC-UA server. For this, I use this Advantech Wise 710:

This Wise 710 is very versatile. It is capable of ingesting data using its own DI/DO ports, serial ports, and network ports. It can expose calculations based on the incoming data and user-defined variables.

It supports up to 3000 tags.

Programming of the Wise 710 is done using a software tool, Edgelink Studio:

Let’s see how this is done.

Programming the Wise 710

First, install EdgeLink Studio on a Windows PC or laptop.

Keep in mind the version of EdgeLink Studio (eg. 2.5.1, 2.5.2, or 2.6.0) has to be on par with the firmware version of your wise 710. I opened the configuration page of the Wise 710. Here I see I have to use EdgeLink 2.5.2:

Note: EdgeLink Studio gives some warnigs too if the wrong firmware version is targeted.

EdgeLink Studio can connect to the Wise 710 over the local network to download the final project configuration:

Within this programming tool, I first add my Wise 710 in a new project:

As you can see, multiple models of devices can be programmed using EdgeLink Studio.

Once the device is added, the Project Download option is already available:

This is what we will use later on to actually send our configuration and thus program our Wise 710.

Let’s add some logic first.

Connecting to the Wise 4012E

The Wise 4012E exposes data from two potentiometers and two switches. It also has two LEDs that can be turned on or off.

We want to read and write data from this IO module, so we have to add a device:

This is a Modbus device accessible over TCP-IP (Modbus TCP):

Note: EdgeLink Studio supports 200+ device drivers.

We add the Modbus registers and coils:

As you can see, we can read the six values and we also can write the two LED values.

The Wise 710 also exposes system values like CPU and network traffic:

This is great if you are interested in the health of your device.

The Wise 710 also exposes user tags:

This particular user tag is configurable in the Browser interface:

Note: The browser interface is just available after a successful project download/transfer to the Wise 710.

The Wise 710 also supports calculated values:

You can create a calculation based on up to eight other tags. Here, I just compare the two switch tags Switch1 and Switch2. So if both are 1 or 0, the calculated field returns a 1. Otherwise, it returns 0.

Here are some of the possible conditions:

This becomes even more flexible if you combine this with user tags (eg. flexibility) or system tags (eg. for alerting)!

Note: You can even test the calculation before it is deployed using a separate dialog behind the big ‘+-*=’ button.

Once the tags are set, you can expose them to the world in multiple ways:

  • Logging to persisted memory data storage or an external database
  • Sending data to external cloud platforms (eg. AWS, Azure, or Wise-PaaS)
  • Exporting the tag data as Modbus or OPC-UA service

Today, we expose the data using OPC-UA. Our protocol gateway must expose an OPC-UA server:

Enable the OPC-UA service and set the correct port of your choice. Regarding security, I disabled it for now, just for demonstration purposes.

Warning: In production, please add at least a name/password. Securing the service with a certificate is recommended.

Finally, I added all eight tags I wanted to expose (including the calculated tag and user tag).

After adding all tags, the project must be downloaded to the Wise 710:

Open the Project Download dialog and wait until the project is compiled. Then, press the Download button. The project will be transferred to the Wise 710 over the local network.

Note: Wait until the Download button is available again. This marks a successful transfer.

So, we end with this solution:

We are now ready to connect with the OPC-Publisher module.

The OPC Publisher module

We deploy the Microsoft OPC Publisher module from the market place:

This module is open source and part of the larger Connected Factory accelerator. Still, it can be used stand-alone.

The container added via the market place is in fact this generic version:

mcr.microsoft.com/iotedge/opc-publisher:latest

Later on, I checked the actual version I got using the first log lines of the module:

[00:39:13 INF Root] Starting module OpcPublisher version 2.7.199.64639.

OPC-UA Module Configuration

It needs two sets of configuration settings to expose OPC-UA server values:

The first set of configuration settings is a local file in a folder of your choice.

Here, I give two examples of the location where the pn.json can be placed:

  1. ‘c:\iiotedge’ for IoT Edge gateways using a Windows 10 LTS runtime.
  2. ‘/var/iiotedge’ for IoT Edge gateways using a Linux (eg. Ubuntu) runtime.

Your module needs enough permissions to access the folder and alter the file. Within Linux I relaxed the folder and file permissions:

sudo chmod 777 /var/iiotedge
sudo chmod 777 /var/iiotedge/*

Windows 10 also allows changing permissions.

Within this folder, we need one file which tells which OPC-UA servers to access, which nodes to listen too and how the security is done:

[
  {
    "EndpointUrl": "opc.tcp://192.168.1.85:4840",
    "UseSecurity": false,
    "OpcNodes": [
      {
        "Id": "ns=2;s=CalcTag"
      },
      {
        "Id": "ns=2;s=UserTag"
      },
      {
        "Id": "ns=2;s=Led1"
      },
      {
        "Id": "ns=2;s=Led2"
      },
      {
        "Id": "ns=2;s=Switch1"
      },
      {
        "Id": "ns=2;s=Switch2"
      },
      {
        "Id": "ns=2;s=Potentio1"
      },
      {
        "Id": "ns=2;s=Potentio2"
      }
    ]
  }
]

Here, the file is named ‘pn.json’, you can choose your own filename. Remember that name.

So, a single tag is exposed as a single node.

Each node has its own NodeId, including a namespace part. The actual name does not seem to be exposed by EdgeLink Studio. I looked them up using the Prosys OPC-UA Client:

Note: This is an excellent tool to test OPC-UA in general and specifically the Wise 710 OPC-UA configuration.

The second set of configuration settings are the OPCPublisher ‘Container Create Options’. These settings are depending on the Host operating filesystem.

Linux related Container Create Options

Here is an example of Linux container create options:

{
    "Hostname": "publisher",
    "Cmd": [
        "--pf=/appdata/pn.json",
        "--aa",
        "--ms=0",
        "--si=10",
        "--ll=verbose",
        "--to"
    ],
    "HostConfig": {
        "Binds": [
            "/var/iiotedge:/appdata"
        ]
    }
}

Note: The settings in the Cmd section are just an example. More information about the settings is available in this documentation.

The most important part is the combination of the bind and the ‘–pf’ setting. if you replace ‘/appdata’ in ‘/appdata/pn.json’ you get ‘/var/iiotedge/pn.json’ which is the actual location.

Warning: This path is usually the biggest source of misconfiguration.

If the path is somehow not working for you, please debug the access to the pn.json by getting bash access inside your Linux container (the container must run stable):

sudo docker exec -i -t [the name of your OPCPublisher module] /bin/bash

Within the module, try if you can find the appdata folder and check if you can open the pn.json file.

Windows related Container Create Options

In the following example, the ‘pn.json’ file is located in ‘ c:\iiotedge’. The container create options are:

{
    "Hostname": "opcpublisher",
    "Cmd": [
        "--pf=c:\\appdata\\pn.json",
        "--aa"
    ],
    "HostConfig": {
        "Binds": [
            "c:\\iiotedge:c:\\appdata"
        ]
    }
}

Again, the combination of the internal path and the Bind results in the actual full file name.

OPC-UA message response

Once both configurations are set up, you should see incoming telemetry.

If all goes well, it results in this kind of output:

[
    {
        "NodeId": "nsu=OpcUaServer.Data_Center;s=Potentio1",
        "ApplicationUri": "urn:wise710a1:ua.Server:OpcUaServer",
        "Value": {
            "Value": 5,
            "SourceTimestamp": "2021-01-04T18:11:25.436053Z"
        }
    },
    {
        "NodeId": "nsu=OpcUaServer.Data_Center;s=Potentio1",
        "ApplicationUri": "urn:wise710a1:ua.Server:OpcUaServer",
        "Value": {
            "Value": 0,
            "SourceTimestamp": "2021-01-04T18:11:26.370269Z"
        }
    }
]

The output seen in the Azure IoT Explorer is:

Optimizing the output

Please invest some time in optimizing the OPC-UA output. Be aware of the memory usage and performance, both on the OPC Publisher and the OPC-UA servers.

The Wise 710 exposes its memory and CPU usage, please make use of that:

Next to that, be aware you can get duplicate values of the same node in one message. Also, nodes that are not changing are not part of the output.

This all can be configured. So, fiddling with the module options really pays off.

Conclusion

After two years, it was time to revisit the OPC Publisher. The original way of setting the published nodes is still working well.

As OPC-UA Server, I used an Advantech Wise 710 which was exceptionally easy to set up. It proofs to be a versatile tool on the factory floor to collect data telemetry and calculate new values.

Once the telemetry messages flow into the Azure IoT Edge and cloud, please take some time to optimize the message flow.

2 gedachten over “Handling Advantech Wise 710 OPC-UA telemetry using OPCPublisher

  1. Why didn’t you connect the Advantech Wise 710 to the edge runtime directly using the Modbus module? What is the advantage of your solution?

    1. Hello Oliver, in the past I already demonstrated how to use the Microsoft Modbus module to connect to a Wise 4000 series IO device. The Wise 710 is used to demonstrate how to connect to a generic OPC-UA server using the Microsoft OPCPublisher. In real-world solutions it becomes more common to connect Edge to protocol gateways instead off running all kinds of protocol transformation modules.

Reacties zijn gesloten.