Erbessd PHANTOM® OPC UA

Go to PHANTOM® main page

The Gateway version 2 for the wireless sensor system ERBESSD INSTRUMENTS® PHANTOM®, and the DEFIANT™ wired monitor, embed a native OPC UA server. Every sensor appears as an object in the server address space, with its live measurements as OPC UA variables that any standard client — Ignition, Kepware, WinCC, FactoryTalk, Node-RED, UAExpert, opcua-asyncio — can browse, read, subscribe to and, for a few control points, write.

Because of how the OPC UA protocol works, the full time waveform and the FFT are not available over OPC UA. Use the MQTT integration for waveform data.

You can use the OPC UA server at the same time as all other protocols supported by the Gateway, including EI-Analytic™, EI Monitor, MQTT and Modbus.

Some of the options described here were added in later gateway releases. If you cannot find one in your admin console, update your gateway to the latest firmware.

Server capabilities at a glance

Enabling the OPC Server

To enable the OPC UA server, in the Gateway 2 admin console, enable it in the General config page by clicking the “Enable OPC UA Server” checkbox. Click save and the Gateway will restart. After the Gateway restarts the OPC Server will be ready.

Endpoint URL

After the OPC UA server has been enabled you can access it with any OPC UA client using:

opc.tcp://192.168.1.2:4334/UA/PhantomGW

where 192.168.1.2 is replaced by the IP address of your gateway. For a first connection use security mode None and security policy None.

The server publishes its endpoints under the hostname PhantomGW, and also advertises these alternate hostnames so a client that rewrites the endpoint URL after discovery can still reach it:

• PhantomGW-<gatewaySerial>
• the gateway current eth0 address, or wlan0 when there is no wired address

Overriding the hostname

Some clients reject an endpoint whose hostname they cannot resolve. Tick Override OPC hostname and enter a Host name — a DNS name, or the fixed IP address of the gateway — to have the server advertise that name instead of PhantomGW.

Security profiles

Security policies and message modes

By default the server offers the complete set, so any client can connect regardless of what it supports:

Disable OPC UA unencrypted communication

Ticking Disable OPC UA unencrypted communication narrows the server down to the modern policies only:

None, Basic128Rsa15 and Basic256Sha256 are withdrawn, and the None and Sign-only modes are no longer offered. This is the recommended production setting. Basic128Rsa15 and Basic256Sha256 are deprecated by the OPC Foundation; leaving them enabled is only useful for older clients that cannot negotiate the AES policies.

Verify that your client supports Aes128_Sha256_RsaOaep or Aes256_Sha256_RsaPss before enabling this option — otherwise it will no longer be able to connect.

User authentication

Out of the box the server accepts anonymous sessions. You can lock this down in the same OPC config page:

Users are defined per gateway. Combine Disable OPC UA Anonymous login with Disable OPC UA unencrypted communication so credentials are never sent over an unencrypted channel.

Address space

The OPC UA server is organized in a tree-like structure. Under the root folder there is an Objects folder, under which all the sensor serial numbers are shown. Under each serial number there is a number of different variables depending on the sensor type.

All nodes live in namespace index 1 and use string NodeIds.

Root
└── Objects
    ├── 40217                         ← wireless sensor, browse name = sensor serial
    │   ├── friendlyName              (String)
    │   ├── isPaired                  (Boolean)
    │   ├── type                      (UInt16)
    │   ├── version                   (UInt16)
    │   ├── battery                   (Double)
    │   ├── batteryType               (UInt32)
    │   ├── temperature               (Double)
    │   ├── rms                       (Double[3])
    │   ├── rms_element0..2           (Double)
    │   ├── arms                      (Double[3])
    │   ├── arms_element0..2          (Double)
    │   ├── sensorActions
    │   │   ├── triggerCollection     (Boolean, writable)
    │   │   └── triggerStateUpdate    (Boolean, writable)
    │   └── extendedMetrics           (triaxial sensors only)
    │       ├── 0                     ← X axis
    │       ├── 1                     ← Y axis
    │       └── 2                     ← Z axis
    └── WiredCH1                      ← DEFIANT™ wired channel
        ├── accel_rms                 (Double)
        ├── velocity_rms              (Double)
        └── …

NodeId scheme

Every node has a deterministic string NodeId, so you can address a tag directly without browsing:

For sensor 40217, the velocity RMS on the Z axis is ns=1;s=ph40217-rms_element2, and the whole velocity RMS array is ns=1;s=ph40217-rms.

Arrays are published twice. Every array variable (rms, arms, tcTemperature, voltage, instCurrent, dryContactsState, …) is exposed both as a single array node and as one scalar node per element, suffixed _element0, _element1, … Use the array node when your client handles arrays; use the _elementN nodes when it expects one tag per value, which is what most PLC and SCADA tag browsers assume.

