SEMAIQ · PLC e IoT industrial · Querétaro
MQTT y Sparkplug B: llevar datos de planta a la nube sin abrir la red de control
1. Por qué no se debe exponer la red de control a la nube
La forma más rápida de llevar un dato de producción al tablero de dirección es también la más peligrosa: abrir un puerto del PLC o del HMI hacia internet. En cuanto eso ocurre, el controlador comparte superficie de ataque con cualquier equipo del mundo, y los protocolos de piso no están hechos para redes no confiables: Modbus TCP no tiene autenticación ni cifrado, y S7comm y EtherNet/IP asumen que quien está en el segmento es un par legítimo.
Tampoco es buena ingeniería. Una consulta directa desde la nube somete al controlador a tráfico que no controla, ocupa su stack de comunicaciones, que es un recurso limitado, y compite con lo crítico: HMI, variadores y seguridad funcional. Además, la nube no necesita el dato a la velocidad del ciclo: el lazo se cierra en el PLC en milisegundos, mientras tendencias, indicadores y alertas se alimentan con segundos o minutos. La solución no es subir el PLC a la nube, sino publicar una copia ordenada de sus datos, en una sola dirección.
2. Qué es MQTT industrial y qué aporta Sparkplug B frente a OPC UA
MQTT industrial es el uso de MQTT, un protocolo publicar/suscribir creado para enlaces poco confiables y de bajo ancho de banda, como columna vertebral de los datos de planta. Cada productor publica en un tema y el broker reparte el mensaje a quien esté suscrito: el productor no conoce a los consumidores y el consumidor no necesita ruta hacia el PLC, solo hacia el broker. Esa inversión en la dirección del tráfico es lo que permite cerrar por completo el acceso a la red de control.
El protocolo aporta cuatro piezas de uso diario. Los niveles de QoS definen la garantía de entrega: QoS 0 para telemetría rápida donde el siguiente valor reemplaza al anterior, QoS 1 para señales de proceso y eventos, y QoS 2 para lo que no admite duplicados. Los mensajes retenidos entregan el último valor de un tema a cualquier consumidor nuevo. El testamento, o Last Will and Testament, publica la ausencia cuando un cliente se cae sin despedirse. Y la sesión se conserva o se descarta según la configuración de sesión limpia.
Sparkplug B, especificación abierta de la Eclipse Foundation, resuelve lo que MQTT deja al criterio de cada integrador. Fija el namespace de tópicos, define un payload binario en Protocol Buffers donde cada dato viaja con su tipo y su unidad, y maneja el estado con birth certificates (NBIRTH y DBIRTH) y death certificates (NDEATH y DDEATH). Al conectarse, el nodo publica su NBIRTH con la lista completa de métricas, tipos y valores iniciales; a partir de ahí solo envía los valores que cambian, el llamado report by exception, con alias numéricos de dos bytes para reducir cada mensaje.
La diferencia con OPC UA es de propósito, no de jerarquía. OPC UA es un modelo de información completo, con tipos y seguridad integrada por diseño, ideal dentro de la planta y hacia el MES; MQTT es más ligero y está pensado para el salto hacia afuera, sobre todo con varias plantas y enlaces celulares. Los dos conviven: se lee por OPC UA en la celda y se publica por MQTT hacia el exterior. Lo detallamos en la guía de OPC UA para monitoreo remoto de PLCs; aquí vamos del lado del transporte.
3. Arquitectura típica: PLC, gateway o edge, broker y consumidores
La arquitectura tiene cuatro niveles y una regla que la ordena: el dato viaja de adentro hacia afuera. Primero el piso, con PLC, variadores, medidores de energía y básculas. Después el gateway industrial o el servicio de edge, que habla los protocolos de campo por un lado y MQTT por el otro. Luego el broker, ubicado en una DMZ industrial o directamente en la nube. Al final los consumidores: tablero de indicadores, historizador, sistema de eficiencia y reglas de alarma.
El gateway decide si el proyecto se sostiene. Normaliza escalas y unidades, marca la calidad del dato, agrega valores en el borde y guarda en almacenamiento local cuando el enlace falla. Publicar el registro crudo y dejar todo al consumidor obliga a replicar la lógica en cada aplicación y garantiza que el tablero y el reporte de producción no coincidan. El camino inverso, escribir consignas desde la nube, se planea aparte y con confirmación en sitio; ese es trabajo de programación de PLC.
4. Qué datos publicar y con qué frecuencia: no todo a 10 ms
La tentación es publicar todo a la mayor frecuencia posible, y el resultado es un caudal que nadie usa. La práctica correcta separa dos cosas distintas: la frecuencia con la que se adquiere el dato en el PLC y la frecuencia con la que se publica hacia afuera. Se puede leer un contador cada segundo y publicar solo cuando cambia, o enviar el promedio de cada minuto.
Como referencia, un enlace celular supera los 100 milisegundos de ida y vuelta antes de sumar la sobrecarga del protocolo: pedirle una publicación cada 10 milisegundos no es ambicioso, es imposible. Los únicos datos que salen de inmediato son eventos, no muestras: una alarma o un rechazo de calidad.
- Estado y producción. Contadores de piezas, tiempos de ciclo, estado de máquina y motivo de paro: por cambio de estado, consolidados cada minuto.
- Proceso y calidad. Temperaturas, presiones y pares: una muestra representativa o un promedio cada cinco minutos.
- Consumos. Energía, aire comprimido y agua por área: promedio cada 15 minutos, suficiente para eficiencia.
- Salud del activo. Alarmas, diagnóstico del variador, horas de operación: por excepción y con un consolidado diario.
La regla es que cada etiqueta publicada tenga un consumidor identificado y una decisión asociada. Lo que nadie va a accionar se queda en el PLC o en el historizador local.
5. Modelo de datos y nombres de tópicos: el namespace manda
Sparkplug B fija la estructura de tópicos y conviene adoptarla desde el inicio: spBv1.0/grupo/tipo/nodo/dispositivo. Un nodo de celda publica su latido en spBv1.0/NaveQro/NDATA/Celda3, y el robot que cuelga de esa celda en spBv1.0/NaveQro/DDATA/Celda3/Robot1. Grupo es el sitio, nodo es la celda o gateway y dispositivo es la máquina; los nombres van en ASCII, sin espacios ni acentos, para que quien consulte el broker después deduzca el origen solo con leer el tópico.
En las etiquetas el criterio es igual de estricto: nombre único, unidad de ingeniería declarada en el birth certificate y tipo de dato correcto, no un valor real escalado y transportado como entero. Y hay tres datos que después se extrañan en cada análisis: la marca de tiempo del origen, la calidad del dato y la versión del modelo.
6. Seguridad: certificados, permisos por tópico y separación de redes
La seguridad de un despliegue MQTT industrial no viene del protocolo, viene de cómo se despliega. Lo mínimo aceptable es TLS en el puerto 8883, con certificados X.509 por cliente y validación del broker; el puerto 1883 sin cifrado se queda en el laboratorio. Cada gateway y consumidor se identifica con su propia credencial, no con un usuario y contraseña compartido en cinco dispositivos.
El segundo control se usa poco y es muy fino: listas de control de acceso por tópico. El gateway de la celda 3 solo publica dentro de su rama y no se suscribe a nada; el tablero de eficiencia solo lee las ramas de producción; mantenimiento tiene credenciales de solo lectura sobre diagnóstico. Así, una credencial comprometida en calidad no abre la nave completa.
El tercer control es de red y sostiene a los otros dos: el broker vive en una DMZ industrial, no hay ruta directa desde oficina o internet hacia los controladores, y el único tráfico que sale de la celda es la conexión del gateway hacia el broker. Aquí MQTT se cruza con la seguridad OT, y por eso conviene revisar el detalle de ciberseguridad en PLC y redes industriales antes de publicar el primer dato.
- Cifrado obligatorio. TLS en todos los clientes, sin excepción para el gateway de pruebas.
- Certificado por dispositivo. Uno por gateway y por consumidor, con caducidad conocida y procedimiento de renovación.
- Permisos por tópico. Publicar solo en la rama propia, leer solo lo necesario y separar producción de diagnóstico.
- Broker en DMZ. Sin ruta directa de oficina a celda y sin puertos abiertos hacia los controladores.
7. Vigilancia y diagnóstico: qué pasa cuando cae el broker
En publicar/suscribir el silencio es ambiguo: si un nodo deja de enviar no se sabe si no hubo cambios o si se cayó. El testamento resuelve parte del problema y Sparkplug B lo aprovecha publicando el NDEATH de forma retenida, de modo que el consumidor sabe que el nodo salió de línea aunque nunca haya hablado con él. El latido complementa: si el broker no escucha nada durante una vez y media el intervalo de keep alive, considera al cliente perdido. En planta suele funcionar bien un valor que detecte la caída en menos de un minuto.
La pieza más importante es el comportamiento del gateway cuando el enlace se va: debe seguir guardando en su buffer local y reenviar todo al reconectarse, no descartar el intervalo perdido. Al volver, el nodo republica su birth certificate con el estado actual y el consumidor se resincroniza. Después queda la vigilancia del broker: clientes conectados, tasa de mensajes por rama y tópicos retenidos obsoletos.
8. Tabla comparativa: MQTT con Sparkplug B, OPC UA y Modbus TCP
Los tres protocolos conviven en una planta moderna y resuelven problemas distintos. Compararlos ayuda a decidir qué se usa dentro de la celda y qué se usa para salir hacia afuera.
| Criterio | MQTT con Sparkplug B | OPC UA | Modbus TCP |
|---|---|---|---|
| Modelo de comunicación | Publicar/suscribir a través de un broker | Cliente/servidor y Pub/Sub | Maestro/esclavo por petición y respuesta |
| Dirección del dato | Saliente: la planta inicia la conexión | Entrante: el consumidor consulta o se suscribe | Entrante: cada consulta llega al equipo |
| Seguridad | TLS, certificados por cliente y permisos por tópico | Integrada: firma, cifrado y X.509 | Sin autenticación ni cifrado nativos |
| Modelo de datos | Namespace fijo spBv1.0 y payload autodescriptivo | Modelo de información con tipos y jerarquía | Direcciones de registro, sin semántica |
| Ancho de banda | Bajo; pensado para enlaces celulares e inestables | Medio a alto según el modelo de datos | Bajo por consulta, pero repetitivo |
| Mejor uso en planta | Llevar datos a la nube desde varios sitios | Integración interna, MES e historizador | Equipos y controladores legados en red local |
9. Caso práctico: monitoreo de eficiencia con datos publicados por el PLC
Situación (caso representativo): una planta de plásticos del Bajío con seis inyectoras quería medir eficiencia y paros por máquina en un tablero en la nube que la dirección revisaba cada mañana. Cada máquina tenía su propio controlador, de dos marcas distintas, y no existía red común entre celdas: la producción se capturaba a mano al final del turno.
Diagnóstico: la primera propuesta era publicar cada controlador a internet para que el proveedor del software leyera los registros por Modbus TCP. Los controladores estaban en una red plana junto con las terminales de calidad, ninguno tenía autenticación y dos no tenían respaldo de proyecto. Exponerlos habría dejado el proceso completo al alcance de cualquiera que encontrara la dirección, sin registro de quién escribió qué.
Solución implementada por fases, sin detener la producción:
- Un gateway industrial por máquina, conectado solo a la red de la celda, con la lista de etiquetas definida junto con producción: piezas, tiempo de ciclo, estado, motivo de paro, horas de operación y consumo eléctrico.
- Normalización en el borde: escalas y unidades uniformes, marca de tiempo del origen y promedio de ciclo por minuto, para que el tablero recibiera el dato ya interpretado.
- Publicación con Sparkplug B hacia un broker en una DMZ industrial, con una rama por celda, certificados por gateway y permisos de solo lectura para el equipo de eficiencia.
- Publicación por excepción en los cambios de estado y promedio cada 15 minutos en los consumos, con buffer local en cada gateway para no perder el turno si falla el enlace.
- Vigilancia con el death certificate de cada nodo y un tablero de estado del broker: qué gateway está en línea, cuántos mensajes por minuto y qué nodos dejaron de publicar.
Resultados: el tablero de eficiencia dejó de depender de la captura manual y se alimenta con datos del propio controlador; mantenimiento detecta una máquina que dejó de reportar antes de que termine el turno; ninguna dirección de los controladores es alcanzable desde la red de oficina ni desde internet; y cuando se interrumpe el enlace de una celda, el gateway conserva el intervalo y lo reenvía al reconectarse, en lugar de dejar un hueco en el historial.
Preguntas frecuentes
¿Puedo publicar datos del PLC a la nube sin abrir puertos en la planta?
Sí, y es la arquitectura recomendada. El PLC se queda en su red de control y solo el gateway, o la función MQTT del controlador, abre una conexión saliente hacia el broker. Como la conexión la inicia la planta, el firewall cierra todas las entradas y no existe ruta desde internet hacia el controlador. Es la diferencia entre publicar y exponerse.
¿Necesito un gateway o el PLC puede hablar MQTT solo?
Depende del controlador. Muchas CPU modernas ya traen cliente MQTT nativo o por bloques de función, y para unas decenas de etiquetas son suficientes. Cuando hay varios controladores, protocolos distintos o necesidad de buffering y normalización, el gateway industrial aísla del PLC todo el trabajo de publicar, agregar y reintentar.
¿MQTT y Sparkplug B sustituyen a OPC UA?
No, se complementan. OPC UA es el modelo de información y la integración dentro de la planta, con tipos, jerarquía y seguridad por diseño; MQTT con Sparkplug B es el transporte ligero hacia afuera, ideal para enlaces celulares y varias plantas. Lo habitual es leer por OPC UA en el piso y publicar por MQTT hacia la nube.
¿Qué pasa con los datos cuando se cae el enlace o el broker?
Un gateway bien configurado guarda los datos en un buffer local y los reenvía cuando vuelve la conexión. No se debe publicar cada 10 milisegundos confiando en que la red no perderá nada. El consumidor detecta la ausencia del nodo por el NDEATH retenido y por el latido, así que la caída se convierte en alerta y no en un hueco silencioso en el historial.
¿MQTT industrial es seguro para datos de producción?
Sí, con TLS, certificados X.509 por cliente, permisos por tópico y el broker en una DMZ industrial. Lo que no es seguro es usar el puerto 1883 sin cifrado, con usuario y contraseña compartidos y temas abiertos a cualquiera. La seguridad aquí no viene del protocolo, viene de cómo se despliega.
