Conectar OPC UA a Mosquitto / broker MQTT

Antes de empezar

• Algo que hable OPC UA de verdad: un publicador, un colector o un gateway. El broker es un destino, no un cliente, y ninguna configuración de broker hará que un PLC publique.
• Una decisión sobre el formato de payload antes de que exista el primer topic. OPC UA PubSub sobre MQTT con JSON es la vía basada en normas; la forma de JSON propia de un colector y Sparkplug B son las alternativas habituales, y no son intercambiables.
• Una convención de nomenclatura de topics acordada con quien vaya a consumirla, porque el árbol de topics es el contrato y renombrarlo después rompe de golpe a todos los suscriptores.
• TLS con certificados reales y autenticación configurada antes de que publique nada de producción. Un broker abierto en una red de planta es una planta abierta.

Cómo configurarlo

1. Configure primero el broker para TLS y autenticaciónDefina un listener explícito, deshabilite el acceso anónimo, configure credenciales o certificados de cliente y añada control de acceso por topic para cada cliente. Hacerlo antes de que exista ningún publicador es mucho más fácil que adaptarlo después en una flota de publicadores.
2. Diseñe la jerarquía de topics desde la planta, no desde el espacio de direccionesUn árbol de topics derivado mecánicamente de las rutas de exploración OPC UA es cómodo y produce topics a los que nadie puede suscribirse de forma útil. Derívelo del emplazamiento, el área, la línea y la máquina, y coloque el nombre de la señal en la hoja. Cuando un publicador sí ofrezca enrutado automático a partir de los BrowseName, tenga en cuenta que los caracteres reservados de MQTT deben escaparse, y compruebe qué hace el publicador con ellos.
3. Elija y fije la codificación del payloadSi usa OPC UA PubSub sobre MQTT, decida entre UADP y JSON y, si es JSON, entre las formas reversible y no reversible. El JSON no reversible pierde la información de tipo y no admite ida y vuelta, lo que es una sorpresa que aparece meses después en un consumidor aguas abajo.
4. Decida los mensajes retenidos y el last will por clase de topicLos mensajes retenidos dan al nuevo suscriptor el valor actual de inmediato, lo cual es correcto para el estado y la identidad e incorrecto para los eventos, donde un mensaje retenido reproduce algo que ya ocurrió. Configure un topic de last will por publicador para que un colector caído sea visible.
5. Ajuste la calidad de servicio al significado del datoLa calidad de servicio 0 vale para una analógica de alta frecuencia que va a remuestrear de todos modos y es inaceptable para un evento de parada o un incremento de contador, porque un corte de red simplemente lo pierde. Use la entrega «al menos una vez» para todo aquello de lo que dependa un cálculo y haga idempotentes a los consumidores.
6. Verifique el payload con un cliente antes de construir consumidoresSuscríbase con MQTT Explorer o con un cliente de línea de comandos y lea los bytes reales que circulan. Tenga en cuenta en particular que, en la codificación JSON de OPC UA, un estado Good es el valor cero y se omite, de modo que un campo de estado ausente significa bueno, no datos ausentes.
7. Supervise el broker y los publicadores por separadoVigile el número de conexiones del broker y los mensajes descartados, y alerte sobre la vida de los publicadores mediante topics de last will o un topic de heartbeat por máquina. El silencio en un topic es ambiguo y necesita una señal independiente para interpretarse.

Qué aspecto tiene el espacio de direcciones

MQTT no tiene modelo, solo una cadena de topic y un payload, de modo que todo lo que sabía el espacio de direcciones OPC UA tiene que volver a expresarlo quien publique. Esa es la decisión de diseño central de un espacio de nombres unificado: la jerarquía de topics más el esquema del payload son todo el modelo de información para cualquier consumidor. OPC UA PubSub transporta los metadatos del dataset junto a los datos, lo que preserva tipos y nombres de campo y es la razón por la que la vía basada en estándares merece la configuración adicional; el JSON de un colector improvisado normalmente no lo hace, y entonces el significado de un campo vive en algún documento. Sea cual sea la opción, publique la URI del espacio de nombres OPC UA y el identificador del nodo en el payload o en los metadatos del topic, para que un valor pueda rastrearse hasta el nodo del que procede.

Las trampas

• Tratar el broker como si fuera la integración es el error clásico. El broker mueve bytes; la semántica viene del diseño de topics y de payload del publicador, y en ese diseño está el trabajo real del proyecto.
• La calidad de servicio 0 sobre datos de tipo evento pierde eventos en silencio justo en las condiciones de red que producen los eventos más interesantes. Los registros de parada y los incrementos de contador necesitan entrega al menos una vez.
• Los mensajes retenidos en topics de eventos reproducen eventos obsoletos para cada nuevo suscriptor, lo que corrompe a los consumidores que suponen que un mensaje significa ahora.
• La codificación JSON no reversible pierde información de tipo y no admite ida y vuelta. Elija de forma deliberada y deje constancia de la elección; descubrirlo aguas abajo sale caro.
• En la codificación JSON de OPC UA un estado Good es cero y se omite, así que un consumidor que trate un campo de estado ausente como dato ausente descartará valores buenos.
• Los árboles de topics derivados automáticamente de las rutas de navegación codifican la estructura interna del PLC en su espacio de nombres de planta, y cambian cuando cambia el programa del PLC.
• El broker se convierte en un punto único de fallo para toda la planta y en una frontera de seguridad para toda la planta. Móntelo en clúster o acepte el riesgo explícitamente, y nunca deje activado el acceso anónimo porque resultara cómodo durante la puesta en marcha.
• MQTT no garantiza el orden entre topics distintos. Un cambio de estado y el recuento que le corresponde pueden llegar desordenados si se publican en topics separados, así que ponga en un mismo mensaje los hechos que deban ser coherentes entre sí.

Cómo sacarle datos de OEE

El broker no aporta nada al OEE por sí solo y puede deteriorarlo de forma silenciosa. Lo que hace bien es desacoplar la recogida del cálculo, de modo que una plataforma de analítica pueda consumir el estado de máquina, los recuentos y los motivos sin mantener sesiones contra cada PLC. Los requisitos que impone son concretos: publicar las transiciones de estado como eventos con la marca de tiempo de la propia máquina en el payload en lugar de depender de la hora de llegada, publicar incrementos de recuento o contadores absolutos con contexto suficiente para detectar reinicios, usar entrega al menos una vez para ambos, y dar a cada máquina un heartbeat o un topic de last will para poder distinguir el silencio de una máquina parada. El tiempo de producción planificado, los calendarios de turnos, el contexto de orden y los tiempos de ciclo estándar no son datos de máquina y deben llegar al cálculo desde el MES o el ERP, no publicándose a mano en un topic y olvidándose.

Última verificación el 7 de septiembre de 2026 frente a OPC UA 1.05.07. OPC UA Connect es un recurso educativo y no está afiliado a la OPC Foundation.