OPC UA & MQTT, ventajas y casos de uso

No hay lugar donde los desafíos de un mundo de objetos comunicados sean más evidentes que una planta industrial. Los grandes fabricantes de sistemas de control de la industria se enfrentan a una cada vez mayor presión del mercado por proponer soluciones para la digitalización de todos los procesos de fabricación: desde el sensor y hasta la nube. Es por ello que los protocolos para el IIOT de uso más extendido, OPC UA y MQTT, son ya protagonistas principales de esta nueva era industrial.  Desde AeI preguntamos a estos grandes fabricantes los detalles, características, ventajas e inconvenientes de ambos protocolos.

Comenzando la comparativa entre ambos estándares, preguntamos a los expertos qué modelos de comunicación utilizan ambas tecnologías. Y Alfonso Ramón, Information Network Technical Specialist en Emerson, responde: “Las necesidades de la nueva industria ponen sobre el tapete nuevos desafíos y retos que desde la oficina de los chicos de OT se tienen que afrontar. Atrás quedan los tiempos en los que sólo necesitábamos que las comunicaciones fueran confiables, la nueva realidad exige que la industria sea más rápida, flexible, modular e inteligente. Es por ello que el mundo industrial está abrazando y adaptando de una manera paulatina las soluciones existentes de IT”. Según comenta, para poder alcanzar los nuevos niveles de excelencia es crucial que las comunicaciones sean ciberseguras además de robustas. Esta ha sido la causa por la que han florecido nuevos estándares de comunicación con el fin de garantizar que ese trasiego de datos entre distintos niveles de red. Dos propuestas son las que han tomado el gobierno de flujo de datos: MQTT y OPC UA.

“La magia consiste en saber qué protocolo es el más adecuado en cada situación”, continúa, “aunque sobre el ‘Power Point’ se pueden obtener resultados parecidos, debemos analizar qué escenario tenemos para tomar la decisión correcta. Cada protocolo tiene sus puntos fuertes y es labor del ingeniero responsable saber seleccionar la solución adecuada”. Así, OPC UA “nos presenta una solución más completa donde se nos permite consultar métodos, estructuras de datos y nodos de la red bajo demanda. La comunicación nos permite tanto establecer un modelo basado en suscripción como puede estar orientada a modelo cliente-servidor donde un grupo de servicios pueden ser consultados con el fin de acceder a los nodos con objetivo de escribir, leer, llamar a métodos de servidores y otras funcionalidades”. Por su parte, “MQTT nos brinda las bondades de un protocolo muy ligero especialmente diseñado para medios con un ancho de banda reducido o inestable. Requiere una programación específica para cada aplicación lo que hace que sea menos versátil. No es del todo justo enfrentar a ambos protocolos puesto que cada uno tiene sus fortalezas y virtudes. Si necesito un protocolo de bajo consumo, con poca huella en el dispositivo IIOT en el que palpite y que sea capaz de garantizar la comunicación en redes de poco ancho de banda, MQTT puede ser un buen aliado”. Alfonso Ramón pone el siguiente ejemplo: Planteando un escenario de red móvil 4G/5G para hacer consultas de equipos remotos, diseñar la solución sobre MQTT puede ser una buena idea. El tamaño reducido de consumo de ancho de banda y su capacidad de implementar QoS para evitar pérdida de información puede brindarnos la solución más adecuada ante este escenario. Si por contra, se presenta una solución local en la que se necesita hacer consultas dinámicas y escalables, OPC UA puede solucionar este reto al tratarse de un protocolo mucho más versátil. “Bajo mi punto de vista y conociendo los ritmos de los entornos industriales, aunque existen otros protocolos válidos desde el punto de vista IIOT (AMQP, CoAP, etc.) la estandarización para este tipo de soluciones está gravitando en torno a los protocolos MQTT y OPC UA”, concluye.

