15 Oktober 2026

MQTT ist ein standardisiertes Nachrichtenprotokoll für den Austausch von Daten nach dem Publish-Subscribe-Prinzip. Sender veröffentlichen Nachrichten unter einem Topic, während Empfänger passende Topics abonnieren. Ein Broker vermittelt die Nachrichten zwischen den Teilnehmern. In der Produktion wird MQTT beispielsweise für die Verteilung von Zustands- und Messdaten eingesetzt; die fachliche Bedeutung der Inhalte muss zusätzlich vereinbart werden.

Wie funktioniert MQTT?

Ein Teilnehmer kann Nachrichten senden, empfangen oder beides tun. Der Publisher muss die einzelnen Empfänger nicht direkt kennen. Er veröffentlicht seine Nachricht beim Broker. Dieser verteilt sie an Teilnehmer mit passenden Abonnements und Berechtigungen.

Das Prinzip entkoppelt die Anwendungen in bestimmtem Umfang. Eine zusätzliche Auswertung kann passende Daten abonnieren, ohne dass jeder Sender unmittelbar an diese Anwendung angepasst wird. Die gemeinsame Datenstruktur und das Verhalten bei Änderungen müssen dennoch abgestimmt sein.

Begriff	Aufgabe	Beispiel
Publisher	Veröffentlicht Nachrichten	Ein Gateway sendet einen Maschinenzustand.
Broker	Vermittelt Nachrichten	Ein zentraler Dienst verteilt sie an berechtigte Empfänger.
Subscriber	Abonniert passende Nachrichten	Eine Anzeige empfängt Zustandsänderungen.
Topic	Ordnet Nachrichten einem benannten Kanal zu	Ein hierarchisch aufgebauter Maschinenpfad
Payload	Enthält die eigentlichen Nutzdaten	Status, Zeitstempel und Kennung

Topics und Dateninhalt

Topics können hierarchisch aufgebaut werden. In einem fiktiven Werk könnte ein Kanal beispielsweise „werk1/linie2/maschine7/status“ heißen. Die Benennung sollte zu den betrieblichen Objekten passen und langfristig nachvollziehbar bleiben. Ein umbenannter Arbeitsplatz darf nicht unbemerkt die gesamte Datenzuordnung verändern.

MQTT schreibt keine allgemeine fachliche Bedeutung des Payloads vor. Ein Text, eine strukturierte Nachricht oder ein anderes vereinbartes Format kann übertragen werden. Für eine zuverlässige Nutzung müssen Empfänger wissen, wie der Inhalt aufgebaut ist und welche Bedeutung die Felder besitzen.

Zu einem Temperaturwert können beispielsweise Einheit, Messstelle und Ereigniszeit gehören. Für eine Mengenmeldung sind Auftrag und Zählweise wichtig. Ein Topic allein ersetzt kein vollständiges Datenmodell. Interoperabilität benötigt deshalb zusätzlich gemeinsame Begriffe und Regeln.

Was bedeuten die QoS-Stufen?

MQTT definiert drei Quality-of-Service-Stufen für die Nachrichtenübertragung. Die folgende Übersicht beschreibt ihre grundlegende Bedeutung auf Protokollebene.

Stufe	Grundprinzip	Wichtige Einordnung
QoS 0	Höchstens einmal	Eine Nachricht kann verloren gehen.
QoS 1	Mindestens einmal	Mehrfache Zustellung kann auftreten.
QoS 2	Genau einmal im jeweiligen Protokollaustausch	Erfordert zusätzlichen Austausch und Zustandsverwaltung.

Die Übertragung vom Publisher zum Broker und die Weitergabe an einen Subscriber sind getrennte Kommunikationsabschnitte. Die tatsächlich genutzte Zustellstufe und die Sitzungseinstellungen müssen zusammenpassen. Ein pauschales „QoS 2“ beschreibt noch nicht die gesamte Ende-zu-Ende-Anwendung.

