Los dashboards son para el verano
agosto 13, 2019
Ventajas de utilizar un sistema de monitorización SaaS en la nube
septiembre 12, 2019
Comparativa entre MQTT y OPC-UA
En el blog de hoy compararemos dos de los protocolos más populares en el entorno de Industrial Internet of Things (IIoT): MQTT y OPC-UA, para intentar arrojar algo de luz sobre las diferencias y usos de los mismos. Comencemos viendo un pequeño resumen de las principales características de estos dos conocidos protocolos de intercambio de mensajes, siendo MQTT de los más populares en el mundo IoT y, desde hace unos años, OPC UA en entornos industriales.
El protocolo MQTT para seguir el modelo de publicación suscripción define dos entidades en la red: el broker, también llamado servidor, y los clientes. Los clientes son cualquier dispositivo que vaya a interactuar con el broker, tanto publicando mensajes como suscribiéndose a un topic. Los topic son las rutas donde se publican los mensajes dentro de un broker. Esto nos sirve para poder tener la información ordenada y poder gestionar mejor los mensajes.
Siguen el siguiente formato:
Empresa/horno1/temperatura
Al definirse con esta estructura, los topics nos permiten el uso de wildcards para aumentar su flexibilidad, permitiéndonos suscribirnos a múltiples topics.
# - wildcard multilevel
+ - wildcard singlelevel
Supongamos ahora que tenemos a mayores los siguientes topics:
empresa/horno2/temperatura
empresa/horno/humedad
MQTT
MQTT (Message Queque Telemetry Transport) es un protocolo liviano de mensajes que se basa en un modelo suscripción - publicación, en el que los publicadores envían mensajes a un servidor y este es quien reenvía los mensajes a los suscriptores evitando las conexiones punto a punto entre suscriptores y publicadores, esto permite que los suscriptores no necesiten saber quién proporciona la información a la que está suscrito. MQTT está diseñado para poder ser implementado en dispositivos de bajos recursos, en redes de bajo ancho de banda y de alta latencia.El protocolo MQTT para seguir el modelo de publicación suscripción define dos entidades en la red: el broker, también llamado servidor, y los clientes. Los clientes son cualquier dispositivo que vaya a interactuar con el broker, tanto publicando mensajes como suscribiéndose a un topic. Los topic son las rutas donde se publican los mensajes dentro de un broker. Esto nos sirve para poder tener la información ordenada y poder gestionar mejor los mensajes.
Siguen el siguiente formato:
Empresa/horno1/temperatura
Al definirse con esta estructura, los topics nos permiten el uso de wildcards para aumentar su flexibilidad, permitiéndonos suscribirnos a múltiples topics.
# - wildcard multilevel
+ - wildcard singlelevel
Supongamos ahora que tenemos a mayores los siguientes topics:
empresa/horno2/temperatura
empresa/horno/humedad
Usando las wildcards podríamos suscribirnos a todos los mensajes dentro de “empresa/horno1/” seleccionando el topic “empresa/horno1/#”, si ahora queremos recibir solo todas las temperaturas de los hornos, sólo nos tendríamos que suscribir al topic “empresa/*/temperatura”. En el broker se publican todos los mensajes dentro de sus respectivos topics, el broker es el encargado de recibir los mensajes y reenviarlos a los clientes suscritos a esos topics.
La conexión cliente – servidor para el envío de los mensajes se hace mediante una conexión TCP o una conexión TLS cifrada en caso de necesidad de envío de mensajes seguros.
El mensaje puede tener cualquier formato de datos para la carga útil, como JSON, XML, binario cifrado o Base64. Esto da mucha flexibilidad al protocolo, pero el cliente destino debe poder analizar el tipo de carga.
El protocolo admite el envío de mensajes con calidad de servicio, dejando elegir tres niveles distintos:
Por todas estas características como su bajo consumo de ancho de banda, su flexibilidad a la hora de diseñar el contenido del mensaje lo hacen ideal para que dispositivos de bajo consumo puedan enviar información a un servidor como pueden ser un Arduino, una Raspberry Pi o soluciones comerciales de domótica en las que el propio desarrollador de la plataforma sabe cómo debe ser su contenido del mensaje.
En los servidores OPC UA se definen los servicios que pueden proporcionar a los clientes, un modelo de objetos que puede ser descubierto dinámicamente por los clientes y un modelo de datos siguiendo los data-types definidos en el propio protocolo.
Un cliente puede comunicarse con uno o varios servidores, un servidor de la misma forma puede comunicarse con varios clientes. Los servidores pueden actuar como clientes para la comunicación con otros servidores.
La conexión cliente – servidor para el envío de los mensajes se hace mediante una conexión TCP o una conexión TLS cifrada en caso de necesidad de envío de mensajes seguros.
El mensaje puede tener cualquier formato de datos para la carga útil, como JSON, XML, binario cifrado o Base64. Esto da mucha flexibilidad al protocolo, pero el cliente destino debe poder analizar el tipo de carga.
El protocolo admite el envío de mensajes con calidad de servicio, dejando elegir tres niveles distintos:
- 0 sin calidad de servicio. El mensaje se envía una sola vez, en caso de que el cliente no se encuentre disponible el mensaje se perderá.
- 1 el mensaje se reenviará hasta que llegue al menos una vez, esto puede suponer alguna duplicidad en la recepción de los mensajes.
- 2 el mensaje llegará al cliente una sola vez.
Por todas estas características como su bajo consumo de ancho de banda, su flexibilidad a la hora de diseñar el contenido del mensaje lo hacen ideal para que dispositivos de bajo consumo puedan enviar información a un servidor como pueden ser un Arduino, una Raspberry Pi o soluciones comerciales de domótica en las que el propio desarrollador de la plataforma sabe cómo debe ser su contenido del mensaje.
OPC UA
OPC UA (Open Platform Communications Unified Architecture) es un estándar independiente de la plataforma a través del cual varios tipos de sistemas y dispositivos pueden comunicarse enviando mensajes de solicitud y respuesta entre clientes y servidores o de forma similar a MQTT mediante un modelo de suscripción – publicación.En los servidores OPC UA se definen los servicios que pueden proporcionar a los clientes, un modelo de objetos que puede ser descubierto dinámicamente por los clientes y un modelo de datos siguiendo los data-types definidos en el propio protocolo.
Un cliente puede comunicarse con uno o varios servidores, un servidor de la misma forma puede comunicarse con varios clientes. Los servidores pueden actuar como clientes para la comunicación con otros servidores.
OPC UA da un espacio de direcciones (AddressSpace) consistente e integrado y un modelo de servicio. Esto permite a un solo servidor integrar datos, alarmas y eventos en este espacio de direcciones y proveer acceso a ellos usando sus servicios integrados que incorporan mecanismos para que los clientes puedan detectar y recuperar los fallos en la comunicación.
TOPC UA nos proporciona mecanismos de seguridad para la autentificación de los usuarios, clientes y servidores, la comprobación de la integridad de las comunicaciones y aportar seguridad a nivel de transporte encriptando y firmando los mensajes.
OPC UA busca facilitar la forma de operar entre los dispositivos de distintos fabricantes estableciendo una forma común de comunicación, esto lo hace especialmente útil en entornos industriales donde pueden convivir dispositivos de distintos fabricantes, permitiendo la comunicación de todos ellos con un solo cliente, o incluso entre los propios dispositivos.
MQTT es un protocolo donde la codificación de campo de datos y su contenido son específicos a cada aplicación, por lo tanto, será útil cuando la comunicación de los mensajes sea para una aplicación especifica desarrollada para esos campos de datos.
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. La comunicación puede estar basada tanto 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.
Ahora pongamos un ejemplo, como puede ser la escritura de una variable alojada en un PLC
Como vimos anteriormente, MQTT está diseñado para ser 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, para esta implementación vamos a necesitar un programa cliente que esté suscrito al topic en el broker, este programa debe procesar el mensaje publicado, acceder al PLC y escribir la variable.
Esto tiene varios problemas:
Todos estos problemas se solucionan con OPC UA. Para la escritura de una variable en un servidor OPC UA, sería simplemente con una serie de peticiones desde el propio cliente OPC. Los pasos que seguiría el protocolo serían: Abrir un canal seguro, ver la lista de endpoints disponibles, crear la sesión, escribir el valor de la variable, cerrar la sesión y cerrar el canal.
Por contrapartida, el consumo de ancho de banda de hacer la escritura, sin contar el envío de la petición de escritura, supera los 600 Bytes cuando el envío de la variable a escribir mediante el protocolo MQTT consume unos 17 Bytes.
La conclusión a la que llegamos es que cada protocolo se debe utilizar para lo que fue diseñado. MQTT para dispositivos de bajos recursos, redes de bajo ancho de banda, de alta latencia o en aplicaciones que requieran la flexibilidad de este protocolo y OPC UA para entornos industriales, ya que busca unificar la forma de operar con distintos fabricantes de dispositivos industriales siendo una solución completa que abarca desde la comunicación de los dispositivos a su interoperabilidad, en estos entornos el aumento de consumo de ancho de banda no es tan crítico como para que no compensen todas las ventajas que nos aporta OPC UA.
La plataforma Minerva de Muutech, basada en Zabbix y Grafana trabaja con ambos protocolos, por lo que no dudéis en contactar con nosotros si necesitáis una plataforma de monitorización que combine el mundo IoT con el mundo industrial y de sistemas TI.
OPC UA busca facilitar la forma de operar entre los dispositivos de distintos fabricantes estableciendo una forma común de comunicación, esto lo hace especialmente útil en entornos industriales donde pueden convivir dispositivos de distintos fabricantes, permitiendo la comunicación de todos ellos con un solo cliente, o incluso entre los propios dispositivos.
COMPARATIVA
Actualmente, después de ver sus principales características, podemos afirmar que hacer una comparación entre estos dos protocolos no es del todo justa.MQTT es un protocolo donde la codificación de campo de datos y su contenido son específicos a cada aplicación, por lo tanto, será útil cuando la comunicación de los mensajes sea para una aplicación especifica desarrollada para esos campos de datos.
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. La comunicación puede estar basada tanto 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.
Ahora pongamos un ejemplo, como puede ser la escritura de una variable alojada en un PLC
Como vimos anteriormente, MQTT está diseñado para ser 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, para esta implementación vamos a necesitar un programa cliente que esté suscrito al topic en el broker, este programa debe procesar el mensaje publicado, acceder al PLC y escribir la variable.
Esto tiene varios problemas:
- Procesado del mensaje, el mensaje publicado no tiene un formato concreto, por tanto, el suscriptor tiene que saber el formato con el que va a recibir el mensaje.
- La escritura de los datos en el PLC varía dependiendo del fabricante.
Todos estos problemas se solucionan con OPC UA. Para la escritura de una variable en un servidor OPC UA, sería simplemente con una serie de peticiones desde el propio cliente OPC. Los pasos que seguiría el protocolo serían: Abrir un canal seguro, ver la lista de endpoints disponibles, crear la sesión, escribir el valor de la variable, cerrar la sesión y cerrar el canal.
Por contrapartida, el consumo de ancho de banda de hacer la escritura, sin contar el envío de la petición de escritura, supera los 600 Bytes cuando el envío de la variable a escribir mediante el protocolo MQTT consume unos 17 Bytes.
La conclusión a la que llegamos es que cada protocolo se debe utilizar para lo que fue diseñado. MQTT para dispositivos de bajos recursos, redes de bajo ancho de banda, de alta latencia o en aplicaciones que requieran la flexibilidad de este protocolo y OPC UA para entornos industriales, ya que busca unificar la forma de operar con distintos fabricantes de dispositivos industriales siendo una solución completa que abarca desde la comunicación de los dispositivos a su interoperabilidad, en estos entornos el aumento de consumo de ancho de banda no es tan crítico como para que no compensen todas las ventajas que nos aporta OPC UA.
La plataforma Minerva de Muutech, basada en Zabbix y Grafana trabaja con ambos protocolos, por lo que no dudéis en contactar con nosotros si necesitáis una plataforma de monitorización que combine el mundo IoT con el mundo industrial y de sistemas TI.
CTO & TECHNICAL DIRECTOR
Experto en monitorización industrial y analítica de datos.
Te contamos cómo mejorar la toma de decisiones y la eficiencia productiva en tu planta, sin perder tiempo generando reportes. ¡Tu planta en un vistazo!
Suscríbete a nuestra Newsletter
