• Fraunhofer IMS: Vertrauenswürdige eingebettete KI mit RISC-V 16. Oktober 2019
    Auf Basis der freien Befehlssatzarchitektur RISC-V entwickelte das Fraunhofer Institut für Mikroelektronische Schaltungen und Systeme einen Prozessor, der eine vertrauenswürdige eingebettete Künstliche Intelligenz möglich macht. Eine eigene Kryptoeinheit sorgt dabei für Sicherheit.
Know-how für alle

MQTT wie funktioniert das?

MQTT basiert auf dem Publish/Subscribe-Muster. Die Publisher von Nachrichten und die Subscriber der Nachrichten sind komplett entkoppelt durch einen MQTT Broker. Der MQTT Broker ist dafür verantwortlich, eine Nachricht den richtigen Empfängern zuzustellen, und er verwaltet die einzelnen verbundenen Clients.

Der Broker ist in der Lage, eine einzelne, von einem Publisher versendete Nachricht an eine Vielzahl von Subscribern zu versenden. Es handelt sich also um eine 1:N-Kommunikation quasi ein Broadcast. Sowohl sendende als auch empfangende Clients bleiben ständig mittels einer stehenden TCP-Verbindung mit dem MQTT Broker verbunden, es kommt bei dem MQTT Broker das Push-Verfahren zum Einsatz, welches ohne Verzögerung an interessierte Clients ausliefern kann.

Bild 1 Mehrere Geräte können eine Subscription am MQTT Broker erstellen und signalisieren über sogenannte Topics. Der Broker kennt nun diese Abonnements (Subscriptions) der einzelnen Clients und ist in der Lage, neu ankommende Nachrichten (Publishes) direkt weiterzuleiten.

Adressierung über Topics
Die Adressierung der MQTT-Nachrichten erfolgt über Topics. Topics sind hierarchisch aufgebaute Strings, ähnlich wie POSIX-Dateisystempfade. Die einzelnen Hierarchiestufen werden über einen Slash („/“) getrennt. Ein Beispiel-Topic ist sensors/temperature/sensor1. Ein sendender Client benutzt einen Topic für die Nachricht in beliebiger Hierarchiestufe. Jede gesendete Nachricht enthält zwingend einen Topic. Topics müssen vorab nicht am Broker bekannt sein, sie sind vollkommen dynamisch. Wenn nun ein Subscriber am MQTT Broker einen Topic abonniert hat, ist der MQTT Broker in der Lage, die Nachricht weiterzuleiten, sobald eine Nachricht mit diesem Topic am Broker ankommt.

Um die Granularität der Abonnements für die Subscriber besser steuern zu können, existieren für die Selektion von Topics folgende Wildcards:

  • Das Plus-Zeichen ist eine Single-Level Wildcard und wird benutzt, um alle Nachrichten einer einzelnen Hie­rarchieebene abzubilden.

Diese Wildcard wird benutzt, um einen ganzen Teilbaum von möglichen Topics zu selektieren.

So könnte man mittels eines Abonnements auf sensors/# alle darunterliegenden Topics abonnieren. Es würden also alle darunterliegenden Topics wie z.B. sensors/temperature, aber auch sensors/humidity/sensor1 abonniert werden.

Mittels der Single-Level Wildcard könnte man eine ganze Hierarchieebene selektieren. Auf die Subscription sensors/+/sensor1 würden z.B. sensors/temperature/sensor1 und sensors/humidity/sensor1 greifen.

Kern des MQTT Broker
Es ist ersichtlich, dass der MQTT Broker der Kern der Kommunikation bei MQTT ist. Deshalb ist es wichtig, dass der MQTT Broker die Anforderungen eines Anwendungsfalles erfüllen kann. Neben der Performance spielen oft auch Kriterien wie Sicherheitsmerkmale und die Skalierung des Brokers eine Rolle.

Es gibt eine Fülle an MQTT Brokern, von einbettbaren Open Source Brokern wie etwa Mosquitto (mosquitto.org) bis zu kommerziellen MQTT Brokern wie HiveMQ (www.hivemq.com), welche bis zu mehreren Millionen MQTT Clients
in einem Cluster vernetzen können. Ein Grundprinzip von MQTT ist die Einfachheit der Implementierung am Client.

Es existieren daher viele MQTT-Client-Bibliotheken in unterschiedlichen Programmiersprachen und für unterschiedliche Plattformen. Das Projekt Eclipse Paho (www.eclipse.org/paho) bietet viele frei verfügbare MQTT-Client-Implementierungen an, beispielsweise C (sowohl für Embedded als auch für Windows/Linux), C++, Java, Lua, C# und Go. Auch Eigenentwicklungen von MQTT Clients findet man häufig in Projekten, da die Implementierung vergleichsweise einfach vonstatten geht und u.U. nicht alle MQTT Features für einen spezifischen Anwendungsfall benötigt werden.

