MQTT vs DDS : messagerie avec ou sans broker

La question MQTT vs DDS se pose dans les projets de robotique, d'automobile et d'automatisation industrielle, où certains systèmes exigent un déterminisme de l'ordre de la microseconde sur un réseau local tandis que d'autres doivent remonter les données de nombreux sites vers le cloud. Les deux reposent sur le publish/subscribe, mais MQTT s'appuie sur un broker central alors que DDS laisse les participants se découvrir et échanger directement. Ce guide compare les architectures, les garanties temps réel et les déploiements typiques, et montre quand MQTT avec broker vers un service cloud est le choix pragmatique.

Deux philosophies du publish/subscribe

MQTT fonctionne avec un broker. Chaque client ouvre une connexion vers un broker, publie sur des topics et s'abonne à des filtres de topics, et le broker achemine chaque message. Les clients ne se connaissent pas entre eux. La topologie réseau reste donc simple : les appareils n'ont besoin que d'une connexion sortante vers un point d'accès bien connu, ce qui fonctionne à travers le NAT, les pare-feu et les réseaux cellulaires. Pour un rappel du rôle du broker, consultez ce que fait un broker MQTT.

DDS (Data Distribution Service) est un standard de l'Object Management Group pour un publish/subscribe centré sur les données et sans broker. Les participants d'un domaine DDS se découvrent mutuellement, généralement via multicast UDP sur le réseau local, et échangent directement les données avec le protocole filaire DDSI-RTPS. Les topics sont fortement typés avec une structure de données définie en IDL, et chaque lecteur et rédacteur déclare des politiques de qualité de service que DDS fait correspondre automatiquement. DDS est le middleware sous-jacent de ROS 2 et il est courant dans la défense, l'aérospatiale, les dispositifs médicaux ainsi que dans certains systèmes automobiles et énergétiques.

MQTT vs DDS en un coup d'œil

Aspect	MQTT	DDS
Standard	OASIS MQTT 3.1.1 et 5.0	OMG DDS avec le protocole filaire DDSI-RTPS
Architecture	Broker central	Sans broker, pair-à-pair au sein d'un domaine
Découverte	Aucune ; les clients connaissent l'adresse du broker	Découverte automatique des participants et des endpoints
Transport	TCP, TLS, WebSocket	Surtout UDP (unicast et multicast), aussi mémoire partagée et TCP selon les implémentations
Modèle de données	Chaîne de topic plus payload opaque	Topics typés définis en IDL, instances à clé
QoS	3 niveaux de livraison plus retained et sessions	Nombreuses politiques : fiabilité, durabilité, historique, deadline, liveliness, ownership, etc.
Latence	Faible, mais via un saut par le broker	Très faible, livraison directe entre pairs
Portée réseau	LAN, WAN, Internet, cellulaire	Principalement LAN ; le WAN exige des services de routage
Empreinte	Clients très légers, tourne sur microcontrôleurs	Plus lourde ; des micro-profils existent pour l'embarqué
Sécurité	TLS plus authentification au broker	Plugins DDS Security pour authentification, contrôle d'accès, chiffrement
Terrain de prédilection	Télémétrie IIoT, sites distants, intégration cloud	Robotique, véhicules, systèmes de contrôle temps réel

Architecture : broker ou bus de données

Le broker de MQTT est à la fois une force et un coût. Il vous offre un point unique pour authentifier les clients, appliquer des quotas, voir chaque topic et vous connecter au cloud. Il ajoute aussi un saut réseau et constitue un composant qui doit rester disponible. Un broker MQTT managé transfère cette charge de disponibilité au fournisseur.

DDS supprime ce saut intermédiaire. Les rédacteurs envoient directement aux lecteurs correspondants, ce qui réduit la latence et évite une dépendance centrale sur le réseau local. Le prix à payer est la complexité : le trafic de découverte croît avec le nombre de participants et d'endpoints, le multicast doit être autorisé sur le réseau, et traverser des sous-réseaux, du NAT ou Internet nécessite des services de routage supplémentaires. DDS excelle à l'intérieur d'un robot, d'un véhicule ou d'une cellule ; il devient malcommode sur des centaines de sites distants.

Garanties temps réel et QoS

La QoS de DDS est bien plus riche que celle de MQTT. Un rédacteur DDS peut déclarer qu'il met à jour un topic au moins toutes les 10 millisecondes (deadline), que les retardataires doivent recevoir les N derniers échantillons (durabilité et historique), qu'un lecteur doit être averti si un rédacteur se tait (liveliness), ou que seul le rédacteur de plus forte priorité doit être entendu (ownership, utile pour les capteurs redondants). DDS associe les lecteurs et rédacteurs compatibles et signale les incompatibilités. Combiné aux transports UDP et mémoire partagée, cela fait de DDS un bon choix pour les boucles de contrôle et la fusion de capteurs.

MQTT reste plus simple. Les QoS 0, 1 et 2 définissent les garanties de livraison, les retained messages donnent la dernière valeur aux retardataires, les sessions persistantes mettent en tampon pour les abonnés hors ligne et le Last Will signale les déconnexions brutales. MQTT 5 ajoute l'expiration des messages, ce qui aide à écarter les commandes périmées. Ce sont les fonctionnalités dont la plupart des applications de télémétrie et de supervision ont réellement besoin. Pour un rappel, consultez les niveaux de QoS MQTT expliqués.

