Erbessd PHANTOM® OPC UA

Ir a la página principal de PHANTOM®

El Gateway versión 2 del sistema de sensores inalámbricos ERBESSD INSTRUMENTS® PHANTOM®, y el monitor cableado DEFIANT™, incorporan un servidor OPC UA nativo. Cada sensor aparece como un objeto en el espacio de direcciones del servidor, con sus mediciones en vivo como variables OPC UA que cualquier cliente estándar —Ignition, Kepware, WinCC, FactoryTalk, Node-RED, UAExpert, opcua-asyncio— puede explorar, leer, suscribir y, en unos pocos puntos de control, escribir.

Por la forma en que funciona el protocolo OPC UA, la forma de onda completa y la FFT no están disponibles por OPC UA. Usa la integración por MQTT para los datos de forma de onda.

Puedes usar el servidor OPC UA al mismo tiempo que el resto de los protocolos que soporta el Gateway, incluidos EI-Analytic™, EI Monitor, MQTT y Modbus.

Algunas de las opciones descritas aquí se agregaron en versiones posteriores del gateway. Si no encuentras alguna en tu consola de administración, actualiza el gateway al firmware más reciente.

Resumen de capacidades del servidor

Cómo habilitar el servidor OPC

Para habilitar el servidor OPC UA, en la consola de administración del Gateway 2 actívalo en la página de configuración General marcando la casilla “Enable OPC UA Server”. Haz clic en guardar y el Gateway se reiniciará. Cuando termine de reiniciarse, el servidor OPC estará listo.

URL del endpoint

Una vez habilitado el servidor OPC UA, puedes acceder a él con cualquier cliente OPC UA usando:

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

donde 192.168.1.2 se reemplaza por la dirección IP de tu gateway. Para una primera conexión usa modo de seguridad None y política de seguridad None.

El servidor publica sus endpoints bajo el nombre de host PhantomGW, y además anuncia estos nombres alternativos para que un cliente que reescribe la URL del endpoint tras el descubrimiento pueda seguir alcanzándolo:

• PhantomGW-<serieDelGateway>
• la dirección actual de eth0 del gateway, o la de wlan0 cuando no hay dirección cableada

Sustituir el nombre de host

Algunos clientes rechazan un endpoint cuyo nombre de host no pueden resolver. Marca Override OPC hostname e ingresa un Host name —un nombre DNS o la dirección IP fija del gateway— para que el servidor anuncie ese nombre en lugar de PhantomGW.

Perfiles de seguridad

Políticas de seguridad y modos de mensaje

Por defecto el servidor ofrece el conjunto completo, para que cualquier cliente pueda conectarse sin importar lo que soporte:

Deshabilitar la comunicación sin cifrar de OPC UA

Marcar Disable OPC UA unencrypted communication reduce el servidor únicamente a las políticas modernas:

None, Basic128Rsa15 y Basic256Sha256 quedan retiradas, y los modos None y solo Sign dejan de ofrecerse. Esta es la configuración recomendada para producción. Basic128Rsa15 y Basic256Sha256 están obsoletas según la OPC Foundation; dejarlas habilitadas solo sirve para clientes antiguos que no pueden negociar las políticas AES.

Verifica que tu cliente soporte Aes128_Sha256_RsaOaep o Aes256_Sha256_RsaPss antes de habilitar esta opción; de lo contrario dejará de poder conectarse.

Autenticación de usuarios

De fábrica el servidor acepta sesiones anónimas. Puedes restringirlo desde la misma página de configuración OPC:

Los usuarios se definen por gateway. Combina Disable OPC UA Anonymous login con Disable OPC UA unencrypted communication para que las credenciales nunca viajen por un canal sin cifrar.

Espacio de direcciones

El servidor OPC UA está organizado en una estructura de árbol. Bajo la carpeta raíz hay una carpeta Objects, y dentro de ella se muestran todos los números de serie de los sensores. Bajo cada número de serie hay distintas variables según el tipo de sensor.

Todos los nodos viven en el índice de namespace 1 y usan NodeId de tipo cadena.

Root
└── Objects
    ├── 40217                         ← sensor inalámbrico, browse name = serie del sensor
    │   ├── 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, escribible)
    │   │   └── triggerStateUpdate    (Boolean, escribible)
    │   └── extendedMetrics           (solo sensores triaxiales)
    │       ├── 0                     ← eje X
    │       ├── 1                     ← eje Y
    │       └── 2                     ← eje Z
    └── WiredCH1                      ← canal cableado del DEFIANT™
        ├── accel_rms                 (Double)
        ├── velocity_rms              (Double)
        └── …

Esquema de NodeId

Cada nodo tiene un NodeId de cadena determinista, así que puedes direccionar un tag directamente sin explorar el árbol:

Para el sensor 40217, el RMS de velocidad del eje Z es ns=1;s=ph40217-rms_element2, y el arreglo completo del RMS de velocidad es ns=1;s=ph40217-rms.