Timestamps and sampling

Every measurement variable reports a sourceTimestamp and a serverTimestamp set to the moment the gateway last received an update from that sensor. Comparing that timestamp with the current time is the reliable way to detect a sensor that has stopped reporting — the value itself simply keeps its last reading.

All variables declare a minimumSamplingInterval of 1000 ms. Requesting a faster publishing interval on a subscription will not produce new data: wireless sensors advertise on their own configured interval, typically seconds to minutes.

Which sensors appear

By default every sensor the gateway sees is exported, paired or not. Tick Export only paired sensors to restrict the address space to paired sensors. Nodes are added and removed live as sensors are paired, unpaired, discovered or forgotten — no gateway restart is needed. The isPaired Boolean lets a client that exports everything filter for itself.

Variables

The type variable will contain the type of the sensor according to the following table:

Common Variables for All Sensors

Battery types:

Triaxial Accelerometer (3, 5, 6, 8 and 9)

PHANTOM® MAX (14 and 15)

Triaxial Universal (7)

Thermal camera (10)

The thermal image itself is not published over OPC UA. Use MQTT.

Thermocouple Temperature (20, 21 and 22)

Infrared Temperature (25)

4-20mA Sensor (26) and Voltmeter (27)

Current module (30 and 32)

Dry Contacts Sensor (31)

Velocity (RPM) Sensor (40)

Distance (50)

General purpose node (60)

Repeater (12)

Only type and version are published.

Extended metrics (triaxial sensors)

When a triaxial sensor delivers a full waveform, the gateway computes per-axis statistics from it and publishes them under extendedMetrics, in sub-objects named 0 (X), 1 (Y) and 2 (Z):

These nodes appear the first time a waveform is collected from that sensor, and their timestamps reflect the last waveform, not the last state update.

Sensor actions (writable variables)

Each sensor object carries a sensorActions folder with writable Boolean variables. Writing to one queues the corresponding action on the gateway; the value read back tells you whether an action is currently pending.

For example, writing true to ns=1;s=ph40217-actions-triggerCollection triggers a collection on sensor 40217. The resulting waveform is not returned over OPC UA: it is stored and forwarded to EI-Analytic™, EI Monitor and/or MQTT according to your configuration.

DEFIANT™ wired channels

On a DEFIANT™, each wired channel is added as an object named WiredCH1, WiredCH2, … with the overalls computed for that channel as Double variables. The object browse name and its NodeId are 1-based (WiredCH1 is the first channel, ns=1;s=wired1).

Connecting: worked examples

UAExpert

1. Server → Add → Custom Discovery → Double click to add server.
2. Enter opc.tcp://192.168.1.2:4334/UA/PhantomGW.
3. Expand the discovered server and pick the endpoint: None / None for a first test, or Aes256_Sha256_RsaPss / Sign & Encrypt in production.
4. If you disabled anonymous login, set Authentication Settings → Username and enter the credentials you created in the console.
5. Trust the gateway certificate when prompted, then connect and browse Objects.

Python (opcua-asyncio)

import asyncio
from asyncua import Client

URL = "opc.tcp://192.168.1.2:4334/UA/PhantomGW"

async def main():
    async with Client(url=URL) as client:
        # Read the whole velocity RMS array
        rms = await client.get_node("ns=1;s=ph40217-rms").read_value()
        print("velocity RMS x/y/z (mm/s):", rms)

        # Read a single axis
        rms_z = await client.get_node("ns=1;s=ph40217-rms_element2").read_value()
        print("velocity RMS Z (mm/s):", rms_z)

        # Read the value together with its source timestamp
        dv = await client.get_node("ns=1;s=ph40217-temperature").read_data_value()
        print("temperature:", dv.Value.Value, "at", dv.SourceTimestamp)

asyncio.run(main())

With authentication and encryption enabled:

client = Client(url=URL)
client.set_user("scada")
client.set_password("your-password")
await client.set_security_string(
    "Aes256Sha256RsaPss,SignAndEncrypt,client-cert.der,client-key.pem"
)

Subscribing instead of polling

Because every variable declares a 1000 ms minimum sampling interval, request a publishing interval of 1000 ms or slower. A faster interval is accepted but yields no extra data.

class Handler:
    def datachange_notification(self, node, value, data):
        print(node, value, data.monitored_item.Value.SourceTimestamp)

sub = await client.create_subscription(1000, Handler())
await sub.subscribe_data_change(client.get_node("ns=1;s=ph40217-rms_element2"))

Troubleshooting