Aucun des deux protocoles ne rend à lui seul un système temps réel dur. Le déterminisme dépend aussi du système d'exploitation, du réseau et du matériel. Mais DDS vous donne le vocabulaire pour spécifier le comportement temporel, ce que MQTT ne cherche pas à faire.

Robotique vs IIoT

En robotique, ROS 2 a fait de DDS la norme par défaut. Les nœuds d'un même robot ou d'un même réseau local s'échangent données de capteurs, transformations et commandes avec une faible latence, et la découverte permet de démarrer les nœuds dans n'importe quel ordre. C'est DDS qui fait exactement ce pour quoi il a été conçu.

Dans l'IoT industriel, les exigences sont différentes. Les données doivent circuler depuis les PLC, machines et passerelles de nombreuses usines vers les systèmes de supervision, les historians et les applications cloud, à travers des pare-feu et des liaisons WAN. Les intégrateurs attendent un Unified Namespace organisé selon les niveaux ISA-95, et beaucoup d'appareils parlent déjà MQTT ou Sparkplug B. Ici, le broker est un atout, car il donne à chaque site une seule connexion sortante et un seul endroit où chercher les données. Le guide MQTT Sparkplug B et Unified Namespace explique ce modèle.

Relier DDS à MQTT : un exemple ROS 2

Le modèle courant consiste à garder DDS dans la machine et MQTT vers l'extérieur. Un petit nœud ROS 2 s'abonne aux topics DDS locaux et publie une sélection de données sous-échantillonnées vers un broker MQTT. L'exemple ci-dessous transmet l'état de la batterie d'un robot vers 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:  # sous-échantillonnage : un message toutes les 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()

Deux choix de conception rendent ce pont robuste. Il sous-échantillonne, car les topics DDS peuvent tourner à des fréquences qu'il serait absurde d'envoyer sur un WAN. Et il utilise un Last Will retained, afin que les tableaux de bord de la flotte voient le robot passer hors ligne même si le pont plante. Pour une expérience rapide sans identifiants, connectez-vous au port 1883 avec un client ID unique et utilisez un préfixe connectmq/demo/<random-id>/ sur le serveur MQTT public gratuit, réservé aux tests et aux prototypes.

Check-list de décision

Des composants doivent-ils échanger des données en quelques millisecondes sur la même machine ou le même LAN, avec une QoS temporelle stricte ? Utilisez DDS à cet endroit.
Avez-vous besoin de remonter vers le cloud les données de nombreux sites, à travers du NAT ou du cellulaire ? Utilisez MQTT pour ce chemin.
Vos appareils sont-ils des microcontrôleurs, des PLC ou des passerelles du commerce ? Ils parlent très probablement MQTT.
Construisez-vous sur ROS 2 ? Gardez DDS sur le robot et relayez une sélection de topics vers MQTT.
Avez-vous besoin d'un Unified Namespace ou de Sparkplug B ? Cela relève de l'écosystème MQTT.
Voulez-vous un point unique pour authentifier, surveiller et limiter les clients ? C'est le rôle d'un broker.

La place d'un broker MQTT cloud

Lorsque le monde DDS doit communiquer avec des tableaux de bord, des historians, des applications mobiles et d'autres sites, un broker MQTT cloud est le point de rencontre pragmatique. ConnectMQ propose MQTT 3.1.1 et 5.0 sur TLS, détecte les topics ISA-95 et Unified Namespace, décode Sparkplug B et affiche les appareils par niveau ISA-95 dans son portail. Il ne parle pas DDS lui-même : un nœud de pont comme celui ci-dessus est donc la voie d'intégration honnête. Pour un contexte industriel plus approfondi, lisez le guide IoT industriel avec MQTT, et pour les bases du protocole, le tutoriel MQTT.

Démarrer avec ConnectMQ

Gardez DDS là où le déterminisme compte et envoyez vers un broker MQTT managé les données dont le reste de l'entreprise a besoin. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, lancez votre nœud de pont et regardez les topics apparaître dans l'explorateur en direct.

Questions fréquentes

DDS est-il plus rapide que MQTT ?

Sur un réseau local, DDS a généralement une latence plus faible, car les données vont directement du rédacteur au lecteur sans passer par un broker. Sur des liaisons WAN et Internet, cet avantage s'estompe, et MQTT est plus facile à router.

DDS peut-il fonctionner sur Internet ?

Difficilement à lui seul, car la découverte repose sur le multicast local et l'adressage direct des pairs. Des services de routage et des relais existent, mais la plupart des équipes relaient plutôt une sélection de données vers MQTT.

ROS 2 prend-il en charge MQTT ?

ROS 2 utilise DDS par défaut. Vous pouvez le connecter à MQTT avec un nœud de pont, soit un paquet communautaire, soit un petit nœud personnalisé comme l'exemple de cet article.

Faut-il utiliser DDS ou MQTT pour l'IIoT ?

Pour la télémétrie de l'usine vers le cloud, les données de supervision et les architectures Unified Namespace, MQTT est généralement le meilleur choix. DDS convient au contrôle temps réel à l'intérieur des machines et des cellules.

MQTT vs DDS : messagerie industrielle avec ou sans broker