MQTT Quality-of-Service (QoS) – UNS Basics

Inhalt

Der Begriff Quality-of-Service (QoS) beschreibt die Qualität einer Datenübertragung mit MQTT. Diese Qualität bezieht sich hier immer auf eine eins-zu-eins Beziehung also entweder auf „Publisher zu Broker“ oder auf „Broker zu Subscriber“. Die MQTT QoS Level beschreiben in dieser eins-zu-eins Beziehung bestimmte Empfangsgarantien für die Nachrichten, welche in diesem Artikel beschrieben werden. Zudem werden Best Practices für die Industrial Unified Namespace (UNS) Architektur abgeleitet. Weitere Informationen zum Industrial Unified Namespace (UNS) finden Sie hier.

 

Was sind Quality-of-Service (MQTT QoS) Level?

Um die QoS Level bei einer Nachrichtenübertragung mittels MQTT zu verstehen, hilft es sich zunächst den Übertragungsmechanismus von MQTT zu verstehen. Die Übertragung läuft dabei in zwei Schritten ab:

  1. Publisher sendet eine Nachricht zum Broker
  2. Broker leitet diese Nachricht weiter an alle Subscriber.

Bei der Übertragung kann die Nachricht also theoretisch an zwei Stellen verloren gehen: „Publisher zu Broker“ und „Broker zu Subscriber“. Folglich kann sowohl der Publisher als auch der Subscriber ein MQTT QoS Level festlegen. Dies bedeutet auch: Sollten die Level von Publisher und Subscriber nicht übereinstimmen, sendet der Broker die Nachricht immer mit dem vom Subscriber angeforderten QoS Level. Damit kann es also auftreten, dass trotz eines hohen QoS Levels der Broker die Nachricht mit einem niedrigeren QoS Level weiterleitet.

MQTT Message Transmission from Publisher via Broker to Subscriber depicted in a flow chart

 

Welche MQTT QoS Level gibt es?

MQTT stellt drei Quality-of-Service Level bereit:

  • QoS 0: Nachricht wird maximal einmal empfangen (fire-and-forget),
  • QoS 1: Nachricht wird mindestens einmal empfangen und
  • QoS 2: Nachricht wird genau einmal empfangen.

Die Details der Nachrichtenübertragung werden in den folgenden Abschnitten erläutert.

Warum ist die Wahl eines QoS wichtig für ein UNS?

Mit der obigen Definition lässt sich die Auswirkung auf die Zustellung der Nachricht wie in der Tablle beschrieben zusammenfassen. In der Tabelle ist zu sehen, dass nur MQTT QoS Level 2 eine eindeutige und einmalige Zustellung garantiert. Dennoch sollten auch QoS Level 0 und 1 für ein UNS in Betracht gezogen werden. Denn neben der Zuverlässigkeit sollte bei der Wahl des QoS-Levels auch der Load des Brokers betrachtet werden. Hierbei ist es wichtig eine Balance zwischen Load und Zuverlässigkeit für jedes Topic zu finden. Eine genaue Empfehlung finden Sie im Folgenden.

QoS Publisher Subscriber
0: maximal einmal Nachricht wird einmal gesendet. Kann Nachricht erhalten (keine Garantie).
1: mindestens einmal Nachricht wird bis zur Empfangsbestätigung gesendet. Erhält Nachricht mindestens einmal. Doppelte Zustellung ist jedoch möglich.
2: genau einmal  Nachricht wird einmal gesendet. Erhält Nachricht einmal

MQTT QoS Level 0

MQTT QoS Level 0 stellt nur das einmalige Senden der Nachricht sicher, dabei wird der Empfang jedoch nicht garantiert. Hier wird also vom Sender nicht auf ein Acknowledgement gewartet. Diese Methode ist typischerweise als „Fire and Forget“ bekannt.

MQTT Message Transmission from Publisher to Broker depicted in a flow chart

Funktionsweise

Der Publisher sendet hier lediglich die Nachricht an den Broker und verwirft diese sofort, da er nicht auf ein Acknowledgement wartet.

Beispiel

Diese Level eignen sich besonders für die Zustellung einer hohen Anzahl von Nachrichten, bei der der Verlust einer Nachricht nicht wichtig ist. Ein Beispiel hierfür ist ein Sensor der Produkte am Ende einer Montagelinie zählt. In diesem Szenario veröffentlicht der Sensor immer die aktuelle Stückzahl. Damit ist der Verlust einer Nachricht nicht wichtig, da die Information (Stückzahl) auch in der nächsten enthalten ist.