Para Iker García Oleaga, Ingeniero Técnico Comercial en Optomation Systems, la diferencia entre OPC-UA y MQTT reside principalmente en la raíz de su modelo de comunicación. OPC-UA utiliza un modelo de respuesta de sondeo tradicional (o consulta-respuesta) y está basado en conexiones punto a punto entre clientes y servidores. Se trata de un estándar más potente y complejo que define un modelo de información jerarquizada, en el que se disponen de varios mecanismos de seguridad y servicios, como auditoría y descubrimiento de nodos.

“MQTT es relativamente nuevo (finales de los 90). No es, por lo general, una de las especificaciones estándar promovidas por los principales proveedores de automatización o colaboradores de la industria, como pueda ser el caso de la OPC fundation, pero si se ha convertido, en cambio, en el modelo de comunicación más popular para aplicaciones IoT, lo que le está sirviendo, para abrirse paso, cada vez más, en aplicaciones industriales y alimentar el debate sobre si MQTT o un protocolo como OPC UA, debería de tener preferencia en este tipo de aplicaciones industriales conectadas”, explica y añade que MQTT utiliza un modelo de comunicación basado en publicación-suscripción. Los clientes envían los datos a un servidor central (o bróker), mediante una publicación y solo cuando se detecta el cambio en un valor registrado, el bróker distribuye estos datos únicamente a los clientes que hayan solicitado información de estas actualizaciones (subscriptores). MQTT, se caracteriza por tener una especificación minimalista. No restringe, ni define la estructura de los datos y se basa en los mecanismos de seguridad existentes, ya integrados en TCP/IP, lo que lo convierte en un modelo de comunicación muy eficiente, para ejecutarse en dispositivos perimetrales y redes de bajo ancho de banda. “Aunque también hay excepciones, Eclipse Sparkplug, por ejemplo, tiene la capacidad de definir una estructura de datos estándar para las cargas útiles de MQTT, así como de mecanismos que permiten el descubrimiento automático de nodos y una mayor tolerancia en caso de fallo. OPC UA incluye un formato de datos binario opcional que hace que la transmisión sea más eficiente, y se ha agregado la posibilidad de establecer comunicaciones de publicación-suscripción sobre MQTT”, puntualiza.

Jordi Fernández, Solution Architect en Schneider Electric, por su parte, considera que “se trata de dos estándares consolidados de uso habitual en aplicaciones que requieren la transmisión de información, no obstante, cada uno aporta unas características que satisfacen requerimientos concretos”. En su opinión, si pensamos en interoperabilidad en aquellos casos en que están implicadas aplicaciones de distinta naturaleza y dispositivos de diferentes fabricantes, OPC UA proporciona ventajas como la estandarización de los tipos de datos, la gestión de colas para garantizar que no habrá pérdidas de información, diferentes esquemas de redundancia o la metodología que empleará un cliente y un servidor para acordar cómo se muestrea y cómo se publicará la información. Todo ello fundamentado en la capacidad de implementar el stack OPC UA de forma desligada del hardware y sistema operativo subyacentes. Mientras, en el caso MQTT “nos encontramos con una buena opción cuando se precisa ligereza en la transmisión de información, por ejemplo, cuando el sistema incluye sensores alimentados a batería o cuando no se dispone de enlaces con gran capacidad. Asegurar la interoperabilidad no es la principal vocación de MQTT y ello se debe a que el formato de la información transmitida queda delegado en la aplicación que la utilizará, esto supone que los nodos que producen información y los que la consumen deben contar con un desarrollo ad hoc para interpretar los mensajes y datos intercambiados, por este motivo, no van a ser necesariamente compatibles con otros desarrollos”.

