Cliente OPC UA en Node-RED hacia MQTT con topics ISA-95

Un flujo OPC UA en Node-RED te permite tomar valores de PLC modernos, controladores CNC y servidores SCADA y publicarlos en MQTT, donde muchos consumidores pueden usarlos sin que cada uno tenga que abrir su propia sesión OPC UA. En este tutorial te suscribirás a variables OPC UA con node-red-contrib-opcua, asignarás sus node IDs a topics MQTT de estilo ISA-95 y publicarás cada cambio con su calidad y su marca de tiempo de origen. Puedes seguirlo con un servidor de simulación gratuito y un broker MQTT gratuito.

Por qué combinar OPC UA y MQTT

OPC UA es excelente dentro de la planta: tiene un modelo de información rico, espacios de direcciones navegables, tipos de datos, seguridad y suscripciones. Es menos cómodo para la distribución a gran escala. Cada cliente mantiene una sesión con el servidor, los firewalls entre la planta y la nube complican las conexiones directas y los controladores pueden limitar cuántas sesiones aceptan.

MQTT lo complementa. Un único gateway mantiene una sola sesión OPC UA, recibe los cambios a través de una suscripción OPC UA y los publica en un broker. A partir de ahí, paneles, historiadores, MES y analítica en la nube se suscriben a topics que entienden. La comparativa OPC UA vs MQTT analiza las ventajas y desventajas en detalle. En resumen: OPC UA describe la máquina, MQTT distribuye los datos y Node-RED es un puente práctico entre ambos para pilotos y plantas pequeñas o medianas.

Qué necesitas

Instala los nodos OPC UA:

cd ~/.node-red
npm install node-red-contrib-opcua
# restart Node-RED afterwards

El paquete es grande porque incluye la pila node-opcua, así que la instalación puede tardar unos minutos en una Raspberry Pi.

Como servidor de pruebas se usa mucho el Prosys OPC UA Simulation Server, que es gratuito. Su endpoint por defecto tiene la forma opc.tcp://<your-pc>:53530/OPCUA/SimulationServer y expone variables simuladas como Counter, Random y Sinusoid. Los node IDs varían según la versión, así que lee los IDs exactos en la vista Objects del servidor; en muchas versiones tienen el aspecto ns=3;i=1001.

Paso 1: encuentra los node IDs

Cada variable OPC UA tiene un node ID formado por un índice de namespace y un identificador, por ejemplo ns=3;i=1001 (numérico) o ns=4;s=Line2.Filler.Temperature (cadena). Necesitas estos IDs antes de poder suscribirte.

Hay dos formas de encontrarlos:

1. Usa el nodo OpcUa-Browser en Node-RED: apúntalo al endpoint y navega desde la carpeta Objects.
2. Usa un cliente de escritorio como UaExpert, selecciona una variable y copia su NodeId.

Anota también el tipo de dato (Double, Int32, Boolean). El nodo cliente lo usa al escribir y te indica cómo formatear el valor en MQTT.

Paso 2: configura el cliente OPC UA

Añade un nodo OpcUa-Client y crea una configuración de endpoint:

• Endpoint: opc.tcp://<server-host>:53530/OPCUA/SimulationServer
• Política de seguridad: None y modo None para la primera prueba
• Acción: SUBSCRIBE
• Intervalo: 1000 ms (el intervalo de publicación de la suscripción OPC UA)

Después añade un nodo OpcUa-Item por variable, con el item igual al node ID y el tipo igual al tipo de dato de la variable. Conecta un único nodo inject, configurado para dispararse una vez a los 2 segundos, a todos los nodos item, y conecta los nodos item al cliente. Al arrancar el flujo, cada item pide al cliente que monitorice ese nodo y, a partir de entonces, el cliente emite un mensaje cada vez que cambia un valor, con el valor en msg.payload y el node ID en msg.topic.

Despliega y añade un nodo debug después del cliente. Deberías ver Counter incrementándose y Random cambiando cada segundo. Si el estado del cliente muestra un error de conexión, revisa la URL del endpoint, sobre todo el nombre de host: muchos servidores anuncian su propio hostname, que debe poder resolverse desde la máquina de Node-RED.

