Nicht in Echtzeit: IoT-Protokolle für den Datenaustausch
Protokolle für die verzögerte, entkoppelte Datenübertragung eignen sich für IoT-Umgebungen häufig besser als Echtzeitprotokolle. Eine Übersicht.
Das Internet der Dinge (Internet of Things, IoT) bringt einige technische Herausforderungen mit sich, darunter die Kommunikation zwischen den verschiedenen vernetzten Geräten. Für die optimale Verbindung ergeben sich Anforderungen wie eine niedrige Latenz, hohe Verfügbarkeit mit wenigen Timeouts und eine hohe Bandbreite. Hier stellt sich die Frage: Auf welchem Protokoll soll die IoT-Kommunikation basieren?
Im Internet der Dinge werden die meisten Daten nicht in Echtzeit verschickt. Während ein Düsentriebwerk IoT-Daten sicherlich kontinuierlich an Apache Storm übertragen könnte, leiten ein Luftkompressor oder das Ventil einer Gas-Pipeline möglicherweise nur einmal pro Stunde wenige Kilobyte an Daten an eine Cloud-Plattform zur Analyse weiter. Daher verwenden die meisten IoT-Anwendungen zum Datenaustausch Protokolle, die Daten nicht in Echtzeit übertragen. Doch nutzen sie deren Potenzial voll aus?
Beginnen wir mit der Definition: Wir verstehen unter dem IoT-Protokoll die Anwendungsschicht (Layer 7) des OSI-Netzwerkmodells, das den Netzwerkverkehr und dessen Elemente klassifiziert. Weitere Schichten wären etwa die Transportschicht (Layer 4 etwa mit TCP) oder die Netzwerkschicht (Layer 3 mit Paketen).
IoT-Protokolle wie MQTT, CoAP, DDS und XMPP beschreiben ein Verfahren zur Übertragung von Daten auf einem IP-Netzwerk, die üblicherweise in Pakete aufgeteilt sind. Hier lohnt sich ein Vergleich mit der Übertragungsschicht unter dem Protokoll, die aus Standards wie Z-Wave, ZigBee, NFC, Bluetooth 4.0 (aka BLE), BACnet, Wi-Fi oder dem Mobilfunknetz bestehen kann. Jeder dieser Standards eignet sich für bestimmte Anforderungen, etwa die Übertragung von Daten über wenige Millimeter, wenige Meter oder über das Internet. Denkbar ist auch der Betrieb mit einem kostengünstigen Chip, der weder ein teureres Modem, eine Handy-Nummer oder eine Netzwerk-Schnittstelle erfordert.
HTTP wird in der Regel nicht verwendet
HTTP lässt sich als Protokoll der Anwendungsschicht des Netzwerks auch für das Internet der Dinge einsetzen. Sie können das selbst ausprobieren: Kaufen Sie einen kostengünstigen BeagleBone-Einplatinencomputer (oder ein vergleichbares Angebot), bauen sie einen Temperatur- und Feuchtigkeitssensor für fünf Euro ein und nutzen Sie den integrierten Linux-Webserver, um die Temperatur in Ihrem Haus über das Internet zu überprüfen, während Sie im Büro sind.
Allerdings ist HTTP in vielen Fällen nicht ideal für das Internet der Dinge, weil es keine vorhersehbare Latenz bietet und als komplett textbasiertes Protokoll bei jedem Request im HTTP-Header einen Overhead an Daten mit überträgt. Die meisten gängigen IoT-Protokolle nutzen einen Publish-and-Subscribe-, Message-Queuing-Mechanismus, um Daten an einen Messaging-Server zu senden. Damit ermöglichen sie einen entkoppelten Offline-Betrieb.
Unternehmen, die mit IBM MQ-Server und seinen vielen Open-Source-Alternativen wie OpenMQ arbeiten, kennen wahrscheinlich die Nachrichtenwarteschlangen. MQTT, eines der wichtigsten IoT-Protokolle, basiert auf dem IBM MQ-Modell.
Unterscheidung von IoT-Clouds und Protokoll-Frameworks
Iot-Protokolle unterscheiden sich auch von Programmier-Frameworks für IoT-Protokolle oder IoT-Clouds. Ein Protokoll-Framework entlastet den Entwickler und dient der Programmierung von Code, der die Arbeit mit dem Protokoll vereinfacht.
IoT-Cloud-Frameworks dagegen sind so konzipiert, dass sie mit der Cloud eines spezifischen IoT-Anbieters funktionieren. So kann beispielsweise eine API dazu dienen, ein Gerät in der IoT-Cloud zu registrieren und es etwa über einen Mobilfunk-Carrier bereitzustellen.
Arbeiten in beschränkten Umgebungen
IoT-Protokolle unterscheiden sich von Netzwerk-Protokollen wie FTP, MQ, JMS oder SFTP, dass sie für die Arbeit in begrenzten oder eingeschränkten Umgebungen konzipiert wurden. Während die IoT-Nachricht in der Regel zu einer wortreichen XML- oder JSON-Darstellung erweitert und meist um Code-intensive Verschlüsselung ergänzt wird, ist das Protokoll selbst leichtgewichtig konzipiert. Der Grund: Das Protokoll muss auch über langsame Netzwerkverbindungen oder einfache, kostengünstige Computer-Chips funktionieren, die in einfachen IoT-Geräten wie beispielsweise solarbetriebenen Straßenschildern installiert sind.
Ein IoT-Gerät besteht in der Regel nicht aus mehr als einem Intel Galileo-Chip, Raspberry Pi oder einer BeagleBone-Karte für 30-50 Euro. Teilweise besitzen IoT-Geräte noch kleinere Chips mit günstigen Sensoren zum Preis zwischen einem und 25 Euro sowie eine Bluetooth-, WLAN-, Mobilfunk- oder Ethernet-Verbindung. Es wäre nicht kosteneffizient, jeden IoT-Endpunkt mit einem GSM-Modem auszustatten oder einen Router in der Nähe zu installieren. Zudem ist nicht immer eine WAN-Verbindung (Wide Area Network) notwendig; manche IoT-Protokolle dienen zur Verbindung mit anderen IoT-Geräten, die nur wenige Meter entfernt sind; in diesen Fällen überträgt ein Messaging-Server die Daten an die IoT-Cloud.
Der letzte Schritt im Internet der Dinge ist die Sammlung, Aufbereitung und Analyse aller Datenpakete beim Empfänger, um damit einen Mehrwert zu generieren. Am häufigsten wird dabei REST (Representational State Transfer) eingesetzt, um einen Webserver über die HTTP-Schicht zu erreichen. IoT-Geräte sind so programmiert, dass sie diese Aktion umsetzen ‑ der Programmierer braucht aber nicht zu wissen, welches Protokoll dabei verwendet wird. Der Webservice lädt dann die empfangenen Daten und Informationen etwa zu Temperatur, Vibration oder Bewegung an den Webserver. Je nach Anwendung kann die Übertragung der Daten auch in die umgekehrte Richtung erfolgen, etwa wenn die IoT-Anwendung Befehle an das IoT-Gerät schickt.
Hier ein kurzer Blick auf die wichtigsten IoT-Protokolle MQTT, CoAP, DSS und XMPP.
MQTT
Das Protokoll MQTT (Message Queuing Telemetry Transport) wurde 1999 von IBM und Arcom Control Systems für die Überwachung einer Ölpipeline entwickelt; die Datenübertragung erfolgte damals über Satellit. Seit 2010 ist MQTT offiziell unter einer freien Lizenz verfügbar, so dass auch Open-Source-Implementierungen möglich sind.
MQTT basiert auf dem ereignisgesteuerten Publisher-Subscriber-Modell anstelle einer Request/Response-Architektur. Publish/Subscribe ersetzt Point-to-Point-Verbindungen durch einen zentralen Server für die Erzeuger und Empfänger der Daten. Die zentrale Rolle beim Senden (Publish) und Empfangen (Subscribe) der Nachrichten spielen Topics. Diese sind ähnlich einer URL aufgebaut und fungieren als eine Art Betreff der Nachricht. Ein Beispiel: Ein vernetztes Gerät sendet unter dem Topic Temperatur Informationen etwa zur Temperatur einer bestimmten Maschine oder der Umgebungstemperatur. Jede Anwendung oder mobile App, die Nachrichten über das Topic Temperatur empfangen will, kann diese Informationen abonnieren. MQTT-Geräte können sich diese Topics untereinander zuschicken oder an einen Messaging-Server, der die Informationen an die IoT-Cloud weiterleitet.
Jedes IoT-Protokoll hat seine eigene Terminologie. Die Sprache von MQTT ist relativ clever und sogar poetisch. Ein Beispiel: Die Nachricht, dass ein Gerät offline ist, läuft unter dem düsteren Motto Last Will and Testament (Letzter Wille und Testament). Bei MQTT steht Servicequalität nicht für die Abschwächung von Datenpaketen oder den Prozentsatz der verworfenen Pakete; stattdessen gibt die Servicequalität an, wie viel Aufwand für die Zustellung einer Nachricht notwendig war, sei es höchstens einmal, mindestens einmal, genau einmal. Wie schon Shakespeare sagte: „Kürze ist die Seele des Witzes" - das ist kurz und absolut klar.
Das folgende kurze Code-Schnipsel liefert eine Vorstellung davon, wie sich all diese Elemente zusammenfügen. Es nutzt das MQTT.js-Framework für die Verbindung zu einem öffentlichen MQTT-Server. Dieser einfache JavaScript-Code verschickt und ruft eine Temperaturanzeige ab und veröffentlicht sie über die Standardausgabe (stdout), in diesem Fall der Konsole. Voraussetzung dafür ist die Installation von Node.js, einem JavaScript-Server, der keinen Browser benötigt.
var mqtt = require('mqtt');
var client = mqtt.connect('mqtt://test.mosquitto.org');
client.subscribe('temperature');
client.publish('temperature', '120C');
client.on('message', function (topic, message) {
console.log(message.toString());
});
client.end();
CoAP (Constrained Application Protocol)
Das Constrained Application Protocol (CoAP) basiert auf UDP und dem Request/Response-Modell. Um so viele Daten wie möglich auf kleinstem Raum unterzubringen, verfügt CoAP über binäre Felder in der Nutzlast und einen 4-Byte-Header. Das Protokoll ist für kostengünstige, mit Akku oder Batterie betriebene Geräte mit geringer Netzwerk-Geschwindigkeit konzipiert. Dazu gehören beispielsweise smarte Glühlampen. CoAP benötigt nur 10 KByte RAM und 100 KByte Speicher, um den Code zu laden.
Da CoAP wie das REST-Protokoll die Befehle GET, PUT, POST und DELETE nutzt, um Nachrichten zu senden und zu empfangen, ist eine dauerhafte Verbindung notwendig. Der Nachteil: Wird die Verbindung unterbrochen, gehen die Daten verloren. CoAP ist über zwei Schichten organisiert, den Transport Layer und den Transaction Layer. Im Unterschied zu HTTP, das TCP als Transportschicht nutzt, arbeitet CoAP mit UDP, das einen wesentlich kleineren Overhead als TCP hat. Dadurch eignet sich das Protokoll sehr gut für Low Power and Lossy Networks (LLN), sprich für Netzwerke mit geringer Leistung und niedrigen Datenraten.
DDS (Data Distribution Service)
Der DDS-Standard wird von der Object Management Group unterstützt und kommt hauptsächlich in industriellen Anwendungen zum Einsatz, die eine direkte Kommunikation von Maschine zu Maschine erfordern (M2M). DDS verwendet als Standard für Machine-to-Maschine-Middleware wie MQTT ein Publish-und-Subscribe-Modell, bietet allerdings eine höhere Geschwindigkeit als MQTT. Dafür aber gehen Daten verloren, wenn das Zielgerät ausfällt. DDS wird oft auch als Bus bezeichnet, da es ähnlich schnell wie eine Hardware-Schnittstelle arbeitet.
Wie CoAP findet auch DDS verbundene Geräte automatisch, das heißt es ist nicht notwendig, sie explizit an einer Netzwerk-Topologie anzumelden.
XMPP
XMPP ist besser bekannt unter dem Namen Jabber, dem einst beliebten Instant-Messenger. XMPP wurde ursprünglich für die Echtzeit-Kommunikation entwickelt, hat sich aber in ein Publish-Subscribe-Modell verwandelt. Das Kommunikationsprotokoll basiert auf XML, ist erweiterbar und verwendet keinen zentralen Nachrichtenserver wie CoAP und MQTT. Da XMPP das E-Mail-Adressformat verwendet, ist es einfach, XMPP an seinen Zielort weiterzuleiten.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+ und Facebook!
