MQTT-Protokoll Detailliert: Der Umfassende Leitfaden von den Grundlagen zur Industriellen Anwendung

1. Dez. 2025

26 Min. Lesezeit

Aktualisiert: 12. Okt.

MQTT im Industrienetz: Datenpfad planen und Zustellung prüfen

Eine entfernte Pumpe kann einen Temperaturwert an ein Wartungsdashboard senden, ohne diesem direkten Zugriff auf ihre SPS zu geben. MQTT kann diesen Wert transportieren: Ein Client veröffentlicht eine Nachricht an einen Broker; berechtigte Abonnenten erhalten Nachrichten zu passenden Topics. Das Protokoll definiert weder die Bedeutung des Pumpenwerts noch liest es selbst ein Modbus-Register oder stabilisiert eine Mobilfunkverbindung.

Klären Sie vor den MQTT-Einstellungen Datenquelle, Publisher, Broker, Abonnenten und die Entscheidung, die aus dem Wert folgt. Die MQTT-5.0-Spezifikation beschreibt das Protokollverhalten. Gerätefunktionen und die Bedeutung der Nutzdaten müssen im Projekt gesondert geprüft werden.

Einleitung

MQTT (Message Queuing Telemetry Transport) ist ein binäres Anwendungsprotokoll für die Nachrichtenübermittlung zwischen Clients über einen Broker. Dieser Leitfaden erklärt Zweck, Nachrichtenfluss, Topics, Zustellsemantik, Sitzungen, MQTT 5.0, Sicherheit und Cliententwicklung. Ein Datenpfad von einem Pumpenwert über Steuerung, Gateway und Broker bis zum Dashboard dient als durchgehendes Beispiel neben den historischen Einsatzfeldern. Tabellen und Code veranschaulichen Entscheidungen; Broker-, Bibliotheks-, Firmware- und Netzwerkeigenschaften müssen für die konkrete Installation geprüft werden.

MQTT 3.1.1 und MQTT 5.0 sind unterschiedliche Protokollversionen mit abweichenden Funktionen und Diagnosemöglichkeiten. Die OASIS-Standards beschreiben ihr Verhalten; ob ein Broker und seine Clients eine bestimmte Funktion unterstützen, muss anhand der jeweiligen Version geprüft werden. MQTT 5.0 kann beispielsweise zusätzliche Angaben zu einer Ablehnung oder Ablaufzeit transportieren. Ein Versionswechsel belegt weder eine bestimmte weltweite Verbreitung noch einen automatischen Vorteil für Edge-AI- oder 5G-Projekte.

Was ist das MQTT-Protokoll?

MQTT entstand Ende der 1990er Jahre für Telemetrie und ist heute ein binäres Client-Broker-Protokoll. Ein Client veröffentlicht eine Nachricht unter einem konkreten Topic; der Broker ordnet sie passenden und berechtigten Abonnements zu. MQTT benötigt eine geordnete, verlustfrei arbeitende bidirektionale Verbindung; häufig wird dafür TCP/IP verwendet, optional mit TLS. Mobilfunk oder Satellit bilden den Zugang zum IP-Netz und sind keine MQTT-Übertragungsverfahren an sich; MQTT-SN ist ein separates Protokoll für Sensor-Netzwerke. Der feste MQTT-Header enthält ein Steuerbyte und die variabel codierte Remaining Length. Paketgröße und zusätzlicher Aufwand hängen unter anderem von Pakettyp, Version, Topic, Eigenschaften und Nutzlast ab; eine allgemeingültige Bytezahl oder ein pauschaler Vergleich mit HTTP ist daher nicht belastbar.

Die Design-Philosophie und Schlüsseleigenschaften von MQTT

MQTT entkoppelt Sender und Empfänger und bietet klar abgegrenzte Mechanismen für Zustellung, Sitzungszustand und Transportabsicherung. Jeder Mechanismus löst einen bestimmten Teil der Kommunikationsaufgabe:

Publish/Subscribe: Publisher senden an konkrete Topic-Namen; Subscriber abonnieren Topic-Filter. Beide Seiten müssen keine direkte Verbindung zueinander unterhalten.
QoS: Die Stufen 0, 1 und 2 definieren unterschiedliche MQTT-Zustellabläufe. Sie bestätigen nicht, dass eine nachgelagerte Anwendung, ein Dashboard oder eine SPS eine Aktion genau einmal ausgeführt hat.
Sitzungen: Je nach Protokollversion und Konfiguration können Abonnements und ausstehender QoS-Zustand über eine Wiederverbindung erhalten bleiben. Ablaufzeit, Broker-Speicher und Produktlimits gelten weiterhin.
TLS: Eine unterstützte und korrekt konfigurierte TLS-Verbindung kann den Transport zwischen Client und Broker schützen. Vertrauenskette und Peer-/Hostname müssen geprüft werden; das ist weder automatisch Ende-zu-Ende-Verschlüsselung noch Anwendungsberechtigung.

MQTT verwendet üblicherweise eine länger bestehende, geordnete Verbindung; CoAP basiert im Grundmodell auf Datagrammen. MQTT 3.1 ist eine ältere Version, MQTT 3.1.1 wurde 2014 als OASIS-Standard veröffentlicht und MQTT 5.0 im Jahr 2019. MQTT 5.0 ergänzt unter anderem Eigenschaften, differenziertere Reason Codes und Sitzungssteuerung. Diese Funktionen können Diagnose und Konfiguration unterstützen, versprechen jedoch keine feste Verbesserung von Zuverlässigkeit oder Entwicklungsaufwand.

Warum MQTT für IoT/IIoT nützlich ist

Ein kompaktes Nachrichtenmodell kann nützlich sein, wenn ein Gerät Messwerte oder Ereignisse über eine begrenzte Verbindung überträgt. Der tatsächliche Speicherbedarf umfasst Clientbibliothek, Laufzeit, TLS-Puffer, Warteschlangen und Anwendung. In einem veranschaulichenden Smart-City-Szenario könnten Straßenlaternen ihren Status veröffentlichen und separat berechtigte Wartungsbefehle empfangen. Datenvolumen, Speicher, Verfügbarkeit und Verhalten von Steuerbefehlen müssen für die konkrete Installation gemessen und abgesichert werden; MQTT belegt keine bestimmte Knotenzahl oder Einsparung gegenüber HTTP-Abfragen.

Grundprinzipien und Arbeitsablauf von MQTT

Der MQTT-Ablauf ist ereignisgesteuert: Ein Publisher veröffentlicht eine Application Message unter einem konkreten Topic; ein Subscriber meldet Topic-Filter an. Der Broker ordnet passende Veröffentlichungen gemäß Abonnement, Berechtigung und QoS zu. Retained-Nachrichten, Sitzungszustand und Warteschlangen sind zusätzliche Funktionen bzw. Konfigurationsentscheidungen und keine pauschale Folge jedes Routings. Das Muster entkoppelt Sender und Empfänger; eine Anfrage-Antwort-Interaktion kann bei Bedarf auf Anwendungsebene ergänzt werden.

Publish/Subscribe-Modell und MQTT-Nachrichtenfluss

Entscheidend ist die Trennung zwischen dem konkreten Topic einer Veröffentlichung und den Topic-Filtern in Abonnements. Der Broker übernimmt Zuordnung und Zustellung gemäß Protokoll, Berechtigungen und Konfiguration; eine bestimmte Warteschlange, Baumstruktur oder Matching-Implementierung schreibt MQTT nicht vor. Der Ablauf lässt sich in diesen Schritten nachvollziehen:

Veröffentlichen: Der Client sendet ein PUBLISH-Paket mit Topic, Nutzlast, QoS und gegebenenfalls gesetztem Retain-Flag. Das veröffentlichte Topic ist ein konkreter Name, kein Wildcard-Filter.
Zuordnen: Der Broker vergleicht das Topic mit den passenden Abonnementfiltern und prüft seine Regeln. Datenstruktur und Laufzeitverhalten sind brokerabhängig.
Abonnieren: Ein Client sendet SUBSCRIBE mit einem oder mehreren Filtern und den jeweils angeforderten QoS-Stufen.
Zustellen: Der Broker liefert passende Nachrichten gemäß QoS und Sitzungsregeln aus. MQTT 5.0 Shared Subscriptions können Empfängergruppen unterstützen; Verteilung und Planungsverhalten hängen vom Broker ab.

Ein Publisher kann eine Veröffentlichung an mehrere passende Subscriber verteilen lassen; die tatsächliche Zahl und Last hängen von Broker, Berechtigungen und Installation ab. Der Broker ist ein zentraler Routingdienst und muss daher für die gewünschte Verfügbarkeit ausgelegt werden. Als anschauliches Beispiel kann eine Motorsteuerung Fahrzeug- oder Motordaten wie Drehzahl veröffentlichen, die ein Dashboard und ein Analysedienst getrennt abonnieren. Das Beispiel beschreibt ein mögliches Design, keine gemessene Synchronisationszeit oder garantierte Verteilungskapazität.

Einen Datenpunkt durch den Broker verfolgen

Angenommen, ein Gateway liest die Pumpentemperatur aus einem dokumentierten SPS-Register. Es versieht den Wert mit Zeitstempel und Qualitätsprüfung und veröffentlicht ihn unter site1/pump01/telemetry/temperature. Ein Überwachungsdienst abonniert dieses Topic. Der Leitfaden zu Sensoren, SPS und Modbus erklärt, warum ein Protokoll-Gateway die Registerbelegung kennen muss. Ein Router, der nur IP-Pakete weiterleitet, wandelt Modbus nicht automatisch in MQTT um.