“No es muy justo comparar OPC UA y MQTT, ya que son dos protocolos que surgen para necesidades diferentes y aunque comparten similitudes, en mi opinión, se complementan más que se enfrentan”, opina Sergio Muiña Simón, Automation Sales Engineer Manager en Weidmüller. Así, OPC UA surge de la necesidad de comunicar los controladores de una planta industrial con independencia de su plataforma. “OPC UA nos permite mediante cliente-servidor crear una estructura de comunicación totalmente customizada para cada aplicación ya que es una comunicación directa. Al ser una estructura customizada con OPC UA la estructura de variables tiene que ser creada previamente en el servidor. OPC UA permite diferentes niveles de seguridad como, por ejemplo, certificados PKI, WebSocket tokens, TLS o autentificación por usuario/contraseña de cada dispositivo cliente. Por otro lado, MQTT es un protocolo libre desde 2010 pero que lo creó en los años 90 un ingeniero de IBM. Lo que se buscaba con MQTT era una comunicación muy eficiente que necesitara muy poco ancho de banda. Para ello, MQTT utiliza un Brocker para realizar el intercambio de información entre los diferentes clientes. En este caso, la estructura de comunicación siempre es muy similar, ya que todos los dispositivos (clientes) publican o se subscriben a un Topic gestionado por el Brocker (servidor). Estos mensajes, a diferencia de OPC UA que previamente se tenían que crear la estructura de variables, se pueden crear a posteriori. MQTT tiene tres capas de QoS para determinar si el mensaje solo se envía una vez, el mensaje se enviará tantas veces como se necesite hasta ser recibido o similar al anterior, pero garantizando la entrega. Al igual que OPC UA, con MQTT tenemos diferentes niveles de seguridad por usuario/contraseña, SSL/TLS…”.

Por último, Ramón Quirós Menéndez, Jefe de Producto IMA  (Industry Management and Automation) en Phoenix Contact, nos explica que MQTT es un protocolo donde la codificación del campo de datos y su contenido son específicos a cada aplicación, por lo tanto, la solución va orientada a una aplicación específica normalmente. Además, MQTT fue diseñado para ser especialmente ligero y de bajo consumo. Por ello, no tiene implementada la búsqueda del topic ni del broker donde se publica el mensaje, esto hace que sea necesario que el cliente lo sepa de antemano. De la misma forma, tampoco tiene ningún mecanismo implementado para la escritura de la variable en la máquina. Por lo tanto, vamos a necesitar un programa cliente que esté suscrito al topic en el bróker; este programa debe procesar el mensaje publicado, acceder en nuestro caso al IPC o al PLC y escribir la variable.

“OPC UA (Unified Architecture) es una arquitectura completa donde el protocolo de comunicación es únicamente una parte. Una aplicación OPC UA permite ver todos los nodos de la red, métodos, estructuras de datos. OPC UA dispone de un concepto flexible basado en objetos y de perfiles específicos de aplicación - por ejemplo, PLCopen, MES, BACnet.  Esto le permite que pueda comunicarse con todas las aplicaciones de la empresa y a través de todas las capas empresariales. Con respecto a su predecesor, OPC DA, OPC UA por ejemplo ofrece una clara mejoría en aspectos de ciberseguridad, pues es compatible con el uso de firewalls en el medio y la comunicación entre cliente y servidor va cifrada”, concluye Quirós.

¿Qué modelos de comunicación utilizan ambas tecnologías?

