Por James R. Koelsch, editor colaborador
El protocolo de transporte de telemetría de cola de mensajes (MQTT) es un competidor clave para el método más favorecido de transferencia de datos. La razón principal por la que el diseño de código abierto y la estatura liviana de MQTT lo hacen ideal para conectar dispositivos dispares a sistemas de control de supervisión y adquisición de datos (SCADA), así como a otras redes industriales.
Como explica Omer Qadri, gerente de marketing de productos para productos HMI y de borde en Aveva, MQTT utiliza una arquitectura de publicación/suscripción que reduce la utilización del ancho de banda en un 95 % en comparación con las comunicaciones de sondeo tradicionales y las comunicaciones cliente/servidor que utilizan el protocolo de transferencia de hipertexto (HTTP). “Un encabezado HTTP suele tener alrededor de 8000 bytes”, dice, “pero el protocolo MQTT usa solo dos bytes y unas pocas líneas de código”. Esto es clave en una era en la que se han implementado millones de dispositivos IIoT (Internet industrial de las cosas), muchos de ellos con poca memoria interna y capacidad de procesamiento.
Además de tener una huella mucho más pequeña en la red, la arquitectura de publicación/suscripción de MQTT también es más plana que la arquitectura utilizada por los protocolos de automatización industrial tradicionales, como Modbus, EtherNet/IP y Profinet. “Esta arquitectura [MQTT] reemplaza la pirámide de automatización tradicional”, observa Garrett Schmidt, gerente senior de productos para interfaces de comunicación en Phoenix Contact USA.
Mientras que los clientes en una arquitectura cliente/servidor se comunican directamente con un punto final o servidor, los publicadores y suscriptores (emisores y destinatarios de mensajes, respectivamente) nunca se comunican directamente entre sí en una arquitectura de publicación/suscripción. Más bien, se comunican con un intermediario llamado corredor; el editor proporciona datos al corredor y los suscriptores consumen los datos.
“El corredor puede residir en cualquier lugar: en la nube, en un servidor privado o simplemente ejecutándose en una PC en algún lugar”, dice Schmidt. “Filtra los mensajes entrantes y los distribuye a los suscriptores apropiados”.
Agrega que este desacoplamiento de editores y suscriptores mejora la flexibilidad en las aplicaciones de IIoT en al menos tres formas: “Primero, los editores y suscriptores solo necesitan saber cómo contactar al corredor, no entre ellos. En segundo lugar, un corredor puede almacenar mensajes para clientes que no están en línea y entregarlos cuando el recurso esté disponible. Y tercero, las operaciones no tienen que interrumpirse cuando se espera recibir o publicar un mensaje para coincidir con la naturaleza asíncrona de la mayoría de las bibliotecas de clientes”.
MQTT también tiene la ventaja de ser un protocolo de código abierto basado en TCP/IP (protocolo de control de transmisión y protocolo de Internet). En esencia, MQTT permite a los usuarios enviar mensajes TCP/IP de un lado a otro, según Arlen Nipper, cocreador de MQTT y presidente y director de tecnología de Cirrus Link Solutions.
Al igual que HTTP, MQTT define solo un protocolo de transporte. No proporciona seguridad; se basa en TCP/IP para eso. Al igual que HTTP, MQTT tampoco define una especificación de carga útil. Aunque ser independiente de la carga útil ofrece la flexibilidad de transferir cualquier carga útil, incluidas las de sistemas heredados, puede complicar la conexión de algunos dispositivos. En estos casos, se requeriría un programador para traducir los datos.
Para eliminar este trabajo de traducción y agilizar la implementación, la especificación de carga útil Sparkplug de código abierto se lanzó en 2016. "Marcó el primer intento de estandarizar un formato interoperable para MQTT en aplicaciones industriales", dice Josh Eastburn, director de marketing técnico de Opto 22.
En 2018, la Eclipse Foundation patrocinó el Proyecto Tahu, que recopiló implementaciones de referencia de Sparkplug. El resultado ha sido la aparición de dispositivos IIoT plug-and-play que utilizan MQTT.
Nipper dice que Sparkplug hace por IIoT lo que el lenguaje de marcado de hipertexto (HTML) hizo por Internet of People. En consecuencia, espera que las aplicaciones IIoT exploten, como lo hizo Internet of People una vez que se definieron tanto HTTP como HTML.
Se espera un crecimiento explosivo
MQTT ya está logrando avances significativos en la automatización industrial, además de disfrutar de un uso generalizado en otras aplicaciones. Facebook, por ejemplo, lo adoptó como capa de transporte para su aplicación Messenger en 2011.
"Literalmente de la noche a la mañana, 800 millones de personas usaban MQTT", señala Andy Stanford-Clark, otro cocreador de MQTT y distinguido ingeniero e inventor maestro en IBM UK.
Desde entonces, otras empresas de Big Tech han seguido su ejemplo. Las plataformas AWS de Amazon, Azure de Microsoft, Watson de IBM y Google IoT, por ejemplo, utilizan MQTT. Con una aceptación tan amplia, MQTT superó a HTTP en 2018 como el protocolo de transporte elegido para Internet de las cosas, informa Stanford-Clark.
Muchos proveedores de automatización esperan que MQTT finalmente domine el espacio de redes industriales. “Creemos que MQTT se convertirá en el estándar industrial de facto en los próximos 10 años”, predice Qadri. “Disfrutará de una adopción generalizada a medida que la industria reemplace Modbus, OPC y otros protocolos de telemetría heredados que aún predominan en las aplicaciones SCADA”.
Hitos clave
El éxito de MQTT en el espacio del consumidor ha oscurecido algunos hechos fundamentales sobre sus orígenes. Es decir, que el protocolo existe desde hace 23 años y se desarrolló originalmente para la automatización industrial, específicamente para Phillips 66.
Andy Stanford-Clark, co-creador de MQTT, maestro inventor en IBM UK
La única excepción fue AT&T, que diseñó su nueva oferta SCADA para ejecutarse de forma nativa en TCP/IP. Phillips 66 había instalado uno de estos sistemas y pidió ayuda a Nipper para aumentar la eficiencia de los flujos de datos en tiempo real entre dispositivos de campo y múltiples consumidores de datos. “El sondeo en un VSAT [terminal de apertura muy pequeña] es lento”, explica Nipper. “Y era muy costoso si tenías cientos de sitios, como hicimos en Phillips 66”. Otras limitaciones incluían el uso de dispositivos que dependían de microprocesadores integrados de 8 bits y comunicaciones de 300 baudios.
Debido a que el gerente de SCADA en Phillips 66 quería replicar el éxito que el departamento de TI había tenido con el middleware orientado a mensajes (MOM) de IBM, presentó a Nipper a Stanford-Clark de IBM. En 1999, este par desarrolló MQTT para SCADA basado en MOM.
A pesar de ser un protocolo eficiente de código abierto, MQTT no ganaría mucho impulso durante casi una década. “No fue hasta que el protocolo estuvo disponible en una licencia libre de regalías que comenzó a popularizarse fuera de IBM”, explica Eastburn. “En 2010, se lanzó Mosquitto, el primer bróker de MQTT de código abierto, lo que demostró que MQTT tenía una vida fuera de IBM y marcó un punto de inflexión en su adopción”. Otros dos hitos en la adopción del protocolo por parte de la industria ocurrieron en 2011. Primero, la Fundación Eclipse inició el Proyecto Paho, que recopiló clientes MQTT implementados en varios idiomas. “En 2011, IBM y Eurotech donaron implementaciones de clientes MQTT en C y Java a la fundación, lo que permitió construir un sistema MQTT completo a partir de componentes de código abierto”, dice Eastburn.
Ese mismo año, IBM también comenzó el proceso de estandarización de MQTT con la Organización para el Avance de los Estándares de Información Estructurada (OASIS) y finalmente adoptó la versión 3.1.1 como estándar en 2014. Luego, en 2016, la Organización Internacional para la Estandarización (ISO) y la Comisión Electrotécnica Internacional (IEC) con sede en Ginebra también lo aprobó como ISO/IEC 20922:2016.
Para mantenerse al día con los avances en tecnologías relacionadas, OASIS lanzó la versión 5 de MQTT en marzo de 2019. Esta versión permite a los usuarios hacer cosas nuevas con MQTT a través de la nube, grandes infraestructuras distribuidas y grupos de múltiples intermediarios. “Tuvimos cuidado de no dejar que se filtraran demasiadas cosas, ya que debemos apegarnos a los principios fundamentales de mantener el protocolo fácil de entender y no muy hablador en el cable”, dice Stanford-Clark. Actualmente, ISO también está considerando la adopción de la versión 5.
Preocupaciones potenciales de la aplicación
A pesar del éxito que han tenido MQTT y su arquitectura de publicación/suscripción, no es óptimo para todas las aplicaciones, según Kenneth Tran, fundador y director ejecutivo de Koidra Inc., un proveedor de tecnologías IoT impulsadas por inteligencia artificial. “Encontramos que el modelo pub/sub a menudo no es la mejor solución para aplicaciones de alto nivel, en parte porque deben configurarse para considerar la disponibilidad de datos asincrónicos”, dice. “En una fábrica, es típico tener muchos sensores conectados a un controlador, servidor o concentrador de sensores en el campo”.
Arlen Nipper, cocreador de MQTT, presidente y CTO de Cirrus Link Solutions
Otro peligro potencial es quedar atrapado en la plataforma de IoT patentada de un proveedor en particular. Esto puede suceder con los datos enviados a los servicios en la nube del proveedor, lo que puede suceder a pesar de los orígenes de código abierto de MQTT. En estos casos, los usuarios compran su dispositivo y software de borde y lo conectan mediante MQTT.
“Pero no tiene acceso a los datos si todo permanece dentro del entorno de nube del proveedor”, explica Travis Cox, codirector de ingeniería de ventas de Inductive Automation.
En consecuencia, Cox insta a los usuarios a asegurarse de que la configuración de estos sistemas basados en la nube les permita acceder a sus datos. “Puede enviar los datos a su nube”, dice, “pero en última instancia, también debería poder enviar esos datos a sus sistemas”.
Una segunda forma de quedar atrapado en la tecnología propietaria, a pesar del uso de MQTT, es a través del formato de carga útil. Esto puede ocurrir porque MQTT puede transferir cargas útiles en cualquier formato, incluido el formato binario propietario de un proveedor.
“Si no comprende lo que se envía, le resultará muy difícil aprovecharlo”, señala Cox. Para evitar este escollo, insista en tener una definición que le diga cómo se ven los datos o use la especificación de carga útil Sparkplug de código abierto.
Cox también recomienda construir una arquitectura resistente. “Si perdiera la conexión o el acceso a su corredor central, sus aplicaciones quedarían ciegas”, dice. Una forma que él sugiere para construir resiliencia contra tales conexiones interrumpidas sería almacenar datos en un caché local para que puedan reenviarse cuando se restablezca la conexión. Otra forma de mejorar la resiliencia es tener dos intermediarios, de modo que uno pueda continuar trabajando si el otro falla.