Paket- und Abonnementweg verfolgen

Der Publisher verbindet sich mit Client-ID und ausgehandelten Einstellungen zum Broker und sendet PUBLISH an ein Topic. Ein Subscriber verbindet sich getrennt und meldet mit SUBSCRIBE einen oder mehrere Filter an; der Broker ordnet Nachrichten zu und leitet sie gemäß Berechtigung und QoS weiter. Er erzeugt keinen SPS-Wert. Erfassen Sie beim Pumpenbeispiel Quellregister, Payload-Umsetzung und Client-Identität sowie Ziel-Topic. Bleibt die Anzeige leer, prüfen Sie nacheinander Lesen, Publizieren, Annahme durch den Broker und passenden Filter.

Wenn der Router die Daten selbst erfasst und veröffentlicht, nutzen Sie bei ausbleibenden neuen Nachrichten die Diagnose des Veröffentlichungsauftrags.

Ein durchgehendes Pumpenbeispiel trennt Wertaufnahme und Übersetzung in SPS bzw. Gateway vom anschließenden Topic-Routing durch den MQTT-Broker.

Detaillierte MQTT-Paketstruktur

MQTT-Control-Packages bestehen je nach Typ aus festem Header, variablem Header und gegebenenfalls Nutzlast. Der feste Header beginnt mit einem Steuerbyte und enthält eine variabel codierte Remaining Length; der variable Header kann beispielsweise Topic, Packet Identifier oder MQTT-5.0-Eigenschaften enthalten. CONNECT, PUBLISH und PINGREQ haben unterschiedliche Felder. Paketlänge und Overhead ergeben sich aus Version, Pakettyp, Topic, Eigenschaften und Nutzlast; eine feste Zwei-Byte-Gesamtgröße gilt nicht für jedes Paket.

MQTT 3.1, 3.1.1, 5.0: Versionsunterschiede und Migrationsleitfaden

MQTT 3.1, 3.1.1 und 5.0 unterscheiden sich in Protokollfunktionen und Sitzungssteuerung. Die Tabelle fasst Versionseinordnung, Kernfunktionen, Änderungen und zu prüfende Migrationspunkte zusammen:

Version	Zeitliche Einordnung	Kernfunktionen	Abgrenzung zur Vorgängerversion	Migrationshinweise
3.1	Ältere, vor MQTT 3.1.1 veröffentlichte Version	Publish/Subscribe und QoS 0–2	Historische Protokollfassung; keine MQTT-5.0-Eigenschaften	Kompatibilität der konkreten Client- und Broker-Version prüfen.
3.1.1	OASIS-Standard von 2014	Publish/Subscribe, QoS 0–2, Clean Session und Will	Standardisierte Details; MQTT-SN bleibt ein separates Protokoll	Versionen und Verhalten von Clean Session, TLS und Will im Zielsystem prüfen.
5.0	OASIS-Standard von 2019	User Properties, Reason Codes, Topic Alias, Shared Subscriptions und Ablaufzeiten	Ergänzt Eigenschaften und Diagnose; konkrete Unterstützung hängt von Client und Broker ab	Kompatibilität, Session Expiry, Reason Codes und Rückwärtsbetrieb schrittweise testen.

Ein Wechsel von MQTT 3.1.1 auf 5.0 sollte von den tatsächlich benötigten Funktionen ausgehen. Prüfe zuerst Client- und Brokerunterstützung, Topics, Authentifizierung sowie gewünschtes Sitzungs- und Nachrichtenablaufverhalten. Teste anschließend die Versionen und Reason Codes im Zielsystem. MQTT 3.1.1 bleibt eine standardisierte Option; MQTT 5.0 ist nicht allein wegen zusätzlicher Funktionen für jedes Projekt vorzuziehen.

Anwendungsszenarien von MQTT im IoT (Detaillierte Integration von Modbus/MQTT/OPC UA)

Ein Gateway oder eine Anwendung kann MQTT als Nachrichtenweg zwischen vorhandenen Systemen und einem Broker einsetzen. Das Gateway muss die jeweilige Feldschnittstelle tatsächlich auslesen, Werte interpretieren und bei Bedarf abbilden; MQTT-Routing allein übernimmt keine Modbus- oder OPC-UA-Datenerfassung.

Modbus/MQTT: Ein Gateway oder eine Erfassungsanwendung liest Modbus-RTU-Register und kann ausgewählte Werte einem Topic wie plc/holding/001 zuordnen. Abfrage, Datentypen und JSON-Abbildung sind Teil dieser Integration. Ein Windpark kann als anschauliches Beispiel Turbinendaten über ein Gateway an einen MQTT-Broker weitergeben; eine bestimmte Latenz ist damit nicht belegt.
OPC UA/MQTT: Eine konfigurierte OPC-UA-PubSub-Installation kann MQTT als Transport bzw. Brokeranbindung verwenden. Zertifikate und Sicherheitsregeln müssen in den beteiligten Komponenten abgestimmt werden; MES-Anbindung ist ein mögliches Integrationsszenario.
Edge und eingeschränkte Netze: MQTT-SN ist ein separates Sensor-Network-Protokoll mit eigenen Topic- und Transportkonzepten. Kurze Topic-IDs können dort Protokollfelder beeinflussen; sie sind keine automatische MQTT-Komprimierung oder pauschale Funkersparnis.

Detailliertes Verständnis der MQTT-Protokollarchitektur

In einer üblichen MQTT-Architektur verbinden sich Clients mit einem Broker über ein geordnetes Transportprotokoll, häufig TCP/IP. Port 1883 wird oft für MQTT ohne TLS und 8883 für MQTT über TLS verwendet; Broker können Listener und Ports anders konfigurieren. Die Schichten lassen sich als MQTT-Anwendungsprotokoll, Transport und IP-Netz beschreiben. TLS schützt den Transport nur, wenn Vertrauenskette und Servername geprüft werden.

Interne Implementierung des Publish/Subscribe-Modells

Der Broker gleicht veröffentlichte Topics mit passenden Abonnementfiltern ab und verwaltet die zugehörige Zustellung. Ein Topic-Baum, eine Hash-Tabelle oder eine andere Datenstruktur kann Teil einer konkreten Brokerimplementierung sein, wird vom MQTT-Standard aber nicht vorgeschrieben. Durchsatz und Skalierung müssen mit dem gewählten Broker, Topic-Muster, QoS und Nachrichtentakt gemessen werden.

Die Rolle, Typen und Hochverfügbarkeits-Design des Brokers

Ein Broker kann je nach Produkt und Konfiguration unter anderem folgende Aufgaben übernehmen:

Routing: Veröffentlichungen passenden und berechtigten Abonnements zuordnen und den QoS-Ablauf für die jeweilige Verbindung verwalten.
Sitzungs- und Nachrichtenzustand: Abonnements oder ausstehende Nachrichten gemäß Protokollversion, Ablaufzeit, Speicherregeln und Brokerlimits halten. Speicher kann flüchtig, persistent oder über unterstützte Integrationen organisiert sein; Redis ist keine MQTT-Vorgabe.
Erweiterungen: Plugins oder Regel-Engines können zum Beispiel Alarmfilter ergänzen, sofern das Brokerprodukt sie bereitstellt und die Regeln korrekt konfiguriert sind.

Typen:

Open-Source-Broker: Für einzelne Installationen und Tests geeignet; Funktionsumfang, Skalierung und Betriebsaufwand unterscheiden sich je Projekt.
Kommerzielle oder verwaltete Angebote: Können Cluster, Failover oder Sitzungsübertragung bereitstellen. Verfügbarkeit und Sitzungsmigration sind Produkt-, Tarif- und Konfigurationseigenschaften, keine MQTT-Garantie.

Hochverfügbarkeit kann beispielsweise mit Aktiv/Passiv, Load Balancern oder Edge-Brokern mit einer Cloud-Anbindung entworfen werden. Ob Sitzungen beim Wechsel erhalten bleiben, ob Clientverbindungen Affinität benötigen und wie ein Failover abläuft, hängt vom Brokerprodukt und seiner Konfiguration ab. Das Design muss mit den tatsächlichen Wiederverbindungs- und Datenverlustzielen getestet werden.

Struktur, Regeln und Best Practices von Topics

Ein Topic-Name ist eine UTF-8-Zeichenfolge; Topic-Ebenen werden üblicherweise mit / getrennt. Der Standard setzt eine maximale codierte Topic-Länge, während Broker, Produkt und Anwendung zusätzliche praktische Grenzen haben können. Topic-Namen für Veröffentlichungen sind von Topic-Filtern für Abonnements zu unterscheiden. Nützliche Regeln sind:

$SYS/ ist ein verbreitetes Präfix für Brokerstatus-Topics, aber kein allgemeiner Bestandteil der Anwendungs-Topics; Verfügbarkeit und Inhalte hängen vom Broker ab.
Im Abonnementfilter steht + für genau eine Ebene und # für mehrere nachfolgende Ebenen, zum Beispiel home/+/temp oder home/#. Details zu $-Topics und Filtern sind in der eingesetzten Version zu prüfen.
Wildcards gehören in Abonnementfilter, nicht in den Topic-Namen einer PUBLISH-Nachricht.