MQTT QoS Level 1

MQTT QoS Level 1 stellt den einmaligen Empfang der Nachricht sicher. Dafür sendet der Sender die Nachricht, bis er ein Acknowledgement vom Empfänger erhält. Diese Methode ist etwas komplexer als QoS Level 0, da die Nachricht bis zum Erhalt erneut versendet und gespeichert werden muss.

MQTT Message Transmission QoS 1 from Publisher to Broker depicted in a flow chart

Funktionsweise

 

Die Nachrichtenübertragung im MQTT QoS Level 1 erfolgt in zwei Schritten:

  1. Zunächst sendet der Publisher sendet die Nachricht an den Broker.
  2. Der Broker antwortet mit einem Acknowledgement (PUBACK). Sollte das PUBACK nicht beim Publisher ankommen, sendet er die Nachricht erneut, bis er ein PUBACK Packet erhält.

Dies stellt sicher das bei einem (zeitweisen) Verbindungsausfall die Nachricht trotzdem am Broker ankommt. Die Komplexität dieses Verfahrens liegt damit zwischen QoS Level 0 und 2 und bietet einen guten Kompromiss zwischen Zuverlässigkeit und Effektivität. Nachteil dieses Levels ist, das eine Nachricht auch doppelt versendet werden kann. Durch einen Verbindungsausfall beim Acknowledgment (PUBACK) kann der Broker dieselbe Nachricht doppelt erhalten und im Worst Case mehrfach weiterverteilen.

Beispiel

Ein typischer Anwendungsfall für QoS Level 1 ist ein Alarm. So kann beispielsweise der offene Zustand einer Lichtschranke mittels QoS Level 1 einer zentralen Alarmstelle gesendet werden. Durch das wiederholende Senden bis zum Acknowledgement wird damit sichergestellt, dass die sicherheitskritische Nachricht beim Broker empfangen wird und notwendige Schritte eingeleitet werden können.

MQTT QoS Level 2

MQTT QoS Level 2, als kompliziertestes Level, stellt den genau einmaligen Empfang sicher. Dabei hat es den höchsten Level des Qos, hat jedoch auch die höchste Belastung für den Broker/Client und damit die langsamste Ausführung.

MQTT Message Transmission QoS 2 from Publisher to Broker depicted in a flow chart

Funktionsweise

Jede Nachricht, die per MQTT QoS Level 2 verschickt folgt vier Schritten:

  1. Zunächst sendet der Publisher die Nachricht an den Broker (Publish). Anschließend antwortet der Broker mit einem Acknowledgement (PUBREC). Dies funktioniert analog zum QoS Level 1, und stellt damit dem Empfang sicher. Auch hier werden die Nachrichten vom Publisher erneut gesendet, sollte dieser kein PUBREC Acknowledgement erhalten.
  2. Nach Erhalt des PUBREC Acknowledgements, antwortet der Publisher mit einem PUPREL Packet und löscht die Nachricht. Die Packet ID der Nachricht bleibt jedoch gespeichert, um ein erneutes Senden zu verhindern.
  3. Der Broker wiederum weiß mit der PUPREL Antwort, dass der Sender die Nachricht nicht mehr schicken wird. Somit kann er nun die gespeicherte Nachricht und Packet ID löschen. Dies bestätigt er mit PUPCOMP.
  4. Der Publisher wiederum kann mit der PUPCOMP Antwort sicher die Packet ID entfernen, da er nun sicher ist das die Nachricht beim Broker nicht doppelt empfangen wird. Die Packet ID ist jetzt wieder frei für weitere Nachrichten.

 

Sowohl der Sender als auch der Empfänger haben dabei einen Queue (ähnlich einer Backlog Liste). Diese Queue speichert alle Nachrichte, welche noch nicht bestätigt angekommen sind, um Duplikate zu vermeiden. Somit wird die Auslieferung aller Nachrichten auch bei einer (zeitweisen) Unterbrechung der Verbindung garantiert.

Beispiel

Business-kritische Nachrichten sollten immer mit MQTT QoS Level 2 übertragen werden. Ein typisches Beispiel ist das Auslösen eines Bestellprozesses bei Erreichen eines niedrigen Füllstands. Hier muss sichergestellt werden, dass die Bestellung genau einmal ausgelöst wird. Eine höhere Belastung für Broker/Client kann hier in Kauf genommen werden, da die Nachricht selten übertragen wird.

Welche Best Practises sollten bei einem UNS beachtet werden?

