MQTT vs. DDS: Industrielles Messaging mit und ohne Broker

Die Frage MQTT vs. DDS taucht in Robotik-, Automotive-, Maschinenbau- und Automatisierungsprojekten auf, in denen manche Systeme Determinismus im Mikrosekundenbereich im lokalen Netz brauchen und andere Daten von vielen Standorten in die Cloud bringen müssen. Beide arbeiten nach dem Publish/Subscribe-Prinzip, doch MQTT setzt auf einen zentralen Broker, während sich bei DDS die Teilnehmer gegenseitig finden und Daten direkt austauschen. Dieser Leitfaden vergleicht Architekturen, Echtzeitgarantien und typische Einsatzszenarien und zeigt, wo MQTT mit Broker zu einem Cloud-Dienst die praktische Wahl ist.

Zwei Philosophien von Publish/Subscribe

MQTT arbeitet mit Broker. Jeder Client öffnet eine Verbindung zu einem Broker, publiziert auf Topics und abonniert Topic-Filter, und der Broker routet jede Nachricht. Die Clients wissen nichts voneinander. Das macht die Netzwerktopologie einfach: Geräte brauchen nur eine ausgehende Verbindung zu einem bekannten Endpunkt, was durch NAT, Firewalls und Mobilfunknetze funktioniert. Zur Auffrischung der Rolle des Brokers lesen Sie Was ein MQTT-Broker macht.

DDS (Data Distribution Service) ist ein Standard der Object Management Group für datenzentriertes Publish/Subscribe ohne Broker. Teilnehmer einer DDS-Domain finden sich gegenseitig, meist per UDP-Multicast im lokalen Netz, und tauschen Daten direkt über das Wire-Protokoll DDSI-RTPS aus. Topics sind über eine in IDL definierte Datenstruktur stark typisiert, und jeder Reader und Writer deklariert Quality-of-Service-Richtlinien, die DDS automatisch abgleicht. DDS ist die Middleware unter ROS 2 und verbreitet in Verteidigung, Luft- und Raumfahrt, Medizintechnik sowie in einigen Automotive- und Energiesystemen.

MQTT vs. DDS auf einen Blick

Architektur: Broker vs. Datenbus

Der Broker in MQTT ist Stärke und Kostenfaktor zugleich. Er bietet Ihnen einen zentralen Ort, um Clients zu authentifizieren, Kontingente durchzusetzen, jedes Topic zu sehen und die Cloud anzubinden. Gleichzeitig fügt er einen Netzwerk-Hop hinzu und ist eine Komponente, die verfügbar sein muss. Ein verwalteter MQTT-Broker verlagert diese Verfügbarkeitsarbeit zum Anbieter.

DDS entfernt den Hop in der Mitte. Writer senden direkt an passende Reader, was die Latenz senkt und eine zentrale Abhängigkeit im lokalen Netz vermeidet. Der Preis ist Komplexität: Der Discovery-Traffic wächst mit der Zahl der Teilnehmer und Endpunkte, Multicast muss im Netz erlaubt sein, und das Überqueren von Subnetzen, NAT oder dem Internet erfordert zusätzliche Routing-Services. DDS glänzt innerhalb eines Roboters, eines Fahrzeugs oder einer Zelle; über Hunderte entfernter Standorte hinweg wird es umständlich.

Echtzeitgarantien und QoS

DDS-QoS ist weit reichhaltiger als MQTT-QoS. Ein DDS-Writer kann deklarieren, dass er ein Topic mindestens alle 10 Millisekunden aktualisiert (Deadline), dass Nachzügler die letzten N Samples erhalten sollen (Durability und History), dass ein Reader benachrichtigt werden soll, wenn ein Writer verstummt (Liveliness), oder dass nur der Writer mit der höchsten Stärke gehört werden soll (Ownership, nützlich für redundante Sensoren). DDS gleicht kompatible Reader und Writer ab und meldet Inkompatibilitäten. Zusammen mit UDP- und Shared-Memory-Transporten macht das DDS zu einer guten Wahl für Regelkreise und Sensorfusion.

MQTT hält es einfacher. QoS 0, 1 und 2 definieren Zustellgarantien, Retained Messages geben Nachzüglern den letzten Wert, persistente Sessions puffern für Offline-Subscriber und Last Will signalisiert unsaubere Verbindungsabbrüche. MQTT 5 ergänzt Message Expiry, das hilft, veraltete Befehle zu verwerfen. Das sind die Funktionen, die die meisten Telemetrie- und Überwachungsanwendungen tatsächlich brauchen. Zur Auffrischung lesen Sie MQTT-QoS-Stufen erklärt.

Keines der beiden Protokolle macht ein System allein hart echtzeitfähig. Determinismus hängt auch von Betriebssystem, Netzwerk und Hardware ab. DDS gibt Ihnen aber das Vokabular, um Zeitverhalten zu spezifizieren – MQTT versucht das gar nicht erst.

Robotik vs. IIoT

In der Robotik hat ROS 2 DDS zum Standard gemacht. Nodes auf demselben Roboter oder im lokalen Netz publizieren Sensordaten, Transformationen und Befehle mit niedriger Latenz untereinander, und dank Discovery können Sie Nodes in beliebiger Reihenfolge starten. Das ist DDS in genau dem Einsatz, für den es entworfen wurde.

