Mejorar la calidad de vida de las personas siempre ha sido una de las principales motivaciones para buscar nuevas y mejores mejoras tecnológicas, y con el impulso actual de conectar más y más dispositivos a Internet, el desarrollo de mejores productos para la “Internet de las Cosas” (IoT) es uno de los temas más candentes de hoy en día.
Uno de los mayores desafíos para los ingenieros de IoT Industrial (o IIoT) es que las “cosas”, a menudo denominadas como “dispositivos de borde” (o perimetrales o Edge), pueden no tener acceso listo a una conexión cableada o inalámbrica estable. Dado que estos dispositivos proporcionan datos (generalmente intermitentemente) a un sistema central, cómo recopilar datos de dichos dispositivos es una gran preocupación. Varios protocolos, incluidos MQTT, AMQP y CoAP, son posibles candidatos para cumplir con los requisitos de conexión IIoT. Sin embargo, MQTT se ha convertido en la mejor opción para la mayoría de estas aplicaciones y estudios indican que más de la mitad de los desarrolladores de IoT lo utilizan como su protocolo de comunicación.
¿Qué es MQTT?
El protocolo de mensajería MQTT fue desarrollado por primera vez en 1999 por IBM y Cirrus Link, y aceptado como estándar ISO en 2013, comenzando con la versión 3.1. MQTT utiliza un patrón de publicación-suscripción (o “pub-sub”) para intercambiar mensajes (ver Figura 1). Como se ilustra en la fi gura, un sistema MQTT comprende de un “bróker” y varios clientes, donde los clientes pueden ser editores o suscriptores. Los editores envían datos al bróker en forma de paquetes MQTT, que consisten en un “tema” (o “tópico”) y un “contenido” (o “payload”). A continuación, el bróker distribuye los datos a los suscriptores en función de los temas en los que han expresado interés.
El protocolo MQTT no especifi ca un formato estándar para transmitir datos, aunque es común que las aplicaciones utilicen el protocolo JSON o texto sin formato. En comparación con otros protocolos, MQTT tiene ventajas que lo hacen una combinación perfecta para aplicaciones IoT.
Patrón “Pub-Sub” de mensajería
En comparación con otros protocolos basados en un patrón de solicitudrespuesta, el patrón “Pub-Sub” permite a los desarrolladores de IoT resolver ciertos problemas de conexión comunes. Por ejemplo, los patrones de solicitudrespuesta requieren que tanto el cliente como el servidor estén en línea al mismo tiempo para asegurarse de que los datos se transmiten y reciben correctamente. Sin embargo, en particular para las aplicaciones IIoT, puede ser imposible que los dispositivos mantengan una conexión lo sufi cientemente fuerte a la red para recibir los datos requeridos y, en consecuencia, el patrón de solicitudrespuesta no es adecuado para este tipo de aplicaciones.
Figura 1: Patrón de mensajería Publicación/Suscripción ("Pub/Sub").
El patrón Pub-Sub de MQTT está hecho a medida para situaciones en las que no se garantiza que los dispositivos estén conectados a la red al mismo tiempo. El bróker MQTT es crucial en este respecto, pues actúa como un centro de información aceptando los datos que se le envían desde clientes designados como “editores” y, a continuación, enviando los datos a clientes designados como “suscriptores”. Cuando el bróker envía los datos a un suscriptor, primero comprueba si el cliente de destino está en línea o no. Si no es así, puede retener los datos hasta que el suscriptor esté en línea y, a continuación, enviarlos. Una ventaja de esta estrategia es que solo el bróker necesita estar en línea todo el tiempo, y los clientes, tanto editores como suscriptores, solo necesitan conectarse cuando hay una conexión disponible o cuando necesitan enviar o recibir datos.
Generado por eventos
Cuando se utiliza un patrón de publicación-suscripción, los clientes MQTT solo le publican datos al bróker cuando se cumplen determinadas condiciones (por ejemplo, una señal de advertencia podría indicar que la temperatura de un dispositivo determinado es demasiado alta). Otra forma de describir este tipo de operación es que los clientes actualizan activamente los datos, en lugar de esperar pasivamente a que otro dispositivo solicite los datos.
Otro punto relevante es que, para las aplicaciones de IoT, las tarifas de comunicación se cobran en función de cuántos paquetes de datos se transmiten. En comparación con un patrón de solicitud-respuesta, MQTT ahorra dinero, ya que solo se necesita comunicación unidireccional para completar las transmisiones de datos.
Comunicación “Varios-a-Varios”
Una de las principales ventajas de MQTT es que un patrón Pub-Sub se puede usar para establecer fácilmente la comunicación de varios a varios. El concepto de Máquina a Máquina (M2M), que es una realización de la comunicación “Varios-a-Varios” (“Many-to-Many”, en inglés), es uno de los temas más candentes en IIoT.
En las aplicaciones M2M en fábricas, las máquinas de cada estación comparten sus propios estados de proceso con máquinas de otras estaciones. Compartir información de este modo sirve para automatizar la optimización de la producción, sin necesidad de la entrada manual de los operadores. Puesto que MQTT se utiliza para implementar la comunicación M2M, las máquinas solo necesitan establecer una conexión con el bróker en lugar de conectarse directamente entre sí, ahorrando una cantidad significativa de tiempo en el “apretón de manos” (“handshake”). Dado que un bróker se dedica a gestionar la comunicación entre todas las máquinas, la transmisión de datos es más fiable.
Calidad de Servicio
El protocolo MQTT utiliza tres niveles de Calidad de Servicio (QoS) para priorizar los datos:
• QoS 0 (“Como máximo una vez”): En este caso, el cliente publica un mensaje al bróker una sola vez. Este último no confirma la recepción del mensaje ni proporciona al cliente ninguna notificación relativa a la comunicación con los suscriptores. La única garantía es que el editor sabe que ha enviado el mensaje. Sin embargo, no sabe si el bróker o algún suscriptor ha recibido el mensaje. Aunque QoS 0 es por mucho la política de calidad de servicio más rápida, también es la menos confiable.
• QoS 1 (“Al menos una vez”): Cuando un cliente publica un mensaje al bró- ker, espera que el bróker reconozca si un cliente ha recibido o no el mensaje. Si el editor no recibe el acuse de recibo del bróker dentro de un intervalo de tiempo preestablecido, volverá a publicar el mensaje una y otra vez hasta que se reciba la confirmación. En comparación con QoS 0, QoS 1 es más confiable, aunque puede esperar que sea más lento con el tiempo.
• QoS 2 (“Exactamente una vez”): En este caso, el cliente y el bróker intercambian cuatro mensajes. El cliente publica primero los datos al bróker y, a continuación, el cliente y el bróker intercambian tres mensajes: PUBREC, PUBREL y PUBCOMP, para asegurarse de que los datos se entregan solo una vez. QoS 2 es la política de calidad de servicio MQTT más confiable, aunque más lenta.
Seguridad
La seguridad es una preocupación principal para las aplicaciones IIoT. Con más y más dispositivos conectados a Internet, saber cómo minimizar la posibilidad de que los datos sean hackeados es una prioridad.
En lo que respecta a MQTT, el bróker admite nombres de cuenta y contraseñas para evitar que los clientes no autorizados se conecten para suscribirse a temas. El protocolo también admite el cifrado TLS para transmisiones de datos para minimizar en gran medida la posibilidad de que los datos sean hackeados durante la transmisión.
Por Chase Shih, Gerente de Producto de Moxa. Artículo gentileza de Techvalue, representante de Moxa en Chile.
www.techvalue.cl