MQTT vs DDS: mensajería industrial con broker frente a sin broker

MQTT vs DDS es una pregunta que aparece en proyectos de robótica, automoción y automatización industrial, donde algunos sistemas necesitan un determinismo del orden de microsegundos en una red local y otros necesitan llevar datos de muchas instalaciones a la nube. Ambos son publish/subscribe, pero MQTT se apoya en un broker central mientras que DDS permite que los participantes se descubran entre sí e intercambien datos directamente. Esta guía compara las arquitecturas, las garantías de tiempo real y los despliegues típicos, y muestra cuándo MQTT con broker hacia un servicio en la nube es la opción práctica.

Dos filosofías de publish/subscribe

MQTT funciona con broker. Cada cliente abre una conexión con un broker, publica en topics y se suscribe a filtros de topic, y el broker enruta cada mensaje. Los clientes no se conocen entre sí. Esto simplifica la topología de red: los dispositivos solo necesitan una conexión saliente hacia un endpoint conocido, lo que funciona a través de NAT, firewalls y redes celulares. Para repasar el papel del broker, consulta qué hace un broker MQTT.

DDS (Data Distribution Service) es un estándar del Object Management Group para publish/subscribe centrado en datos y sin broker. Los participantes de un dominio DDS se descubren entre sí, normalmente mediante multicast UDP en la red local, e intercambian datos directamente usando el protocolo de transmisión DDSI-RTPS. Los topics tienen un tipado fuerte con una estructura de datos definida en IDL, y cada lector y escritor declara políticas de calidad de servicio que DDS empareja automáticamente. DDS es el middleware que hay debajo de ROS 2 y es habitual en defensa, aeroespacial, dispositivos médicos y algunos sistemas de automoción y energía.

MQTT vs DDS de un vistazo

Arquitectura: broker frente a bus de datos

El broker de MQTT es a la vez una ventaja y un coste. Te da un único lugar para autenticar clientes, aplicar cuotas, ver todos los topics y conectar con la nube. También añade un salto de red y es un componente que debe estar disponible. Un broker MQTT gestionado traslada ese trabajo de disponibilidad al proveedor.

DDS elimina el salto intermedio. Los escritores envían directamente a los lectores emparejados, lo que reduce la latencia y evita una dependencia central en la red local. El precio es la complejidad: el tráfico de descubrimiento crece con el número de participantes y endpoints, la red debe permitir multicast y cruzar subredes, NAT o internet requiere servicios de enrutamiento adicionales. DDS es excelente dentro de un robot, un vehículo o una célula; resulta incómodo entre cientos de instalaciones remotas.

Garantías de tiempo real y QoS

La QoS de DDS es mucho más rica que la de MQTT. Un escritor DDS puede declarar que actualiza un topic al menos cada 10 milisegundos (deadline), que quienes se incorporen tarde deben recibir las últimas N muestras (durability e history), que un lector debe ser notificado si un escritor deja de emitir (liveliness) o que solo debe escucharse al escritor de mayor prioridad (ownership, útil para sensores redundantes). DDS empareja lectores y escritores compatibles e informa de las incompatibilidades. Combinado con transportes UDP y de memoria compartida, esto hace que DDS encaje bien en lazos de control y fusión de sensores.

MQTT es más sencillo. QoS 0, 1 y 2 definen las garantías de entrega, los retained messages dan a quienes se incorporan tarde el último valor, las sesiones persistentes almacenan mensajes para los suscriptores desconectados y el Last Will señala las desconexiones abruptas. MQTT 5 añade la expiración de mensajes, que ayuda a descartar comandos obsoletos. Estas son las funciones que realmente necesitan la mayoría de las aplicaciones de telemetría y supervisión. Para repasarlo, consulta los niveles de QoS de MQTT explicados.

Ninguno de los dos protocolos convierte por sí solo un sistema en tiempo real estricto. El determinismo también depende del sistema operativo, la red y el hardware. Pero DDS te da el vocabulario para especificar el comportamiento temporal, y MQTT ni lo intenta.

Robótica frente a IIoT

En robótica, ROS 2 convirtió DDS en la opción por defecto. Los nodos de un mismo robot o de una misma red local se publican entre sí datos de sensores, transformaciones y comandos con baja latencia, y gracias al descubrimiento puedes arrancar los nodos en cualquier orden. Es DDS haciendo exactamente aquello para lo que se diseñó.

En el IoT industrial, los requisitos son otros. Los datos deben fluir desde PLC, máquinas y gateways de muchas plantas hacia sistemas de supervisión, historiadores y aplicaciones en la nube, atravesando firewalls y enlaces WAN. Los integradores esperan un Unified Namespace organizado por niveles ISA-95, y muchos dispositivos ya hablan MQTT o Sparkplug B. Aquí un broker es una ventaja, porque da a cada instalación una única conexión saliente y un único lugar donde buscar los datos. La guía de MQTT Sparkplug B y Unified Namespace explica ese modelo.

Conectar DDS con MQTT: un ejemplo con ROS 2

