MQTT vs DDS: Mensageria Industrial com e sem Broker

MQTT vs DDS é uma questão que aparece em projetos de robótica, automotivos e de automação industrial, em que alguns sistemas precisam de determinismo na ordem de microssegundos em uma rede local e outros precisam levar dados de muitas unidades para a nuvem. Os dois são publish/subscribe, mas o MQTT depende de um broker central, enquanto o DDS permite que os participantes se descubram e troquem dados diretamente. Este guia compara as arquiteturas, as garantias de tempo real e as implantações típicas, e mostra onde o MQTT com broker até um serviço em nuvem é a escolha prática.

Duas Filosofias de Publish/Subscribe

O MQTT usa broker. Cada client abre uma conexão com um broker, publica em topics e assina filtros de topic, e o broker roteia cada mensagem. Os clients não sabem da existência uns dos outros. Isso torna a topologia de rede simples: os dispositivos só precisam de uma conexão de saída para um endpoint conhecido, o que funciona através de NAT, firewalls e redes celulares. Para relembrar o papel do broker, veja o que um broker MQTT faz.

O DDS (Data Distribution Service) é um padrão do Object Management Group para publish/subscribe centrado em dados e sem broker. Os participantes de um domínio DDS se descobrem, geralmente via UDP multicast na rede local, e trocam dados diretamente usando o protocolo de rede DDSI-RTPS. Os topics são fortemente tipados, com uma estrutura de dados definida em IDL, e cada reader e writer declara políticas de qualidade de serviço que o DDS casa automaticamente. O DDS é o middleware por baixo do ROS 2 e é comum em defesa, aeroespacial, dispositivos médicos e alguns sistemas automotivos e de energia.

MQTT vs DDS em Resumo

Arquitetura: Broker vs Barramento de Dados

O broker do MQTT é ao mesmo tempo uma força e um custo. Ele oferece um único lugar para autenticar clients, aplicar cotas, ver todos os topics e conectar a nuvem. Também adiciona um salto de rede e é um componente que precisa estar disponível. Um broker MQTT gerenciado transfere esse trabalho de disponibilidade para o provedor.

O DDS elimina o salto intermediário. Writers enviam diretamente para os readers compatíveis, o que reduz a latência e evita uma dependência central na rede local. O preço é a complexidade: o tráfego de descoberta cresce com o número de participantes e endpoints, o multicast precisa ser permitido na rede e atravessar sub-redes, NAT ou a internet exige serviços de roteamento adicionais. O DDS é excelente dentro de um robô, de um veículo ou de uma célula; é desajeitado entre centenas de unidades remotas.

Garantias de Tempo Real e QoS

O QoS do DDS é muito mais rico que o QoS do MQTT. Um writer DDS pode declarar que atualiza um topic pelo menos a cada 10 milissegundos (deadline), que quem chega depois deve receber as últimas N amostras (durability e history), que um reader deve ser notificado se um writer ficar em silêncio (liveliness) ou que apenas o writer de maior força deve ser ouvido (ownership, útil para sensores redundantes). O DDS casa readers e writers compatíveis e reporta incompatibilidades. Combinado com transportes UDP e de memória compartilhada, isso torna o DDS uma boa opção para malhas de controle e fusão de sensores.

O MQTT é mais simples. QoS 0, 1 e 2 definem as garantias de entrega, retained messages dão a quem chega depois o último valor, sessões persistentes guardam mensagens para assinantes offline e o Last Will sinaliza desconexões abruptas. O MQTT 5 adiciona a expiração de mensagens, que ajuda a descartar comandos obsoletos. Esses são os recursos de que a maioria das aplicações de telemetria e supervisão realmente precisa. Para relembrar, veja os níveis de QoS do MQTT explicados.

Nenhum dos protocolos torna um sistema hard real-time por si só. O determinismo também depende do sistema operacional, da rede e do hardware. Mas o DDS oferece o vocabulário para especificar o comportamento temporal, e o MQTT não tenta fazer isso.

Robótica vs IIoT

Na robótica, o ROS 2 tornou o DDS o padrão. Nós no mesmo robô ou na mesma rede local publicam dados de sensores, transformações e comandos entre si com baixa latência, e a descoberta permite iniciar os nós em qualquer ordem. É o DDS fazendo exatamente aquilo para que foi projetado.