Eine nachvollziehbare Hierarchie kann Funktion, Standort, Anlage, Gerät und Messgröße verbinden, zum Beispiel telemetry/site1/line2/sensor3/temp. Wähle die Ebenen passend zu Abonnements und Berechtigungen; eine allgemeine Grenze von 100 Zeichen gibt es nicht als Gestaltungsregel. Ein Lagerbestand wie inventory/warehouseA/shelfB/itemC/stock kann als Beispiel dienen. Dokumentiere Topic-Eigentümer und ACLs, damit ein Filter nur den beabsichtigten Datenbereich freigibt.

Ordnen Sie Topics nach Standort, Anlage, Nachrichtenzweck und Verantwortlichkeit. Trennen Sie Messwerte und Befehle, etwa mit site1/pump01/telemetry/... und site1/pump01/command/.... Ein Topic ist eine Zeichenfolge zur Weiterleitung, weder Datenschema noch Berechtigungsregel. Dokumentieren Sie Felder, Einheiten, Zeitstempelquelle, Qualitätskennzeichen und Versionen gesondert. Für fehlende oder veraltete Werte braucht der Empfänger eine klare Regel.

Topic-Filter und Rechte gemeinsam entwerfen

Ein Topic besteht aus durch Schrägstriche getrennten Ebenen. Subscriber können + für eine oder # für die restlichen Ebenen nutzen; Publisher senden an ein konkretes Topic ohne Wildcard. Verwenden Sie konsistente Standort- und Anlagenkennungen und keine Geheimnisse im Namen. Legen Sie ACLs je Rolle fest: Telemetrie-Publisher, Dashboard-Subscriber und getrennte Befehls-Publisher. Testen Sie erlaubte und bewusst gesperrte Filter. Ein breites site/# kann mehr Geräte offenlegen, als der Bediener benötigt.

Erklärung der QoS-Level (Mechanismen, Leistung und Auswahlleitfaden)

QoS beschreibt die Zustellsemantik zwischen MQTT-Teilnehmern. Für eine Weiterleitung berücksichtigt der Broker Veröffentlichungs-QoS und das angeforderte Abonnement-QoS. Die Stufen beeinflussen Bestätigungen und möglichen Zustand, bestätigen aber nicht, dass eine angeschlossene SPS oder Geschäftslogik den Wert verarbeitet oder eine Aktion ausgeführt hat. Die folgenden Abläufe zeigen den Protokollunterschied:

QoS	Zustellsemantik	MQTT-Protokollablauf	Protokollaufwand (qualitativ)	Typischer Einsatz und Grenze
0	Höchstens einmal; keine erneute Zustellbestätigung	PUBLISH, keine QoS-Bestätigung	Geringer Bestätigungs- und Zustandsaufwand	Für geeignete Telemetrie; eine Nachricht kann verloren gehen.
1	Mindestens einmal; doppelte Zustellung ist möglich	PUBLISH → PUBACK	Zusätzlicher Bestätigungsablauf	Für Status- oder Ereignisnachrichten; Empfänger sollten Duplikate bei Bedarf erkennen.
2	Einmalige MQTT-Zustellung innerhalb des QoS-2-Ablaufs	PUBLISH → PUBREC → PUBREL → PUBCOMP	Mehr Bestätigungsschritte und Zustand als QoS 0/1	Für passende Nachrichten, wenn die Protokollsemantik benötigt wird; bestätigt keine einmalige SPS- oder Geschäftshandlung.

QoS 1 kann ein sinnvoller Ausgangspunkt für Nachrichten sein, bei denen eine erneute Zustellung verarbeitet werden kann; es gibt jedoch keinen universellen Standardwert für alle Anwendungen. Setze QoS 2 nur ein, wenn sein zusätzlicher Protokollablauf erforderlich ist. Prüfe Wiederholungen, Duplikatbehandlung, Nachrichtentyp und End-to-End-Verarbeitung im Zielsystem; QoS 2 beseitigt weder Netzwerkverluste noch Anwendungsfehler.

QoS nach Folgen von Verlust und Duplikaten wählen

MQTT bietet QoS 0, 1 und 2. QoS 0 sendet einmal ohne protokollseitige Bestätigung. QoS 1 bestätigt die Zustellung protokollseitig, kann aber ein Duplikat liefern. QoS 2 nutzt einen vierstufigen Austausch, um Duplikate innerhalb dieses MQTT-Austauschs zu vermeiden. Keine dieser Stufen beweist, dass eine nachgelagerte Anwendung eine Nachricht genau einmal verarbeitet oder dass eine SPS-Aktion gelungen ist.

Anwendung	Ausgangsfrage	Prüfung in der Anwendung
Häufige Messwerte	Kann der nächste Wert einen verpassten ersetzen?	Lücken und veraltete Zeitstempel erkennen
Alarm oder Ereignis	Sind Wiederholungen nötig und Duplikate beherrschbar?	Ereignis-ID vergeben und Verarbeitung prüfen
Steueranforderung	Ist MQTT als Steuerpfad an diesem Standort freigegeben?	Absender berechtigen, alte Aufträge ablehnen und Geräteergebnis bestätigen

QoS 2 ist keine universelle Sicherheitseinstellung. Es benötigt mehr Austausch und Zustand; Wiederholungen, Sitzungseinstellungen und Anwendungsverarbeitung bleiben wichtig.

Halten Sie die QoS-Wahl pro Nachrichtentyp fest und testen Sie sie über den tatsächlichen Mobilfunkpfad.

Bestätigungen an der richtigen Grenze verstehen

Bei QoS 1 bestätigt PUBACK einen MQTT-Schritt; Wiederholung kann Duplikate erzeugen. QoS 2 verwendet einen mehrstufigen Austausch für genau einmalige Zustellung innerhalb dieses Protokollaustauschs, braucht aber mehr Zustand und Pakete. Keine Bestätigung belegt, dass Anzeige oder SPS-Aktion abgeschlossen ist. Wenn wiederholte Verarbeitung Folgen hat, braucht die Anwendung Nachrichten-ID und Deduplizierung. Entscheiden Sie für Telemetrie, ob Verlust, Duplikat oder verspäteter Rückstau schädlicher ist, und testen Sie bei unterbrochenem Mobilfunk.

Sitzungsverwaltung (Persistierung und Lebenszyklussteuerung)

Eine MQTT-Sitzung wird über CONNECT und CONNACK ausgehandelt. Ob Zustand über eine Verbindung hinaus bestehen bleibt, hängt von Protokollversion, Clean-Session-/Clean-Start-Einstellungen, Ablaufzeiten, Brokerverhalten und verfügbaren Ressourcen ab.

MQTT 3.1.1 Clean Session: Der Wert false kann eine vorhandene Sitzung mit Abonnements und ausstehenden QoS-Nachrichten fortsetzen, sofern Broker und Client sie speichern. MQTT 5.0 trennt Clean Start von Session Expiry Interval; die Ablaufzeit bestimmt, wie lange die Sitzung erhalten bleibt.
Keep Alive: Der Client legt im CONNECT-Paket das Intervall fest. Fehlen Steuerpakete länger als die im Standard beschriebene Grenze, kann der Broker die Verbindung schließen. Ein Bereich von 20 bis 1200 Sekunden gilt nicht allgemein für alle Broker und Clients.
MQTT 5.0 unterscheidet Session Expiry von Message Expiry. Die Sitzungsdauer und die Ablaufzeit einer einzelnen Nachricht steuern verschiedene Zustände.

Offline-Warteschlangen sollten nach Speicher, Nachrichtentyp und Ablaufzeit des konkreten Brokers geplant und überwacht werden; eine universelle Obergrenze von 1000 Nachrichten gibt es nicht. Bei einem Drohnenschwarm oder anderen zeitweise getrennten Geräten kann eine passend konfigurierte Sitzung ausgewählte Abonnements und QoS-Nachrichten erhalten. Wiederverbindung und Aufarbeitung hängen von Funkverbindung, Client, Ablaufzeit und Brokerressourcen ab und sind nicht auf eine feste Wiederherstellungszeit garantiert.

MQTT 5.0 bietet Einstellungen für Sitzungs- und Nachrichtenablauf. Ihre Wirkung hängt von Client, Broker und Abonnement ab. Prüfen Sie, was während eines Standortausfalls in der Warteschlange bleibt und bei Wiederverbindung ankommt. Legen Sie fest, wie Empfänger späte Nachrichten, Duplikate und Reihenfolge behandeln. Bei einem sich ändernden Prozesswert kann ein alter Rückstau weniger nützlich sein als eine neue Messung.

Sitzungslebenszyklus bewusst festlegen

Client-ID, Clean Start und Session Expiry bestimmen, ob Abonnement und offener QoS-Zustand nach Wiederverbindung erhalten bleiben können. Eine persistente Sitzung bedeutet keinen unbegrenzten Offline-Speicher: Broker-Regeln, Quoten und Nachrichtenablauf gelten weiter. Legen Sie fest, wie lange eine ausgefallene Pumpe Daten sammeln soll und ob der Empfänger alle Proben oder nur einen frischen Wert braucht. Prüfen Sie kurze und längere Unterbrechungen sowie gegebenenfalls einen Broker-Neustart und notieren Sie reale Warteschlangengrenzen.

Anwendung und Bereinigung von Retained Messages

Mit gesetztem Retain-Flag kann der Broker die letzte retained Veröffentlichung für ein Topic speichern und an passende neue Abonnements ausliefern. Der gespeicherte Wert ist nicht automatisch aktuell; Empfänger sollten Zeitstempel, Sequenz oder Heartbeat prüfen. Zum Löschen wird eine retained PUBLISH-Nachricht mit leerer Nutzlast gesendet. MQTT 5.0 Retain Handling steuert die Zustellung gespeicherter Nachrichten bei einem Abonnement und löscht sie nicht. Speicherverhalten und Grenzen hängen vom Broker ab.