MQTT kann mehr als nur Nachrichten austauschen. MQTT besitzt eine Fülle an Features, die es als Kommunikationsprotokoll für das Internet of Things optimal machen, vor allem wenn eine unzuverlässige Verbindung (z.B. via Mobilfunk) zu erwarten ist. MQTT besitzt das Konzept von Quality of Service (QoS) Levels. Diese QoS-Ebenen bestimmen die Übertragungsgarantien für Nachrichten. Es wird zwischen drei QoS-Arten unterschieden:

QoS 0: At-most-once delivery. Es wird versucht, die Nachricht auszuliefern. Die Nachricht kommt einmal oder keinmal beim Empfänger an.
QoS 1: At-least-once De­livery. Der Sender versendet die Nachricht neu, falls der Empfänger den Empfang nicht quittiert.
QoS 2: Exactly-once Delivery. Das MQTT-Protokoll stellt sicher, dass die Nachricht genau einmal beim Empfänger ankommt.
MQTT benutzt TCP als Transportprotokoll, welches im Normalfall „Exactly-once Delivery“-Garantien bei der Datenübertragung gibt.

Es kann jedoch jederzeit passieren, dass die TCP-Verbindung während der Datenübertragung getrennt wird. In einem solchen Fall greifen QoS 1 und QoS 2, da nach einer Wiederherstellung der Verbindung die Datenübertragung fortgesetzt werden kann.

Retained Messages

Ein weiteres Protokoll-Feature von MQTT sind „Retained Messages“. Ein Publisher kann beim Versenden einer MQTT-Nachricht diese als retained markieren. Der MQTT Broker speichert diese Nachricht nun für diesen Topic ab, damit alle neuen Subscriber auf diesem Topic direkt diese Nachricht zugestellt bekommen. Bei einer normalen MQTT Message würde die Nachricht zwar an alle aktiven MQTT Subscriber verschickt werden, am Broker würde jedoch nichts hinterlegt werden, weshalb ein neuer Subscriber warten müsste, bis auf einem Topic eine neue Nachricht versendet wird. Mittels Retained Messages bekommt nun jeder neue Subscriber den letzten Stand auf einem Topic, vorausgesetzt, dass das Retained Flag für eine zu sendende Nachricht vom Client gesetzt wurde.

Nachricht bei Verbindungsabbruch

Durch die stehende TCP-Verbindung der MQTT Clients zum Broker wird eine ereignisgetriebene Kommunikation umgesetzt. Ein weiterer Vorteil dieser stehenden Verbindung ist, dass der MQTT Broker bei einem Verbindungsabbruch eines Client dies sofort erkennen kann. Das Last Will and Testament Feature von MQTT erlaubt einem Client, eine Nachricht am MQTT Broker zu hinterlegen, welche vom Broker versendet wird, sobald die TCP-Verbindung geschlossen wurde. Damit ist es möglich, auf einen Ausfall eines Gerätes zu reagieren, da man den Last Will and Testament Topic dieses Gerätes über MQTT-Bordmittel abonnieren kann.

Persistent Sessions

Speziell Geräte, die per Mobilfunk vernetzt werden, müssen mit häufigeren Verbindungsabbrüchen rechnen, was beim Einsatz von MQTT dazu führt, dass die Verbindung zum Broker gekappt wird. Ein MQTT Client kann daher beim Verbindungsaufbau entscheiden, ob er eine persistente Session anlegen möchte, also eine Session, die über die Lebenszeit einer TCP-Verbindung hinweg bestehen bleibt. Wenn ein Gerät sich nun wieder verbindet, dann kann es seine Session fortführen. Konkret bedeutet das, dass der Broker die Subscriptions eines nicht verbundenen Clients vorhält und somit alle Nachrichten, die der Client verpasst hat, für den Client ausliefert, sobald dieser wieder online ist. Hierbei handelt es sich um das Konzept der „Queued Messages“. Dabei werden alle verpassten QoS-1- und -2-Nachrichten vom Broker für den Client vorgehalten, QoS-0-Nachrichten werden jedoch nicht gespeichert.

Natürlich kann ein Client auch entscheiden, keine langlebigen Persistent Sessions anzulegen. Rein sendende Clients können sich mit einer „Clean Session“ beim Broker anmelden und somit werden alle Daten über diesen Client nach Beendigung der TCP-Verbindung am Broker gelöscht.

Ressourcenschonend und schnell
MQTT ist ein sehr schlankes IoT-Protokoll mit interessanten Funktionen, die eine ereignisgetriebene Kommunikation ermöglichen. Im Vergleich zu deutlich komplexeren Protokollen versteht sich MQTT als Datentransportprotokoll und entkoppelt dabei Sender und Empfänger von Nachrichten mittels eines MQTT Broker. Neben Brokern für den professionellen Einsatz wie HiveMQ gibt es ein Vielzahl an freier Software, weshalb MQTT sich auch für kostengünstige Entwicklungen eignet. Besonders wenn Kommunikation über das Internet oder eine schnelle und pragmatische IoT-Entwicklung gefordert sind, ist MQTT eine sehr gute Wahl und eine gute Alternative zu schwergewichtigeren Protokollen für die Vernetzung von Geräten und Software.

Print Friendly, PDF & Email

There are no comments

Leave a Reply