Im industriellen IoT sehen die Anforderungen anders aus. Daten müssen von SPS, Maschinen und Gateways in vielen Werken zu Leitsystemen, Historians und Cloud-Anwendungen fließen, durch Firewalls und über WAN-Strecken. Integratoren erwarten einen Unified Namespace (UNS), in dem die ISA-95-Ausrüstungshierarchie (Enterprise → Site → Area → Line → Cell) zur Topic-Struktur auf dem MQTT-Broker wird, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Viele Geräte sprechen bereits MQTT oder Sparkplug B, und OPC-UA-Server lassen sich über Gateways anbinden. Hier ist ein Broker ein Vorteil, denn er gibt jedem Standort eine ausgehende Verbindung und einen zentralen Ort für die Daten. Der Leitfaden zu MQTT Sparkplug B und Unified Namespace erklärt dieses Modell.

DDS mit MQTT koppeln: ein ROS-2-Beispiel

Das gängige Muster lautet: DDS innerhalb der Maschine, MQTT nach außen. Ein kleiner ROS-2-Node abonniert lokale DDS-Topics und publiziert ausgewählte, ausgedünnte Daten an einen MQTT-Broker. Das folgende Beispiel leitet den Akkuzustand eines Roboters an ConnectMQ weiter.

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:  # auf eine Nachricht pro 5 s ausdünnen
            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()

Zwei Designentscheidungen machen diese Bridge robust. Sie dünnt Daten aus, denn DDS-Topics können mit Raten laufen, deren Übertragung über ein WAN keinen Sinn ergibt. Und sie nutzt einen Retained Last Will, damit Flotten-Dashboards sehen, dass der Roboter offline geht, selbst wenn die Bridge abstürzt. Für ein schnelles Experiment ohne Zugangsdaten verbinden Sie sich auf Port 1883 mit einer eindeutigen Client ID und verwenden ein Präfix connectmq/demo/<random-id>/ auf dem kostenlosen öffentlichen MQTT-Broker, der für Tests und nicht für Produktionsdaten gedacht ist.

Entscheidungs-Checkliste

1. Müssen Komponenten auf derselben Maschine oder im selben LAN Daten im Millisekundenbereich mit strikten Timing-QoS austauschen? Dort DDS verwenden.
2. Brauchen Sie Daten von vielen Standorten, über NAT oder Mobilfunk, in der Cloud? Für diesen Pfad MQTT verwenden.
3. Sind Ihre Geräte Mikrocontroller, SPS oder kommerzielle Gateways? Sie sprechen höchstwahrscheinlich MQTT.
4. Bauen Sie auf ROS 2? DDS auf dem Roboter belassen und ausgewählte Topics per Bridge an MQTT weitergeben.
5. Brauchen Sie einen Unified Namespace oder Sparkplug B? Das ist das MQTT-Ökosystem.
6. Wollen Sie einen zentralen Ort, um Clients zu authentifizieren, zu überwachen und zu begrenzen? Das ist die Aufgabe eines Brokers.

Wo ein Cloud-MQTT-Broker passt

Wenn die DDS-Welt mit Dashboards, Historians, mobilen Apps und anderen Standorten sprechen muss, ist ein Cloud-MQTT-Broker der praktische Treffpunkt. ConnectMQ bietet MQTT 3.1.1 und 5.0 über TLS, erkennt ISA-95- und UNS-Topics, dekodiert Sparkplug B und zeigt Geräte im Portal nach ISA-95-Ebene an. DDS selbst spricht es nicht, daher ist ein Bridge-Node wie der obige der ehrliche Integrationsweg. Mehr industriellen Kontext bietet der Leitfaden Industrial IoT mit MQTT, die Protokollgrundlagen das MQTT-Tutorial.

Starten Sie mit ConnectMQ

Behalten Sie DDS dort, wo Determinismus zählt, und senden Sie die Daten, die der Rest des Unternehmens braucht, an einen verwalteten MQTT-Broker, idealerweise in Ihren Unified Namespace. Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ganz ohne Kreditkarte, starten Sie Ihren Bridge-Node und sehen Sie zu, wie die Topics im Live-Explorer erscheinen.

Häufig gestellte Fragen

Ist DDS schneller als MQTT?

Im lokalen Netz hat DDS meist eine geringere Latenz, weil Daten ohne Broker-Hop direkt vom Writer zum Reader gehen. Über WAN- und Internetstrecken schwindet dieser Vorteil, und MQTT lässt sich leichter routen.

Funktioniert DDS über das Internet?

Allein nicht ohne Weiteres, da Discovery auf lokalem Multicast und direkter Peer-Adressierung beruht. Es gibt Routing-Services und Relays, die meisten Teams koppeln ausgewählte Daten aber stattdessen an MQTT.

Unterstützt ROS 2 MQTT?

ROS 2 verwendet standardmäßig DDS. Sie können es über einen Bridge-Node mit MQTT verbinden, entweder mit einem Community-Paket oder einem kleinen eigenen Node wie im Beispiel dieses Artikels.

Sollte ich für IIoT DDS oder MQTT verwenden?

Für Telemetrie vom Werk in die Cloud, Überwachungsdaten und Unified-Namespace-Architekturen ist MQTT meist die bessere Wahl. DDS eignet sich für Echtzeitsteuerung innerhalb von Maschinen und Zellen.