El patrón habitual es DDS dentro de la máquina y MQTT hacia fuera. Un pequeño nodo ROS 2 se suscribe a topics DDS locales y publica en un broker MQTT datos seleccionados y submuestreados. El ejemplo siguiente reenvía el estado de la batería de un robot a ConnectMQ.

import json
import ssl
import time

import paho.mqtt.client as mqtt
import rclpy
from rclpy.node import Node
from sensor_msgs.msg import BatteryState


class BatteryToMqtt(Node):
    def __init__(self):
        super().__init__("battery_to_mqtt")
        self.last_sent = 0.0
        self.mqtt = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                                client_id="YOUR_CLIENT_ID")
        self.mqtt.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
        self.mqtt.tls_set(cert_reqs=ssl.CERT_REQUIRED)
        self.mqtt.will_set("connectmq/site1/fleet/robot7/status", "offline",
                           qos=1, retain=True)
        self.mqtt.connect("broker.connectmq.com", 8883, keepalive=30)
        self.mqtt.loop_start()
        self.mqtt.publish("connectmq/site1/fleet/robot7/status", "online",
                          qos=1, retain=True)
        self.create_subscription(BatteryState, "/battery_state",
                                 self.on_battery, 10)

    def on_battery(self, msg: BatteryState):
        now = time.time()
        if now - self.last_sent < 5.0:  # submuestrea a un mensaje cada 5 s
            return
        self.last_sent = now
        payload = json.dumps({
            "voltage": round(msg.voltage, 2),
            "percentage": round(msg.percentage, 3),
            "ts": int(now),
        })
        self.mqtt.publish("connectmq/site1/fleet/robot7/battery", payload,
                          qos=1, retain=True)


def main():
    rclpy.init()
    node = BatteryToMqtt()
    try:
        rclpy.spin(node)
    finally:
        node.mqtt.loop_stop()
        node.destroy_node()
        rclpy.shutdown()


if __name__ == "__main__":
    main()

Dos decisiones de diseño hacen que este bridge sea robusto. Submuestrea, porque los topics DDS pueden funcionar a frecuencias que no tiene sentido enviar por una WAN. Y usa un Last Will retenido, para que los dashboards de la flota vean que el robot se desconecta aunque el bridge se caiga. Para un experimento rápido sin credenciales, conéctate al puerto 1883 con un client ID único y usa un prefijo connectmq/demo/<random-id>/ en el servidor MQTT público gratuito.

Lista de comprobación para decidir

1. ¿Necesitan los componentes intercambiar datos en milisegundos en la misma máquina o LAN, con una QoS temporal estricta? Usa DDS ahí.
2. ¿Necesitas datos de muchas instalaciones, a través de NAT o redes celulares, en la nube? Usa MQTT para ese camino.
3. ¿Tus dispositivos son microcontroladores, PLC o gateways comerciales? Lo más probable es que hablen MQTT.
4. ¿Estás construyendo sobre ROS 2? Mantén DDS en el robot y conecta los topics seleccionados a MQTT.
5. ¿Necesitas un Unified Namespace o Sparkplug B? Eso es ecosistema MQTT.
6. ¿Quieres un único lugar para autenticar, monitorizar y limitar clientes? Ese es el trabajo de un broker.

Dónde encaja un broker MQTT en la nube

Cuando el mundo DDS necesita hablar con dashboards, historiadores, apps móviles, un gemelo digital 3D de la flota de robots y otras instalaciones, un broker MQTT en la nube es el punto de encuentro práctico. ConnectMQ ofrece MQTT 3.1.1 y 5.0 sobre TLS, detecta topics ISA-95 y de Unified Namespace, decodifica Sparkplug B y muestra los dispositivos por nivel ISA-95 en su portal. No habla DDS por sí mismo, así que un nodo bridge como el anterior es la vía de integración honesta. Para más contexto industrial, lee la guía de IoT industrial con MQTT, y para los fundamentos del protocolo, el tutorial de MQTT.

Empieza con ConnectMQ

Mantén DDS donde importa el determinismo y envía a un broker MQTT gestionado los datos que necesita el resto del negocio. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, ejecuta tu nodo bridge y observa cómo aparecen los topics en el explorador en vivo.

Preguntas frecuentes

¿Es DDS más rápido que MQTT?

En una red local, DDS suele tener menor latencia porque los datos van directamente del escritor al lector sin pasar por un broker. En enlaces WAN e internet esa ventaja se diluye, y MQTT es más fácil de enrutar.

¿Puede funcionar DDS a través de internet?

No fácilmente por sí solo, ya que el descubrimiento depende del multicast local y del direccionamiento directo entre pares. Existen servicios de enrutamiento y relays, pero la mayoría de los equipos prefieren conectar datos seleccionados a MQTT.

¿Admite ROS 2 MQTT?

ROS 2 usa DDS por defecto. Puedes conectarlo a MQTT con un nodo bridge, ya sea un paquete de la comunidad o un pequeño nodo propio como el del ejemplo de este artículo.

¿Debo usar DDS o MQTT para IIoT?

Para telemetría de planta a nube, datos de supervisión y arquitecturas de Unified Namespace, MQTT suele encajar mejor. DDS es adecuado para el control en tiempo real dentro de máquinas y células.