Retained Messages, Sitzungen und Unterbrechungen behandeln

Eine als retained veröffentlichte Nachricht bleibt als letzte solche Nachricht zum Topic im Broker und kann neuen Abonnenten zugestellt werden. Für manche Zustandsanzeigen ist das nützlich, doch der Wert kann alt sein. Ergänzen Sie Zeitstempel und Gültigkeitsregel; ein retained Befehl darf nicht als neue Anweisung gelten. Eine Last-Will-Nachricht kann einen unerwarteten Verbindungsabbruch melden, beweist aber keinen Ausfall der Maschine.

Implementierung und Monitoring-Integration von Last Will and Testament (LWT)

Ein Client kann sein Will in CONNECT mit Topic, Nutzlast, QoS und Retain-Option anmelden. Der Broker veröffentlicht es, wenn er einen unerwarteten Verbindungsverlust gemäß Keep Alive oder Transportbedingungen feststellt; ein geordnetes Beenden löst nicht einfach denselben Ablauf aus. MQTT 5.0 bietet unter anderem Will Delay, dessen Wirkung von Sitzung und Broker abhängt. Ein Status wie {"status":"offline","timestamp":123456} beschreibt die Verbindung, nicht unmittelbar den Zustand des Prozesses. Für Anlagenzustand sind zusätzlich frische Messwerte oder Heartbeats nötig.

Will als Verbindungssignal behandeln

Ein Client kann beim Verbinden eine Will-Nachricht hinterlegen; der Broker sendet sie bei unerwartetem Verbindungsende unter den eingestellten Bedingungen. Sie meldet Verlust der MQTT-Verbindung, nicht zwingend einen Maschinenausfall. Kombinieren Sie sie mit Zeitstempeln und gegebenenfalls Heartbeat oder Datenqualitätsregel. Sauberes Trennen und Netzausfall verhalten sich unterschiedlich. Testen Sie beides und verhindern Sie, dass eine verspätete Will-Nachricht einen neueren gesunden Zustand überschreibt.

Retained-Nachrichten zeigen einen gespeicherten letzten Wert; ein Will beschreibt einen erkannten Verbindungsverlust. Beides beweist nicht, dass der Prozesswert aktuell ist oder die Anlage sicher steht.

Was sind die neuen Funktionen von MQTT 5.0

MQTT 5.0 ergänzt Funktionen für Metadaten, Diagnose und Ablaufsteuerung, darunter User Properties, Reason Codes, Subscription-Optionen, Shared Subscriptions, Request/Response-Felder und Nachrichtenablauf. Welche Funktionen nutzbar sind, richtet sich nach Client, Broker und gewählter Protokollversion. Aus der Funktionszahl folgt keine pauschale Steigerung der Entwicklungseffizienz.

Benutzereigenschaften (User Properties)

User Properties sind Schlüssel-Wert-Paare, die MQTT 5.0 an unterstützten Control Packets übertragen kann. Sie sind kein QoS-Wert und können Protokollmetadaten vom Anwendungs-Payload trennen, wenn Client, Broker und Anwendung sie gemeinsam nutzen. Ältere Versionen benötigen dafür ein anderes, etwa im Payload definiertes Datenmodell; Zugriffsregeln für Metadaten bleiben zu konfigurieren.

Ursachencodes (Reason Codes)

MQTT 5.0 Reason Codes liefern je nach Paket zusätzliche Informationen zum Ergebnis. 0x92 bedeutet „Packet Identifier not found“; 0x95 steht für „Packet too large“. Ein Beispiel muss zum jeweiligen Paket und der Protokollversion passen. Die Übergabe solcher Angaben an ELK oder ein anderes Logsystem kann die Diagnose unterstützen, verkürzt die Fehlerlokalisierung aber nicht automatisch.

MQTT-5-Diagnosen nur bei Unterstützung nutzen

MQTT 5 bietet Reason Codes und Eigenschaften für abgewiesene Verbindungen, Abonnements und Publikationen. Message Expiry Interval begrenzt die Nutzdauer einer wartenden Nachricht; Session Expiry Interval kann Sitzungszustand befristet halten. User Properties und Topic Aliases sind Optionen, kein Ersatz für ein definiertes Payload-Schema. Prüfen Sie Broker, Client-Bibliothek und Router-Firmware auf kompatible Version und Einstellungen. Lesen Sie den tatsächlichen Fehlercode, bevor Sie Firewall oder Zugang ändern.

Abonnementoptionen und erweiterte Filterung

Shared Subscriptions können mit einem Filter wie $share/group/topic eine Empfängergruppe adressieren. Ob der Broker Last verteilt und nach welchem Plan, ist implementierungsabhängig; Round-Robin ist keine allgemeine Garantie.
No Local kann die Zustellung eigener Veröffentlichungen an die jeweilige Verbindung unterdrücken. Retain Handling steuert, ob gespeicherte retained Nachrichten bei einem Abonnement gesendet werden.
Ein Subscription Identifier kann in MQTT 5.0 eine Zustellung einer passenden Subscription zuordnen und die Verarbeitung in der Anwendung erleichtern.

Die folgende Tabelle vergleicht ausgewählte MQTT-5.0-Funktionen mit MQTT 3.1.1. Mögliche betriebliche Auswirkungen hängen von Produktunterstützung, Nachrichtenmuster und Konfiguration ab:

Funktion	Unterstützung in 3.1.1	Ergänzung in MQTT 5.0	Möglicher Betriebsbezug (implementierungsabhängig)
User Properties	Nicht enthalten	Schlüssel-Wert-Metadaten an unterstützten Control Packets	Kann Metadaten vom Payload trennen, wenn Anwendung und Produkte es nutzen.
Reason Codes	Begrenzte Ergebnisangaben	Detailliertere standardisierte Codes für unterstützte Abläufe	Kann Diagnosekontext liefern; garantiert keine kürzere Fehleranalyse.
Topic Alias	Nicht enthalten	Verhandelter Alias für Topic-Namen innerhalb einer Verbindung und Richtung	Kann wiederholte Topic-Bytes reduzieren; keine feste Bandbreitenersparnis.
Shared Subscriptions	Nicht als MQTT-5.0-Funktion enthalten	Abonnements für eine gemeinsame Empfängergruppe	Kann horizontale Verteilung unterstützen; Scheduling und Kapazität hängen vom Broker ab.

Weitere Funktionen: Request-Response und Nachrichtenablauf

MQTT 5.0 ergänzt Response Topic und Correlation Data, mit denen Anwendungen ein Anfrage-Antwort-Muster aufbauen können. Das ist kein automatisch synchroner RPC-Aufruf: Die Anwendung verwaltet Korrelation, Antwort, Berechtigungen und Zeitüberschreitungen. Message Expiry kann die Gültigkeit einer Nachricht begrenzen, wenn Client und Broker die Eigenschaft unterstützen.

Als veranschaulichendes Beispiel für eine 5G-Fabrik könnten mehrere Roboterpublikationen über Shared Subscriptions an eine Gruppe von Verarbeitungsdiensten verteilt und wiederkehrende Topic-Namen über Alias-Funktionen behandelt werden. Das setzt Unterstützung auf beiden Seiten und eine passende Brokerkonfiguration voraus. Latenz, Funkbandbreite und Skalierung müssen gemessen werden; eine bestimmte Zahl von Robotern oder Einsparung ist damit nicht belegt.

Wie man sichere MQTT-Übertragung implementiert

Zu den Sicherheitsrisiken einer IoT-Installation zählen Abhören, Wiederholung alter Daten und Denial-of-Service. MQTT stellt dafür nicht allein eine Sicherheitsarchitektur bereit. Transportabsicherung, Clientidentität, Topic-Berechtigungen, Eingabeprüfung, Netzwerkkontrollen und Brokerhärtung müssen passend zur Anwendung zusammenspielen.

Verschlüsselungsmechanismen (TLS/mTLS Bereitstellungsschritte)

TLS-Version und Listener-Port werden vom Broker und Client konfiguriert; 8883 ist verbreitet, aber nicht vorgeschrieben. Handshake-Dauer und Wiederaufnahme hängen von Verbindung und Implementierung ab.
Zertifikatsverwaltung: Verwende eine geeignete Vertrauenskette und prüfe die Serveridentität anhand des Hostnamens bzw. der SAN-Angaben. CA, Zertifikatslaufzeit und Rotation müssen für Broker und Geräte geplant werden.
Einrichtung: Schlüssel und CSR nach dem Prozess der Plattform erzeugen, den TLS-Listener im Broker konfigurieren und im Client CA-Vertrauen sowie Peer-/Hostnameprüfung aktivieren. API-Aufrufe sind bibliotheks- und versionsabhängig.

Bei mTLS prüft der Broker zusätzlich ein Clientzertifikat, wenn Produkt und Listener dies unterstützen. Ein Zertifikat sollte an eine verwaltete Clientidentität gebunden werden; eine MAC-Adresse ist kein Ersatz für die Zertifikatsprüfung. Handshake- und Verschlüsselungsaufwand hängen von Gerät, Kryptobibliothek und Netzwerk ab und sollten auf der Zielplattform gemessen werden.

Authentifizierung und Autorisierung (Feingranulare ACL-Steuerung)

