¿Qué es el MQTT? Todo sobre el popular protocolo de IIoT
Descubra cómo el MQTT, un protocolo de transferencia de datos ultraligero, se volvió esencial para la recopilación de datos en aplicaciones IIoT.
mar 20, 2022
El MQTT es un protocolo de transferencia de datos ultraligero y eficiente para la comunicación entre dispositivos IoT.
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.
Arquitectura eficiente y flexible del protocolo MQTT para IIoT
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: un protocolo de código abierto para IIoT con Sparkplug
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.
MQTT: dominando la automatización industrial
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”.
El origen industrial de MQTT: 23 Años de innovación en automatización
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 del protocolo MQTT, maestro inventor en IBM UK.El desarrollo de MQTT ocurrió después de que AT&T se disolvió y varios proveedores comenzaron a ofrecer sus propios sistemas SCADA para entregar datos en tiempo real por satélite. “Cada una de esas empresas tenía una capa de transporte patentada”, recuerda Nipper, que en ese momento trabajaba en Arcom Control Systems Inc., una empresa de la que fue cofundador y que ahora forma parte de Eurotech.
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.
El ascenso de MQTT: de código abierto a estándar global
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.
Limitaciones de MQTT en aplicaciones de IoT avanzadas
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 del protocolo MQTT, presidente y CTO de Cirrus Link SolutionsEn los sistemas de IoT que ofrece Koidra, un centro de IoT en las instalaciones agrega datos extraídos de los sensores de una fábrica a través de centros de sensores locales más pequeños. “Estos centros de IoT realizan una limpieza, un procesamiento y una compresión de datos livianos, y luego envían la información resultante a la nube”, explica Tran. En este caso, "debido a que solo hay un consumidor, la nube central, el marco pub/sub sería excesivo".
Plataformas IoT: acceso y control de datos
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”.
Evitar limitaciones en MQTT: claves para una arquitectura resistente
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.
Mas de 2,500 proveedores con nuevas tecnologías de envasado y procesamiento
En PACK EXPO International puedes discutir con expertos problemas reales y llegar a ideas innovadoras. Descubre nuevas tendencias de envasado y procesamiento, disfruta la maquinaria en acción y encuentra soluciones sostenibles de la mano de expertos.