Paso 3: asigna los node IDs de OPC UA a topics MQTT ISA-95

Publicar en un topic como opcua/ns=3;i=1001 funcionaría técnicamente, pero nadie aguas abajo sabría qué significa. En su lugar, asigna cada node ID a un lugar de tu jerarquía de equipos: empresa o planta, área, línea, celda y tag. Esa es la idea detrás de las estructuras de topics ISA-95 y del Unified Namespace. La guía de topics MQTT ISA-95 explica los niveles.

Una tabla de correspondencias en un nodo function mantiene la asignación explícita y fácil de revisar:

// Function node "opc ua to isa-95 topic"
// Map OPC UA node IDs to equipment paths and tag names.
const PREFIX = "connectmq/demo/a7f3k2";    // demo prefix for the public broker
const MAP = {
    "ns=3;i=1001": { path: "plant1/packaging/line2/filler", tag: "counter", unit: "" },
    "ns=3;i=1002": { path: "plant1/packaging/line2/filler", tag: "pressure", unit: "bar" },
    "ns=3;i=1004": { path: "plant1/packaging/line2/capper", tag: "torque", unit: "Nm" }
};

const nodeId = String(msg.topic);
const entry = MAP[nodeId];
if (!entry) {
    node.warn("Unmapped node ID: " + nodeId);
    return null;
}

// Quality: node-opcua status codes expose a name such as "Good" or "Bad..."
let quality = "Good";
if (msg.statusCode && typeof msg.statusCode === "object" && msg.statusCode.name) {
    quality = msg.statusCode.name;
}

const value = typeof msg.payload === "number"
    ? Math.round(msg.payload * 1000) / 1000
    : msg.payload;

msg.topic = `${PREFIX}/${entry.path}/${entry.tag}`;
msg.payload = {
    value: value,
    unit: entry.unit,
    quality: quality,
    sourceTimestamp: msg.sourceTimestamp || new Date().toISOString(),
    nodeId: nodeId
};
msg.retain = true;
return msg;

El topic resultante, por ejemplo connectmq/demo/a7f3k2/plant1/packaging/line2/filler/pressure, tiene ocho niveles. Eso encaja en el límite de ocho niveles de topic del servidor público; en un broker privado eliminarías el prefijo de demostración y podrías añadir un nivel de empresa.

Publicar con retain significa que cualquier suscriptor nuevo recibe de inmediato el último valor de cada tag, que es exactamente como debe comportarse un Unified Namespace: el árbol de topics representa el estado actual. Mantén la calidad y la marca de tiempo de origen en el payload. Un historiador necesita saber cuándo cambió el valor en el origen, no cuándo lo reenvió Node-RED, y un valor de calidad "Bad" no debería graficarse como si fuera real.

Paso 4: publica en MQTT

Añade un nodo mqtt out dejando vacíos los campos de topic y retain, para que se usen las propiedades del mensaje. Para pruebas, conéctate a broker.connectmq.com en el puerto 1883 con un client ID único; es el servidor MQTT público gratuito, así que sustituye a7f3k2 por tu propia cadena aleatoria y no publiques allí datos reales de producción.

Comprueba la salida desde una terminal:

mosquitto_sub -h broker.connectmq.com -p 1883 -i sub-opcua-a7f3k2 -v \
  -t 'connectmq/demo/a7f3k2/plant1/#'

Cada línea muestra un topic y un payload JSON con valor, unidad, calidad y marca de tiempo.

Escribir de vuelta en OPC UA (con cuidado)

El mismo nodo cliente admite una acción WRITE. Un flujo de comandos MQTT se suscribiría a un topic de comandos dedicado, validaría el valor y el rango en un nodo function, fijaría msg.topic a un node ID fijo y lo enviaría a través de un OpcUa-Item configurado con el tipo de dato correcto. Como en cualquier ruta de escritura OT, nunca dejes que el mensaje entrante elija el node ID, registra cada escritura y publica un topic de confirmación. Muchas plantas mantienen el gateway en solo lectura hasta que existe una necesidad clara.