Los arreglos se publican dos veces. Cada variable de arreglo (rms, arms, tcTemperature, voltage, instCurrent, dryContactsState, …) se expone tanto como un nodo de arreglo como un nodo escalar por elemento, con el sufijo _element0, _element1, … Usa el nodo de arreglo si tu cliente maneja arreglos; usa los nodos _elementN cuando espere un tag por valor, que es lo que asumen la mayoría de los exploradores de tags de PLC y SCADA.

Marcas de tiempo y muestreo

Cada variable de medición reporta un sourceTimestamp y un serverTimestamp fijados al momento en que el gateway recibió la última actualización de ese sensor. Comparar esa marca de tiempo con la hora actual es la forma confiable de detectar un sensor que dejó de reportar: el valor simplemente conserva su última lectura.

Todas las variables declaran un minimumSamplingInterval de 1000 ms. Pedir un intervalo de publicación más rápido en una suscripción no producirá datos nuevos: los sensores inalámbricos anuncian en su propio intervalo configurado, normalmente de segundos a minutos.

Qué sensores aparecen

Por defecto se exportan todos los sensores que ve el gateway, estén emparejados o no. Marca Export only paired sensors para limitar el espacio de direcciones a los sensores emparejados. Los nodos se agregan y se quitan en vivo conforme los sensores se emparejan, se desemparejan, se descubren o se olvidan; no hace falta reiniciar el gateway. El booleano isPaired permite que un cliente que exporta todo filtre por su cuenta.

Variables

La variable type contiene el tipo de sensor según la siguiente tabla:

Variables comunes a todos los sensores

Tipos de batería:

Acelerómetro triaxial (3, 5, 6, 8 y 9)

PHANTOM® MAX (14 y 15)

Triaxial universal (7)

Cámara termográfica (10)

La imagen térmica en sí no se publica por OPC UA. Usa MQTT.

Temperatura por termopar (20, 21 y 22)

Temperatura infrarroja (25)

Sensor 4-20 mA (26) y voltímetro (27)

Módulo de corriente (30 y 32)

Sensor de contactos secos (31)

Sensor de velocidad (RPM) (40)

Distancia (50)

Nodo de propósito general (60)

Repetidor (12)

Solo se publican type y version.

Métricas extendidas (sensores triaxiales)

Cuando un sensor triaxial entrega una forma de onda completa, el gateway calcula estadísticas por eje a partir de ella y las publica bajo extendedMetrics, en subobjetos llamados 0 (X), 1 (Y) y 2 (Z):

Estos nodos aparecen la primera vez que se recolecta una forma de onda de ese sensor, y sus marcas de tiempo reflejan la última forma de onda, no la última actualización de estado.

Acciones del sensor (variables escribibles)

Cada objeto de sensor incluye una carpeta sensorActions con variables booleanas escribibles. Escribir en una de ellas encola la acción correspondiente en el gateway; el valor que se lee de vuelta indica si hay una acción pendiente.

Por ejemplo, escribir true en ns=1;s=ph40217-actions-triggerCollection dispara una recolección en el sensor 40217. La forma de onda resultante no se devuelve por OPC UA: se almacena y se reenvía a EI-Analytic™, EI Monitor y/o MQTT según tu configuración.

Canales cableados del DEFIANT™

En un DEFIANT™, cada canal cableado se agrega como un objeto llamado WiredCH1, WiredCH2, … con los valores globales calculados para ese canal como variables Double. El browse name del objeto y su NodeId empiezan en 1 (WiredCH1 es el primer canal, ns=1;s=wired1).

Conexión: ejemplos prácticos

UAExpert

1. Server → Add → Custom Discovery → Double click to add server.
2. Ingresa opc.tcp://192.168.1.2:4334/UA/PhantomGW.
3. Expande el servidor descubierto y elige el endpoint: None / None para una primera prueba, o Aes256_Sha256_RsaPss / Sign & Encrypt en producción.
4. Si deshabilitaste el acceso anónimo, entra a Authentication Settings → Username e ingresa las credenciales que creaste en la consola.
5. Confía en el certificado del gateway cuando te lo pida, luego conéctate y explora 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:
        # Leer el arreglo completo del RMS de velocidad
        rms = await client.get_node("ns=1;s=ph40217-rms").read_value()
        print("RMS de velocidad x/y/z (mm/s):", rms)

        # Leer un solo eje
        rms_z = await client.get_node("ns=1;s=ph40217-rms_element2").read_value()
        print("RMS de velocidad Z (mm/s):", rms_z)

        # Leer el valor junto con su marca de tiempo de origen
        dv = await client.get_node("ns=1;s=ph40217-temperature").read_data_value()
        print("temperatura:", dv.Value.Value, "a las", dv.SourceTimestamp)

asyncio.run(main())

Con autenticación y cifrado habilitados:

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

Suscribirse en lugar de sondear

Como todas las variables declaran un intervalo mínimo de muestreo de 1000 ms, pide un intervalo de publicación de 1000 ms o más lento. Un intervalo más rápido se acepta pero no entrega datos adicionales.

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"))

Solución de problemas