¿Qué es MQTT y cómo pueden usarlo las empresas de automatización industrial?

Si se está involucrando en absoluto con el Internet industrial de las cosas (IIoT), seguramente verá un nuevo acrónimo que se usa por todas partes:MQTT. Si bien MQTT es bastante nuevo en la automatización, existe desde hace más de 20 años. Originalmente se desarrolló como un protocolo para obtener datos de yacimientos petrolíferos remotos, pero hasta hace poco, nunca ganó mucha adopción fuera de esta aplicación de nicho. Ahora se perfila como uno de los principales protocolos para proyectos de transformación digital para la fabricación.

¿Qué es MQTT?

MQTT significa transporte de telemetría de Message Queue Server. Es un protocolo de transporte de mensajería de publicación/suscripción de servidor cliente, considerado un protocolo de mensajería ligero para enviar pequeños paquetes de información en aplicaciones de ancho de banda limitado. En esencia, se considera un estándar OASIS en el corazón de la conectividad IoT.

Historial

A fines de la década de 1990, existía la necesidad de un protocolo de comunicación liviano que pudiera transmitir datos desde sitios petroleros remotos con velocidades de conexión extremadamente bajas, quizás tan bajas como 300 baudios. La estrategia fue aprovechar las capacidades ya ofrecidas en la capa de transporte, que utilizaba el protocolo TCP. El protocolo de aplicación propuesto eliminaría cualquier redundancia que se agregara a la carga útil de transmisión. También necesitaba tener estado y solo reportar por excepción. Con estas limitaciones en mente, Phillips 66 trabajó con Arlen Nipper de Cirrus Link Solutions y Andy Stanford-Clark de IBM para desarrollar lo que ahora se conoce como el protocolo MQTT.

Primeros usos comerciales

Si bien a las empresas de automatización se les acercó el protocolo MQTT a principios de la década de 2000, su único otro uso comercial fue con las aplicaciones Facebook Messenger y Apple Messages. La característica principal que resultó de interés es que el protocolo garantiza un estado y calidad de los datos. Cuando un remitente estaba escribiendo, el receptor veía los tres puntos ahora demasiado familiares en la pantalla. También se usó en algunas aplicaciones de datos meteorológicos y monitoreo del hogar, pero en ese momento, el uso de MQTT era bastante limitado.

Adopción de automatización

A mediados de la década de 2010, Arlen Nipper una vez más se acercó a las empresas de automatización para promover el uso de MQTT. Hubo una necesidad emergente de agregar datos de fabricación adicionales sin una demanda significativa de la red. Sin embargo, había algunas capacidades adicionales que debían desarrollarse para ganar aceptación en la fabricación. Cirrus Link Solutions, junto con Inductive Automation, procedió con el desarrollo de lo que ahora es el estándar Sparkplug, que incluye los atributos necesarios para la automatización, a saber, un conjunto definido de temas, una carga útil estándar y compresión de mensajes.

Descripción general de la estructura

MQTT usa una estructura que es similar a la estructura de carpetas de una computadora. Usaré el escritorio de Windows como ejemplo. El escritorio tiene una carpeta llamada Mis documentos. En Mis documentos, hay otra carpeta llamada Familia, y en esa carpeta hay una carpeta para cada miembro de la familia. La ruta a mi carpeta sería Escritorio/Mis documentos/Familia/David. Le guardaría (publicaría) todos mis documentos a David. Cualquiera que quisiera leer mis documentos abriría (suscribirse) a David.

Los dispositivos que utilizan el protocolo MQTT publicarán y se suscribirán a una ruta de tema similar denominada espacio de nombres. Al igual que una computadora, está organizado de lo más general a lo más específico. Cuanto más alto sea el nivel al que me suscribo, más datos recibiré. También hay comodines que se pueden usar para ayudar a definir una ruta de tema. Un asterisco (*) incluye todo, desde el nivel actual y por debajo. Un signo más (+) mueve la ruta un nivel más abajo. He incluido un par de ejemplos más abajo en el artículo.

Alineación con los estándares ISA

El estándar ISA-95 se entiende bien dentro de la fabricación. Describe un modelo estándar y una terminología para la interfaz entre la empresa y los sistemas de control. Si bien generalmente se realiza como una jerarquía, comenzando con un ERP en la parte superior y dispositivos en la parte inferior, el estándar se ocupa principalmente de los datos de fabricación y cómo se debe estructurar. Debido a que MQTT usa un espacio de nombres de temas, estos pueden alinearse fácilmente con la jerarquía ISA-95. Se recomienda que un espacio de nombres de tema siga a la empresa, el sitio, el área, la línea y la celda cuando se construye. La carpeta raíz del editor/suscriptor también debe existir en el nivel adecuado. Por ejemplo, un PLC que controla una celda debe publicar sus datos en un tema de Empresa/Sitio/Área/Línea/Celda. Si un historial de procesos es específico de un área, debe suscribir todos los datos a nivel de empresa/sitio/área.

