Cómo encaja MQTT en las arquitecturas industriales

En un episodio reciente del podcast «Augmented Ops», analizamos el panorama de las arquitecturas IoT industrial y el papel que desempeña MQTT junto a Dominik Obermaier, cofundador y director técnico de HiveMQ. Bajo el título«Creación de arquitecturas industriales con MQTT», el coloquio con Obermaier analiza el papel de MQTT, cómo da soporte a nuevas arquitecturas como el Espacio de Nombres Unificado (UNS) y por qué muchos fabricantes están rediseñando su infraestructura digital para aprovechar estas nuevas tecnologías y enfoques.

Desde que fundó HiveMQ nada más salir de la universidad, hasta su participación en el comité técnico de MQTT durante más de una década y su contribución al desarrollo del estándar, Obermaier ofrece una perspectiva matizada sobre esta tecnología y su aplicación en el sector manufacturero. En concreto, insta a los fabricantes a adoptar 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 en el sector del petróleo y el gas, antes de convertirse en código abierto en 2010, lo que permitió a cualquiera implementar la especificación sin tener que pagar derechos de autor. Este cambio supuso el impulso inicial para la proliferación de MQTT, que se utilizó primero en sistemas de domótica, antes de convertirse en el protocolo de comunicación preferido para todo tipo de aplicaciones, desde los coches conectados hasta los sectores industrial y manufacturero. Pero, ¿qué es lo que distingue exactamente a MQTT de la miríada de otros protocolos contemporáneos como HTTP u OPC UA?

En primer lugar, MQTT sigue el patrón de comunicación «publicar/suscribirse» (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 broker central, y también puede suscribirse a los datos que otros nodos publican en el broker. 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 solo publican un mensaje en el broker cuando los valores de los datos cambian realmente.

Esto se relaciona con otra característica distintiva de MQTT: su diseño ligero, que lo hace especialmente adecuado para los entornos de red con limitaciones que suelen darse en el ámbito industrial. A diferencia de otros protocolos más prolijos que requieren una sobrecarga considerable de paquetes, MQTT utiliza un formato binario para la comunicación entre clientes y brokers, con una cabecera fija de tan solo 2 bytes, junto con una cabecera variable de un máximo de 12 bytes. Junto con el mecanismo de «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 simplicidad. La especificación se diseñó deliberadamente para «facilitar al máximo 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 de todos de forma abierta, cualquiera puede implementar la especificación desde cero utilizando el lenguaje de programación que prefiera. Además, existen numerosas bibliotecas de código abierto de MQTT en diversos lenguajes que facilitan aún más a los desarrolladores el uso de MQTT en sus proyectos.

Si bien la simplicidad y la flexibilidad de la especificación MQTT ofrecen una serie de ventajas frente a otros protocolos, también plantean 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, pasando por cualquier otro tipo de datos que se puedan convertir en formato binario, hasta un máximo de 256 megabytes—. Si bien la flexibilidad en cuanto a la carga útil y a muchos detalles de la implementación hace que la especificación sea muy versátil, también complica garantizar la interoperabilidad con diversos sistemas que pueden estar implementando MQTT de formas diferentes.

El mero hecho de especificar MQTT como protocolo de datos deseado no basta para garantizar una interoperabilidad perfecta 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 mayor carga para los sistemas que los consumen a la hora de hacer un uso efectivo de esos datos. Obermaier señala que esta es la razón por la que marcos como Sparkplug B han comenzado a ganar popularidad, ya que estandarizan numerosos aspectos de MQTT para facilitar en gran medida la interoperabilidad.

Sparkplug B es un marco de código abierto que permite la integración fluida de datos procedentes de diversas fuentes de forma bidireccional e interoperable, mediante la definición de patrones coherentes para la estructura de los temas MQTT, la carga útil, la gestión de estados y otros aspectos. Obermaier explica que, al establecer un estándar sobre «cómo debe ser la carga útil, cómo debe ser la estructura de los temas MQTT, etcétera», marcos como Sparkplug han facilitado la consecución de la interoperabilidad sin tener que preocuparse por los detalles de cómo los distintos sistemas implementan la especificación MQTT.

Un tipo de arquitectura para la que MQTT resulta especialmente adecuado es el concepto de Espacio de Nombres Unificado (UNS), que ha ido ganando terreno en todo el sector en los últimos años. Obermaier destaca que las tecnologías tradicionales «funcionan con protocolos punto a punto o, en ocasiones, con protocolos de bus que en realidad no están diseñados para el movimiento de datos de extremo a extremo dentro de una organización», lo que da lugar a «una gran cantidad de silos de datos». Sin embargo, con un UNS, existe un «centro central accesible tanto para el personal de OT como para el de TI y para las aplicaciones», afirma. Esto elimina la necesidad de conexiones punto a punto entre nodos, lo que permite a cualquiera acceder y consultar los datos del espacio de nombres.

Pero, ¿por qué utilizar MQTT? Los requisitos técnicos mínimos para un UNS son que esté impulsado desde el perímetro (lo que significa que los nodos del perímetro envían información al nodo central), que utilice el modelo de «notificación por excepción», que sea ligero y que se base en una arquitectura abierta. MQTT cumple todos estos requisitos, gracias a su uso de un patrón de comunicación de publicación/suscripción, su capacidad para funcionar con notificación por excepción, su bajo consumo de ancho de banda y el hecho de que la especificación es abierta y cualquiera puede implementarla de forma gratuita. Aunque existe una fuerte sinergia entre MQTT y UNS, Obermaier subraya que «el Espacio de Nombres Unificado, para que quede 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.