Integración MQTT

Integración MQTT industrial: qué cubre el servicio

Implementamos brokers MQTT y flujos de datos para conectar sensores y dispositivos industriales a escala. Dicho en términos de planta: montamos la infraestructura que recoge lo que publican los equipos (una temperatura de horno, el contador de piezas de una línea, el estado de una bomba) y lo pone a disposición de cualquier sistema que lo necesite, desde un histórico de datos hasta un cuadro de mando o el ERP. Nuestro alcance es la conectividad de datos: leer, transportar y entregar la información de los equipos, no la instalación física de maquinaria.

MQTT es un protocolo de mensajería ligero, nacido para redes poco fiables y dispositivos con recursos limitados, que se ha convertido en el estándar de facto para mover datos de planta hacia arriba. Su modelo de publicación y suscripción es lo que lo hace distinto: los equipos no responden a preguntas, publican sus datos cuando cambian, y quien los necesita se suscribe. Esa inversión del flujo tiene consecuencias prácticas importantes que conviene entender antes de diseñar la arquitectura.

El broker: la columna vertebral de los datos de planta

En una integración clásica, cada aplicación que quiere un dato de un PLC abre su propia conexión contra él. Con tres aplicaciones y veinte equipos, el resultado es una maraña de conexiones punto a punto que nadie documenta y que se rompe con cada cambio. El broker MQTT elimina ese problema: todos los dispositivos se conectan a un único punto central. Los productores publican, los consumidores se suscriben, y ninguno necesita saber que el otro existe.

Ese desacoplamiento es la razón de fondo para adoptar MQTT. Si mañana el departamento de calidad quiere recibir los datos de la línea de envasado, basta con suscribir su aplicación al tópico correspondiente. No se toca el PLC, no se abre una conexión nueva contra el autómata, no se pide permiso a producción para cargar la CPU con otro cliente de lectura. El equipo de planta publica una vez y el dato llega a tantos consumidores como haga falta.

La organización de los tópicos merece diseño propio. Una jerarquía del estilo planta/area/linea/maquina/variable permite suscribirse con comodines a toda una línea o a una sola señal, y es la base sobre la que después se construye un espacio de nombres unificado. Sobre ese concepto y el puente OT/IT en general puede leerse más en nuestro recurso sobre unified namespace y puente OT/IT.

QoS y Sparkplug B: fiabilidad y lenguaje común

MQTT define tres niveles de calidad de servicio (QoS) que determinan qué garantía de entrega tiene cada mensaje. QoS 0 envía sin confirmación: vale para señales que se refrescan cada segundo, donde perder una muestra no importa. QoS 1 garantiza que el mensaje llega al menos una vez, aceptando posibles duplicados. QoS 2 garantiza entrega exactamente una vez, al precio de más intercambio de red. Elegir bien el nivel por tipo de dato es parte del diseño: un contador de producción que alimenta el ERP no se trata igual que una temperatura ambiente.

El protocolo también resuelve el problema del estado. Con el mensaje de última voluntad (last will), el broker avisa a los suscriptores cuando un dispositivo se desconecta de forma inesperada, de modo que un dato congelado no se confunda con un dato válido.

Sobre esta base, Sparkplug B añade lo que a MQTT le falta para entornos industriales: una estructura de tópicos normalizada, un formato de carga útil definido y la gestión explícita del ciclo de vida de cada nodo mediante certificados de nacimiento y muerte. A nivel conceptual, la diferencia es esta: con MQTT plano, dos aplicaciones necesitan un acuerdo previo sobre nombres y formatos; con Sparkplug B, cualquier aplicación compatible descubre los dispositivos y entiende sus métricas sin ese acuerdo. Cuando el objetivo es que varios sistemas consuman los mismos datos de planta, esa interoperabilidad justifica la disciplina extra que impone la especificación.

Cuándo elegir MQTT frente al polling directo

No toda planta necesita un broker desde el primer día. Si una única aplicación lee diez variables de dos PLCs, un polling directo por OPC UA o Modbus es más simple y perfectamente válido. La pregunta cambia cuando crecen los consumidores, los equipos o la distancia. Algunas señales claras de que conviene pasar a MQTT:

• Varios consumidores para el mismo dato: histórico, cuadros de mando, mantenimiento y ERP quieren las mismas señales. Con polling, cada uno carga al PLC; con MQTT, el dato se publica una vez.
• Muchos dispositivos heterogéneos: decenas o cientos de sensores y máquinas de distintos fabricantes se gestionan mejor publicando contra un punto central que manteniendo mapas de registros por cada consumidor.
• Redes intermitentes o plantas remotas: MQTT tolera cortes, permite almacenar y reenviar desde el borde, y consume poco ancho de banda porque solo publica cambios.
• Separación entre red OT y red IT: el broker actúa como frontera controlada. Los sistemas de oficina se suscriben al broker y nunca tocan directamente la red de control.

En la práctica, ambos mundos conviven: el software de borde hace polling local contra los autómatas con sus protocolos nativos y publica el resultado en MQTT. Esa lectura de la capa de control es un servicio en sí mismo, que describimos en conectividad PLC.

Arquitectura de referencia y siguiente paso

Una arquitectura MQTT de planta bien resuelta suele tener tres capas. En el borde, una o varias pasarelas leen los equipos con sus protocolos nativos, normalizan los datos y los publican en el broker; ahí se decide el modelo de tópicos y se resuelve el almacenamiento local ante cortes de red. En el centro, el broker (redundante si la criticidad lo exige) gestiona sesiones, seguridad y enrutado de mensajes, con autenticación por certificados o credenciales y cifrado TLS en las conexiones. Arriba, los consumidores: bases de datos de series temporales, aplicaciones de análisis, sistemas de gestión que se suscriben solo a lo que necesitan.

Cada proyecto ajusta esta plantilla a su realidad: qué equipos existen, qué datos importan, qué sistemas van a consumirlos y con qué garantías. Nuestro trabajo consiste en diseñar esa arquitectura, implementar el broker y los flujos de datos, y dejar el conjunto documentado para que la planta pueda crecer sobre él. La integración MQTT es una pieza dentro de la oferta de conectividad industrial de Captia Connect, junto a la conectividad de PLCs, sensores y la integración con sistemas de gestión.