Comprender la arquitectura MQTT: una inmersión profunda

Monitorear las redes de información industrial es esencial para garantizar el rendimiento, reducir el tiempo de inactividad no planificado y optimizar el uso de energía en la producción diaria. Un aspecto importante del monitoreo de estas redes es comprender los protocolos en uso, los más comunes son HTTP, OPC UA y MQTT, entre otros. Para este artículo, nos centraremos específicamente en el monitoreo de MQTT, que se ha vuelto más común en las redes de tecnología operativa con el auge del IIoT (Internet industrial de las cosas). 

Entonces, ¿cómo se resuelve la tarea de monitorear MQTT? Un requisito es tener a su disposición herramientas convenientes y confiables, como el sensor de ida y vuelta MQTT . Pero el otro punto crucial es tener conocimiento de la arquitectura MQTT en uso , que puede usarse para comprender los flujos de datos y solucionar problemas y tomar acciones efectivas en caso de cualquier problema. Esto significa que debe tener conocimiento de factores como el corredor MQTT en uso, los requisitos de alta disponibilidad y más.

En las siguientes secciones, examinaremos brevemente las arquitecturas MQTT utilizadas en entornos confiables, de alta disponibilidad y de alto rendimiento. Pero primero, echemos un vistazo a qué son los corredores y temas de MQTT.  

MQTT: ¿Por qué, cómo, qué?

La comunicación es un valor clave a nivel de taller en las redes de producción industrial. Como puede imaginar, los trabajadores están acostumbrados a utilizar aplicaciones de mensajería para enviar, recibir o compartir información fácilmente en grupos o entre individuos a lo largo de su jornada laboral, asegurando que las tareas se completen. MQTT es un protocolo ligero y estandarizado que suelen utilizar máquinas y controladores para enviar, recibir o compartir información en grupos o entre entidades específicas. El concepto es bastante parecido al de las aplicaciones de mensajería personal. Como resultado, MQTT se utiliza ampliamente en muchas aplicaciones inteligentes para fábricas, ciudades, hogares y vehículos.

Uno puede publicar información sobre un tema específico y otros pueden suscribirse a esos temas para recibir la información publicada al instante. La instancia que gestiona la distribución de los mensajes publicados es el denominado intermediario de mensajes. Este software puede ejecutarse en pequeños dispositivos integrados como Raspberry Pi o en servicios en la nube como Pro Mosquitto MQTT Broker de Cedalo .

Llegados a este punto, los principales puntos a considerar sobre los clientes MQTT (como un PLC o un dispositivo de sensor inteligente) son:

• pueden publicar mensajes sobre temas (por ejemplo, “temperatura/desde/sensorA”)
• reciben mensajes de temas suscritos (por ejemplo, “temperatura/de/sensorB”) a través del broker MQTT
• mantienen la conexión con el corredor establecida o se vuelven a conectar en caso de pérdida de conexión

Para obtener más detalles sobre MQTT, consulte TI explicada: MQTT .

La conectividad y funcionalidad del broker MQTT son cruciales para asegurar esta comunicación y, por tanto, el transporte de la información, por lo que es una buena idea monitorear constantemente el estado del broker y establecer una arquitectura de alta disponibilidad.

Arquitectura MQTT

Como se mencionó anteriormente, usar MQTT desde la perspectiva del cliente es sencillo: publicar y suscribirse a temas. Pero la arquitectura necesaria para realizar el transporte de información puede diferir según los requisitos de seguridad de la información, disponibilidad y las diferentes ubicaciones donde se producen/consumen los datos. Echaremos un vistazo a la arquitectura MQTT básica y luego pasaremos a los corredores de alta disponibilidad , un escenario del mundo real para la arquitectura MQTT y el mapeo de mensajes estáticos versus dinámicos , todos los cuales es importante comprender al configurar el monitoreo. 

La arquitectura básica de MQTT

En la arquitectura básica, hay varios clientes y un corredor en la misma ubicación. Básicamente, «misma ubicación» significa que la comunicación de red subyacente no necesita cruzar fronteras a través de una conexión a Internet.

Por ejemplo, la información se transporta de un cliente a otro a través del broker MQTT mediante una conexión TCP Ethernet (ver Figura 1).

Figura 1  : Arquitectura MQTT básica: un corredor y varios clientes en la misma ubicación

Esta arquitectura se puede configurar fácilmente para implementaciones locales y una pequeña cantidad de clientes (< 500) sin utilizar cifrado de transporte (TLS), ya que otros mecanismos pueden proteger la red contra violaciones. Una ventaja de la arquitectura básica es el sencillo proceso de configuración y la disponibilidad de numerosos paquetes de software de cliente.

Un inconveniente de utilizar esta arquitectura en entornos de producción es la gestión de los derechos de acceso. Esto significa que diferentes clientes pueden o no acceder a cada tema, y ​​puede haber problemas de rendimiento y disponibilidad cuando aumenta el número de clientes o cuando hay altas tasas de publicación de mensajes. Por lo tanto, para prepararse para una arquitectura escalable y de alto rendimiento, se necesitará un intermediario de alta disponibilidad con una API de administración de acceso, y esto se presenta en la siguiente sección.

El concepto de corredores MQTT de alta disponibilidad.

La arquitectura básica utiliza un intermediario. Sin embargo, puede tener clientes conectados desde diferentes ubicaciones comunicándose con el corredor a través de Internet. Si tiene requisitos con altas exigencias en cuanto a la disponibilidad del corredor MQTT, entra en juego el concepto de un clúster de alta disponibilidad (HA Broker).