Zugangsdaten: Benutzername und Passwort sind brokerabhängige Authentifizierungsoptionen und müssen geschützt übertragen sowie sicher gespeichert werden. Eine pauschale SHA-256-Regel ist kein MQTT-Protokollmerkmal.
Externe Identität: JWT oder OAuth 2.0 können über Broker-Plugins oder externe Authentifizierungsdienste integriert werden; MQTT 5.0 definiert sie nicht als eingebaute Loginverfahren oder Refresh-Token-Verhalten.
ACL: Regeln sollten festlegen, welche Identität konkrete Topics veröffentlichen oder abonnieren darf. Platzhalter wie devices/%u/# sind syntax- und produktabhängig; dynamische IP-Regeln benötigen eine explizite Brokerintegration.

Ein Bedrohungsmodell sollte TLS nur dann als Schutz vor Mitlesen oder Manipulation ansetzen, wenn Zertifikatskette und Hostname geprüft werden. Payloadvalidierung kann fehlerhafte oder unerlaubte Eingaben abweisen; sie ersetzt keine Berechtigungsprüfung. Bei Medizin- oder anderen regulierten Geräten sind zusätzlich Produktkontrollen, Betrieb, Nachweise und anwendbare Regeln zu bewerten. mTLS oder JWT allein belegen weder HIPAA-Konformität noch eine bestimmte Eindringungsrate.

Best Practices und Audit

Schwache oder gemeinsam genutzte Zugangsdaten vermeiden, Geheimnisse sicher speichern und Rotation einplanen. PSK ist kein universeller Sicherheits-Fallback; verwende nur ausdrücklich unterstützte und bewertete Verfahren.
CONNECT-, DISCONNECT- und Sicherheitsereignisse können protokolliert und bei Bedarf in ein SIEM integriert werden. Umfang, Schutz und Aufbewahrung der Logs hängen von Broker und Betriebsumgebung ab.

Broker-Verbindung schützen und in Betrieb nehmen

Nutzen Sie TLS, soweit unterstützt und erforderlich, prüfen Sie das Broker-Zertifikat, schützen Sie Client-Zugangsdaten und beschränken Sie jedes Konto auf nötige Topics. Trennen Sie Veröffentlichungs- und Aborechte: Ein Telemetrie-Publisher darf nicht automatisch Befehle senden. Der Leitfaden zur Routersoftware trennt Verbindung, Firewall, Anwendung und Verwaltung. MQTT verschlüsselt die Verbindung ohne entsprechende Transportsicherung nicht selbst.

TLS-Vertrauen, Clientidentität, Topic-ACLs und Hochverfügbarkeit hängen von Client, Broker, Gateway und deren Konfiguration ab; die konkrete Installation muss sie nachweisen.

Aufbau eines MQTT-Brokers und Client-Entwicklung

Broker-Einrichtungsprozess

Broker auswählen und Listener, Protokollversion, Netzwerkzugriff, TLS, Identitäten, ACLs sowie gewünschte Persistenz konfigurieren.
Optionale Erweiterungen wie Bridging oder Monitoring nur aktivieren, wenn das konkrete Brokerprodukt sie unterstützt; anschließend Zugriff und Fehlerverhalten prüfen.
Inflight-Fenster und Warteschlangengrenzen nach Nachrichtentyp, Speicher und Last festlegen. Produktstandardwerte sind nicht allgemeingültig; unter realistischer Last messen und überwachen.

Broker als Dienst statt nur als offenen Port einrichten

Dokumentieren Sie Listener und Transport, Zertifikatsvertrauen, Client-Authentifizierung, getrennte Publish-/Subscribe-ACLs, Sitzungs- und Warteschlangengrenzen, Persistenz und Logs. Klartext-MQTT und MQTT über TLS nutzen häufig unterschiedliche Ports; der konkrete Listener ist eine Einsatzentscheidung. Begrenzen Sie die Erreichbarkeit und vermeiden Sie anonymes Schreiben auf einem öffentlichen Broker. Ist Hochverfügbarkeit nötig, prüfen Sie, wie das gewählte Produkt Sitzungen, Abonnements und Retained Messages beim Failover behandelt; MQTT garantiert kein Clustering.

Beginnen Sie mit einem bekannten SPS-Datenpunkt und einem Abonnenten. Prüfen Sie Registeradresse, Einheit, Zeitstempel und Nutzdaten, danach Veröffentlichung, Abo und Topic-Rechte. Trennen Sie in kontrollierten Tests das WAN und starten Sie Client und Broker neu.

Vergleichen Sie die Nachrichten nach dem Wiederanlauf; prüfen Sie Duplikate, veraltete retained Werte, Warteschlangen und Mobilfunkverbrauch. SPS-Steuerung und Sicherheitsfunktionen verbleiben im freigegebenen System, solange kein gesondert geprüfter Entwurf MQTT-Aktionen erlaubt.

Mit vier Beobachtungen in Betrieb nehmen

Erfassen Sie für einen bekannten Punkt Quellwert, Publikationsversuch, Annahme durch den Broker und Empfang beim Subscriber mit Zeitstempeln. Sperren Sie dann testweise die Topic-Berechtigung und beobachten Sie die Broker-Antwort; stellen Sie sie wieder her und unterbrechen Sie WAN, um Wiederverbindung, Duplikate und alte Daten zu prüfen. Halten Sie Client- und Broker-Version, TLS-Modus, Topic, QoS und Payload-Schema fest. Eine TCP-Verbindung zeigt nur Erreichbarkeit; die Anwendung braucht einen korrekten, frischen und erlaubten Wert.

Überblick über Client-Entwicklungsframeworks

MQTT-Clientbibliotheken gibt es für verschiedene Sprachen und Laufzeitmodelle. Vergleiche Versionen, Protokollunterstützung, TLS-Prüfung, Callback- und Netzwerkloop-API, Fehlerbehandlung, Sitzungsmodell und Zielplattform. Asynchrone Ausführung, Verbindungspooling oder Batch-Publishing sind nur sinnvoll, wenn die Bibliothek und Anwendung sie unterstützen und der konkrete Arbeitsablauf davon profitiert.

Integration der MQTT-Client-Entwicklung

Java-Integration (Eclipse Paho)

Das Java-Beispiel verwendet Eclipse Paho Java 1.2.5 und MQTT 3.1.1 mit Clean Session. Es veranschaulicht einen TLS-konfigurierten Client mit endlichen Wartezeiten und geprüften Rückmeldungen für die gezeigten Abläufe. Die TLS-Konfiguration muss Vertrauenskette und Hostnamen prüfen. Das Beispiel beschreibt keinen vollständigen automatischen Wiederverbindungs- oder persistenten Sitzungsbetrieb.

// Eclipse Paho Java 1.2.5; MQTT 3.1.1; simulated telemetry.
import java.net.URI;
import java.nio.charset.StandardCharsets;
import java.util.concurrent.CountDownLatch;
import java.util.concurrent.TimeUnit;
import org.eclipse.paho.client.mqttv3.*;
import org.eclipse.paho.client.mqttv3.persist.MemoryPersistence;

public final class MqttJavaExample {
    static String required(String name) {
        String value = System.getenv(name);
        if (value == null || value.isEmpty()) throw new IllegalArgumentException(name);
        return value;
    }
    public static void main(String[] args) throws Exception {
        String broker = required("MQTT_BROKER_URI"); // ssl://dns-name:8883
        if (!"ssl".equals(URI.create(broker).getScheme()))
            throw new IllegalArgumentException("TLS broker URI required");
        String topic = "demo/device01/telemetry";
        CountDownLatch received = new CountDownLatch(1);
        MqttClient client = new MqttClient(broker, required("MQTT_CLIENT_ID"),
                                         new MemoryPersistence());
        client.setTimeToWait(10000);
        client.setCallback(new MqttCallback() {
            public void connectionLost(Throwable error) {
                System.err.println("Connection lost; stop and inspect recovery policy");
            }
            public void deliveryComplete(IMqttDeliveryToken token) { }
            public void messageArrived(String name, MqttMessage message) {
                if (!message.isRetained()) received.countDown();
            }
        });
        MqttConnectOptions options = new MqttConnectOptions();
        options.setMqttVersion(MqttConnectOptions.MQTT_VERSION_3_1_1);
        options.setCleanSession(true); // This example does not resume offline state.
        options.setAutomaticReconnect(false);
        options.setConnectionTimeout(10);
        options.setUserName(required("MQTT_USERNAME"));
        options.setPassword(required("MQTT_PASSWORD").toCharArray());
        options.setHttpsHostnameVerificationEnabled(true);
        // Configure the JVM trust store with the broker's issuing CA.
        try {
            client.connect(options);
            client.subscribe(topic, 1);
            byte[] payload = "{\"example\":true,\"temperature\":23.5}".getBytes(StandardCharsets.UTF_8);
            client.publish(topic, payload, 1, false);
            if (!received.await(10, TimeUnit.SECONDS))
                throw new IllegalStateException("No non-retained subscription delivery");
            System.out.println("Demo MQTT exchange observed; no PLC action is implied");
        } finally {
            try { if (client.isConnected()) client.disconnect(); }
            finally { client.close(); }
        }
    }
}

Behandle MqttException und Rückgabewerte anhand der verwendeten Paho-Version und protokolliere den konkreten Fehlerkontext. MQTT-3.1.1-Clientausnahmen sind nicht automatisch MQTT-5.0-Reason-Codes; eine feste Zuordnung von 0x84 zu einer ungültigen Client-ID ist nicht allgemein belastbar.

Go-Integration (Paho Go)

// github.com/eclipse/paho.mqtt.golang v1.5.0; MQTT 3.1.1.
package main

import (
    "crypto/tls"
    "crypto/x509"
    "fmt"
    "net"
    "os"
    "time"
    mqtt "github.com/eclipse/paho.mqtt.golang"
)

