MQTT en Automatización Industrial: Guía Práctica para Fabricantes

Si te involucras en el Internet Industrial de las Cosas (IIoT), verás un acrónimo omnipresente: MQTT. Aunque nuevo en automatización, existe desde hace más de 20 años. Se desarrolló originalmente como protocolo para obtener datos de yacimientos petrolíferos remotos, pero hasta hace poco no ganó adopción fuera de ese nicho. Ahora emerge como uno de los principales protocolos para proyectos de transformación digital en manufactura.

¿Qué es MQTT?

MQTT significa Message Queuing Telemetry Transport. Es un protocolo de transporte de mensajería cliente-servidor tipo publish/subscribe, considerado ligero para enviar pequeños paquetes de información en aplicaciones de ancho de banda limitado. En su núcleo, es un estándar OASIS en el corazón de la conectividad IoT.

Historia

A finales de los 90 surgió la necesidad de un protocolo de comunicación ligero para transmitir datos desde yacimientos petrolíferos remotos con velocidades de conexión extremadamente bajas, quizás 300 baudios. La estrategia aprovechaba capacidades de la capa de transporte (TCP). El protocolo de aplicación propuesto eliminaba redundancias que aumentaban la carga de transmisión. También debía ser stateful y reportar solo por excepción. Con estas restricciones, Phillips 66 trabajó con Arlen Nipper (Cirrus Link Solutions) y Andy Stanford-Clark (IBM) para desarrollar el protocolo MQTT.

Primeros Usos Comerciales

Aunque se acercó a empresas de automatización a principios de 2000, su único otro uso comercial fue en Facebook Messenger y Apple Messages. La característica de interés: el protocolo garantiza estado y calidad del dato. Cuando el remitente escribía, el receptor veía los tres puntos familiares. También se usó en monitorización doméstica y datos meteorológicos, pero su uso era limitado.

Adopción en Automatización

A mediados de 2010, Arlen Nipper volvió a promover MQTT en automatización. Surgió necesidad de agregar datos de manufactura adicionales sin demanda significativa de red. Faltaban capacidades adicionales para ganar aceptación. Cirrus Link Solutions, con Inductive Automation, desarrolló el estándar Sparkplug, que incluye atributos necesarios: conjunto definido de topics, payload estándar y compresión de mensajes.

Visión General de la Estructura

MQTT usa estructura similar a carpetas de un ordenador. Ejemplo: Escritorio/Documentos/Familia/David. Guardo (publico) mis documentos en David. Quien quiera leerlos abre (suscribe) David.

Dispositivos MQTT publican y suscriben a una ruta de tema similar llamada namespace. Organizado de lo general a lo específico. Cuanto más alto el nivel de suscripción, más datos recibo. Comodines: asterisco (*) incluye todo desde el nivel actual hacia abajo; más (+) baja un nivel. Ejemplos más adelante.

Alineación con Estándares ISA

El estándar ISA‑95 es bien conocido en manufactura. Describe modelo y terminología estándar para la interfaz entre sistemas empresariales y de control. Aunque se ve como jerarquía (ERP arriba, dispositivos abajo), trata principalmente datos de manufactura y su estructura. Como MQTT usa namespace de temas, pueden alinearse con la jerarquía ISA‑95. Se recomienda que el namespace siga Empresa, Planta, Área, Línea, Celda. La carpeta raíz del publicador/suscriptor debe existir en el nivel adecuado. Ej.: un PLC que controla una celda debe publicar en Empresa/Planta/Área/Línea/Celda. Si un historiador de proceso es específico de un área, debe suscribir todos los datos en Empresa/Planta/Área.

Arquitectura

Pregunta común: ¿qué pasa si hay pérdida de conectividad? Varias opciones mitigan esto. Solución común: método «store-and-forward» (almacenar y reenviar). Ej.: sistemas SCADA en capa de control siguen recogiendo datos hasta que se reanuda conexión al broker MQTT. Al reanudarse, las marcas de tiempo de datos almacenados permanecen intactas.

MQTT también soporta brokers de respaldo. Si falla la conexión al broker primario, nodos conectados cambian automáticamente a otro. Relación configurada vía aplicación (ej. SCADA) que lo soporta.

Otra solución: clustering. Típico en aplicaciones que no toleran pérdida de datos. Varios brokers MQTT en clúster, todos conscientes entre sí, comparten mensajes. Al perder conectividad, publicadores y suscriptores enrutan datos a otro broker sin pérdida.

Común que una aplicación empresarial use datos de todas sus plantas. MQTT soporta bridging, similar a store-and-forward. Un broker publica o hace bridge de parte o todo su namespace a otro. Una planta hace bridge a broker empresarial. Tanto topics publicados como estructura de namespace pueden definirse. Esto limita datos publicados y da contexto al broker receptor.

Publicar todos los datos tal cual con asterisco (*) sin definir estructura es lo más simple, pero genera datos innecesarios y potencialmente confusos. Para dar contexto, se puede añadir un tema al inicio del namespace publicado. Ej.: Empresa/Planta añadido a Área/+/Celda resulta en Empresa/Planta/Área/+/Celda enviada al broker empresarial. Así, datos de nivel Celda de todas las Líneas están disponibles (obsérvese comodín +).

Todos estos escenarios son desplegables. Un SCADA puede usar store-and-forward a clúster MQTT. Podría haber clústeres primario y de respaldo, pero añadiría complejidad innecesaria. Finalmente, clúster de planta hace bridge a clúster empresarial para maximizar integridad de datos. Ideal para analítica empresarial y machine learning, que requieren grandes volúmenes de datos de calidad.

Seguridad

Preocupación principal al enviar/recibir datos de manufactura por internet: ciberseguridad. La única forma de ser totalmente seguro es air gap, pero impide transformación digital. Una ventaja clave de MQTT: seguridad. Mientras otros protocolos requieren abrir puertos de red entrantes, MQTT solo necesita conexión saliente al broker. Las plantas no deben abrir puertos entrantes, muy atractivo para departamentos de TI.

Consideraciones Futuras

En futuros artículos exploraré aplicaciones comunes con MQTT. Aunque el protocolo es bastante plug-and-play, habrá interés en detalles técnicos adicionales. Líderes de negocio deben considerar cómo MQTT afecta sus esfuerzos actuales de transformación digital. Líderes de ingeniería querrán saber su impacto.

En conclusión, MQTT no debe considerarse reemplazo de arquitectura existente. Alineado con requisitos Industria 4.0, aprovecha lo ya instalado. Seguirá habiendo necesidad de OPC UA y otros protocolos, más verbosos para control. Pero para agregar grandes cantidades de datos, MQTT es excelente opción.