Ante esta segunda cuestión, desde Emerson opinan que OPC UA “nos presenta una solución más completa donde se nos permite consultar métodos, estructuras de datos y nodos de la red bajo demanda. La comunicación nos permite tanto establecer un modelo basado en suscripción como puede estar orientada a modelo cliente-servidor donde un grupo de servicios pueden ser consultados con el fin de acceder a los nodos con objetivo de escribir, leer, llamar a métodos de servidores y otras funcionalidades. Por su parte, MQTT nos brinda las bondades de un protocolo muy ligero especialmente diseñado para medios con un ancho de banda reducido o inestable. Requiere una programación específica para cada aplicación lo que hace que sea menos versátil”. “El estándar OPC-UA Parte 14 PubSub, define una manera en la que los clientes OPC y los servidores se comuniquen a través de un patrón basado en publicación-suscripción, sobre protocolos de transporte MQTT. Pero hasta la fecha, este estándar ha tenido una escasa aceptación”, explican desde Optomation Systems, mientras que en Schneider Electric consideran que, tomando como base el esquema cliente/servidor de OPC UA, el estándar contempla en esencia dos opciones, la codificación de información en binario sobre TCP, idónea para alto rendimiento y de amplia aceptación en el mercado, y la codificación XML sobre sobre HTTPS, buena opción cuando la información debe transmitirse a través de cortafuegos en los que no es viable permitir tráfico en el puerto TCP requerido para la codificación en binario. Existen especificaciones híbridas que combinan la compacidad de la codificación en binario o la versatilidad de JSON con la simplicidad del transporte sobre HTTPS o sobre WebSockets. En todos los casos se trata de transmisión de información de uno a uno. “MQTT introduce un esquema diferente con el que no es posible efectuar una comunicación de uno a uno, ya que para su funcionamiento se precisa de un bróker, siendo éste un nodo requerido para recibir información de nodos cliente y redistribuirla a nodos que se hayan suscrito a dicha información. Este esquema facilita la transmisión eficiente, a la vez que confiable, de uno a muchos”. Y continúan: “El modelo PubSub de OPC UA, descrito más adelante, contempla el uso de diferentes codificaciones para el envío de datagramas en escenarios basado en bróker, igual que en el caso MQTT, o sin bróker, en cuyo caso se opta por transporte UDP. El escenario PubSub satisface la necesidad de comunicar uno a muchos en aquellos sistemas que así lo requieren. En ambos casos se trata de estándares que se apoyan en métodos para garantizar la seguridad de la información y, con tal efecto, soportan políticas para autenticar nodos y cifrar los datos en tránsito, beneficiándose para ello del uso de otro estándar consolidado como es X.509”.

Para Weidmüler, MQTT es una comunicación asíncrona que se basa en el patrón de publicación/subscripción. La arquitectura es Publisher / MQTT Broker / Subscriber. Un agente que publica un Topic en el MQTT Broker y todos los clientes que estén conectados a este MQTT Broker y se subscriban a ese Topic tendrán esa información. Opc Ua, sin embargo, se basa en cliente/servidor, utilizando un patrón de Request-Response. La arquitectura de comunicación puede ser mucho más compleja, ya que no todos los agentes apuntan sobre el mismo servidor como es el caso de MQTT.  Y la respuesta de Phoenix Contact: “MQTT: modelo suscripción - publicación, en el que los publishers envían mensajes a un servidor (broker) que es quien reenvía los mensajes a los subscribers evitando las conexiones punto a punto entre suscriptores y publicadores. OPCUA: La comunicación puede estar basada tanto en un modelo de suscripción publicación como en el modelo cliente servidor, donde el servidor muestra un grupo de servicios para poder acceder a los nodos de la red haciendo posible la lectura, la escritura, la llamada a métodos de los servidores, etc.”.

Utilización sobre redes de radiotelefonía móvil

Pero, estos protocolos, ¿pueden ser utilizados sobre redes de radiotelefonía móvil como 5G u otras similares? A este respecto, Alfonso Ramón explica que, “si necesito un protocolo de bajo consumo, con poca huella en el dispositivo IIOT en el que palpite y que sea capaz de garantizar la comunicación en redes de poco ancho de banda, MQTT puede ser un buen aliado. Por ejemplo, planteando un escenario de red móvil 4G/5G para hacer consultas de equipos remotos, diseñar la solución sobre MQTT puede ser una buena idea. El tamaño reducido de consumo de ancho de banda y su capacidad de implementar QoS para evitar pérdida de información puede brindarnos la solución más adecuada ante este escenario”. “En su origen, MQTT fue diseñado para utilizarse con redes y dispositivos de recursos limitados y una mínima anchura de banda, lo que le ofrece una alta rentabilidad en las transmisiones vía radio y móvil”, responde García Oleaga, “además, incluyen mecanismos que sirven para hacer frente a problemas de comunicación por la inestabilidad de red. Las transmisiones OPC UA, por el contrario, requieren de una anchura de banda superior y son menos apropiadas para conexiones de medidas, a no ser que optemos por la codificación binaria, mencionada anteriormente”.