func required(name string) string {
    value := os.Getenv(name)
    if value == "" { panic("Missing " + name) }
    return value
}
func checked(token mqtt.Token) {
    if !token.WaitTimeout(10 * time.Second) { panic("MQTT operation timeout") }
    if err := token.Error(); err != nil { panic(err) }
}
func main() {
    host := required("MQTT_HOST") // DNS name covered by the broker certificate.
    pem, err := os.ReadFile(required("MQTT_CA_FILE"))
    if err != nil { panic(err) }
    roots := x509.NewCertPool()
    if !roots.AppendCertsFromPEM(pem) { panic("No CA certificate loaded") }
    options := mqtt.NewClientOptions()
    options.AddBroker("ssl://" + net.JoinHostPort(host, required("MQTT_PORT")))
    options.SetClientID(required("MQTT_CLIENT_ID"))
    options.SetUsername(required("MQTT_USERNAME"))
    options.SetPassword(required("MQTT_PASSWORD"))
    options.SetProtocolVersion(4) // MQTT 3.1.1.
    options.SetCleanSession(true)
    options.SetAutoReconnect(false)
    options.SetConnectTimeout(10 * time.Second)
    options.SetWriteTimeout(10 * time.Second)
    options.SetTLSConfig(&tls.Config{
        RootCAs: roots, ServerName: host, MinVersion: tls.VersionTLS12,
    })
    client := mqtt.NewClient(options)
    checked(client.Connect())
    defer client.Disconnect(1000)
    topic := "demo/device01/telemetry"
    received := make(chan struct{}, 1)
    token := client.Subscribe(topic, 1, func(_ mqtt.Client, msg mqtt.Message) {
        if !msg.Retained() {
            select { case received <- struct{}{}: default: }
        }
    })
    checked(token)
    granted, ok := token.(*mqtt.SubscribeToken).Result()[topic]
    if !ok || granted == 0x80 { panic("Subscription rejected") }
    checked(client.Publish(topic, 1, false, `{"example":true,"temperature":23.5}`))
    select {
    case <-received:
        fmt.Println("Demo MQTT exchange observed; no PLC action is implied")
    case <-time.After(10 * time.Second):
        panic("No non-retained subscription delivery")
    }
}

Go-Goroutines können nebenläufige Verarbeitung unterstützen. Tatsächliche Parallelität, Zustellung und Verfügbarkeit hängen jedoch von Clientbibliothek, Anwendung, Broker und Netz ab; die Sprachlaufzeit allein stellt keine Hochverfügbarkeit mehrerer Abonnements sicher.

Python-Integration (Paho MQTT)

# paho-mqtt 2.1.0; Callback API VERSION2; MQTT 3.1.1.
import os
import ssl
import threading
import paho.mqtt.client as mqtt

connected = threading.Event()
subscribed = threading.Event()
received = threading.Event()
errors = []
topic = "demo/device01/telemetry"

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        errors.append("Broker rejected CONNECT")
    connected.set()

def on_subscribe(client, userdata, mid, reason_codes, properties):
    if not reason_codes or any(code.is_failure for code in reason_codes):
        errors.append("Broker rejected SUBSCRIBE")
    subscribed.set()

def on_message(client, userdata, message):
    if not message.retain:
        received.set()

def ready(event):
    if not event.wait(10):
        raise TimeoutError("MQTT readiness timeout")
    if errors:
        raise RuntimeError(errors[0])

client = mqtt.Client(
    callback_api_version=mqtt.CallbackAPIVersion.VERSION2,
    client_id=os.environ["MQTT_CLIENT_ID"],
    clean_session=True, protocol=mqtt.MQTTv311, reconnect_on_failure=False,
)
client.on_connect = on_connect
client.on_subscribe = on_subscribe
client.on_message = on_message
context = ssl.create_default_context(cafile=os.environ["MQTT_CA_FILE"])
context.minimum_version = ssl.TLSVersion.TLSv1_2
client.tls_set_context(context) # Certificate and hostname verification stay enabled.
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.connect(os.environ["MQTT_HOST"], int(os.environ["MQTT_PORT"]), keepalive=30)
client.loop_start()
try:
    ready(connected)
    result, _ = client.subscribe(topic, qos=1)
    if result != mqtt.MQTT_ERR_SUCCESS:
        raise RuntimeError("Unable to queue SUBSCRIBE")
    ready(subscribed)
    info = client.publish(topic, '{"example":true,"temperature":23.5}', qos=1, retain=False)
    if info.rc != mqtt.MQTT_ERR_SUCCESS:
        raise RuntimeError("Unable to queue PUBLISH")
    info.wait_for_publish(timeout=10)
    if not info.is_published():
        raise TimeoutError("Publication was not acknowledged")
    ready(received)
    print("Demo MQTT exchange observed; no PLC action is implied")
finally:
    client.disconnect()
    client.loop_stop()

Eine asynchrone Python-Integration mit asyncio hängt von der dafür vorgesehenen API und der konkreten paho-mqtt-Version ab. Das gezeigte Beispiel nutzt Callback API V2 und den Paho-Netzwerkloop, nicht ein vollständiges asyncio-Programm. Callbacks sollten nicht blockieren; die Einbindung in einen externen Event-Loop ist anhand der Bibliotheksdokumentation zu prüfen.

Die Tabelle vergleicht Clientbibliotheken nach Sprache, Paketierungs- und Laufzeitbedarf, Verbindungsaufbau, Nebenläufigkeitsmodell und typischen Einsatzfeldern. Größe und Latenz sind keine festen Bibliothekseigenschaften; sie müssen für Version, TLS-Konfiguration, Zielhardware, Broker und Netzwerk gemessen werden:

Sprache / Bibliothek	Bibliotheksgröße (KB)	Verbindungslatenz (ms)	Nebenläufigkeitsunterstützung	Typische Einsatzfelder
Java — Eclipse Paho 1.2.5	Kein fixer Wert; abhängig von Paketierung, Laufzeit und TLS	Mit Zielbroker und Netzwerk messen	Callbacks; Threads/Executor gemäß Client-API	Unternehmensanwendungen und Java-Integration
Go — paho.mqtt.golang v1.5.0	Kein fixer Wert; abhängig von Build und Abhängigkeiten	Mit Zielbroker und Netzwerk messen	Callbacks und Goroutines gemäß Anwendung	Dienste und nebenläufige Verarbeitung
Python — paho-mqtt 2.1.0	Kein fixer Wert; abhängig von Umgebung und TLS	Mit Zielbroker und Netzwerk messen	Paho-Netzwerkloop und Callback API V2; Event-Loop-Integration separat prüfen	Skripte und Datenverarbeitung

Vergleich von MQTT vs. andere Protokolle in Sicherheit und Leistung

Die Wahl eines IoT-Protokolls hängt von Kommunikationsmuster, Gerätegrenzen, Sicherheitsanforderungen und vorhandener Infrastruktur ab. Die Tabelle vergleicht MQTT, CoAP, AMQP, XMPP und DDS nach Modus, Protokollaufwand, Sicherheit, Leistung und typischen Stärken bzw. Grenzen. Die Angaben sind qualitative Orientierung; Durchsatz, Latenz und Bytes pro Nachricht müssen in einer definierten Testumgebung gemessen werden.

Protokoll	Modus	Overhead (Byte/Nachricht)	Sicherheit (Verschlüsselung/Authentifizierung)	Leistung (Durchsatz/Latenz)	Anwendungsszenarien und Vor-/Nachteile
MQTT	Publish/Subscribe über Broker	Kein allgemeingültiger Bytewert; Paket, Topic, Eigenschaften und Nutzlast bestimmen die Größe.	TLS/mTLS sowie Authentifizierung und ACLs hängen von Broker, Client und Konfiguration ab.	Abhängig von Broker, Topic-Muster, QoS, Netzwerk und Last; im Zielsystem messen.	Telemetrie und Ereignisse; QoS definiert Zustellabläufe. Abhängigkeit vom Broker und dessen Betrieb.
CoAP	Request/Response über UDP im Grundmodell	Kein pauschaler Wert; Optionen, Blockbildung und Payload wirken sich aus.	DTLS und weitere Schutzmechanismen hängen von Profil und Produkt ab.	Abhängig von Gerät, Datagrammnetz, Sicherheit und Anwendung; messen.	Eingeschränkte Geräte und REST-ähnliche Interaktionen; anderes Sitzungs- und Zustellmodell als MQTT.
AMQP	Messaging mit Links/Adressen; Broker-Routing ist produktabhängig	Kein pauschaler Wert; Frame, Nachricht und Erweiterungen variieren.	TLS und SASL gemäß Client, Broker und Betriebsrichtlinie.	Abhängig von Broker, Routing, Persistenz und Netz; messen.	Unternehmensintegration und Messaging-Anforderungen; Begriffe und Funktionen wie Exchange hängen von Produkt oder Protokollversion ab.
XMPP	XML-basierter Nachrichtenstream	Kein pauschaler Wert; XML und Erweiterungen beeinflussen die Nachrichtengröße.	TLS und SASL gemäß XMPP-Server und eingesetztem Profil.	Abhängig von Stream, Erweiterungen, Server und Nutzlast; messen.	Messaging und Dienste mit Erweiterungen; XML-Stream ist strukturiert, kann aber mehr Darstellungsaufwand mitbringen.
DDS	Datenzentriertes Publish/Subscribe	Kein pauschaler Wert; Datenmodell, QoS und Transport wirken sich aus.	DDS-Security-Profile, PKI und Berechtigungen hängen von Implementierung und Konfiguration ab.	Abhängig von Discovery, Transport, QoS und Zielsystem; messen.	Verteilte Echtzeitsysteme; kann direkte Datenverteilung unterstützen, ist aber konfigurations- und integrationsintensiv.

