Hier kommt eine praktische Anleitung hin 😀

Das Message Queue Telemetry Transport (kurz MQTT) Protokoll wird in diesem Projekt für die Kommunikation zwischen den verschiedenen Geräten genutzt. Der sowohl ISO- (ISO/IEC PRF 20922), als auch OASIS-Standard MQTT gilt mittlerweile als der de facto Standard des IoT und findet auch zunehmend Anwendung in industriellen Umgebungen. Das offene Nachrichtenprotokoll ist für die Machine-to-Machine-Kommunikation (M2M) konzipiert und hat einen kleinen Overhead, wodurch die Menge der transferierten Daten gering gehalten und das jeweilige Netzwerk nur wenig belastet wird. Diese ressourcenschonende Art der Kommunikation eignet sich bestens für die Kommunikation zwischen vielen Akteuren und ist daher prädestiniert für IoT-Szenarien, zu welchen auch der vorliegende Anwendungsfall – das vernetzte Testbed – zählt.

Die Übermittlung der Daten erfolgt eventbasiert über einen zentralen Broker. Eine MQTT-Nachricht besteht immer aus mindestens dem Topic und der Payload, dem eigentlichen Inhalt der Nachricht. Der Inhalt der Payload ist für den Broker irrelevant, denn alle Daten werden BASE64-codiert übertragen. Topics hingegen werden genutzt um die Kommunikation zwischen den unterschiedlichen Teilnehmern (Clients) zu organisieren und haben eine hierarchische Struktur (siehe Abbildung 1). Der Name der Topics ist prinzipiell frei wählbar. Andere Teilnehmer (Clients) können diese Topics abonnieren (subscribe) und empfangen jede Nachricht, die auf dem entsprechenden Topic veröffentlicht wird (publish), irrelevant von welchem Client diese stammt.

Ein Client kann entweder ein (oder mehrere) spezifische Topics abonnieren oder mit Hilfe von Wildcards ganze Teile der Hierarchie auf einmal abonnieren. Das Zeichen „+“ gilt dabei als Wildcard für eine einzelne Hierarchieebene und das Zeichen „#“, welches immer am Ende eines Topics stehen muss, gilt für alle folgenden Hierarchieebenen inkl. aller Unterebenen. Folgende Beispiele veranschaulichen die Funktionsweise der Wildcards in Topics des MQTT-Protokolls: Beispiele von HiveMQ.

Optionale Eigenschaften eines MQTT-Clients

Persistent Session

Wenn ein Client die Verbindung zum Server verliert, gewollt oder ungewollt, sind normalerweise alle abonnierten Topics verschwunden und müssen neu hinzugefügt werden. Dieses Verhalten wird „Clean Session“ bezeichnet. In bestimmten Anwendungsfällen kann es allerdings sehr mühsam sein, zuvor abonnierte Topics wieder hinzuzufügen, wenn es sich z. B. um eine Vielzahl von Sensoren an unterschiedlichen Standorten handelt. Für diese Fälle gibt es die Möglichkeit einer „Persistent Session“. Hier werden nicht nur die Topics eines Clients vom Server vorgehalten, sondern auch alle Nachrichten mit dem QoS Level 1 und 2, die den Client seit dem letzten Verbindungsabbruch nicht erreicht haben.

Last Will & Testament

MQTT-Clients ist es möglich, dem Broker beim Verbinden eine „Last Will & Testament“ (LWT) -Nachricht bekannt zu geben. Diese Nachricht wird gesendet, falls der Client die Verbindung zum Server ungewollt verliert. Dadurch lässt sich z. B. eine Übersicht über den Verbindungsstatus eines Clients realisieren

Optionale Eigenschaften einer MQTT Nachricht

Quality of Service

MQTT bietet für die Spezifizierung der Semantik des Nachrichtentransfers drei Level von Quality of Service (QoS) an. Dafür sind im Header der Nachricht zwei Bit reserviert, die bei jeder Nachricht das Level angeben. Die Bedeutung der unterschiedlichen Level ist wie folgt:

• Level 0: Die Nachricht wird einmalig gesendet und anschließend verworfen. Damit ist nicht sichergestellt, dass diese ankommt.
• Level 1: Es wird sichergestellt, dass die Nachricht mindestens einmal beim jedem Subscriber ankommt. Es kann aber vorkommen, dass die Nachricht mehrfach von einem Subscriber empfangen wird.
• Level 2: Im höchsten Level der QoS wird sichergestellt, dass die Nachricht genau einmal von den Subscribern empfangen wird.

Je höher das Level der QoS, desto höher ist die benötigte Servicezeit des Brokers für die Nachrichtenverteilung. Die Verwendung des jeweiligen QoS-Levels hängt vom Einsatzfall ab und sollte nicht pauschal als Restriktion für alle vorgegeben werden.

Retained Messages

Nachrichten können vom sendenden Client als „Retained Message“ (aufbewahrte Nachrichten) markiert werden. Diese werden vom Broker zwischengespeichert und jeder Client, der das Topic mit der Retained Message abonniert, bekommt automatisch die letzte Nachricht mit einer Retained Kennzeichnung. Bei Temperaturdaten kann es beispielsweise sinnvoll sein Retained Messages zu aktivieren, damit ein neuer Subscriber nicht auf die nächste Änderung warten muss bis er den aktuellen Status empfängt, sondern sofort die letzte Meldung erhält.

Sicherheit