Para Jordi Fernández, al tratarse de estándares que no precisan de protocolos propietarios de transporte ni direccionamiento de red, pueden beneficiarse de cualquier infraestructura de comunicaciones que se apoye en un stack TCP/UDP-IP, en consecuencia, “se pueden utilizar, por ejemplo, enlaces existentes con routers 3G, nuevos despliegues 5G, Ethernet o redes de fibra óptica dedicadas. Ambos ofrecerán un buen desempeño en todos los casos, si bien, la ligereza y modos de configuración de calidad de servicio de MQTT será un aspecto a su favor cuando se precise transmitir información a través de redes poco confiables o con mucha latencia”.

Muiña Simón también lo tiene claro: “Sí, la comunicación es independiente de la capa física, ya que cualquiera de los dos protocolos únicamente necesita una red IP, puesto que se basan en TCP/IP para las comunicaciones Subscriber, o Publisher y el Broker. La red IP puede ser local o tener acceso a internet. En muchas ocasiones, los clientes entienden la digitalización como sacar los datos a internet y no es así. Las comunicaciones con una arquitectura Cloud o entre servidores de diferentes plantas por medio de redes de radiotelefonía móvil o fija son una de las posibilidades de la digitalización. Tener datos digitalizados por medio de MQTT u OPC Ua permite sacarles mucho más partido a los datos que comunicarlos por una red de radiotelefonía. Por ejemplo, para hacer una base de datos local, una gestión de alarmas, un control del OEE… una vez hemos digitalizado un dato, las posibilidades son mucho mayores que si solo utilizamos ese dato para acciones meramente productivas.

También Ramón Quiros responde de manera afirmativa: “Sí, claramente. El que mejor funciona o más se usa para IIoT por el momento es MQTT, ya que es un protocolo de comunicación más ligero. Pero en nuestro caso OPC UA es usado por ciberseguridad, también por nuestro Device Update and Management Service para parchear y mantener al día en firmware de equipos como PLCnext a través de diferentes tipos de conexiones a internet, también conexión de radiotelefonía móvil”.

¿Es posible un uso compartido en función del tipo de comunicación a resolver?

“La magia consiste en saber qué protocolo es el más adecuado en cada situación. Aunque sobre el ‘Power Point’ se pueden obtener resultados parecidos, debemos analizar qué escenario tenemos para tomar la decisión correcta. Cada protocolo tiene sus puntos fuertes y es labor del ingeniero responsable saber seleccionar la solución adecuada, responde antes esta cuarta cuestión Alfonso Ramón desde Emerson. García Oleaga contesta rotundo desde Optomation: “Totalmente. Ambos estándares se complementan a la perfección en arquitecturas mixtas IIoT y aplicaciones en la nube.

MQTT ha encontrado su nicho en aplicaciones de telecomunicaciones e IT, tanto a nivel de empresas, como de consumidores. Cuenta con un respaldo sólido en prácticamente todas las principales plataformas en la nube, y es la herramienta ideal para la comunicación con sistemas IT y arquitecturas altamente escalables”. Según sus palabras, OPC cuenta con un soporte más amplio dentro de los sistemas de automatización, especialmente en los más antiguos, lo que lo convierte en un excelente intermediario para traducir datos hacia y desde equipos heredados y protocolos propietarios en el EDGE o borde de red. Los EDGE gateways tienen la capacidad de agregar varios protocolos de automatización, traducir datos a OPC UA, para compartir estos datos con sistemas heredados y de automatización, y posteriormente traducirlos de OPC UA a MQTT para distribuirlos a sistemas comerciales y analíticos.

