Cómo encaja MQTT en las arquitecturas industriales

En un reciente episodio del podcast Augmented Ops, exploramos el panorama de las arquitecturas industriales IoT y el papel que desempeña MQTT con Dominik Obermaier, cofundador y director técnico de HiveMQ. Bajo el título"Construir arquitecturas industriales con MQTT", el debate con Obermaier examina el papel de MQTT, cómo es compatible con nuevas arquitecturas como Unified Namespace (UNS) y por qué muchos fabricantes están rediseñando su infraestructura digital para aprovechar estas nuevas tecnologías y enfoques.

Desde la fundación de HiveMQ recién salido de la universidad, hasta su participación en el comité técnico de MQTT durante más de una década y su ayuda en el desarrollo del estándar, Obermaier ofrece una perspectiva matizada de esta tecnología y su aplicación en la fabricación. En particular, pide a los fabricantes que adopten un MQTT para construir infraestructuras industriales a escala empresarial.

Obermaier detalló la historia de MQTT, explicando cómo fue desarrollado por primera vez en 1999 por IBM para un caso de uso de petróleo y gas antes de ser de código abierto en 2010, lo que permitió a cualquiera implementar la especificación sin tener que desembolsar derechos de autor. Este cambio proporcionó el impulso inicial para que MQTT proliferara, viendo primero su uso en configuraciones de automatización doméstica, antes de convertirse en un protocolo de comunicación preferido para todo, desde coches conectados, hasta casos de uso industrial y de fabricación. Pero, ¿qué diferencia exactamente a MQTT de la miríada de otros protocolos contemporáneos como HTTP u OPC UA?

Ante todo, MQTT sigue el patrón de comunicación publicar/suscribir (a menudo abreviado como Pub/Sub). Esto significa que cualquier nodo de una infraestructura MQTT puede publicar datos en una dirección específica (conocida como tema) en un corredor central, y también puede suscribirse a los datos que se publican en el corredor desde otros nodos. El resultado es que cuando se publica un mensaje, todos los suscriptores lo reciben automáticamente, a diferencia de los protocolos que implican sondear continuamente a un cliente a intervalos regulares para solicitar datos actualizados. Como explica Obermaier, "esto significa que se está desacoplando a los productores de datos de los consumidores de datos". Los clientes MQTT también suelen estar diseñados para "informar por excepción", lo que significa que sólo publican un mensaje al intermediario cuando los valores de los datos cambian realmente.

Esto enlaza con otra característica distintiva de MQTT: su diseño ligero, que lo hace especialmente adecuado para los entornos de red restringidos que suelen encontrarse en los entornos industriales. A diferencia de otros protocolos más prolijos que requieren una considerable sobrecarga de paquetes, MQTT utiliza un formato binario para la comunicación entre clientes y corredores, con una cabecera fija de sólo 2 bytes, junto con una cabecera variable de 12 bytes como máximo. Junto con el informe por excepción, esto se traduce en una reducción significativa del tráfico de red, lo que hace que MQTT sea ideal para aplicaciones a gran escala que requieren un alto rendimiento.

La clave de la proliferación de MQTT es su sencillez. La especificación se diseñó deliberadamente para "facilitar enormemente su implementación por parte de los clientes", afirma Obermaier. Gracias a que el organismo de normalización de MQTT, OASIS, la ha puesto a disposición del público, cualquiera puede implementar la especificación desde cero utilizando el lenguaje de programación de su elección. Además, existe una serie de bibliotecas MQTT de código abierto en varios lenguajes que simplifican aún más a los desarrolladores el uso de MQTT en sus proyectos.

Aunque la simplicidad y flexibilidad de la especificación MQTT proporciona una serie de ventajas sobre otros protocolos, también presenta una serie de retos. Por ejemplo, Obermaier explica que "al protocolo no le importa" la estructura de los datos que se envían, que pueden ser desde texto hasta imágenes y cualquier otro dato que pueda convertirse en binario, hasta la friolera de 256 megabytes. Aunque la flexibilidad en lo que respecta a la carga útil y a muchos detalles de la implementación hace que la especificación sea muy versátil, también hace que sea más complicado garantizar la interoperabilidad con varios sistemas que pueden estar implementando cada uno MQTT de formas diferentes.

La simple especificación de MQTT como protocolo de datos deseado no basta para garantizar una interoperabilidad sin fisuras entre dos sistemas, ya que no especifica cómo se codifican los datos ni qué contiene realmente la carga útil. Y aunque esto hace que la especificación sea sencilla de implementar para los productores de datos, supone una carga mayor para los sistemas que la consumen para que realmente hagan uso de esos datos. Obermaier señala esto como la razón por la que marcos como Sparkplug B han empezado a ganar popularidad, ya que estandarizan numerosos aspectos de MQTT para facilitar la interoperabilidad.

Sparkplug B es un marco de trabajo de código abierto que permite la integración perfecta de datos procedentes de diversas fuentes de forma bidireccional e interoperable mediante la definición de patrones coherentes para la estructura de temas MQTT, la carga útil, la gestión de estados, etc. Obermaier explica que al establecer una norma sobre "cómo debe ser la carga útil, cómo debe ser la estructura de temas MQTT, etc.", marcos como Sparkplug han facilitado la interoperabilidad sin tener que preocuparse por los detalles de cómo implementan la especificación MQTT sistemas dispares.

Un tipo de arquitectura que MQTT se presta especialmente bien a implementar es el concepto de espacio de nombres unificado (UNS), que ha ido ganando adeptos en la industria en los últimos años. Obermaier destaca cómo las tecnologías tradicionales "funcionan con protocolos punto a punto, o a veces con protocolos de bus que no están realmente diseñados para el movimiento de datos de extremo a extremo a través de una organización", lo que da lugar a "muchos silos de datos". Con un SNU, sin embargo, hay un "eje central accesible para la gente de OT y la gente de TI y para las aplicaciones", dice. Esto elimina la necesidad de conexiones punto a punto entre nodos, lo que permite a cualquiera acceder a los datos del espacio de nombres y consultarlos.

Pero, ¿por qué utilizar MQTT? Los requisitos técnicos mínimos de un SNU son que esté orientado al borde (es decir, que los nodos del borde informen al concentrador central), que informe por excepción, que sea ligero y que esté construido sobre una arquitectura abierta. MQTT cumple todos estos requisitos gracias a su patrón de comunicación publicar/suscribir, su capacidad de informar por excepción, su bajo consumo de ancho de banda y el hecho de que la especificación es abierta y cualquiera puede implementarla gratuitamente. Aunque existe una fuerte sinergia entre MQTT y UNS, Obermaier subraya que "Unified Namespace, para dejarlo muy claro, es un concepto, no una tecnología". Y mientras que "Sparkplug y MQTT son tecnologías, UNS es un concepto" que puede implementarse con diversas tecnologías de mensajería.