Inhalt
  1. Publisher, Broker und Subscriber
  2. Ein kleines Datenmodell zahlt sich aus
  3. Zustellqualität ist keine Geschäftslogik
  4. Mit lesender Telemetrie beginnen
  5. Quellen

Eine Maschine sendet ihren Energieverbrauch. Ein Dashboard zeigt ihn an, ein Archiv speichert ihn und eine Auswertung sucht nach Abweichungen. Ein Publish-Subscribe-System erlaubt, dieselbe Meldung an mehrere interessierte Empfänger zu verteilen, ohne dass der Sender jeden davon einzeln kennen muss.

Publisher, Broker und Subscriber

MQTT.org beschreibt MQTT als leichtgewichtiges OASIS-Nachrichtenprotokoll für das Internet der Dinge. Ein Publisher veröffentlicht Nachrichten zu einem Topic. Ein Broker übernimmt die Verteilung an Subscriber, die passende Topics abonniert haben. Das eignet sich für entkoppelte Datenwege, beispielsweise zwischen Messgerät, Archiv und Visualisierung.

Die Entkopplung schafft Flexibilität, erfordert aber klare Konventionen. Der Name eines Topics sollte verständlich ausdrücken, wozu die Daten gehören. Ebenso muss die Nutzlast dokumentiert sein. Ein Transportprotokoll entscheidet nicht von allein, ob eine Zahl eine Momentanleistung oder einen fortlaufenden Energiezähler darstellt.

Ein kleines Datenmodell zahlt sich aus

Feld Zweck
Quelle Maschine oder Messstelle eindeutig erkennen
Zeitstempel Messung zeitlich einordnen
Wert und Einheit Physikalische Bedeutung erhalten
Status Gültige und gestörte Daten unterscheiden

Bei einem Zählerstand ist zusätzlich wichtig, ob der Zähler zurückgesetzt werden kann. Bei einer Zustandsmeldung muss klar sein, ob sie eine Änderung oder den aktuellen Gesamtzustand beschreibt. Ohne solche Regeln entstehen leicht fehlerhafte Auswertungen, obwohl die Übertragung technisch funktioniert.

Zustellqualität ist keine Geschäftslogik

MQTT definiert verschiedene Quality-of-Service-Stufen. Sie betreffen die Nachrichtenzustellung. Daraus sollte keine pauschale Garantie abgeleitet werden, dass eine nachgelagerte Bestellung oder Buchung genau einmal ausgeführt wird. Empfänger benötigen bei solchen Aktionen eine eigene Vorgangskennung und passende Verarbeitung.

Ebenso verdient ein Wiederverbinden Aufmerksamkeit. Was macht ein Dashboard mit einer älteren Nachricht? Wie erkennt ein Archiv eine Datenlücke? Wie lange ist ein letzter bekannter Zustand noch brauchbar? Die Antworten hängen von der Anwendung ab und sollten im Test sichtbar sein.

Mit lesender Telemetrie beginnen

Ein erster Pilot kann wenige Messwerte von einer abgegrenzten Anlage an ein internes Archiv liefern. Prüfe Brokerzugriff, erlaubte Topics und das Verhalten bei Verbindungsabbruch. Für schreibende Befehle sind strengere Prozessregeln nötig als für die Darstellung von Telemetrie.

Plane Änderungen am Nachrichtenformat mit. Kommt später ein zusätzliches Feld hinzu oder ändert sich die Einheit, müssen vorhandene Empfänger weiter eindeutig reagieren können. Eine dokumentierte Versionsangabe und klare Regeln für unbekannte Felder helfen dabei. Teste das mit einem alten Empfänger, bevor die Maschine umgestellt wird. Die entkoppelte Architektur ist nur dann wartungsfreundlich, wenn Änderungen nicht unbemerkt die Bedeutung bereits gespeicherter oder neu eintreffender Daten verändern.

Unsere Einordnung: MQTT ist besonders nützlich, wenn Daten an mehrere Dienste verteilt werden sollen. Seine Einfachheit ersetzt kein gemeinsames Informationsverständnis. Wie strukturierte Maschinendaten modelliert werden, erklärt der Beitrag zu OPC UA.

Quellen & weiterführende Informationen