MQTT passt, wenn topicbasiertes Publish/Subscribe über einen Broker zum Datenfluss passt. CoAP kann für begrenzte Request/Response- oder REST-ähnliche Datagrammkommunikation geeignet sein; AMQP für definierte Messaging- und Routinganforderungen; DDS für datenverteilte Systeme mit passenden Echtzeitanforderungen. Ein hybrider Pfad, etwa MQTT am Edge und AMQP in einem Backend, benötigt explizite Übersetzung, Zuständigkeiten und Sicherheitsregeln. Die Auswahl sollte durch Anforderungen und Messungen der Zielumgebung begründet werden.

Industrielle MQTT-Protokollstack-Architektur

Ein industrieller MQTT-Stack kann als Schichtenmodell dargestellt werden, etwa mit Feldzugriff, Gateway, Gerätemanagement und Broker. Das ist ein mögliches Integrationsdesign, keine vom MQTT-Standard vorgeschriebene Architektur. Echtzeitverhalten und Interoperabilität ergeben sich aus den beteiligten Geräten, Schnittstellen und Konfigurationen und müssen systemweit geprüft werden.

EMS-Schicht (Gerätemanagementsubsystem)

Eine Geräteverwaltungs- oder EMS-Schicht kann Sitzungs- und Will-Ereignisse auswerten und getrennte Funktionen wie OTA-Updates koordinieren. Eine Plattform wie Eclipse Hono kann als Integrationsbeispiel dienen, sofern die benötigten Schnittstellen eingesetzt und konfiguriert sind. MQTT selbst führt keine Firmwareaktualisierung aus und liefert keinen Prozesszustand.

Gateway-Treiberschicht

Ein Gateway kann ausgewählte Modbus-Werte lesen und auf MQTT-Topics abbilden; eine konfigurierte OPC-UA-PubSub-Verbindung kann MQTT als Brokertransport einbeziehen. Dafür braucht es passende Protokolltreiber, Mapping, Typ- und Sicherheitsregeln. Serielle oder Ethernet-Adapter und Pufferung hängen von Gerät und Software ab; eine festgelegte Nachrichtenpuffergröße ist nicht allgemeingültig.

Low-Level-Treiberschicht

Eine Low-Level-Schicht kann TCP/TLS, MQTT-Clientzustand und begrenzte Warteschlangen auf einem Embedded-System bereitstellen. LwIP ist ein mögliches TCP/IP-Stack-Beispiel; TLS- und MQTT-Unterstützung müssen zur Plattform passen und Zertifikate einschließlich Hostname prüfen. Speicherbedarf und Energieverbrauch hängen von Hardware, Funk, Bibliothek und Arbeitslast ab.

Ein mögliches Fertigungsbeispiel ist: Ein Sensor liefert Modbus-Werte an einen Treiber; ein Gateway liest und normalisiert sie in Topics; eine Geräteverwaltungs- oder EMS-Schicht kann Identität und Auditregeln ergänzen; der Broker verteilt passende Veröffentlichungen an Subscriber. Diese Schichtenfolge ist eine Illustration, kein verbindlicher MQTT-Aufbau oder Wavetel-Produktversprechen. Eine Verkürzung von Ausfallzeiten oder Unterstützung von 5G-Slicing ist ohne projektspezifische Nachweise nicht ableitbar.

Industrielle MQTT-Client-Entwicklung

C++-Integration (Paho C++)

// Paho C++ 1.5.3 with a TLS-enabled Paho C dependency; MQTT 3.1.1.
#include <mqtt/async_client.h>
#include <chrono>
#include <cstdlib>
#include <iostream>
#include <stdexcept>
#include <string>

std::string required(const char* name) {
    const char* value = std::getenv(name);
    if (!value || !*value) throw std::runtime_error(name);
    return value;
}
void checked(mqtt::token_ptr token) {
    if (!token->wait_for(std::chrono::seconds(10)))
        throw std::runtime_error("MQTT operation timeout");
}
int main() {
    try {
        const auto uri = required("MQTT_BROKER_URI"); // ssl://dns-name:8883
        if (uri.rfind("ssl://", 0) != 0) throw std::runtime_error("TLS URI required");
        mqtt::async_client client(uri, required("MQTT_CLIENT_ID"));
        mqtt::ssl_options tls;
        tls.set_trust_store(required("MQTT_CA_FILE"));
        tls.set_enable_server_cert_auth(true);
        tls.set_verify(true); // Check the broker certificate host name.
        mqtt::connect_options options;
        options.set_mqtt_version(MQTTVERSION_3_1_1);
        options.set_clean_session(true);
        options.set_connect_timeout(10);
        options.set_user_name(required("MQTT_USERNAME"));
        options.set_password(required("MQTT_PASSWORD"));
        options.set_ssl(tls);
        client.start_consuming();
        try {
            checked(client.connect(options));
            checked(client.subscribe("demo/device01/telemetry", 1));
            auto message = mqtt::make_message("demo/device01/telemetry",
                "{\"example\":true,\"temperature\":23.5}");
            message->set_qos(1);
            message->set_retained(false);
            checked(client.publish(message));
            mqtt::const_message_ptr incoming;
            const auto deadline = std::chrono::steady_clock::now() + std::chrono::seconds(10);
            while (std::chrono::steady_clock::now() < deadline) {
                incoming = client.try_consume_message_for(std::chrono::milliseconds(200));
                if (incoming && !incoming->is_retained()) break;
            }
            if (!incoming || incoming->is_retained())
                throw std::runtime_error("No non-retained subscription delivery");
            checked(client.disconnect());
            client.stop_consuming();
        } catch (...) {
            client.stop_consuming();
            if (client.is_connected()) { try { client.disconnect()->wait_for(std::chrono::seconds(2)); } catch (...) {} }
            throw;
        }
        std::cout << "Demo MQTT exchange observed; no PLC action is implied\n";
    } catch (const std::exception& error) {
        std::cerr << error.what() << '\n';
        return 1;
    }
}

Zero-Copy-Payloads und SIMD-beschleunigtes JSON-Parsing können für bestimmte C++-Anwendungen untersucht werden. Entscheidend sind Profiling, Bibliotheksunterstützung und sichere Pufferlebensdauer; daraus folgt keine garantierte Leistungssteigerung. Optimierungen erst nach Messung des tatsächlichen Engpasses einsetzen.

Java Embedded-Variante (Android/IoT)

Eine Android-/IoT-Integration kann Paho-Funktionen mit Androids Aufgaben- und Hintergrundregeln verbinden. WorkManager kann geeignete aufschiebbare Arbeit koordinieren, garantiert aber keine sofortige oder dauerhafte MQTT-Wiederverbindung. Netzwerkkonnektivität, Prozesslebenszyklus, Broker-Sitzung und Plattformbeschränkungen müssen gemeinsam behandelt werden.

Embedded C (ESP32/FreeRTOS)

/* Paho paho.mqtt.embedded-c MQTTClient-C API, single-task platform fragment.
 * Build with the library's platform header (Network and Timer definitions).
 * tls_network must ALREADY be connected through a platform TLS adapter that
 * validates the CA chain and broker host name. Plain TCP is not sufficient.
 * Caller owns that transport and its cleanup. Payload is simulated telemetry.
 */
#include "MQTTClient.h"
#include <string.h>
#include <stdio.h>

static void arrived(MessageData* data) {
    MQTTMessage* message = data->message;
    printf("Received %u payload bytes\n", (unsigned)message->payloadlen);
}
int publish_demo(Network* tls_network, const char* client_id,
                 const char* username, const char* password) {
    if (!tls_network || !client_id || !*client_id || !username || !password)
        return -1;
    unsigned char send_buffer[512], read_buffer[512];
    MQTTClient client;
    MQTTClientInit(&client, tls_network, 5000,
                   send_buffer, sizeof send_buffer, read_buffer, sizeof read_buffer);
    MQTTPacket_connectData options = MQTTPacket_connectData_initializer;
    options.MQTTVersion = 4; /* MQTT 3.1.1 */
    options.clientID.cstring = (char*)client_id;
    options.username.cstring = (char*)username;
    options.password.cstring = (char*)password;
    options.cleansession = 1;
    options.keepAliveInterval = 30;
    int rc = MQTTConnect(&client, &options);
    if (rc != 0) return rc;
    rc = MQTTSubscribe(&client, "demo/device01/telemetry", QOS1, arrived);
    if (rc == 0) {
        char payload[] = "{\"example\":true,\"temperature\":23.5}";
        MQTTMessage message = {0};
        message.qos = QOS1;
        message.retained = 0;
        message.payload = payload;
        message.payloadlen = strlen(payload);
        rc = MQTTPublish(&client, "demo/device01/telemetry", &message);
        if (rc == 0) rc = MQTTYield(&client, 1000);
    }
    int close_rc = MQTTDisconnect(&client);
    return rc != 0 ? rc : close_rc;
}

Bei Embedded-Zielen können feste Puffer und begrenzte Speicherbudgets wichtig sein, sofern Bibliothek und Plattform diese Nutzung unterstützen. Prüfe Heap, Stack, Puffergrößen, TLS- und MQTT-Lebenszyklus auf dem konkreten Gerät. Ein LwIP-TLS-Pfad oder vollständig statische Speicherverwaltung folgt nicht automatisch aus dem MQTTClient-C-API-Ausschnitt.

