MQTT Quality-of-Service (QoS) – Anwendungsfälle und Beispiele

Inhalt

In der modernen Fertigungsindustrie spielt MQTT eine zentrale Rolle, insbesondere im Kontext des Unified Namespace (UNS). Diese Architektur ermöglicht eine nahtlose und skalierbare Kommunikation zwischen verschiedenen Maschinen, Systemen und Applikationen. MQTT, als leichtgewichtiges und effizientes Protokoll, ist ideal für den Einsatz in industriellen Umgebungen, da es eine zuverlässige Datenübertragung ermöglicht. Bei der Zuverlässigkeit der Datenübertragung spielt MQTT Quality-of-Service (QoS) eine große Rolle. Dieser Artikel beschreibt die verschiedenen QoS-Level und deren Bedeutung für die sichere und effiziente Nachrichtenübermittlung in MQTT. Zudem zeigt der Artikel Best Practices für die Anwendung in der Unified Namespace (UNS) Architektur auf. Weitere Informationen zum Unified Namespace (UNS) finden Sie hier.

 

Was ist MQTT Quality-of-Service (QoS)?

Der Begriff Quality-of-Service (QoS) beschreibt im MQTT-Protokoll die Zuverlässigkeit der Nachrichtenübertragung. Diese Zuverlässigkeit bezieht sich auf die Verbindung zwischen zwei Akteuren – entweder vom Publisher zum Broker oder vom Broker zum Subscriber. Die verschiedenen QoS-Level bieten dabei bestimmte Garantien für die erfolgreiche Zustellung von Nachrichten.

 

Was sind QoS Level?

Um die QoS Level bei einer Nachrichtenübertragung mittels MQTT zu verstehen, hilft es sich zunächst den Übertragungsmechanismus von MQTT näher zu betrachten. Die Übertragung läuft dabei in zwei Schritten ab. Zunächst sendet der Publisher eine Nachricht zum Broker. Dieser leitet diese Nachricht im Anschluss weiter an alle Subscriber.

MQTT Quality-of-Service (QoS) Level

Bei der Übertragung kann die Nachricht also theoretisch an zwei Stellen verloren gehen: „Publisher zu Broker“ und „Broker zu Subscriber“. Daher können sowohl der Publisher als auch der Subscriber jeweils ein MQTT QoS-Level festlegen. Wenn die QoS-Level von Publisher und Subscriber unterschiedlich sind, leitet der Broker die Nachricht stets mit dem vom Subscriber festgelegten QoS-Level weiter. Dies bedeutet, dass eine Nachricht trotz eines höheren QoS-Levels vom Publisher mit einem niedrigeren QoS-Level vom Broker an den Subscriber übermittelt werden kann.

 

Welche QoS Level gibt es?

MQTT stellt die folgenden 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.

 

Welches QoS Level ist im Kontext des Unified Namespace (UNS) sinnvoll?

Mit der oben genannten Definition lassen sich die Auswirkungen auf die Nachrichtenübermittlung in der Tabelle zusammenfassen. Hier wird deutlich, dass nur MQTT QoS Level 2 eine eindeutige und einmalige Zustellung garantiert. Trotzdem sollten auch QoS Level 0 und 1 im Kontext des UNS in Betracht gezogen werden. Denn: Bei der Wahl des QoS-Levels ist nicht nur die Zuverlässigkeit entscheidend, sondern auch die Last auf dem Broker. Es gilt, für jedes Topic eine optimale Balance zwischen Zuverlässigkeit und Systemlast zu finden. Eine detaillierte Empfehlung dazu finden Sie im folgenden Abschnitt.

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 Quality-of-Service (QoS) Level 0

MQTT QoS Level 0 stellt nur das einmalige Senden der Nachricht sicher, der Empfang ist jedoch nicht garantiert. Hierbei wartet der Sender nicht auf ein Acknowledgement. Diese Methode, auch als „Fire and Forget“ bekannt, sollte als Standard-Einstellung verwendet werden, da sie die geringste Last auf dem Broker verursacht.

MQTT QoS Level 0

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

Beispiel: Dieses Level eignet sich für die Zustellung hochfrequenter Nachrichten. Dies können zum Beispiel Telemetriedaten aus einem Sensor sein, der alle 100ms Prozessparameter wie Temperatur oder Vibrationen übermittelt. Dabei aktualisiert der Sensor die Daten kontinuierlich und mit einer hohen Frequenz. Daher ist der Verlust einzelner Nachrichten für Use-Cases wie Condition Monitoring unkritisch.

 

MQTT QoS Level 1

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

MQTT QoS Level 1

Funktionsweise: Die Nachrichtenübertragung im MQTT QoS Level 1 erfolgt in zwei Schritten. Zunächst sendet der Publisher die Nachricht an den Broker. 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 im Broker ankommt. Die Komplexität dieser Methode bietet einen guten Kompromiss zwischen Zuverlässigkeit und Effektivität. Allerdings kann der Publisher die Nachricht bei diesem QoS Level auch doppelt versenden. Dies kann dazu führen, dass bei einem Verbindungsausfall während des Acknowledgments (PUBACK) der Broker dieselbe Nachricht doppelt erhält und damit auch mehrfach weiterleitet.