Auswahl des richtigen QoS Levels

Zur Auswahl des richtigen MQTT QoS Levels müssen die Wichtigkeit der Nachricht gegen Belastung für den Broker und Client abgeschätzt werden. Hier sollten unteranderem die Folgen einer nicht oder doppelt erhaltenen Nachricht, die Sendefrequenz, die Anzahl der Subscriber und das State Management (Client offline) betrachtet werden.

Im Folgenden werden beispielhafte Szenarien für jedes MQTT QoS Level beschrieben. Mit den Informationen sollten Sie eine informierte Entscheidung zu Ihrem UNS Projekt treffen können. Wichtig: Die QoS Levels von Subscriber und Publisher sollten aufeinander abgestimmt werden. Bei unterschiedlichen Levels wird immer das niedrigere Level genutzt. Damit kann die MQTT QoS ungewollt heruntergestuft werden.

Szenario: MQTT QoS Level 0

Das MQTT QoS Level 0 sollte genutzt werden, wenn:

  • Die Verbindung zwischen Senden und Empfänger sehr zuverlässige ist. Beispielsweise die Anbindung eines KPI-Dashboards über eine Kabelverbindung.
  • Der Verlust von Nachrichten nicht wichtig ist oder die Frequenz der Daten sehr hoch ist und damit die Load gering sein muss. Beispielsweise bei Positionsdaten eines AGVs im Lager, welche nur kurz relevant sind und schnell überschrieben werden.

Szenario: MQTT QoS Level 1

Das MQTT QoS Level 1 sollte genutzt werden, wenn:

  • Die doppelte Zustellung von Nachrichten nicht wichtig ist. Wie bei Business Daten die lediglich einen Status darstellen.
  • Oder der Load von MQTT QoS Level 2 nicht realisierbar ist, da die Daten sonst den Broker zu stark auslasten.

Szenario: MQTT QoS Level 2

Das höchste MQTT QoS Level 2 sollte besonders bei kritischen Nachrichten wie

  • Business-kritische Daten für wichtige Transaktionen, wie eine Bestellauslösung.

Bei der Nutzung von MQTT QoS Level 2 sollte jedoch immer die zusätzliche Belastung für den Broker beachtete werden: Achtung hier jedoch: Der Unterschied zwischen QoS 1 und 2 besteht hauptsächlich in der Vermeidung von Duplikaten. Dies erfordert jedoch auch einen höheren Kommunikationsaufwand, der aus 4 statt 2 Schritten besteht.

Fazit

QoS-Level bieten drei Zustellgarantien: maximal einmal, mindestens einmal und genau einmal. Die Wahl des MQTT QoS-Levels sollte gezielt für jedes Topic abhängig vom jeweiligen Use-Case erfolgen. Dabei spielen nicht nur die Wichtigkeit der Daten, sondern auch die Übertragungsfrequenz, der Load des Brokers und das Ausfallrisiko eine Rolle. Ein guter Standard ist MQTT QoS-Level 1. In der i-flow UNS Referenzarchitektur wird für nicht kritische Anwendungsfälle MQTT QoS-Level 0 empfohlen.

Zusätzlich zu den QoS-Leveln gibt es weitere Optionen für die Nachrichtenübertragung bei MQTT. Für mehr Informationen dazu lesen Sie gern unsere Artikel zu MQTT Retained Messages in unseren Ressourcen.

Über i-flow: i-flow ist ein Unternehmen für industrielle Software mit Sitz in Süddeutschland. Wir bieten produzierenden Unternehmen die weltweit intuitivste Software zur Vernetzung von Fabriken. Täglich über 400 Millionen Datenoperationen in produktionskritischer Umgebung demonstrieren nicht nur die Skalierbarkeit der Software, sondern auch das tiefe Vertrauen, das unsere Kunden in i-flow setzen. Unser Erfolg basiert auf enger Zusammenarbeit mit Kunden und Partnern weltweit, darunter namhafte Fortune-500-Unternehmen und Branchenführer wie Bosch.

Jetzt selbst ausprobieren - Kostenlose Testversion

Überzeugen Sie sich in einem Test selbst von den unbegrenzten Möglichkeiten, die Sie mit i-flow erhalten. Jetzt 30 Tage kostenfrei testen, auf Ihren Systemen.

Ihre Frage wurde nicht be­antwortet? Kontaktieren Sie uns.

Es gilt unsere Datenschutzerklärung.

Ihr Kontakt:

Marieke Severiens (i-flow GmbH)
content@i-flow.io