MQTT - Transmisión a nivel de redes
MQTT utiliza el protocolo básico TCP y, por lo tanto, trabaja según el principio de cliente/servidor.
El broker es aquí el servidor que, de una forma estándar, puede recibir conexiones en el puerto TCP 1883. Los usuarios de MQTT actúan de clientes TCP y cuando es necesario se conectan con el broker.
MQTT - Intercambio de datos a nivel de protocolo
Un cliente en MQTT puede desempeñar dos papeles.
Publisher
Como publicador, el cliente envía datos al broker. Estos pueden ser valores de medición, estados de conmutación o cualquier otro dato del proceso. Además de contenidos de texto legibles, MQTT permite también datos binarios. Que las transmisiones de datos del publicador al broker se realicen cíclicamente o cada vez que se produce un cambio depende de la aplicación.
Subscriber
El suscriptor recibe los datos del broker. Como suscriptor, una vez establecida la conexión, el cliente notifica al broker los datos que desea recibir o suscribir.
Cada cliente de MQTT puede ser publicador, suscriptor o ambos. Es decir, que no hay ningún principio de maestro/esclavo obligatorio como en otros protocolos industriales. En MQTT todos los dispositivos terminales o clientes tienen los mismos derechos al nivel de MQTT. Quién envía y quién recibe los datos es algo que define únicamente la aplicación mediante la asignación de publicador y suscriptor.
Topic
El broker de MQTT administra los datos a intercambiar según los puntos terminales de datos. La denominación de los puntos terminales de datos se realiza mediante tópicos. Estos son strings, es decir cadenas de caracteres que pueden tener una estructura similar a la de URL cuando se abre una página web.
Ejemplo:
Un Web-Termo-higrobarómetro de W&T mide la temperatura, la humedad del aire y la presión en la sala de servidores de la empresa W&T. Cada uno de esos tres datos constituye un punto terminal de datos.
Los tópicos respectivos podrían tener este aspecto:
wut/serverraum/temperatur
wut/serverraum/luftfeuchte
wut/serverraum/luftdruck
El Web-Termo-higrobarómetro envía los datos medidos como carga útil vía publicación MQTT, es decir como contenido de datos bajo estos tópicos, al broker de MQTT.
Un cliente de MQTT cualquiera puede enviar ahora al broker una suscripción indicando el tópico deseado. Aquí el clientes en MQTT envía una suscripción wut/serverraum/temperatur
y se suscribe al valor de temperatura del Web-Termo-higrobarómetro.
Un ordenador cliente de MQTT recibirá automáticamente el valor publicado por el Web-Termo-higrobarómetro mientras se mantenga la conexión con el broker.
El suscriptor puede trabajar con comodines "#" para indicar los tópicos.
Beispiel: wut/serverraum/# abonniert Temperatur, Luftfeuchte und Luftdruck für den Serverraum.
Otro comodín, a parte de "#", es "+". Cuando se utiliza "+", la suscripción se limita a los tópicos terminales del nivel respectivo, ignorándose los tópicos de los niveles posteriores.
Para cada valor suscrito tiene lugar un envío de datos propio.
La transmisión de los datos se realiza por bytes y, por lo tanto, es binaria transparente, es decir, que se pueden transmitir contenidos arbitrariamente. Para la uniformización de los contenidos de texto está predeterminado el formato UTF8.
MQTT - Propiedades especiales
Para el transporte y el intercambio de datos, MQTT ofrece algunas opciones especiales que pueden ser aplicadas mediante flags para cada conexión o cada suscripción.
Quality of Service – QoS
Con valores entre 0 y 2 se define la fiabilidad con la que un mensaje publicado será enviado al broker.
- Fuera y olvidado
El cliente de MQTT no espera ninguna confirmación de los datos enviados.
Este procedimiento no es seguro pero muy rápido.
- Al menos una vez
Dado el caso, el cliente de MQTT puede enviar los datos más de una vez,
hasta que el broker le envíe una confirmación de recibo.
Ese procedimiento garantiza que los datos lleguen al broker,
pero se pueden repetir los envíos.
- Exactamente una vez
Cada envío de datos tiene que ser confirmada explícitamente por el broker.
De ese modo se garantiza que no se envíe nada por duplicado.
Este procedimiento es el más seguro, pero también el más lento.
Con QoS1 y 2 se plantea la pregunta de por qué un envío único de los datos es más seguro que varios envíos. Con dos ejemplos quedará claro rápidamente.
Si se trata de transferir el valor de una medición, por ejemplo la temperatura, no importa si el valor llega varias veces a un suscriptor. Pero si lo que se transmite es el ángulo de movimiento del brazo de un robot, por ejemplo 5° y el suscriptor recibe el dato tres veces, el brazo del robot se movería 15°, lo que tendría consecuencias fatales.
Last Will and Testament
Un publicador puede especificar que, en caso de que se pierda la conexión MQTT, el broker envíe a los suscriptores un mensaje determinado en lugar de los datos o valores suscritos.
Retained Message
Aplicando esta flag el publicador indica al broker que tiene que guardar de modo intermedio el último valor o dato enviado para enviárselo de inmediato a un suscriptor cuando se conecte de nuevo.
Estas tres propiedades son especialmente útiles cuando la transmisión se efectúa por canales que no siempre funcionan con seguridad (por ejemplo redes móviles).
Propiedades y ventajas de MQTT
MQTT está considerado como el protocolo de transmisión para el "Internet de las Cosas" y ofrece varias ventajas, en particular para el intercambio de datos a través de Internet:
- Puesto que todos los dispositivos terminales que utilizan MQTT trabajan como clientes, en general es posible superar con facilidad los cortafuegos y las medidas de seguridad (no es necesario configurar ninguna autorización de puerto ni enrutamiento NAT o redirección de puerto en los cortafuegos).
- El publicador no tiene que preocuparse de qué destinatario recibe realmente los datos puestos a disposición.
- Al contrario que con otros protocolos basados en Internet, se pueden transmitir datos binarios sin Base64 u otras codificaciones.
Peculiaridades y desventajas
- El suministrador de los datos no tiene ningún conocimiento de quién recibe realmente los datos (no hay confirmación entre extremos).
- No es apto para trabajar en tiempo real
Fundamentos básicos sobre los protocolos industriales más habituales
-
Web-IO - Automatización con protocolos estándar
Integrar señales IO con Modbus TCP, OPC UA/DA, Rest o MQTT
-
Formatos de datos y protocolos
Del clásico intercambio de datos hasta el IoT
-
Modbus-TCP
Estándar abierto para comunicación industrial
-
REST - REpresentational State Transfer
Comunicación industrial en base a peticiones HTTP estandarizadas
-
OPC UA -
OPC Unified ArchitectureOPC Unterstützung out of the box
-
OPC DA -
OPC Data AccessEl intérprete de los datos de procesos