Beispiel: Ein typischer Anwendungsfall für QoS Level 1 ist ein Alarm. So kann beispielsweise ein Sensor den offenen Zustand einer Lichtschranke mittels QoS Level 1 an eine zentrale Alarmstelle senden. Durch das wiederholende Senden bis zum Acknowledgement wird sichergestellt, dass die sicherheitskritische Nachricht beim Broker empfangen wird und notwendige Schritte eingeleitet werden können. Gleichzeitig ist eine mögliche Mehrfachzustellung in diesem Szenario unproblematisch.

 

MQTT QoS Level 2

MQTT QoS Level 2 gewährleistet, dass die Nachricht genau einmal zugestellt wird. Es bietet somit die höchste Zuverlässigkeit, allerdings auf Kosten einer höheren Belastung für Broker und Client, was zu einer langsameren Ausführung führt.

MQTT QoS Level 2

Funktionsweise: Eine Nachricht, die mit MQTT QoS Level 2 gesendet wird, folgt diesen vier Schritten:

  1. Publish: Der Publisher sendet die Nachricht an den Broker.
  2. PUBREC (Acknowledge): Der Broker bestätigt den Empfang der Nachricht mit einem PUBREC-Paket. Ähnlich wie bei QoS Level 1 sorgt dies dafür, dass der Empfang sichergestellt ist. Falls der Publisher kein PUBREC erhält, sendet er die Nachricht erneut.
  3. PUBREL: Nach Erhalt des PUBREC antwortet der Publisher mit einem PUBREL-Paket und entfernt die Nachricht aus seinem Speicher, behält jedoch die Packet-ID, um doppeltes Senden zu verhindern.
  4. PUBCOMP: Der Broker erkennt durch das PUBREL-Paket, dass der Publisher die Nachricht nicht erneut senden wird. Er löscht die Nachricht sowie die Packet-ID und bestätigt dies mit einem PUBCOMP-Paket. Sobald der Publisher das PUBCOMP erhält, kann er die Packet-ID ebenfalls entfernen. Diese steht nun für neue Nachrichten bereit.

 

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

Beispiel: Für business-kritische Nachrichten empfiehlt sich die Übertragung mit MQTT QoS Level 2. Ein typischer Anwendungsfall ist das Auslösen eines Bestellprozesses bei einem niedrigen Füllstand. In diesem Szenario muss die Bestellung genau einmal erfolgen. Die höhere Belastung für Broker und Client ist hier akzeptabel, da die Nachricht nur selten gesendet wird.

 

Best Practices im Kontext des Unified Namespace (UNS)

Im Kontext einer UNS Architektur ist die Auswahl des richtigen MQTT Quality-of-Service (QoS) Levels entscheidend. Dabei gilt es die Wichtigkeit der Nachricht mit der größeren Last von höheren QoS Leveln für Broker und Client abzuwägen. Anwender sollten dabei die Folgen einer nicht oder doppelt erhaltenen Nachricht, die Sendefrequenz, die Anzahl der Subscriber sowie das State Management (zum Beispiel bei offline Clients) einbeziehen. Publisher und Subscriber sollten dabei stets das gleiche QoS-Level verwenden. Unterschiedliche Levels führen sonst zur automatischen Anpassung auf das niedrigere Level, was die Zuverlässigkeit beeinträchtigen kann. Im Folgenden sind 3 typische QoS Szenarien im Kontext des Industrial Unified Namespace (UNS) beschrieben.

 

Szenario: MQTT Quality-of-Service (QoS) Level 0

Anwender sollten MQTT QoS Level 0 nutzen, wenn:

  • Die Verbindung zwischen Senden und Empfänger sehr zuverlässig ist.
  • Der Verlust von Nachrichten verkraftbar oder die Frequenz der Daten sehr hoch ist.
  • Beispiel: Hochfrequente Telemetriedaten aus Maschinen und Sensoren. Der Verlust einer Nachricht beeinflusst den Use-Case nicht.

 

Szenario: MQTT Quality-of-Service (QoS) Level 1

Anwender sollten MQTT QoS Level 1 nutzen, wenn:

  • Die doppelte Zustellung von Nachrichten unkritisch ist.
  • Viele Publisher und/oder Subscriber, MQTT QoS Level 2 ist nicht realisierbar, da die Nachrichten sonst den Broker stark auslasten.
  • Beispiel: Business Daten die lediglich einen Status darstellen. Das wiederholte Erhalten des Status beeinflusst den Use-Case nicht, wie bei einer Statusanzeige in einem Dashboard.

 

Szenario: MQTT Quality-of-Service (QoS) Level 2

Anwender sollten MQTT QoS Level 1 nutzen, wenn:

  • Das Handling von Duplikaten für den Use-Case entscheidend ist.
  • Beispiel: business-kritische Daten für wichtige Transaktionen, wie eine einmalige Bestellauslösung aufgrund der Unterschreitung eines Füllstands.

 

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.

Ihr Kontakt:

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