Ein Sensor überträgt seinen Messwert jede Sekunde per MQTT an einen Broker. Im normalen Betrieb entsteht eine scheinbar lückenlose Messreihe. Nach einer kurzen Netzwerkunterbrechung fehlen jedoch einzelne Werte – oder derselbe Datensatz taucht plötzlich zweimal in der Datenbank auf. Beides muss kein Fehler des Sensors oder des MQTT-Brokers sein. Entscheidend ist unter anderem, welche Quality-of-Service-Stufe für die Übertragung verwendet wird und wie die nachgelagerte Datenverarbeitung mit verlorenen beziehungsweise erneut übertragenen Nachrichten umgeht.
MQTT unterscheidet zwischen QoS 0 „At most once“, QoS 1 „At least once“ und QoS 2 „Exactly once“. Eine höhere QoS-Stufe bietet mehr Absicherung bei der Übertragung, benötigt dafür aber zusätzliche Kommunikationsschritte. Für industrielle Messdaten ist deshalb nicht automatisch QoS 2 die beste Wahl. Ein fehlender Zwischenwert einer sekündlich aktualisierten Temperaturmessung kann beispielsweise unkritisch sein, während der Verlust eines einmalig erzeugten Qualitätsdatensatzes die spätere Dokumentation unvollständig machen kann.
Zusätzlich löst die QoS-Stufe nicht alle Probleme einer industriellen Datenübertragung. Bei längeren Offline-Phasen muss geklärt werden, ob Messwerte lokal zwischengespeichert werden. Bei nachträglich übertragenen Daten ist der ursprüngliche Messzeitpunkt wichtig. Bei QoS 1 muss eine Anwendung mögliche Dubletten erkennen können. Und bei großen IIoT-Installationen spielen Übertragungsintervall, Anzahl der Sensoren, Brokerlast und Datenverdichtung eine ebenso wichtige Rolle wie die eigentliche QoS-Einstellung.
Die richtige MQTT-QoS-Stufe wird deshalb nicht nach dem Prinzip „je höher, desto besser“ ausgewählt. Entscheidend ist, welche Bedeutung der einzelne Datensatz besitzt, welcher Informationsverlust zulässig ist und wie die komplette Datenkette vom Sensor bis zur Datenbank aufgebaut ist.
Was bedeutet MQTT Quality of Service?
Die MQTT Quality of Service beschreibt die Zustelllogik einer Nachricht. Sie hat nichts mit der Messgenauigkeit des Sensors zu tun. Ein Temperaturwert von 82,4 °C wird durch QoS 2 nicht genauer als durch QoS 0. Die QoS-Stufe bestimmt lediglich, wie die Nachricht zwischen den beteiligten MQTT-Komponenten übertragen und bestätigt wird.
Für die Auswahl ist deshalb vor allem die Bedeutung der einzelnen Nachricht relevant. Wird ein Prozesswert im Sekundentakt aktualisiert, kann der nächste Messwert bereits kurz nach einem verlorenen Telegramm zur Verfügung stehen. Ein einmalig erzeugter Datensatz, beispielsweise für einen abgeschlossenen Produktionszyklus, besitzt dagegen möglicherweise keine zweite Gelegenheit zur Übertragung. Genau diese unterschiedliche Bedeutung der Daten muss vor der Festlegung der QoS-Stufe bewertet werden.
MQTT QoS 0: At most once
QoS 0 arbeitet nach dem Prinzip „At most once“, also höchstens einmal. Der Publisher sendet die MQTT-Nachricht, ohne eine bestätigte Zustellung auf dieser QoS-Stufe abzuwarten. Wird die Nachricht während einer Kommunikationsstörung nicht erfolgreich übertragen, erfolgt aufgrund von QoS 0 keine Wiederholung. Einzelne Werte können deshalb verloren gehen.
Für kontinuierlich aktualisierte Messwerte muss das nicht zwangsläufig problematisch sein. Wird beispielsweise jede Sekunde ein Druckwert für ein Live-Dashboard übertragen und fehlt während einer kurzen Störung genau ein Datenpunkt, steht eine Sekunde später bereits wieder ein aktueller Wert zur Verfügung. Wenn die vollständige historische Aufzeichnung jedes einzelnen Zwischenwertes nicht gefordert ist, kann QoS 0 deshalb eine technisch sinnvolle Lösung sein. Der Vorteil liegt im vergleichsweise geringen Kommunikations- und Verarbeitungsaufwand.
MQTT QoS 1: At least once
QoS 1 arbeitet nach dem Prinzip „At least once“, also mindestens einmal. Der Empfang einer Nachricht wird bestätigt. Bleibt die erwartete Bestätigung aus, kann der Sender die Nachricht erneut übertragen. Damit wird das Risiko eines unbemerkten Nachrichtenverlustes gegenüber QoS 0 deutlich reduziert.
Dieses Verfahren hat jedoch eine wichtige Konsequenz: Derselbe Datensatz kann mehr als einmal beim Empfänger eintreffen. Das passiert beispielsweise dann, wenn die ursprüngliche Nachricht erfolgreich angekommen ist, die Bestätigung auf dem Rückweg jedoch verloren geht. Der Sender kann dann nicht sicher erkennen, ob die erste Übertragung erfolgreich war, und sendet die Nachricht erneut. Für Messdatenanwendungen bedeutet das, dass QoS 1 besonders gut geeignet sein kann, wenn der Verlust eines Datensatzes kritischer wäre als eine mögliche Dublette – vorausgesetzt, die nachgelagerte Software kann wiederholt empfangene Datensätze erkennen.
MQTT QoS 2: Exactly once
QoS 2 verwendet einen umfangreicheren Nachrichtenaustausch, um eine Nachricht innerhalb der MQTT-Kommunikation genau einmal zuzustellen. Damit wird sowohl der Verlust als auch die doppelte MQTT-Zustellung stärker abgesichert. Dieser zusätzliche Schutz benötigt jedoch mehr Protokollschritte und damit mehr Kommunikations- und Verarbeitungsaufwand.
Bei wenigen Geräten und niedrigen Datenraten ist dieser Mehraufwand häufig unkritisch. In Installationen mit hunderten oder tausenden Datenquellen und kurzen Übertragungsintervallen kann er dagegen relevant werden. Zudem darf „Exactly once“ nicht als Garantie verstanden werden, dass ein Datensatz im gesamten IT-System automatisch genau einmal verarbeitet wird. Nach der MQTT-Zustellung können weitere Ebenen wie Anwendungen, Datenbanken oder Analyseprozesse folgen, die ihre eigene Verarbeitungssicherheit benötigen.
QoS 0, 1 und 2 im Vergleich
| Kriterium | QoS 0 | QoS 1 | QoS 2 |
|---|---|---|---|
| Prinzip | At most once | At least once | Exactly once |
| Bestätigte Zustellung | Nein | Ja | Erweiterter Nachrichtenaustausch |
| Verlust einzelner Nachrichten | Möglich | Stärker abgesichert | Stärker abgesichert |
| Doppelte MQTT-Zustellung | Nicht durch QoS-Wiederholung vorgesehen | Möglich | Durch QoS-2-Verfahren vermieden |
| Kommunikationsaufwand | Niedrig | Mittel | Hoch |
| Typischer Einsatz | Schnell aktualisierte, verlusttolerante Daten | Messdaten mit hoher Anforderung an Vollständigkeit | Nachrichten mit hoher Anforderung an einmalige MQTT-Zustellung |
Die Tabelle zeigt, weshalb eine pauschale Empfehlung wie „für industrielle Anwendungen immer QoS 2“ nicht sinnvoll ist. Ein sich ständig aktualisierender Messwert stellt eine andere Anforderung als ein einmaliger Prüfdatensatz. Die Auswahl muss sich deshalb am Informationswert der Nachricht orientieren und nicht allein an der maximal verfügbaren Zustellsicherheit.
Welche QoS-Stufe eignet sich für Messdaten?
Für Messdaten sollte zunächst geklärt werden, was passiert, wenn genau ein Datensatz fehlt. Bei einem Live-Wert kann der Informationsverlust sehr gering sein, weil bereits kurz darauf der nächste aktuelle Wert übertragen wird. Bei einer historischen Prozessaufzeichnung kann eine Lücke dagegen eine spätere Analyse erschweren. Noch kritischer kann der Verlust eines einmalig erzeugten Prüf- oder Qualitätsdatensatzes sein.
| Datenart | Typische Anforderung | Mögliche QoS-Tendenz |
|---|---|---|
| Live-Anzeige eines Prozesswertes | Aktueller Wert wichtiger als jeder Zwischenwert | QoS 0 kann ausreichend sein |
| Historische Prozessaufzeichnung | Möglichst wenige Datenlücken | QoS 1 kann sinnvoll sein |
| Einmaliger Prüf- oder Qualitätsdatensatz | Datensatz darf möglichst nicht verloren gehen | QoS 1 oder QoS 2 prüfen |
| Ereignis- oder Alarmmeldung | Einzelne Nachricht kann hohe Bedeutung besitzen | Höhere Zustellsicherheit sinnvoll |
| Viele schnell sendende Sensoren | Broker- und Netzwerklast begrenzen | QoS gegen Datenrate abwägen |
Damit kann selbst innerhalb derselben Maschine eine Kombination unterschiedlicher QoS-Stufen sinnvoll sein. Ein kontinuierlich übertragener Druckwert kann beispielsweise mit QoS 0 gesendet werden, während eine einmalig erzeugte Störmeldung oder ein Qualitätsdatensatz mit QoS 1 übertragen wird. Die QoS-Stufe ist damit häufig eher eine Eigenschaft des Datentyps als des gesamten Gerätes.
Warum entstehen bei QoS 1 doppelte Nachrichten?
Eine doppelte Nachricht bei QoS 1 ist nicht zwangsläufig ein Kommunikationsfehler, sondern kann direkte Folge des vorgesehenen Zustellprinzips sein. Angenommen, ein Sensor sendet einen Messwert erfolgreich an den Broker. Der Broker bestätigt den Empfang, doch genau diese Bestätigung geht während einer kurzen Netzwerkunterbrechung verloren. Für den Sender ist nun nicht eindeutig erkennbar, ob die ursprüngliche Nachricht angekommen ist. Er kann sie deshalb erneut übertragen.
Werden beide Nachrichten anschließend ohne weitere Prüfung in einer Datenbank gespeichert, entstehen zwei scheinbar unterschiedliche Messungen. Für Messdaten sollte deshalb möglichst nicht allein der Empfangszeitpunkt zur Identifikation verwendet werden. Ein ursprünglicher Messzeitpunkt, eine Sequenznummer oder eine eindeutige Datensatzkennung kann der nachgelagerten Anwendung ermöglichen, Wiederholungen zu erkennen. Ein Datensatz könnte beispielsweise logisch aus Sensor-ID + Zeitstempel + Sequenznummer + Messwert bestehen. Wird dieselbe Kombination erneut empfangen, kann die Anwendung sie als Wiederholung behandeln.
QoS 1 funktioniert besonders gut, wenn die Anwendung nach dem Grundsatz aufgebaut ist: Eine Dublette ist beherrschbar, ein verlorener relevanter Datensatz dagegen nicht.
QoS und Offline-Phasen richtig unterscheiden
Eine höhere QoS-Stufe ersetzt keine vollständige Offline-Datenspeicherung. Fällt beispielsweise die Netzwerkverbindung eines IIoT-Gateways für 30 Minuten aus, stellt sich zunächst die Frage, wo die während dieser Zeit erfassten Messwerte gespeichert werden. QoS beschreibt die Zustellung von MQTT-Nachrichten, löst aber nicht automatisch die Speicherung beliebig vieler noch nicht übertragbarer Messdaten.
| Situation | Rolle von QoS | Zusätzliche Anforderung |
|---|---|---|
| Kurze Unterbrechung während einer Übertragung | QoS beeinflusst Bestätigung und Wiederholung | Passende QoS-Stufe wählen |
| Gateway längere Zeit ohne Verbindung | QoS allein nicht ausreichend | Lokale Zwischenspeicherung prüfen |
| Broker längere Zeit nicht erreichbar | QoS ist nur Teil des Verhaltens | Publisher-, Session- und Speicherstrategie festlegen |
| Historische Messreihe muss vollständig bleiben | Zustellsicherheit wichtig | Zeitstempel, Pufferung und Nachübertragung berücksichtigen |
Wenn historische Messdaten auch bei längeren Kommunikationsausfällen vollständig erhalten bleiben sollen, ist deshalb häufig eine Store-and-Forward-Strategie erforderlich. Das Gateway speichert die Daten lokal und überträgt sie nach Wiederherstellung der Verbindung. Dabei muss geprüft werden, wie groß der lokale Speicher ist, wie lange er bei der vorgesehenen Datenrate ausreicht und wie sich das System verhält, wenn nach einem längeren Ausfall sehr viele gespeicherte Datensätze in kurzer Zeit nachträglich übertragen werden.
Zeitstempel und zeitliche Zuordnung von Messdaten
Gerade bei nachträglich übertragenen Messwerten ist der ursprüngliche Messzeitpunkt wichtiger als der spätere Empfangszeitpunkt. Ein Sensor kann beispielsweise um 10:15:03 messen, während die Nachricht aufgrund einer unterbrochenen Verbindung erst um 10:27:40 beim übergeordneten System ankommt. Würde ausschließlich der Empfangszeitpunkt gespeichert, läge der Messwert in der historischen Zeitreihe mehr als zwölf Minuten zu spät.
Der ursprüngliche Zeitstempel sollte deshalb möglichst Bestandteil des Messdatensatzes sein. Das ist besonders wichtig, wenn Daten aus mehreren Maschinen oder Gateways miteinander korreliert werden, wenn Messwerte nach einer Offline-Phase gesammelt übertragen werden oder wenn Ereignisse später zeitlich genau rekonstruiert werden müssen. Voraussetzung dafür ist wiederum eine geeignete Zeitsynchronisation der beteiligten Komponenten.
QoS, Datenrate und Brokerlast
Bei kleinen Anwendungen fällt der zusätzliche Kommunikationsaufwand höherer QoS-Stufen häufig kaum auf. Die Betrachtung ändert sich jedoch mit der Anzahl der Geräte und der Übertragungsfrequenz. Bereits 100 Sensoren, die jede Sekunde eine Nachricht senden, erzeugen 8.640.000 Messnachrichten pro Tag. Bei 1.000 Sensoren wären es unter denselben Bedingungen 86.400.000 Messnachrichten pro Tag. Zusätzliche Bestätigungen und Verarbeitungsschritte können sich bei solchen Größenordnungen deutlich summieren.
Deshalb sollte nicht nur die Payload-Größe betrachtet werden. Relevant sind ebenfalls Anzahl der Publisher, Anzahl der Subscriber, Übertragungsintervall, Topic-Struktur, QoS-Stufe sowie die Leistungsfähigkeit von Broker, Netzwerk und nachgelagerter Datenbank. Eine unnötig hohe QoS-Stufe kann ebenso ineffizient sein wie eine unnötig hohe Übertragungsrate.
Wichtig ist zudem die Unterscheidung zwischen Messrate und Übertragungsrate. Ein Sensor kann intern beispielsweise mit 100 Messungen pro Sekunde arbeiten, während für die zentrale Anlagenüberwachung vielleicht nur ein Messwert pro Sekunde benötigt wird. Abhängig von der Anwendung können Mittelwerte, Minimal- und Maximalwerte, Änderungsschwellen oder ereignisabhängige Übertragungen die Datenmenge reduzieren. Eine solche Verdichtung darf allerdings keine Informationen entfernen, die später benötigt werden – beispielsweise kurze Druckspitzen oder schnelle Schwingungsereignisse.
Praxisbeispiel: Messdaten einer Produktionsmaschine
Eine Produktionsmaschine erfasst Druck, Temperatur, Durchfluss und weitere Prozessgrößen. Die Werte werden über ein IIoT-Gateway an einen zentralen MQTT-Broker übertragen. Der Druckwert dient hauptsächlich zur Live-Darstellung des aktuellen Maschinenzustandes und wird jede Sekunde gesendet. Während einer kurzen Kommunikationsunterbrechung fehlt ein einzelner Messpunkt. Da bereits eine Sekunde später der nächste aktuelle Wert zur Verfügung steht und die vollständige Sekundenhistorie für diese Anzeige nicht benötigt wird, kann QoS 0 hier ausreichend sein.
Nach jedem abgeschlossenen Fertigungszyklus erzeugt dieselbe Maschine zusätzlich einen Qualitätsdatensatz. Dieser enthält beispielsweise Zyklusnummer, maximalen Prozessdruck, Temperatur und Prüfergebnis. Dieser Datensatz wird nur einmal pro Zyklus erzeugt. Geht die Nachricht verloren, fehlt die Dokumentation für genau diesen Produktionsvorgang. Hier kann QoS 1 sinnvoll sein, wenn die empfangende Anwendung mögliche Dubletten anhand der Zyklusnummer beziehungsweise einer eindeutigen Datensatzkennung erkennt.
Fällt die Netzwerkverbindung dagegen für 15 Minuten vollständig aus, hilft auch die höhere QoS-Stufe allein nicht weiter. Soll die Dokumentation vollständig bleiben, muss das Gateway die während dieser Zeit entstehenden Datensätze lokal speichern und später nachübertragen. Dabei bleiben die ursprünglichen Messzeitpunkte erhalten, damit die Daten nachträglich wieder korrekt in die Prozesshistorie eingeordnet werden können.
Das Beispiel zeigt: Nicht die gesamte Maschine benötigt zwangsläufig eine einzige QoS-Stufe. Kontinuierliche Prozesswerte, Qualitätsdatensätze und Ereignismeldungen können unterschiedliche Anforderungen an Zustellsicherheit, Dublettenerkennung und Offline-Speicherung besitzen.
Systematische Auswahl der QoS-Stufe
- Zunächst festlegen, welche Messwerte, Zustandsinformationen und Ereignisse übertragen werden und welche Bedeutung der einzelne Datensatz besitzt.
- Bewerten, welche Folgen ein verlorener Messwert hätte und ob ein späterer aktueller Wert die fehlende Information praktisch ersetzt.
- Bei historischen oder einmaligen Datensätzen festlegen, wie vollständig die Übertragung sein muss und ob QoS 1 beziehungsweise QoS 2 erforderlich ist.
- Bei QoS 1 eine eindeutige Identifikation von Messdatensätzen vorsehen, damit mögliche Dubletten erkannt werden können.
- Messrate und Übertragungsrate getrennt betrachten und prüfen, ob eine lokale Datenverdichtung sinnvoll ist.
- Anzahl der Publisher, Subscriber, Nachrichtenrate und Brokerleistung in die Auslegung einbeziehen.
- Für längere Kommunikationsausfälle festlegen, ob lokale Zwischenspeicherung und Store-and-Forward benötigt werden.
- Den ursprünglichen Messzeitpunkt im Datensatz erhalten, wenn Daten verzögert übertragen werden können.
- Netzwerkunterbrechungen, Broker-Neustarts und Wiederverbindungen gezielt testen und anschließend auf fehlende beziehungsweise doppelte Datensätze prüfen.
Häufige Fehler
- Grundsätzlich QoS 2 für alle Daten verwenden: Die höchste Zustellabsicherung ist nicht automatisch die effizienteste Lösung. Schnell aktualisierte unkritische Messwerte können mit QoS 0 sinnvoll übertragen werden.
- QoS 1 mit „genau einmal“ verwechseln: At least once bedeutet ausdrücklich, dass eine Nachricht mehrfach beim Empfänger eintreffen kann.
- Dubletten nicht bei der Datenstruktur berücksichtigen: Ohne Zeitstempel, Sequenznummer oder eindeutige Datensatzkennung lassen sich wiederholte Nachrichten schwer von echten neuen Messungen unterscheiden.
- QoS mit Offline-Speicherung gleichsetzen: Längere Netzwerkausfälle erfordern gegebenenfalls zusätzlich eine lokale Datenpufferung.
- Nur den Empfangszeitpunkt speichern: Nachträglich übertragene Messwerte können dadurch an der falschen Stelle in der historischen Zeitreihe erscheinen.
- Messrate und Übertragungsrate gleichsetzen: Nicht jeder intern erfasste Sensorwert muss zwangsläufig über MQTT an ein zentrales System übertragen werden.
- Alle Datenarten identisch behandeln: Ein Live-Prozesswert, eine Alarmmeldung und ein Qualitätsdatensatz können völlig unterschiedliche Anforderungen an die Zustellung besitzen.
- Offline-Szenarien nicht testen: Probleme mit Wiederholung, Nachübertragung oder Datenverlust werden dann häufig erst bei einer realen Kommunikationsstörung sichtbar.
IIoT-Lösungen für industrielle Messdaten
Für eine zuverlässige industrielle Messdatenübertragung muss die komplette Kette betrachtet werden: Sensorik, Datenerfassung, Edge- beziehungsweise Gateway-Komponente, Netzwerk, MQTT-Broker und nachgelagerte Datenplattform. Die reine Unterstützung des MQTT-Protokolls sagt noch nicht aus, ob eine Lösung für die jeweilige Messaufgabe geeignet ist.
Je nach Anwendung können insbesondere lokale Datenvorverarbeitung, Zeitstempelung, Datenverdichtung, Zwischenspeicherung bei Kommunikationsausfällen und eine kontrollierte Nachübertragung relevant sein. Ein Edge-Gateway kann beispielsweise schnelle Rohdaten lokal verarbeiten und nur die für Betrieb, Analyse oder Dokumentation tatsächlich benötigten Informationen an den Broker übertragen. Dadurch lassen sich Netzwerkbelastung, Brokerlast und langfristiger Speicherbedarf reduzieren.
Passende Komponenten und Systeme für die Erfassung, Verarbeitung und Übertragung industrieller Mess- und Prozessdaten finden Sie unter IIoT-Lösungen bei ICS Schneider.
Fazit
MQTT QoS 0, 1 und 2 lösen unterschiedliche Aufgaben. QoS 0 bietet einen geringen Kommunikationsaufwand, akzeptiert dafür aber mögliche Nachrichtenverluste. QoS 1 erhöht die Zustellsicherheit, kann jedoch zu mehrfach empfangenen Nachrichten führen. QoS 2 verhindert die doppelte MQTT-Zustellung mit einem zusätzlichen Protokollaufwand.
Für industrielle Messdaten ist deshalb zuerst die Bedeutung des einzelnen Datensatzes zu bewerten. Ein sekündlich aktualisierter Live-Wert kann anders behandelt werden als ein einmaliger Qualitätsdatensatz oder eine Störmeldung. Ebenso wichtig ist die Frage, wie mit längeren Offline-Phasen umgegangen wird. Wenn historische Daten vollständig bleiben müssen, gehören lokale Pufferung, ursprüngliche Zeitstempel und kontrollierte Nachübertragung ebenso zum Konzept wie die QoS-Stufe.
Auch die Datenmenge sollte nicht unterschätzt werden. In großen IIoT-Systemen können bereits kleine Unterschiede beim Übertragungsintervall oder bei der Anzahl der Kommunikationsschritte erhebliche Auswirkungen auf Broker, Netzwerk und Datenbank haben. Deshalb sollten Messrate, Übertragungsrate, Datenverdichtung und Zustellsicherheit gemeinsam betrachtet werden.
Für eine zuverlässige MQTT-Messdatenübertragung gilt somit: Nicht möglichst hohe QoS wählen, sondern für jede Datenart festlegen, welcher Informationsverlust zulässig ist, wie Dubletten behandelt werden und wie sich das gesamte System bei realen Kommunikationsstörungen verhalten soll.
FAQ: MQTT QoS 0, 1 und 2 für Messdaten
Was ist der Unterschied zwischen MQTT QoS 0, QoS 1 und QoS 2?
QoS 0 arbeitet nach „At most once“, QoS 1 nach „At least once“ und QoS 2 nach „Exactly once“. Mit steigender QoS-Stufe nimmt die Absicherung der MQTT-Zustellung zu, gleichzeitig steigt jedoch auch der Kommunikations- und Verarbeitungsaufwand.
Ist MQTT QoS 2 immer besser als QoS 1?
Nein. QoS 2 benötigt einen umfangreicheren Nachrichtenaustausch. Wenn mögliche Dubletten zuverlässig erkannt werden können, kann QoS 1 für viele Messdatenanwendungen einen sinnvollen Kompromiss zwischen Zustellsicherheit und Aufwand darstellen.
Warum entstehen bei MQTT QoS 1 doppelte Nachrichten?
Wenn die ursprüngliche Nachricht angekommen ist, die zugehörige Bestätigung jedoch verloren geht, kann der Sender die Nachricht erneut übertragen. Der Empfänger erhält dadurch denselben Datensatz möglicherweise mehrfach.
Wie lassen sich doppelte MQTT-Messwerte erkennen?
Messdatensätze können beispielsweise einen ursprünglichen Zeitstempel, eine Sequenznummer und eine eindeutige Geräte- beziehungsweise Datensatzkennung enthalten. Damit lässt sich prüfen, ob ein Datensatz tatsächlich neu ist oder lediglich erneut übertragen wurde.
Ist QoS 0 für industrielle Sensordaten geeignet?
Ja, wenn ein einzelner verlorener Zwischenwert tolerierbar ist. Das kann beispielsweise bei häufig aktualisierten Live-Prozesswerten der Fall sein, bei denen kurze Zeit später bereits der nächste aktuelle Messwert zur Verfügung steht.
Welche QoS-Stufe eignet sich für historische Messdaten?
Wenn möglichst keine Datensätze fehlen sollen, kann QoS 1 sinnvoll sein, sofern mögliche Dubletten erkannt werden. Bei besonders hohen Anforderungen kann QoS 2 geprüft werden. Für längere Offline-Phasen sind zusätzlich lokale Speicherung und Nachübertragung zu berücksichtigen.
Verhindert QoS 2 Datenverlust bei einem längeren Netzwerkausfall?
Nein. QoS 2 ersetzt keine lokale Datenspeicherung. Wenn während einer längeren Offline-Phase weiter Messwerte entstehen, muss separat sichergestellt werden, dass diese gespeichert und später wieder übertragen werden können.
Warum sollte ein MQTT-Messwert einen eigenen Zeitstempel enthalten?
Bei einer verzögerten Übertragung entspricht der Empfangszeitpunkt nicht mehr dem tatsächlichen Messzeitpunkt. Ein eigener Zeitstempel ermöglicht die korrekte zeitliche Einordnung in der historischen Messreihe.
Beeinflusst MQTT QoS die Messgenauigkeit?
Nein. Die QoS-Stufe beeinflusst die Nachrichtenübertragung, nicht die messtechnische Genauigkeit des Sensors oder des übertragenen Messwertes.
Erhöht eine höhere MQTT-QoS-Stufe die Kommunikationslast?
Ja. Höhere QoS-Stufen benötigen zusätzliche Kommunikationsschritte und Bestätigungen. Bei wenigen Geräten ist der Unterschied häufig unkritisch, bei vielen Sensoren und kurzen Übertragungsintervallen kann er sich jedoch deutlich summieren.
Sollten alle Daten eines Sensors mit derselben QoS-Stufe übertragen werden?
Nicht zwangsläufig. Ein kontinuierlich aktualisierter Prozesswert kann beispielsweise andere Anforderungen besitzen als eine einmalige Alarm- oder Qualitätsmeldung. Unterschiedliche Topics beziehungsweise Datentypen können deshalb unterschiedliche QoS-Stufen verwenden.
Was ist wichtiger: MQTT QoS oder lokale Datenpufferung?
Beide erfüllen unterschiedliche Aufgaben. QoS bestimmt die Zustelllogik einer MQTT-Nachricht. Eine lokale Pufferung schützt dagegen Messdaten, die während einer längeren Kommunikationsunterbrechung noch gar nicht übertragen werden können.
Wie wählt man die richtige MQTT-QoS-Stufe für Messdaten?
Zunächst sollte bewertet werden, welche Folgen ein verlorener oder doppelter Datensatz hätte. Danach werden Übertragungsrate, Brokerlast, Offline-Verhalten, Zeitstempelung und die Möglichkeit zur Dublettenerkennung berücksichtigt. Erst daraus ergibt sich die für die jeweilige Datenart geeignete QoS-Stufe.