Da das MQTT Protokoll auf dem TCP/IP Stack basiert, besteht die Möglichkeit einer standardisierten Verschlüsselung auf Transportebene mit Hilfe von TLS/SSL. Um diese Art der Verschlüsselung zu nutzen, benötigt der MQTT Broker ein X509 Zertifikat, bevorzugt von einer offiziellen Zertifizierungsstelle signiert, um die spätere Verifizierung des Servers durch den Client zu erleichtern. Des Weiteren wird für die verschlüsselte Kommunikation ein separater Listener auf einem extra Port erstellt, standardmäßig ist dieser Port 8883. Nun können Clients, die die Möglichkeit der verschlüsselten Kommunikation via TLS/SSL unterstützen, über diesen Port verschlüsselt mit dem MQTT Broker Nachrichten austauschen.

Eine weitere Möglichkeit die Kommunikation mit dem MQTT Broker abzusichern besteht darin, durch einen Authentifizierungsmechanismus die Nutzer zu begrenzen. Das Protokoll verfügt dafür über Nutzernamen und Passwort Felder in der „CONNECT“ Nachricht. Der Abgleich des Nutzernamens mit dem Passwort erfolgt brokerseitig, eine Methodik dafür ist nicht standardisiert und muss vom Administrator händisch eingerichtet werden. Hierbei empfiehlt es sich ausdrücklich auf standardisierte, öffentlich zugängliche Sicherheitsmechanismen zurückzugreifen und keine eigenen Mechanismen zu programmieren!

Eine weitere Möglichkeit der brokerseitigen Absicherung der MQTT Kommunikation besteht in der Erstellung von Autorisierungskonzepten. Diese Autorisierung kann jede erdenkliche Form annehmen, z. B. nutzerspezifisch, nutzergruppenspezifisch oder zertifikatsbasierend. Die Implementierung der Logik liegt erneut vollkommen frei in der Hand der Administratoren.

Abschließend besteht noch die Möglichkeit der Nachrichtenverschlüsselung auf Applikationsebene. Diese ist abhängig von den jeweiligen Clients und kann unabhängig vom Broker von jedem Client eingesetzt werden.

Es ist hierbei, wie bei allen übrigen Sicherheitsmechanismen, zu beachten, dass jegliche Erhöhung der Sicherheit immer zu Performanceeinbußen führt. Es kann daher Sinn machen, bei besonders zeitkritischen Anwendungsfällen komplett auf Sicherheitsmechanismen zu verzichten um die Leistung des Gesamtsystems zu optimieren. Es empfiehlt sich in jedem Fall die Besonderheiten des jeweiligen Anwendungsfalles zu betrachten und die Sicherheitsanforderungen individuell zu bestimmen.

Da das Testbed Systeme und Technologien aus unterschiedlichen Bereichen integriert, bietet sich eine architektonische Orientierung am Internet-of-Things (IoT) an. Hier gibt es eine Vielzahl von unterschiedlichen Möglichkeiten, die jeweils spezielle Soft- und Hardwarestacks einsetzen. Die Entscheidung für entsprechende Stacks ist zwar anwendungsfallabhängig und kann nicht pauschal getätigt werden, aber die grundlegende Architektur ist meist gleich und kann auch im Kontext des Testbeds angewandt werden. Folgende Grafik veranschaulicht die Verknüpfung der einzelnen Bereiche:

Quelle: https://iot.eclipse.org/white-papers/iot-architectures/

Devices sind Sensoren bzw. Aktoren, die bestimmte Daten erheben bzw. Aktionen ausführen, wie beispielsweise ein Temperatursensor und eine Klimaanlage. Die Gateways steuern die Aktoren und lesen die Daten der Sensoren aus, speichern diese und leiten sie ggf. an die Cloud oder andere Aktoren weiter. Sollte z. B. der Temperatursensor eine Temperatur über 30° messen wird die Klimaanlage eingeschaltet und ein Logbucheintrag (Zeit, Temperatur, Klimaanlage an oder aus) darüber angelegt.

Die Cloud übernimmt mehrere Funktionen: hier werden die erzeugten Daten langfristig gespeichert, die unterschiedlichen Gateways, Sensoren und Aktoren verwaltet (Übersicht, Zugriffskontrolle etc.); und sie stellt eine universale Schnittstelle für weitere Services zur Verfügung. Zum Beispiel könnten hier alle Temperatursensoren und Klimaanlagen eines Gebäudes verwaltet werden und deren Logbucheinträge vorgehalten werden.

Die Applications sind unabhängige Systeme, die die erzeugten bzw. gespeicherten Daten nutzen, um Mehrwerte für entsprechende Nutzergruppen zu generieren. Diese variieren stark und können daher nicht generalisiert werden. Ein Beispiel dafür könnte eine „Klimamanagement App“ sein, welche einen Überblick über die aktuelle und historische Klimatisierung eines Gebäudes gibt sowie die gezielte Überwachung und Steuerung einzelner Klimaanlagen erlaubt.

Die gestrichelten Linien symbolisieren die Vernetzung zwischen den Systemen, welche auch stark variieren und je nach Anwendungsfall/Infrastruktur zu evaluieren sind. Zum Beispiel könnte in dem bisher beschriebenen Anwendungsfall die Übertragung zwischen Sensor und Gateway drahtlos über Bluetooth erfolgen. Das Gateway ist über ein TCP/IP-Netzwerk mit dem Internet verbunden, worüber die Cloud, welche sich in einem separaten Rechenzentrum befindet, erreichbar ist. Die App befindet sich auf dem Tablet der Hausverwaltung, welches über WLAN mit dem Internet und somit der Cloud verbunden ist.