Arquitectura

Una de las preguntas comunes que surgen del uso de MQTT es qué sucede cuando hay una pérdida de conectividad. Hay varias opciones que se pueden utilizar para mitigar estas situaciones. Una solución común es utilizar un método de "almacenamiento y reenvío". Por ejemplo, los sistemas SCADA que se encuentran en la capa de control continuarán recopilando datos hasta que se reanude la conexión con el intermediario MQTT. Cabe señalar que cuando se reanuda la conexión del intermediario, las marcas de tiempo de todos los datos almacenados permanecen intactas.

MQTT también admite el uso de agentes de respaldo. Mientras haya un intermediario principal, si se pierde esta conexión, los nodos conectados cambiarán automáticamente a otro intermediario. La relación generalmente se configura a través de una aplicación (como un sistema SCADA) que admite esta función.

Otra solución se logra mediante el uso de la agrupación. Esto es típico de las aplicaciones que no pueden permitirse ninguna pérdida de datos. Una configuración común es tener varios intermediarios MQTT organizados en un clúster. Todos estos intermediarios se conocen entre sí y compartirán mensajes dentro del clúster. Cuando se pierde la conectividad, los publicadores y suscriptores de datos enrutarán los datos sin problemas a otro corredor sin ninguna pérdida.

Es común que una aplicación empresarial use datos de todas sus plantas. Para este escenario, MQTT admite el uso de puentes, que es similar a un sistema de almacenamiento y reenvío. En esta arquitectura, un intermediario publicará o conectará parte o la totalidad de su espacio de nombres con otro intermediario. Dicho de otra manera, un corredor de planta se conectaría con un corredor de empresa. Se pueden definir tanto los temas publicados como la estructura del espacio de nombres. Esto limita la cantidad de datos publicados y proporciona contexto para el corredor receptor.

Publicar todos los datos tal como están con un asterisco (*) y no definir ninguna estructura es la forma más sencilla, pero esto puede generar una gran cantidad de datos innecesarios y potencialmente confusos. Para proporcionar algún contexto de datos, se puede agregar un tema al comienzo del espacio de nombres del tema publicado. Por ejemplo, Empresa/Sitio podría agregarse al espacio de nombres Área/+/Celda de la planta, lo que daría como resultado que Empresa/Sitio/Área/+/Celda se envíe al intermediario de Enterprise. El resultado es que los datos de nivel de celda de todas las líneas estarían disponibles desde este sistema (observe el uso del comodín +).

Todos estos escenarios se pueden implementar. Un sistema SCADA puede usar almacenamiento y reenvío a un clúster MQTT. Podría haber clústeres primarios y de respaldo, pero esto probablemente agregaría una complejidad innecesaria. Finalmente, un clúster de planta puede conectarse con un clúster empresarial para maximizar la integridad de los datos. Esto es excelente para el análisis empresarial y el aprendizaje automático, ya que requieren cantidades significativas de datos de buena calidad.

Seguridad

Una de las principales preocupaciones con el envío y la recepción de datos de fabricación a través de Internet es la ciberseguridad. Si bien la única forma de estar verdaderamente seguro es mediante el uso de un espacio de aire, esto impedirá la capacidad de una organización para transformarse digitalmente. Uno de los beneficios clave de MQTT es el de la seguridad. Mientras que otros protocolos de comunicación requieren la apertura de puertos de red, MQTT solo requiere una conexión de salida al intermediario. No se requiere que las plantas abran ningún puerto de entrada, lo cual es muy atractivo para las organizaciones de TI.

Consideraciones futuras

En artículos futuros, exploraré aplicaciones comunes con MQTT. Si bien el protocolo está destinado a ser bastante plug-and-play, es probable que haya interés en detalles técnicos adicionales. Los líderes empresariales pueden querer considerar cómo MQTT afectará sus esfuerzos actuales de transformación digital. Y, por supuesto, los líderes de ingeniería definitivamente querrán saber cómo los afectará MQTT.

Para terminar, MQTT no debe considerarse un reemplazo de la arquitectura existente. Alineado con los requisitos de la Industria 4.0, aprovecha lo que ya existe. Seguirá existiendo la necesidad de OPC UA y otros protocolos, ya que son más detallados para las aplicaciones de control. Sin embargo, cuando se trata de agregar cantidades significativas de datos, MQTT es una excelente opción.