Besonders wichtig ist die Grenze zur fachlichen Verarbeitung. Eine bestätigte Zustellung bedeutet nicht automatisch, dass eine Datenbankbuchung erfolgreich war oder eine Maschine einen Befehl ausgeführt hat. Dafür benötigt die Anwendung gegebenenfalls eigene Bestätigungen und nachvollziehbare Zustände.

Praxisbeispiel: Doppelte Mengenmeldung vermeiden

Das folgende Beispiel ist fiktiv. Ein Gateway meldet, dass zu einem Auftrag zehn weitere Teile bestätigt wurden. Die Nachricht wird mit QoS 1 übertragen. Durch einen Wiederholungsfall erhält die empfangende Anwendung dieselbe fachliche Meldung zweimal.

Wenn sie bei jedem Empfang ungeprüft zehn Teile addiert, entstehen 20 gebuchte Teile, obwohl nur zehn bestätigt wurden. Die Anwendung sollte deshalb eine geeignete Ereigniskennung und eine Regel zur Erkennung bereits verarbeiteter Meldungen verwenden. Die Kennung muss dabei zur fachlichen Meldung gehören und darf nicht bei jeder erneuten Übertragung beliebig neu erzeugt werden.

Eine andere Gestaltung kann einen kumulativen Zählerstand übertragen. Dann entstehen jedoch zusätzliche Fragen: Wann wurde der Zähler zurückgesetzt? Welcher Auftrag gehört zu welchem Abschnitt? Wie werden verspätete Werte behandelt? Keine der Varianten erspart die fachliche Spezifikation.

Für Betriebsdatenerfassung ist deshalb das Zusammenspiel von Übertragung und Buchungslogik entscheidend. Das Protokoll kann eine zuverlässige Kommunikation unterstützen; es definiert nicht automatisch eine korrekte Mengenbilanz.

Gespeicherte Zustände und Verbindungsabbrüche

Eine Retained Message kann einem neu abonnierenden Teilnehmer einen zuletzt gespeicherten Wert zu einem Topic bereitstellen. Sie ist kein vollständiges Historienarchiv. Ein Empfänger sollte außerdem beurteilen können, wie alt die Information ist. Ein gespeicherter Status kann technisch korrekt zugestellt werden und trotzdem für eine aktuelle Entscheidung veraltet sein.

Ein Will-Mechanismus ermöglicht eine Nachricht bei bestimmten unerwarteten Verbindungsabbrüchen. Er kann helfen, den Kommunikationszustand sichtbar zu machen. Daraus folgt jedoch nicht automatisch eine Diagnose des physischen Maschinenzustands. Eine getrennte Verbindung bedeutet beispielsweise nicht zwingend, dass die Maschine stillsteht.

Bei Unterbrechungen sind Sitzungsdauer, Pufferspeicherung und gegebenenfalls Ablaufzeiten von Nachrichten relevant. Welche Daten nach einer Wiederverbindung verfügbar sind, hängt von Version, Implementierung und Konfiguration ab. Diese Fälle sollten ausdrücklich getestet werden.

MQTT und OPC UA

OPC UA umfasst unter anderem Informationsmodellierung und Kommunikationsdienste. MQTT konzentriert sich auf die Nachrichtenvermittlung. Die Technologien können zusammen eingesetzt werden, beispielsweise wenn OPC-UA-PubSub-Daten über MQTT verteilt werden.

Die Auswahl ist deshalb nicht sinnvoll als pauschale Frage „welcher Standard ist besser?“ zu beantworten. Für eine Anwendung sind Datenmodell, Kommunikationsmuster, vorhandene Systeme und Betriebsanforderungen zu prüfen. Unterschiedliche Aufgaben können unterschiedliche Kombinationen benötigen.

Einführung und Betrieb in der Produktion

