MQTT massgeschneidert für Internet of Things
Internet of Things wird fälschlicherweise häufig auf Lösungen, basierend auf dem Internet bzw. innerhalb eines Netzwerks dargestellt. Häufig reduziert man sich dabei auf Module mit Netzwerkanbindung, sei es mittels WLan, Ethernet, Bluetooth, RFID (Radio Frequency Identification), IR Sender / Empfänger, usw.. Das Internet of Things umfasst vielmehr nahezu jedwede Elektronik die mittels entsprechender Schnittstelle Informationen für andere Teilnehmer bereitstellen kann. Sowohl aus Kostengründen als auch aus Gründen der Bauform verfügen Internet of Things Komponenten meist über
- einen sehr begrenzten Speicher
- eine reduzierte Rechenleistung
- eine begrenzte Energieversorgung
Gerade im Bezug von Sensoren ist der Rahmen für Entwicklungen sehr reduziert. Auch sollte das Internet of Things in seiner Gesamtheit betrachtet werden, wobei jede Komponente / Thing möglichst eine autark funktionieren sollte. Das heisst jede Komponente reduziert sich dabei zunächst auf die massgebliche Aufgabe und teilt sich gegenüber den anderen Komponenten im Internet of Things mit. In Verbindung mit MQTT und bei richtiger Umsetzung ermöglicht dies eine nahezu, lückenlose und automatische Kontrolle aller Teilnehmer im Internet of Things Netzwerk.
Diesbezüglich wurde MQTT genau auf diese Rahmenbedingungen optimiert.
- MQTT ist auf sämtlichen, gängigen Plattformen lauffähig
- MQTT Bibliotheken benötigen nur einen geringen Speicher (30KB C / 100KB Java)
- MQTT Nachrichten sind sehr kompakt (Header besteht aus 2 bytes)
- MQTT Spezifikationen basieren auf lediglich 4 Typen
- MQTT Datenpaket basiert auf Byte Array
- MQTT kann bis zu 100.000 Teilnehmer verwalten
MQTT ist diesbezüglich optimiert für den Datentransfer innerhalb von Internet of Things Lösungen.
MQTT Basis Konzept
Hierbei geht es sowohl um die technischen Grundlagen sowie um die Möglichkeiten die durch MQTT geschaffen wurden. Nimmt man beispielsweise einen Herzkranken dessen Herzkreislaufsystems mittels einer IoT Lösung überwacht wird. Vorausgesetzt das IoT System verfügt über notwendige Grundlagen wie
- Energieversorgung
- Netzwerkanbindung
ist die technische Lösung zur Überwachung der Herzkreislauf Funktion keine wirkliche Herausforderung. Auf den mobilen Alltag übersetzt zeigen sich aber weitreichende Probleme. Sowohl die Energieversorgung als auch die Anbindung an ein Netzwerk werden hier bereits zur Herausforderung. Zunächst mag man hier an die optionale Anbindung mobiler Endgeräte denken. Schlussendlich bildet diese Lösung lediglich eine Option, denn diese Anbindung setzt voraus dass:
- das mobile Endgerät funktionsfähig ist
- die Anbindung des IoT Modul an das mobile Endgerät störungssicher ist
- das mobile Endgerät in einem Netzwerk angemeldet ist
- das mobile Endgerät über notwendige Standards verfügt
Steht die IoT Lösung in direkter Abhängigkeit vom mobilen Endgerät unterliegt die Ausfallsicherheit des Systems dem mobilen Endgerät. Um eine möglichst autarke Funktionsweise zu gewährleisten bedarf es einer unabhängigen Energieversorgung als auch Verbindungsmöglichkeit.
Aufgrund des bereits sehr fortgeschrittenen Standards im Bezug der mobilen Endgeräte liegt dennoch ein kombinierter Lösungsansatz in Verbindung mit einem mobilen Endgerät auf der Hand. Der vorgenannte letzte Punkt, Standards verdeutlicht dabei die Notwendigkeit von MQTT.
MQTT publish subscribe Publizieren und Abonnieren
Der MQTT Datenaustausch erfolgt nach dem Anfragen und Abonnieren Prinzip. Anders als bei dem typischen Austausch von Daten im Internet, findet bei MQTT ein stringenter Datenaustausch statt (publish/subscribe model). In der praktischen Anwendung können MQTT Teilnehmer (Clients) dabei Daten publizieren als auch Daten abonnieren. Im vorgenannten Beispiel bildet sowohl das mobile Endgerät als auch das IoT Modul einen MQTT Teilnehmer (Client). Die Kommunikation kann dabei bidirektional erfolgen, das heisst sowohl das mobile Endgerät als auch das IoT Modul können gegenseitig Daten Publizieren oder Abonnieren. Aus praktischer Sicht könnte dabei
- das mobile Endgerät Herzkreislaufdaten abonnieren und das IoT Modul publizieren
- gleichwohl kann das IoT Modul notwendige technische Daten wie Akku Ladezustand, Status der Netzverbindung des mobilen Endgerätes abonnieren
Im Vergleich zu typischen Server Client Modellen erfolgt der Datenaustausch bei MQTT in strikter Form. Ganz gleich welche Neuerungen ein publizierender MQTT Teilnehmer bereithält es erfolgt lediglich ein Datenaustausch abonnierter Daten.
MQTT Topics Subscriptions Thema abonnieren
Um Daten Datenaustausch mittels einem publizieren und abonnieren Modell zu gewährleisten verwendet MQTT nur ausgewählte Themen (Topics). Ähnlich wie bei einem Nachrichtendienst / Feed werden dabei nur ausgewählte Themen abonniert. Dabei kann sowohl ein komplexes Thema, bestehend aus allen Kapiteln (Subscriptions) innerhalb des Themas abonniert werden oder gezielt einzelne Kapitel (Subscriptions) abonniert werden.
- In Anlehnung an das vorgenannte Beispiel kann ein Thema (Topic) des IoT Moduls die Vitalfunktionen eines Herzkranken darstellen, die Herzfrequenz wiederum ein enthaltenes Kapitel (Subscription)
- Im Bezug des mobilen Endgerät kann der Betriebszustand ein komplexes Thema (Topic) bilden, die verfügbare Netzwerkverbindung bildet dabei ein einzelnes Kapitel (Subscription)
Die Kapitel (Subscription) können dabei strikt limitiert / einzeln abonniert oder mittels dem Platzhalter # / Raute (Wildcard #) gesamt abonniert werden.
MQTT QoS Quality of Service Priorität Level
In der praktischen Anwendung werden MQTT Nachrichten nach QoS / Quality of Service, nach Priorität klassifiziert. Die Priorität wird dabei in 3 Stufen klassifiziert sodass beispielsweise bei reduzierter Energieversorgung oder aber einer schlechten Verbindung mit hoher Latenz nur Nachrichten mit der höchsten Priorität übermittelt werden. Gerade im Bezug des vorgenannten Beispiel wird der weitreichend Rahmen von MQTT offensichtlich. Heutige mobile Endgeräten verfügen über eine Vielzahl von Apps die häufig stets Daten abfragen und aktualisieren. Es steht ausser Frage das beispielsweise bei entsprechenden Notfallsituationen die Übermittlung eines Notfallsignals dem Abgleich von Emailnachrichten vorzuziehen ist.
- Bei einer Notfallsituation kann das IoT Modul ein MQTT Nachricht der höchsten Priorität publizieren
- Das mobile Endgerät kann dann andere Prozesse abbrechen um eine notwendige Netzwerkverbindung bereitzustellen sowie fortlaufend Daten an einen bestimmten Empfänger (Abonnenten) übermitteln
Um dass die Übermittlung der jeweiligen Nachricht je nach Priorität erfolgt, wird die jeweilige Priorität seitens des publizierenden MQTT Teilnehmer festgelegt,
MQTT retained messages Nachrichten Archivierung
MQTT unterstützt eine serverseitige Archivierung von Nachrichten. Meldet sich ein neuer MQTT Client am MQTT Server an, können Datensätze direkt auf den Client übertragen werden. Für den Austausch archivierter Datensätze muss der MQTT Client das entsprechende Thema (Topic), sowie das oder die enthaltenen Kapitel (subscriptions) abonnieren. Alsbald der MQTT Client sich bei dem MQTT Server anmeldet erfolgt die Bereitstellung der archivierten Datensätze. Im praktischen Einsatz werden dadurch Hardware Ressourcen wie beispielsweise größerer Speicher gespart. Das IoT Gerät erfasst Daten und gibt diese bei der Verbindungsherstellung weiter. Insbesondere im Austausch von Hardware / Teilnehmern ist dies ein besonders angenehmer Umstand.
MQTT clean session flag Datenabgleich beim Herstellen einer Verbindung
Gerade in Verbindung mit mobilen IoT Geräten ist eine dauerhafte Verbindung nur teilweise notwendig bzw. möglich. Diesbezüglich bedarf es oftmals eines automatischen Datenabgleich zwischen den MQTT Teilnehmern. MQTT erlaubt dabei 2 unterschiedliche Verfahren mittels dem clean session flag.
Bei dem MQTT clean session flag wird zwischen
- true, sobald eine Verbindung mit dem jeweiligen MQTT Teilnehmer wieder hergestellt wurde, erfolgt eine Herstellung der Verbindung ohne Datenabgleich
- false, bei der Verbindungsherstellung zum MQTT Teilnehmer erfolgt ein Datenabgleich
Die MQTT Nachrichten werden dabei stets in Abhängigkeit der Priorität abgeglichen, d.h. Nachrichten mit niedriger Priorität bleiben beim Datenabgleich unberücksichtigt.
MQTT wills der letzte Wille
Bereits die Überschrift verdeutlicht die Wertigkeit dieses Parameters für einen MQTT Teilnehmer, bzw. die hinterbliebenen Teilnehmer. Wie bereits erwähnt basiert das MQTT Protokoll auf einem strikten Nachrichtenverkehr zwischen den Teilnehmern. Dies hat zur Folge das bei einem Verbindungsverlust nicht nur der eigentliche MQTT Teilnehmer und dessen Abonnent beeinflusst wird, sondern zusätzlich andere Teilnehmer Abonnenten in ihrer Funktion beeinträchtigt werden können. Bei einem Verbindungsabbruch zwischen MQTT Teilnehmern ermöglicht MQTT wills mitzuteilen welche Nachricht an welches Thema (Topic) übermittelt werden soll. Unter Anbetracht das Internet of Things M2M (Maschine zu Maschine) basierend ist und auf automatisierten Prozessen beruht ist der wills Parameter elementar. Beim Ausfall eines MQTT Teilnehmers wissen andere MQTT Teilnehmer bereits welche Nachricht zu welchem Thema verbreitet werden soll.
Ein einfaches Beispiel, bewässert man mittels einem IoT gesteuertem Ventil eine Zimmerpflanze so kann hier ein Ausfall erheblichen Schaden herbeiführen. Diesbezüglich ist es ratsam bereits vor dem “Ableben” eine Nachricht (der letzte Wille) für andere MQTT Teilnehmer vorzubereiten. Im Detail ist hier die Rede von Nachrichten für entsprechende Themen (Topics) vorzubereiten. Verabschiedet sich das IoT gesteuerte Ventil unverhofft so wissen andere MQTT Teilnehmer wie sie zu handeln haben, beispielsweise
- eine Nachricht an das Thema Fehlermeldung, Kapitel Bewässerung Wintergarten zu senden
- worauf ein anderer MQTT Teilnehmer / Abonnent, beispielsweise ein vorgeschaltetes IoT Ventil mit dem Thema Alarm Kapitel Notabschaltung
- worauf wiederum ein anderer MQTT Teilnehmer / Abonnent, beispielsweise ein Router der vorzugsweise ein Abonnent von allen vorgenannten, beteiligten Teilnehmern ist (Gegenkontrolle)
- der (Router) wiederum ein Abonnent eines MQTT Teilnehmers eines IoT Feuchtigkeitssensor im Blumentopf ist und die Feuchtigkeit bestimmt (läuft das Wasser?)
- daraufhin kann der Router sowohl eine Nachricht bezüglich der Fehlermeldung, als auch einen Zustandsbericht erstellen und versenden
Das vorgenannte Beispiel verdeutlicht nicht nur das Zusammenspiel einzelner Komponenten in einem Internet of Things Netzwerk, sondern zeigt zusätzlich die notwendige Abhängigkeit beinhalteter Komponenten. Das “Ableben” des ersten IoT gesteuerten Wasserventils kann vielerlei Folgen mit sich bringen. Leider wird oftmals die hier beschriebene Bewässerungslösung durch ein einziges Modul gelöst das sowohl das Ventil steuert als auch die Feuchtigkeit im Blumentopf bestimmt. Dies bringt jedoch den Nachteil mit sich das im Notfall keine bestimmungsgemässe Handlung herbeigeführt werden kann. Fällt die IoT gesteuerte Bewässerung inkl. Feuchtigkeitssensor aus kann dies 3 maßgebliche Folgen mit sich bringen
- das IoT gesteuerte Ventil muss alsbald man vor Ort ist überprüft werden
- die Pflanzen müssen nach Feierabend per Hand gegossen werden
- die Feuerwehr muss den Wintergarten trockenlegen
Dieses Beispiel verdeutlicht das geniale Konzept hinter MQTT.
Bei statischen Lösungen (beispielsweise mittels TCP – IP Socket) muss eine Abhängigkeit einzelner Teilnehmer / Komponenten mit entsprechendem Aufwand eingepflegt werden.
Bei einer MQTT basierenden Internet of Things Lösung muss lediglich abonniert und publiziert werden um eine notwendige Abhängigkeit herzustellen.
Nicht nur im Bezug der Sicherheit, sondern auch im Bezug der stetigen Erweiterung oder Erneuerung werden die Vorzüge einer MQTT basierenden Lösung Internet of Things Lösung offensichtlich.