Seguridad para producción

La configuración de prueba no usa seguridad. Para un controlador real:

1. Usa una política segura. Elige Basic256Sha256 con el modo SignAndEncrypt en la configuración del endpoint.
2. Confía en los certificados. En la primera conexión, el servidor suele rechazar el certificado de cliente de Node-RED. Muévelo a la lista de confianza del servidor (en Prosys, en la pestaña Certificates) y vuelve a conectar.
3. Usa un usuario dedicado. Configura un usuario OPC UA de solo lectura para el gateway si el servidor admite autenticación de usuarios.
4. Protege el lado MQTT. Conéctate a un broker privado mediante TLS en el puerto 8883 con credenciales, no al servidor público de pruebas.

Solución de problemas en flujos OPC UA de Node-RED

Escalar el patrón

Para unas pocas máquinas, una instancia de Node-RED por planta con una tabla de correspondencias funciona bien. A medida que la tabla crece, muévela a un archivo JSON o al contexto del flujo cargado al arrancar, para que los ingenieros puedan revisar los cambios sin tocar código. Cuando intervienen muchos fabricantes y protocolos, combina este flujo con el gateway Modbus en Node-RED para equipos más antiguos y considera Node-RED con Sparkplug B si tus consumidores esperan la gestión de birth, death y estado de Sparkplug. Vale la pena evaluar gateways comerciales cuando necesites cientos de tags por planta con configuración centralizada.

Todos estos gateways necesitan un broker en el que puedan confiar. Un broker MQTT en la nube permite que gateways de varias plantas, por ejemplo en Monterrey, Bogotá o Valencia, publiquen en un único namespace mediante conexiones TLS salientes. ConnectMQ es un broker MQTT gestionado que detecta estructuras de topics ISA-95 y Unified Namespace y muestra los dispositivos por empresa, planta, área, línea y celda en su portal, lo que facilita comprobar que tu tabla de correspondencias produjo la jerarquía que pretendías. Esos mismos topics pueden alimentar después un gemelo digital 3D de la planta. Para repasar qué hace un broker MQTT en esta arquitectura, o cómo configurar los nodos MQTT, consulta el tutorial de Node-RED y MQTT.

Publica tus datos OPC UA en ConnectMQ

Regístrate en app.connectmq.com con el plan gratuito Serverless, sin tarjeta de crédito. Crea un broker, pega el usuario, la contraseña y el client ID generados en el nodo de configuración MQTT de Node-RED, cambia al puerto 8883 con TLS y elimina el prefijo de demostración de la tabla de correspondencias. Tus tags OPC UA aparecerán entonces en el portal de ConnectMQ organizados por niveles ISA-95.

Preguntas frecuentes

¿Qué paquete de Node-RED se usa para OPC UA?

El paquete más utilizado es node-red-contrib-opcua, construido sobre la pila node-opcua. Proporciona nodos de cliente, item, navegador y servidor para leer, escribir, suscribirse y hacer pruebas.

¿Debo hacer polling o suscribirme a los valores OPC UA en Node-RED?

Suscríbete siempre que el servidor lo admita. Así el servidor envía solo los cambios al intervalo que fijes, lo que carga menos al controlador y ofrece actualizaciones más rápidas que el polling.

¿Por qué asignar los node IDs de OPC UA a topics MQTT ISA-95?

Los node IDs solo tienen significado dentro de un servidor. Los topics de estilo ISA-95 describen de dónde vienen los datos en la planta, de modo que cualquier consumidor puede encontrarlos y entenderlos sin conocer el espacio de direcciones OPC UA.

¿Puede Node-RED conectarse a servidores OPC UA con la seguridad activada?

Sí. Elige una política de seguridad como Basic256Sha256 con SignAndEncrypt y marca como confiable el certificado de cliente de Node-RED en el servidor. También se admite la autenticación con usuario y contraseña.