Teste Verbindungsabbrüche, Paketverlust, Wiederholungen, volle Warteschlangen, Speicherbedarf und Wiederanlauf auf der Zielplattform. Lege Testbedingungen und Abnahmekriterien für die Anwendung fest; eine feste Abdeckung oder ein bestimmtes Messergebnis ist nicht belegt. Werkzeuge für Speicher- und Fehleranalyse müssen zur Plattform und zum verwendeten Build passen.

Zusammenfassung

Bewertung der Vor- und Nachteile

Vorteile:

Kompaktes binäres Anwendungsprotokoll: kann für passende Nachrichten einen geringen Protokollaufwand ermöglichen; die tatsächliche Paketgröße hängt von Version, Topic, Eigenschaften und Nutzlast ab.
Zustell- und Verbindungsmechanismen: QoS, Retained und Will unterstützen bestimmte Kommunikationsmuster, ersetzen jedoch keine Prüfung von Frische, Prozesszustand oder Anwendungswirkung.
Breites Client- und Broker-Ökosystem: ermöglicht verschiedene Integrationen; Funktionsumfang, Wartung, TLS und Plattformunterstützung sind je Produkt zu prüfen.

Nachteile:

Broker-Abhängigkeit: Routing läuft über einen Broker; Hochverfügbarkeit erfordert ein zum Produkt und Ausfallmodell passendes Design.
Keine automatische Dienstsuche im MQTT-Kern: Brokeradresse und Namensauflösung müssen über Netzwerk- oder Anwendungsdienste bereitgestellt werden.
QoS 2 benötigt zusätzliche Protokollschritte und Zustand. Ob es die Latenzanforderungen erfüllt, muss mit dem Zielbroker und der tatsächlichen Verbindung getestet werden.

Erweiterung der Anwendungsszenarien

IoT: Smart-Home-Telemetrie und vernetzte Fahrzeugereignisse sind mögliche Publish/Subscribe-Anwendungen.
IIoT: Eine SPS oder ein Gateway kann Messwerte veröffentlichen; Steuerbefehle benötigen getrennte Autorisierung und lokale Sicherheitslogik. Vorausschauende Wartung entsteht erst durch zusätzliche Datenanalyse, etwa mit ML.
Edge/Cloud: Eine 5G-Anbindung kann Teil eines Edge-/Cloud-Datenpfads sein. Latenz, Übergaben und Slicing-Unterstützung hängen von Netz, Betreiber, Gerät und Dienst ab.

Für große historische Datenströme können spezialisierte Streamingplattformen wie Kafka geeigneter sein. Für synchrone Request/Response-APIs können HTTP oder gRPC passen. MQTT 5.0 kann ein Request/Response-Muster unterstützen, stellt aber keinen automatisch synchronen RPC-Dienst bereit; die Wahl richtet sich nach Anforderungen und Systemgrenzen.

Topic-Designprinzipien (Erweiterter Leitfaden)

Stabile Hierarchie: Funktion/Geografie/Gerät/Metrik (z.B. cmd/global/eu/factory1/robotA/arm/speed).
Längenkontrolle: Beachten Sie die Grenzen der UTF-8-kodierten Zeichenfolge und des verwendeten Produkts statt einer allgemeinen Zeichenzahl. Ein MQTT-5-Topic-Alias gilt nur für die jeweilige Verbindung und Senderichtung sowie innerhalb des vom Empfänger angekündigten Limits; er ersetzt die dokumentierte Topic-Struktur nicht.
Sichere Platzhalter: Beschränke # auf Lese-ACL, vermeide Schreibmissbrauch.
Dokumentation und Versionierung: Verwende v1/telemetry/..., inkrementelle Evolution.
Leistung: Messen Sie Topic-Matching und Nachrichtenverteilung am gewählten Broker. Eine einheitliche Präfixhierarchie schreibt keinen Matching-Algorithmus vor und garantiert keinen Leistungsgewinn.

Plane Erweiterungen anhand veröffentlichter Standards und tatsächlich unterstützter Client-, Broker- und Plattformversionen. Andere Transporte, Browseranbindungen oder adaptive QoS-Verfahren benötigen eine eigene Integration und Prüfung. Die hier beschriebenen MQTT-Versionen begründen keine Zusage für MQTT 6.0, QUIC, WebRTC oder KI-gestützte QoS-Steuerung.

FAQ

Was ist MQTT, und wird es noch in industriellen Systemen eingesetzt?

Ja. MQTT wird in industriellen Systemen unter anderem für Telemetrie, Statusereignisse und separat berechtigte Befehle über einen Broker eingesetzt. Ob es passt, hängt von Protokollversion, Client und Broker, Netz, Sicherheitsregeln sowie der lokalen Steuerungslogik ab; MQTT ersetzt nicht automatisch Modbus oder andere Feldschnittstellen.

Ersetzt MQTT Modbus im Maschinennetz?

Nein. Ein Gateway kann Modbus-Daten lesen und als zugeordneten MQTT-Inhalt veröffentlichen, aber beide Protokolle haben unterschiedliche Aufgaben. Prüfen Sie Registerbelegung und Umwandlung.

Garantiert QoS 2, dass eine Maschinenaktion genau einmal erfolgt?

Nein. QoS 2 betrifft den MQTT-Protokollaustausch, nicht den nachgeschalteten Controller oder Vorgang. Kennzeichnen Sie Aufträge eindeutig und prüfen Sie das Anwendungsergebnis in einem freigegebenen Steuerungsentwurf.

Ist eine retained Nachricht immer der aktuelle Wert?

Nein. Sie ist die letzte retained Veröffentlichung im Broker für dieses Topic. Prüfen Sie Zeitstempel, Qualität und Ablaufregel.

Funktioniert MQTT bei wechselnden IP-Adressen im Mobilfunk?

Ein Client kann oft eine ausgehende Verbindung zu einem erreichbaren Broker aufbauen, abhängig von Netzbetreiber, Firewall und Broker. Testen Sie Wiederverbindung und Warteschlangen; MQTT allein macht eine schwache Verbindung nicht zuverlässig.

Darf ein Publisher an ein Wildcard-Topic senden?

Nein. Wildcards gehören in Abonnementfilter. Ein Publisher verwendet ein konkretes Topic, das der Broker mit berechtigten Filtern abgleicht.

Beweist PUBACK die Verarbeitung im Dashboard?

Nein. Es bestätigt einen MQTT-QoS-1-Schritt, nicht die Entscheidung der empfangenden Anwendung. Prüfen Sie Broker-Annahme, Subscriber-Empfang und Anzeige oder Speicherung getrennt.

Welche MQTT-Clientbibliothek eignet sich für Java, Go, Python oder ein Embedded-Ziel?

Wähle nach Zielplattform, API, TLS- und Hostnameprüfung, Netzwerkloop, Fehlerbehandlung und gewünschtem Sitzungsverhalten. Die Beispiele dieses Leitfadens sind begrenzt auf Eclipse Paho Java 1.2.5, paho.mqtt.golang v1.5.0, paho-mqtt 2.1.0 mit CallbackAPIVersion.VERSION2, Eclipse Paho C++ 1.5.3 sowie die Paho Embedded C MQTTClient-C API. Alle veranschaulichen MQTT 3.1.1 mit Clean Session, endlichen Wartezeiten und Rückmeldeprüfungen; sie sind keine Zusage für vollständige automatische Wiederverbindung oder persistente Wiederherstellung. Beim Embedded-C-Ausschnitt muss das Network-Objekt bereits von einem plattformspezifischen TLS-Adapter mit CA- und Hostnameprüfung bereitgestellt werden.

Referenzen

OASIS MQTT Version 5.0 — Der OASIS-Standard für MQTT 5.0 beschreibt Paketverhalten, QoS, Sitzungen, Retained-Nachrichten, Will und Version-5-Eigenschaften.

OASIS MQTT Version 3.1.1 — Der OASIS-Standard für MQTT 3.1.1 belegt dessen Protokollregeln und hilft, Clean Session von MQTT-5.0-Sitzungsoptionen abzugrenzen.

Eclipse Mosquitto Configuration Manual — Das Mosquitto-Handbuch dokumentiert Listener, TLS, Identitäten, ACLs und Persistenz als Konfiguration dieses Brokers; diese Details sind keine universellen MQTT-Vorgaben.

Eclipse Paho — Die Eclipse-Paho-Dokumentation beschreibt verfügbare Clientimplementierungen und ihre versionsabhängigen APIs.

Eclipse Paho Python Migration Guide — Der Paho-Python-Migrationsleitfaden erläutert Callback API V2 und relevante Änderungen zwischen Bibliotheksversionen.

RFC 7252 — CoAP — RFC 7252 definiert CoAPs Grundmodell und Nachrichtenformat für die Protokollvergleichstabelle.

OASIS AMQP 1.0 Overview — Die AMQP-1.0-Übersicht beschreibt den Standard; Begriffe wie Exchange können zu einer konkreten Brokerimplementierung oder anderen AMQP-Version gehören.

RFC 6120 — XMPP Core — RFC 6120 beschreibt XMPP-Core, XML-Streams, Authentifizierung und geschützte Verbindungen für den Vergleich.

OMG DDS 1.4 Specification — Die OMG-Spezifikation DDS 1.4 ist die Referenz für DDS; Sicherheitsprofile, Discovery und Betriebsverhalten hängen zusätzlich von Implementierung und Konfiguration ab.