Este corredor de HA se implementa utilizando tres, cinco o incluso más instancias (nodos) del mismo corredor. Estos nodos pueden estar ubicados en diferentes zonas de disponibilidad, normalmente en los servidores de los proveedores de infraestructura. Para ver un ejemplo de gestión de múltiples nodos de un corredor (y diferentes modos de agrupación), consulte Mosquitto MQTT High Availability y sus diferentes modos de agrupación .

Figura 2  : HA Broker con tres nodos de clúster y punto final con redundancia de zona

Existen diferentes conceptos para realizar estos corredores de HA (para los lectores alemanes, este artículo en línea de Heise lo describe muy bien).

Un enfoque es elegir un intermediario del clúster (nodo) para que actúe como maestro y administre el flujo de tráfico. Mientras tanto, los demás intermediarios permanecen en modo de espera y pueden configurarse para que actúen como maestros en milisegundos.

En una vista de nivel suficientemente alto, los corredores de HA proporcionan un punto final al que se puede acceder a través de Internet, red local o redes privadas virtuales (VPN) que garantiza una disponibilidad técnica del 99,9% o superior, independientemente de la cantidad de mensajes o la cantidad. de clientes conectados. Es posible tener miles o decenas de miles de clientes sin notar pérdidas de rendimiento. El monitoreo y la reacción de las fallas de los nodos se realizan automáticamente mediante el software subyacente, como un complemento de extensión de clúster para las instancias del corredor. Puede leer los detalles técnicos del clúster de alta disponibilidad de Mosquitto para obtener más información.

Posible escenario del mundo real para la arquitectura MQTT

En el mundo real, los flujos o flujos de datos de la red de información de producción utilizan diferentes protocolos. Así, por ejemplo, un enfoque común es utilizar webhooks (HTTP, POST) para receptores de datos o ingestas de análisis de streaming. Por otro lado, las fuentes de datos en un entorno de producción consisten en PLC con capacidades de tiempo real o PC integradas. Aquí se utiliza a menudo el protocolo MQTT. Según el concepto de pirámide de automatización, las entidades en las redes de información se pueden organizar en niveles de información (ver Figura 3).

Figura 3  : Vista conceptual de diferentes niveles de información para un posible escenario de entorno de producción en el contexto de consumidores y receptores de datos.

Se deben tomar decisiones individuales adicionales con respecto a la ubicación de las instancias de procesamiento de datos, es decir, el broker MQTT, ya sea en las instalaciones o en la nube. Este último se puede dividir a su vez en infraestructura compartida o dedicada.

Este enfoque dará como resultado los siguientes requisitos de alto nivel:

• Múltiples clientes en diferentes ubicaciones y múltiples intermediarios que utilizan clústeres puente y de alta disponibilidad tienen que comunicarse.
• Es necesario establecer conexiones confiables de sitio a sitio a nivel de empresa a través de VPN, conexión de cable privado o mediante transporte de datos HTTPS.
• Se necesita un concepto alineado para la denominación de temas y la disposición de los valores de metadatos.

Echemos un vistazo detallado al primer requisito de alto nivel. La arquitectura MQTT básica se puede utilizar para ofrecer comunicación instantánea y flujo de datos entre clientes, como se muestra arriba. La Figura 3 demuestra que los intermediarios se pueden implementar localmente como un intermediario HA con múltiples nodos. Los corredores 1, 2 y 3 brindan servicios de distribución de mensajes para diferentes líneas de producción o infraestructura logística.

La funcionalidad clave para interconectar a estos corredores se llama puente. La unión de corredores MQTT permite asignar mensajes entre diferentes niveles o sitios. Puede, por ejemplo, nombrar los temas como “from_level_0” o “energy_metrics_for_facility_mmgt”. Para obtener una explicación más detallada sobre los puentes, consulte el blog Explicación de la configuración del puente Mosquitto .

En última instancia, las capacidades de puente del corredor garantizan que los clientes ubicados en diferentes niveles de información o en diferentes ubicaciones puedan intercambiar información a través de múltiples corredores puente. En este caso, no importa si los corredores están alojados en las instalaciones o en la nube.

El principal desafío, también para el monitoreo, es alinear y definir convenciones de nomenclatura de temas y asignaciones de temas . El riesgo de crear bucles de mensajes aumenta con el número de intermediarios involucrados. La detección de bucles de mensajes y tráfico redundante es otro desafío donde se necesitan capacidades de análisis de tráfico.

En el escenario ilustrado que se muestra en la Figura 3, también se da el caso de que el puente se realiza desde MQTT al protocolo HTTP. Esto tiene sentido para temas seleccionados y, por tanto, información específica para agregarlos y almacenarlos en un lago de datos central alimentado por un webhook a nivel de empresa.

Mapeo de mensajes estáticos versus dinámicos

La arquitectura descrita anteriormente (consulte la Figura 3) se puede realizar mediante una configuración estática para el puente MQTT. Pero la necesidad de un puente dinámico inteligente puede aumentar a medida que pongamos en práctica posibles casos de uso.

Imagínese si, a nivel de empresa, reconoce que falta una métrica o información para un informe de BI altamente agregado. Luego, podría publicar una solicitud en un AI-Bot con el mensaje: «Para el próximo período de evaluación de la facturación mensual, incluya un gráfico de barras para la suma de kilómetros que recorren los AGV por línea de producción». Sin duda, este podría ser un requisito de funcionalidad futuro.

Las funciones de ejecución tendrían que redefinir automáticamente la configuración del puente en todos los niveles para garantizar que los datos se transporten desde los AGV al lago de datos central. Técnicamente, ya hay un bloque de construcción disponible que utiliza interfaces remotas como la API MQTT y la API REST para actualizar las configuraciones del agente MQTT. Esto puede denominarse puente dinámico inteligente y es el punto de partida para arquitecturas MQTT más avanzadas.

Por Dr. Andreas Schiffler