¬°Hub de contenido!
Acceso a contenido educativo gratis.

Por qué el protocolo MQTT es tan popular

Esta primera entrega de 1 serie de 4 partes sobre tecnologías clave de redes industriales explica cómo un protocolo de transferencia de datos ultraligero se convirtió en una herramienta de recopilación de datos ampliamente usada para aplicaciones IIoT.

Mqtt

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 UKAndy Stanford-Clark, co-creador de MQTT, maestro inventor en IBM UKEl 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.

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 SolutionsArlen Nipper, cocreador de 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".

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.