OPC UA y MQTT: cómo llevar datos de planta al análisis

Separa el significado del transporte de mensajes

Un valor de temperatura de 75 necesita un equipo, sensor, unidad, marca de tiempo y contexto de calidad. Sin ellos, el receptor no puede distinguir con seguridad grados Celsius de grados Fahrenheit o una lectura actual de una almacenada.

OPC UA modela información industrial y soporta varios patrones de comunicación. MQTT distribuye mensajes a través de temas y un broker. La OPC Foundation respalda explícitamente la integración entre ellos; su Iniciativa Cloud incluye una arquitectura de referencia 2026 y un grupo de trabajo para OPC UA sobre MQTT.

La guía de IoT industrial cubre el sistema completo. Aquí nos centramos en conservar el significado de los datos desde la captura hasta el análisis.

Elige un patrón soportado, no un eslogan

Un cliente OPC UA puede leer datos de un servidor o suscribirse a ellos y pasarlos por una aplicación local, llamada edge. Otra opción es una implementación compatible de OPC UA PubSub que publique un conjunto definido mediante MQTT. Son diseños distintos. Comprueba cuál admiten realmente tus equipos y programas.

MQTT no proporciona un modelo de información industrial simplemente porque su carga útil es JSON. Un contrato JSON personalizado puede ser útil, pero no es automáticamente compatible con OPC UA PubSub. El IIoT StarterKit de la OPC Foundation ofrece un ejemplo concreto de publicador compatible.

Confirma la codificación, las convenciones de temas, las versiones de metadatos y la compatibilidad del consumidor antes de elegir una implementación. No supongas que marcar una casilla de protocolo en dos productos prueba la interoperabilidad.

Especifica qué debe saber un receptor

Contrato de datos ilustrativo para un contador de eje solo analítico: la máquina P-07 reporta un conteo acumulado de unidades aceptadas de 412 con una marca de tiempo de origen de 10:15:00 UTC. Un registro de borde llega cinco segundos después. La hora de llegada no debe reemplazar silenciosamente la hora de origen.

Los campos siguientes forman un contrato didáctico, no un formato obligatorio de transmisión OPC UA. En producción, conserva el estado de origen, las versiones y los identificadores del modelo documentado.

Prueba reconexiones, duplicados y valores antiguos

OASIS MQTT define niveles de calidad de entrega. La entrega al menos una vez puede producir duplicados. Incluso la entrega del protocolo exactamente una vez no garantiza que tu base de datos de extremo a extremo y tu proceso de cálculo empresarial procesen cada evento real exactamente una vez.

Un valor retenido puede llegar a un nuevo suscriptor mucho después de medirse. Conserva la hora de origen y define la antigüedad aceptable. Usa caducidad cuando esté disponible. Un intervalo sin datos debe seguir marcado como desconocido, no convertirse en un cero que parezca una línea parada.

Un valor OPC UA que no cambia puede conservar una hora de origen antigua aunque la fuente funcione bien. Comprueba también el estado de adquisición, la hora del servidor o las señales de actividad. Una hora de cambio antigua no demuestra una desconexión.

Prueba reinicios de contadores acumulativos, eventos reordenados, conexiones perdidas y calidad inválida. Diferentes fallos requieren reglas de manejo diferentes.

1. Define un uso analítico único

   Empieza con una medida de solo lectura y define retraso aceptable, validez y ámbito del informe.

2. Documenta el contrato

   Registra IDs de activos, tipos de datos, unidades, semántica temporal, calidad, esquema e identidad del evento.

3. Prueba la entrega anormal

   Simule desconexiones, reproducción, duplicados, valores retenidos obsoletos, reinicios y estado de origen inválido.

4. Comprueba con un registro fiable

   Compara los cambios de unidad aceptados y ventanas temporales con un registro de producción verificado independientemente antes de expandir.

Mantén el control y la seguridad fuera del experimento

El flujo de análisis no debe permitir órdenes a máquinas que nadie haya revisado. El equipo responsable de planta debe revisar accesos, certificados, autorizaciones, separación de redes y ajustes de seguridad con personal competente.

Este ejemplo no es un diseño de control determinista. El retraso de entrega y la disponibilidad de un panel de control en la nube pueden ser aceptables para el análisis de tendencias, pero inadecuados para una función de control o seguridad. Especifica ese límite explícitamente.

Evalúa los datos que puedes usar

Mide antigüedad, calidad, intervalos desconocidos, duplicados rechazados y versiones incompatibles. Contar mensajes sirve de poco si el mismo valor antiguo llega muchas veces.

Una vez que el registro sea fiable, análisis de fabricación y monitoreo de producción pueden responder a la pregunta operativa. Empieza con una máquina y una medida reconciliada, luego expanda el contrato deliberadamente.