MQTT es un protocolo de mensajería por publicación y suscripción que transporta datos sobre TCP/IP a través de un broker central, con una cabecera fija de dos bytes en el caso más simple y tres niveles de garantía de entrega. Está normalizado por OASIS en las versiones 3.1.1 y 5.0; la 3.1.1 se publicó además como ISO/IEC 20922.
De dónde viene
El protocolo nació en 1999 para telemetría de oleoductos sobre enlaces de satélite caros, lentos y poco fiables. IBM lo bautizó como MQ Telemetry Transport, pero desde su traspaso a OASIS en 2013 el nombre dejó de tratarse como acrónimo: MQTT es simplemente el nombre del protocolo. Esa restricción original, contar los bytes y sobrevivir a que el enlace se caiga, explica prácticamente todas sus decisiones de diseño, y es también la razón de que encaje bien en una planta, donde la red rara vez es el problema pero la intermitencia y el número de consumidores sí lo son.
Broker, topics y mensajes retenidos
La pieza central es el broker: un servidor al que se conectan todos los participantes y que se encarga de repartir los mensajes. Nadie conecta con nadie directamente. Un publicador envía un mensaje a un topic y no sabe, ni le importa, quién lo va a recibir; un suscriptor pide un topic y no sabe quién lo publica. Ese desacoplamiento es lo que convierte una integración de N sistemas contra M sistemas en N+M conexiones contra un punto único.
Un topic es una cadena UTF-8 con niveles separados por barras, del estilo planta/linea1/inyectora3/temperatura_husillo. No hay que declararlo en ningún sitio: existe en cuanto alguien publica en él. Las suscripciones admiten dos comodines, + para un nivel («todas las máquinas de la línea 1») y # para el resto del árbol, que solo puede ir al final. Los mensajes de publicación, en cambio, nunca llevan comodines. Esa libertad total es un arma de doble filo: el protocolo no impone ninguna jerarquía, así que la estructura de topics es una decisión de diseño que hay que tomar conscientemente y que después es cara de cambiar, porque renombrar un topic rompe a todos los suscriptores a la vez.
Por defecto, el broker no guarda nada: si un sistema se conecta tres minutos después de que la máquina publicara su temperatura, no ve ese valor y tiene que esperar al siguiente. El mecanismo que resuelve esto son los mensajes retenidos: al publicar con el indicador de retención activo, el broker conserva ese mensaje (uno solo por topic, siempre el último) y se lo entrega de inmediato a cualquiera que se suscriba después. Publicar un mensaje retenido con carga útil vacía borra el retenido anterior. Sin retención no hay «estado actual» en el broker, solo un flujo de eventos, y esa distinción es la que decide si un cuadro de mando arranca con datos o en blanco.
Calidad de servicio y ciclo de vida de la sesión
Los tres niveles de QoS gradúan la garantía de entrega. QoS 0 entrega como mucho una vez: el mensaje se envía y no se confirma, de modo que si el enlace se corta a mitad se pierde. QoS 1 entrega al menos una vez, con confirmación explícita y reenvío si no llega, lo que implica que el receptor puede ver duplicados y debe tolerarlos. QoS 2 entrega exactamente una vez mediante un intercambio de cuatro mensajes, a costa de más latencia y más estado en ambos extremos.
El matiz que se pasa por alto con frecuencia es que la QoS se negocia por salto, no de extremo a extremo: un publicador que envía con QoS 2 y un suscriptor que se suscribió con QoS 0 producen una entrega final de QoS 0, porque cada tramo aplica el menor de los dos. En telemetría industrial la elección práctica suele ser QoS 1 con almacenamiento local en el equipo que publica, y consumidores idempotentes que no se rompen si un valor llega dos veces.
El ciclo de vida de la conexión aporta la otra mitad de la robustez. Al conectarse, un cliente declara un identificador y puede registrar por adelantado un mensaje de última voluntad (last will and testament): un topic y una carga útil que el broker publicará en su nombre si la conexión se corta de forma anómala, sin despedida. Con eso, la caída de un equipo se convierte en un evento explícito que llega por el mismo canal que los datos, en lugar de deducirse de un silencio. El mecanismo se apoya en el intervalo de keep alive, que fija cada cuánto el cliente debe dar señales de vida para que el broker no considere muerta la conexión. Además, una sesión puede ser persistente: el broker recuerda las suscripciones y encola los mensajes de QoS 1 y 2 mientras el cliente está desconectado, y se los entrega al reconectar. MQTT 5.0 añade a este armazón cabeceras de usuario, códigos de razón en las respuestas, caducidad de mensajes y de sesión, alias de topic para no repetir cadenas largas y suscripciones compartidas para repartir un mismo flujo entre varias instancias de un consumidor.
Dónde encaja en una planta
En una fábrica española típica, el dato de máquina se ha movido siempre por sondeo: el SCADA pregunta cada cierto tiempo por Modbus, por el protocolo del fabricante o por OPC DA, y el equipo responde. Ese modelo tiene tres costes que se notan en cuanto aparece un segundo interesado en los datos. La latencia la fija el ciclo de interrogación y no el evento, así que lo que dura menos que el ciclo puede no verse nunca. Cada consumidor nuevo añade su propia carga, porque cada uno pregunta por su cuenta a la misma máquina. Y el equipo no puede avisar de nada: solo contesta cuando le preguntan.
La publicación por suscripción invierte el planteamiento. El dato se publica una vez, cuando cambia o cuando toca, y el broker lo reparte a cuantos consumidores existan: la carga sobre el equipo deja de depender de cuántos sistemas están mirando. Añadir un histórico, un cuadro de mando o un modelo de predicción no obliga a tocar la máquina ni a configurar un sondeo más; basta con suscribirse. Conviene decir con la misma claridad lo que MQTT no es: no es determinista, no sustituye a un bus de campo y no vive dentro del lazo de control. Ocupa la capa que va de la máquina hacia los sistemas de información, no la que gobierna el movimiento.
La realidad del parque instalado es que casi ningún autómata publica en MQTT por sí mismo. Lo habitual es que un gateway industrial o un equipo de edge computing lea los PLC y la instrumentación por sus protocolos nativos y publique en su nombre. Algunas gamas recientes de controladores y algunos sensores IO-Link con maestro Ethernet ya lo incorporan, pero seguirán siendo minoría durante años.
MQTT frente a OPC-UA
La confusión habitual es tratarlos como alternativas del mismo nivel, y no lo son. MQTT es transporte: mueve una carga útil que el protocolo trata como una secuencia de bytes sin interpretarla. Qué significa ese contenido, qué unidades tiene, de qué tipo es o cómo se relaciona con el resto de la planta son preguntas que MQTT deja deliberadamente abiertas. OPC-UA hace lo contrario: su aportación principal es un modelo de información semántico, un espacio de direcciones navegable en el que cada variable lleva nombre, tipo, unidades, relaciones y metadatos, más un modelo de sesión con autenticación, cifrado y firma integrados en la propia especificación.
La consecuencia práctica es que compiten poco y se combinan mucho. El patrón más extendido es leer el equipo por OPC-UA, donde la semántica ya está resuelta, y distribuir el resultado por MQTT, donde el reparto a muchos consumidores y la tolerancia a redes malas ya están resueltos. La propia especificación de OPC-UA lo reconoce: su modelo de publicación y suscripción (parte 14) contempla MQTT como transporte, con las cargas útiles codificadas en JSON o en formato binario. En ese escenario no se elige entre uno y otro; se usa el modelo de información de OPC sobre el transporte de MQTT. La comparación completa está en la guía OPC UA vs MQTT.
MQTT frente a HTTP/REST
Con HTTP la iniciativa es siempre del cliente: alguien pide y el servidor responde. Para saber si un valor ha cambiado hay que volver a preguntar, es decir, sondear otra vez, ahora sobre un protocolo cuyas cabeceras de texto pesan cientos de bytes por petición y que abre y cierra conexiones con frecuencia. Con MQTT, la conexión TCP se establece una vez y se mantiene abierta, y el broker empuja el mensaje al suscriptor en el instante en que llega; la sobrecarga por mensaje se cuenta en unidades de bytes, no en centenares.
A cambio, HTTP tiene ventajas reales que conviene no negar: atraviesa cortafuegos y proxies corporativos sin discusión, encaja de forma natural en las APIs de gestión, es trivial de depurar y no exige mantener sesiones. La regla razonable es usar cada uno donde rinde: MQTT para telemetría continua desde muchos orígenes hacia muchos consumidores, HTTP para consultas puntuales, transacciones y la integración con sistemas de negocio como el ERP. Cuando la política de red no deja salir el puerto 1883, la salida habitual no es abandonar MQTT sino encapsularlo sobre WebSocket y hacerlo viajar por el puerto 443.
Sparkplug B y el unified namespace
El vacío que deja MQTT, que no dice nada sobre el contenido ni sobre la estructura, es el que llena Sparkplug B, la especificación de la Eclipse Foundation que fija un espacio de nombres de topics con una forma cerrada, una carga útil tipada en Protocol Buffers y, sobre todo, un ciclo de vida de sesión explícito. Sparkplug usa el mensaje de última voluntad de MQTT como certificado de muerte y publica al conectarse un certificado de nacimiento que enumera todas las métricas del nodo con su tipo y su valor inicial. El resultado es un sistema autodescriptivo: un consumidor nuevo sabe qué señales existen sin tablas de mapeo previas.
Sobre esa base se construye el patrón de Unified Namespace: un único espacio de nombres donde el estado actual de toda la operación está disponible y cualquier sistema nuevo se engancha sin integraciones a medida. MQTT es el transporte habitual de ese patrón, pero no lo constituye por sí solo. Un broker sin convención de nombres, sin tipado y sin política de retención no es un unified namespace: es un vertedero de números. La parte difícil del proyecto nunca es levantar el broker, sino acordar el modelo.
Seguridad
El protocolo base no cifra nada por sí mismo: el puerto 1883 transporta en claro, incluidos el usuario y la contraseña que viajan en el mensaje de conexión. La configuración correcta es TLS, normalmente sobre el puerto 8883, con autenticación por credenciales o por certificado de cliente X.509. Por encima, casi todos los brokers permiten autorización por topic, que es la pieza que suele faltar: definir qué puede publicar y qué puede leer cada sistema, de modo que un cuadro de mando no pueda escribir en un topic de órdenes y un equipo de línea no pueda leer los datos de otra planta.
El broker es, de hecho, el punto natural donde se materializa la frontera OT/IT: un patrón habitual es desplegar un broker en el borde, dentro de la red de planta, y puentearlo contra un broker corporativo, de forma que el tráfico salga en una sola dirección y por una sola conexión saliente, sin abrir puertos de entrada hacia la red industrial.
Qué implica llevar el dato de planta a un broker
Publicar en MQTT no es leer la máquina: son dos tramos distintos y el primero es el que manda. La latencia real de la cadena la fija el ciclo con el que el gateway interroga al autómata o al instrumento, no el protocolo de transporte; MQTT añade milisegundos, el sondeo de abajo añade décimas o segundos. Por la misma razón, la marca de tiempo debe ponerse en el gateway, junto a la máquina, y no en el consumidor al final del recorrido: si se sella en destino, cualquier retención en la cola o en la red se convierte en un error de fechado que después es imposible de corregir.
El trabajo de ingeniería se concentra en cuatro decisiones. La jerarquía de topics debe reflejar la planta física, normalmente en la línea de ISA-95 (empresa, centro, área, línea, celda), con nombres estables que sobrevivan a que mañana se añada otra máquina, porque cambiar un topic rompe a todos los suscriptores a la vez. El formato de la carga útil hay que fijarlo, ya sea con una convención JSON propia que incluya valor, unidades, calidad y marca de tiempo, ya sea adoptando Sparkplug B; sin esa convención, cada integración vuelve a empezar de cero. La política de retención y QoS decide si un consumidor que arranca ve el estado actual o espera al siguiente cambio, y si tolera duplicados. Y la frecuencia de publicación se dimensiona por la dinámica de cada variable: publicar por excepción, con una banda muerta que filtre el ruido de medida y un latido periódico que distinga «sin cambios» de «sin comunicación», evita llenar el histórico de valores idénticos.
En cuanto a interferencia con el control, publicar es una operación de salida que no toca la lógica del autómata ni sus enclavamientos, y la carga adicional recae en el gateway y en el broker, no en la máquina: el equipo se lee una sola vez por muchos consumidores que haya suscritos, que es precisamente la ventaja frente al sondeo múltiple. El punto de atención está en el sentido contrario. MQTT es bidireccional y nada impide publicar hacia la planta; en cuanto un topic se usa para escribir consignas, deja de ser una capa de datos y pasa a ser una función de control, con las exigencias de diseño, validación y autorización que eso comporta. La separación entre topics de lectura y topics de mando es una decisión de arquitectura, no de comodidad.
Por último, el corte de red. Un gateway que publica debe almacenar localmente mientras el enlace está caído y vaciar la cola al recuperarse, con QoS 1 y sesión persistente; sin eso, una microcaída de la red corporativa se traduce en un hueco permanente en el histórico. Y hay que dimensionar el broker: el número de clientes concurrentes, la profundidad de las colas y el volumen de mensajes por segundo son los tres parámetros que deciden si aguanta, y una suscripción a # desde un cliente lento es la forma más rápida de degradar el conjunto.
Relación con otros términos
MQTT es el transporte habitual del patrón Unified Namespace y una pieza central del puente OT/IT, complementario a OPC-UA, que destaca leyendo equipos con semántica, y a Sparkplug B, que le añade la convención que le falta. Aguas abajo se alimenta de lo que el gateway consigue sacar de PLC e instrumentación por Modbus u otros protocolos de campo, y aguas arriba alimenta al historian y a la capa analítica. El despliegue de brokers, jerarquías de topics y publicación de datos de planta es el objeto de la integración MQTT.