No IoT industrial, os requisitos são outros. Os dados precisam fluir de PLCs, máquinas e gateways em muitas plantas para sistemas de supervisão, historiadores e aplicações em nuvem, atravessando firewalls e links WAN. Integradores esperam um Unified Namespace organizado pelos níveis do ISA-95, e muitos dispositivos já falam MQTT ou Sparkplug B. Aqui um broker é uma vantagem, porque dá a cada unidade uma única conexão de saída e um único lugar para procurar os dados. O guia de MQTT Sparkplug B e Unified Namespace explica esse modelo.

Ponte de DDS para MQTT: Um Exemplo com ROS 2

O padrão comum é DDS dentro da máquina e MQTT para fora. Um pequeno nó ROS 2 assina topics DDS locais e publica dados selecionados e subamostrados em um broker MQTT. O exemplo abaixo encaminha o estado da bateria de um robô para o 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:  # subamostra para uma mensagem a 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()

Duas decisões de design tornam essa ponte robusta. Ela faz subamostragem, porque topics DDS podem rodar em taxas que não faz sentido enviar por uma WAN. E usa um Last Will retido, para que os dashboards da frota vejam o robô ficar offline mesmo que a ponte trave. Para um experimento rápido sem credenciais, conecte-se à porta 1883 com um client ID único e use um prefixo connectmq/demo/<random-id>/ no servidor MQTT público (gratuito), apenas com dados de teste.

Checklist de Decisão

1. Os componentes precisam trocar dados em milissegundos na mesma máquina ou LAN, com QoS temporal rigoroso? Use DDS ali.
2. Você precisa de dados de muitas unidades, através de NAT ou rede celular, na nuvem? Use MQTT nesse caminho.
3. Seus dispositivos são microcontroladores, PLCs ou gateways comerciais? Muito provavelmente eles falam MQTT.
4. Você está construindo sobre o ROS 2? Mantenha o DDS no robô e faça a ponte de topics selecionados para MQTT.
5. Você precisa de um Unified Namespace ou de Sparkplug B? Isso é ecossistema MQTT.
6. Você quer um único lugar para autenticar, monitorar e limitar clients? Esse é o trabalho de um broker.

Onde um Broker MQTT na Nuvem se Encaixa

Quando o mundo DDS precisa conversar com dashboards, historiadores, gêmeos digitais, apps móveis e outras unidades, um broker MQTT na nuvem é o ponto de encontro prático. O ConnectMQ oferece MQTT 3.1.1 e 5.0 sobre TLS, detecta topics ISA-95 e de Unified Namespace, decodifica Sparkplug B e mostra os dispositivos por nível ISA-95 em seu portal. Ele não fala DDS, então um nó de ponte como o mostrado acima é o caminho de integração honesto. Para mais contexto industrial, leia o guia de IoT industrial com MQTT e, para o básico do protocolo, o tutorial de MQTT.

Comece com o ConnectMQ

Mantenha o DDS onde o determinismo importa e envie a um broker MQTT gerenciado os dados de que o resto da empresa precisa. Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, rode seu nó de ponte e veja os topics aparecerem no explorador ao vivo.

Perguntas frequentes

O DDS é mais rápido que o MQTT?

Em uma rede local, o DDS geralmente tem latência menor porque os dados vão diretamente do writer para o reader, sem passar por um broker. Em links WAN e pela internet essa vantagem diminui, e o MQTT é mais fácil de rotear.

O DDS funciona pela internet?

Não facilmente por conta própria, já que a descoberta depende de multicast local e de endereçamento direto entre pares. Existem serviços de roteamento e relays, mas a maioria das equipes prefere fazer a ponte de dados selecionados para MQTT.

O ROS 2 suporta MQTT?

O ROS 2 usa DDS por padrão. Você pode conectá-lo ao MQTT com um nó de ponte, seja um pacote da comunidade ou um pequeno nó personalizado como o exemplo deste artigo.

Devo usar DDS ou MQTT para IIoT?

Para telemetria da planta até a nuvem, dados de supervisão e arquiteturas de Unified Namespace, o MQTT costuma ser a melhor opção. O DDS é adequado para controle em tempo real dentro de máquinas e células.