Anwendungsfall festlegen: Datenverteilung, Ereignismeldung oder andere Aufgabe eindeutig beschreiben.
Datenmodell vereinbaren: Kennungen, Einheiten, Zeitstempel und Versionierung bestimmen.
Kommunikation auslegen: Topics, Zustellstufen und Sitzungsverhalten passend wählen.
Zugriffe regeln: Berechtigte Sender und Empfänger sowie erforderlichen Schutz festlegen.
Ausnahmefälle prüfen: Wiederholung, Unterbrechung, Neustart und veraltete Nachrichten testen.
Betrieb sichern: Zuständigkeiten, Überwachung und Änderungen organisieren.

MQTT allein verschlüsselt nicht automatisch jede Verbindung. Geeignete Transportabsicherung, Authentifizierung und Topic-Berechtigungen gehören zur konkreten Umsetzung. Der Broker wird zu einer wichtigen Infrastrukturkomponente. Seine Verfügbarkeit und Wiederherstellung müssen zum Produktionsbedarf passen.

Für zeitkritische Steuerungs- oder Sicherheitsaufgaben reicht die allgemeine Verwendung von MQTT nicht als Eignungsnachweis. Die gesamte Architektur und das erforderliche Verhalten müssen bewertet werden. Für viele Anwendungen steht dagegen die verlässliche Bereitstellung von Maschinendaten an Auswertungen im Vordergrund.

Häufige Fragen zu MQTT

Ist MQTT eine Datenbank?

Nein. MQTT ist ein Nachrichtenprotokoll. Ein Broker kann je nach Funktionen und Konfiguration bestimmte Nachrichten oder Sitzungszustände speichern, ersetzt damit aber nicht automatisch ein Historien- oder Analysesystem. Wer langfristige Verläufe benötigt, muss deren Speicherung und Auswertung gesondert vorsehen. Eine Retained Message enthält nicht die vollständige Geschichte eines Topics.

Garantiert QoS 2 eine einmalige Auftragsbuchung?

Nicht allein. Die Protokollstufe behandelt die Zustellung im jeweiligen Austausch. Die nachgelagerte Anwendung kann unabhängig davon Fehler, Wiederanläufe oder eigene Wiederholungen besitzen. Für eine genau einmal wirksame fachliche Buchung müssen auch Datenbankverarbeitung und Ereignislogik entsprechend ausgelegt sein. Kommunikationsbestätigung und Geschäftsvorgang sind getrennt zu betrachten.

Muss der Broker in der Cloud laufen?

Nein. Ein Broker kann lokal oder in einer anderen geeigneten Infrastruktur betrieben werden. Die Entscheidung hängt unter anderem von Verfügbarkeit, Datenwegen und Betriebsverantwortung ab. Edge Computing und zentrale Verarbeitung können kombiniert werden. Eine Cloud ist kein notwendiges Definitionsmerkmal von MQTT.

Warum sind Zeitstempel im Payload sinnvoll?

Sie helfen, die tatsächliche Entstehung einer Information vom späteren Empfang zu unterscheiden. Nach Unterbrechungen oder bei gespeicherten Nachrichten kann eine alte Meldung neu eintreffen. Ohne geeigneten Zeitbezug könnte sie als aktueller Zustand interpretiert werden. Die verwendete Zeitbasis und die Bedeutung des Zeitstempels müssen deshalb gemeinsam festgelegt sein.

Was unterscheidet MQTT 3.1.1 von MQTT 5.0?

MQTT 5.0 ergänzt gegenüber 3.1.1 zusätzliche Protokollfunktionen und Eigenschaften, unter anderem differenziertere Rückmeldungen und Regeln zu Sitzungen oder Nachrichtenablauf. Welche Funktionen ein Produkt unterstützt, muss konkret geprüft werden. Für eine bestehende Integration sind Kompatibilität und benötigte Funktionen wichtiger als die Versionsnummer allein.

Quellen und weiterführende Informationen

MQTT.org: The Standard for IoT Messaging, Grundprinzip.
OASIS: MQTT Version 5.0, Standard vom 7. März 2019.
OPC Foundation: OPC UA PubSub – MQTT.

Stand: Oktober 2026. Das Mengenbeispiel und der Topic-Pfad sind fiktiv.