Para Jordi Fernández, en realidad, no sólo es posible, sino que pueden convivir de forma sinérgica. “Como se comentaba con anterioridad, el estándar OPC UA contempla la opción de operar en un esquema de uno a muchos, un nodo publica información y varios nodos interesados en ella se suscriben. Esta opción se fundamenta en la codificación de información en binario o JSON y utiliza MQTT para su transporte, combinando de este modo interoperabilidad y confiabilidad”. Y, en este mismo sentido, se sitúa la respuesta de Ramón Quirós al afirmar que, en el caso de Phoenix Contact, “es muy frecuente usar el mismo PLC con comunicación OPC UA hacia sistemas SCADA o de visualización HMI y en paralelo MQTT para conectividad a entornos cloud o apps que se conecta al MQTT bróker instalado en el propio PLC”. Y añade concluyendo: “No se necesitan en absoluto dos hardware independientes para esto, con los PLCnext Control es posible hacerlo de forma sencilla, ya que se dispone de la implementación de cada protocolo por independiente, por ejemplo, el PLC es OPCUA Server y se le puede instalar en su parte accesible de linux MQTT Broker directamente o desde nuestro Marketplace digital PLCnext Store. También con herramientas ya preinstaladas en nuestros equipos como NodeRed se pueden tener comunicaciones en ambos protocolos de forma simultánea y muy sencilla, aunque en este caso no tengamos determinismo, pero esto en IIoT no suele ser un requerimiento habitual”.

Posibles alternativas

Y una última cuestión: ¿Existen otras alternativas o el mercado ya ha decidido que estos dos protocolos son los mejores y los únicos para IIOT? “Bajo mi punto de vista, y conociendo los ritmos de los entornos industriales, aunque existen otros protocolos válidos desde el punto de vista IIOT (AMQP, CoAP, etc.) la estandarización para este tipo de soluciones está gravitando en torno a los protocolos MQTT y OPC UA”, responde tajante el técnico de Emerson, mientras que Para Jordi Fernández de Schneider Electric es cierto que MQTT y OPC UA son opciones estables, aceptadas y que se benefician de publicaciones actualizadas de sus respectivas especificaciones, sin embargo, “ello no excluye que en determinados casos de uso sean aplicables otros estándares, por ejemplo, AMQP. Es previsible que las implementaciones existentes en ambos casos se vean enriquecidas con la generalización en dispositivos hardware de funcionalidades como el perfil Alarms & Conditions, en el caso OPC UA, o la normalización de interoperabilidad con Sparkplug en MQTT”. Según considera, la respuesta a esta cuestión, aplicable tanto en perímetros exclusivamente OT como en casos de enlace IT con OT, vendrá dada por la capacidad de ambos estándares para ir cubriendo nuevas necesidades en escenarios IIoT. “Sin lugar a duda, ambas opciones se fundamentan en especificaciones maduras y se aprovechan de esta experiencia para una continua evolución que les otorga por derecho la calificación de estándares future proof.”.

En esta misma línea se manifiestan en Weidmüller: “Si bien es cierto que nuestra experiencia nos está demostrando que tanto MQTT para aplicaciones Cloud, en las que hay que mover datos por internet, como OPC Ua para comunicaciones industriales a nivel local de OT son los dos protocolos más demandados, existen otros también utilizados como HTTP, XMPP, CoAP, AMQP…” Y concluimos con la respuesta del experto de Phoenix Contact, muy en la misma dirección que las anteriores: “Realmente OPC UA y MQTT son los más usados hoy por hoy, pero existen varios protocolos que se usan desde hace algunos años como AMQP, Zigbee o Lora Lora/Lorawan. Dependiendo de las características de cada uno, puede tener más o menos sentido su uso en aplicaciones de diferentes sectores o ámbitos como Smart Cities o Building Automation. Lo que tenemos claro desde Phoenix Contact  como fabricante de PLC es que tenemos que ofrecer a nuestros clientes equipos que puedan adaptarse de forma flexible a cada caso y que el que hoy es el protocolo más usado mañana puede estar desfasado para otra aplicación, por eso, PLCnext ofrece la apertura suficiente para garantizar una adaptabilidad ilimitada desde el punto de vista de IIoT y ofrece la posibilidad de trabajar tanto con MQTT, OPC UA como con otros protocolos ya mencionados o futuros”.

Págs. 50 a 56.