Eine Einführung
in IoT-Protokolle

Das Internet der Dinge (IoT) ist ein interdisziplinärer Bereich, der einer Vielzahl von Geräten – von kleinsten Sensoren bis hin zu Industriemaschinen – eine nahezu in Echtzeit erfolgende Kommunikation und Wechselwirkung ermöglicht. Es hat die Abhängigkeit von der Datenverarbeitung auf einem zentralen Server beendet und durch eine dezentralere Lösung ersetzt, bei der jedes Gerät sowohl als Client als auch als Server fungieren kann.

Traditionell konnten einzelne Geräte (oder Clients) in einem Netzwerk nur jeweils eine Verbindung initiieren, um Daten zu senden oder anzufordern, während Server oder Servercluster nur von den Geräten erhaltene Anforderungen bearbeiteten. Dieses Konzept wird als Request/Response Pattern bezeichnet und weist verschiedene erhebliche Nachteile auf.

Ein Hauptnachteil besteht darin, dass in einem aus Sensoren, Aktoren und Servern bestehenden System die Sensoren und Aktoren nicht direkt untereinander kommunizieren können. Ein einfaches Beispiel hierfür ist ein Sensor, der den Zustand verschiedener Aktoren zu ändern versucht, dafür aber die entsprechende Anforderung zuerst an den Server senden muss. Gleichzeitig müssen die Aktoren laufend den Server abfragen, um zu prüfen, ob sie ihren Zustand ändern müssen. Damit sind zwei entscheidende Nachteile verbunden: Erstens besteht ein hohes Risiko, dass Nachrichten vom Server nicht empfangen werden können, weil dieser stark ausgelastet ist und Zeit zur Verarbeitung der Anforderungen benötigt. Zweitens belegen die Aktoren unter Umständen unnötig viel Bandbreite, weil sie ständig den Server abfragen, auch wenn keine Änderungsanforderung anliegt.

Die moderne Vorgehensweise besteht in der Verwendung des so genannten Publish/Subscribe (oder Pub/Sub) Pattern. Dieser Ansatz ersetzt die herkömmliche Architektur und geht deren Probleme an. Im gleichen Beispiel eines Sensors, der den Zustand einiger Aktoren mit einem ähnlichen Architekturdesign zu ändern versucht, tritt an die Stelle des Servers ein sogenannter Message Broker, dessen ausschließliche Aufgabe es ist, mehrere Nachrichten-Warteschlangen zu verwalten. Sensoren und Aktoren werden so upgegradet, dass sie Nachrichten in spezifischen Warteschlangen posten, empfangen und verarbeiten können.

Mit dieser Lösung benötigt der Broker nur eine minimale Zeit vom Erhalt der Nachricht bis zu ihrer Bestätigung. Die Aktoren wiederum müssen nicht laufend den Server abfragen, da sie nur dann benachrichtigt werden, wenn neue, relevante Nachrichten eingehen.


Gängige IoT-Protokolle

Es sind zahlreiche IoT-Protokolle auf dem Markt, die das oben beschriebene Pattern implementieren. Im Folgenden werfen wir einen Blick auf drei der beliebtesten Open-Source-Protokolle und einige Beispiele für deren Implementierung.

MQTT

MQTT

MQTT ist als ein extrem schlankes Protokoll konzipiert. Es eignet sich hervorragend für die Kommunikation zwischen Geräten, die in eingeschränkten Umgebungen mit instabiler Konnektivität eingesetzt werden. Dies ist durch das MQTT-Design bedingt: Ein Broker mit Schutzmechanismen gegen Konnektivitätsprobleme und vergleichsweise kleinen Nachrichten mit vernachlässigbaren Headern. Um die Schutzmechanismen anwenden zu können, ist der Broker für die Handhabung der Warteschlangen, Nachrichten und Abonnentenlisten zuständig. Da der Broker sämtliche Daten besitzt, kann ein typisches MQTT-Setup nicht in effizienter Weise horizontal skaliert werden. Er kann im Durchschnitt bis zu 100.000 Nachrichten in der Sekunde verarbeiten.

Ein ideales Anwendungsszenario für MQTT ist eine vernetzte Fahrzeugflotte. Während der Fahrt können die Fahrzeuge durch Tunnels oder abgelegene Gebiete fahren, wo keine Verbindung besteht. Dank MQTT gehen dann keine Nachrichten verloren. Eine bekannte MQTT-Implementierung ist Mosquitto, die unter der Eclipse Foundation-Lizenz frei nutzbar ist. Dabei kann man den Broker am eigenen Standort oder in der Cloud hosten. Einige der Cloud-Lösungen sind Amazon IoTCore, Azure IoT Hub sowie Google IoTCore.

AMQP

AMQP

AMQP ist eher auf komplexes Routing und Skalierbarkeit ausgelegt. Jede Nachricht besitzt einen Header mit Zustelldaten und Routingpräferenzen. Der Nachrichtenbroker hält für alle bei ihm eingehenden Nachrichten eine strikte Reihenfolge ein. AMQP sollte im Vergleich zu MQTT in weniger stark eingeschränkten Umgebungen genutzt werden und in Fällen, in denen es stärker auf die Reihenfolge von Nachrichten, komplexes Routing und Garantien der Zustellverarbeitung ankommt. Da die Nachrichten ihre Metadaten enthalten, kann der Message Broker mehrere Knoten umfassen, von denen jeder 50.000 Nachrichten in der Sekunde handhaben kann (insgesamt bis zu einer Million Nachrichten).

In komplexen industriellen Umgebungen mit verschiedenen Fertigungslinien kann AMQP eine besser geeignete Lösung sein, da die Komplexität einer Fabrikumgebung mithilfe des Routingprozesses von AMQP exakt abgebildet werden kann. RabbitMQ ist einer der populärsten AMQP-Broker und kann unter der Mozilla-Lizenz kostenlos genutzt werden. RabbitMQ erweitert auch die Unterstützung für MQTT-Nachrichten und ist daher äußerst wertvoll für selbst gehostete Lösungen. Einige kostenpflichtige Cloud-Lösungen sind Amazon MQ und Azure Servicebus.

Apache Kafka

Apache Kafka

Apache Kafka ist anders als MQTT und AMQP konzipiert. Seine Warteschlange kann als Protokollsystem betrachtet werden, in dem alle Nachrichten enthalten sind, mit strikten Zeitstempeln und Reihenfolgen. Eine Mitteilung wird nur dann entfernt, wenn sie verfällt, und nicht, wie bei den anderen beiden Protokollen, bei Zustellung. Der Abonnent (in Kafka als „Verbraucher“ bezeichnet) behält sein eigenes Offset, um zu wissen, welche Nachrichten er bereits gelesen hat, während der Message Broker lediglich für die Reihenfolge zuständig ist. Kafka wird nicht wie MQTT und AMQP für die Echtzeitkommunikation zwischen Geräten verwendet. Es kommt vielmehr zum Einsatz, wenn eine Reihenfolge, Aufbewahrung und Wiedergabe der Nachrichten benötigt wird. Die gesamte Arbeitslast in einer Kafka-Umgebung wird auf die Verbraucher verteilt, wodurch diese Millionen von Nachrichten in der Sekunde handhaben kann.

Kafka eignet sich beispielsweise optimal zur Datenanalyse, um Sensordaten zur vorausschauenden Wartung aufzunehmen oder Benutzeraktionen im Internet zu erfassen, um Einkaufsgewohnheiten vorhersagen zu können. Kafka ist Teil der Apache Foundation und daher im Rahmen von deren 2.0-Lizenz kostenlos nutzbar. Cloud-gehostete Lösungen sind Amazon MSK und Azure Eventhub.

Ein Blick in die Details

In diesem Abschnitt werden die verschiedenen Protokolle ein wenig eingehender betrachtet; als Grundlage dienen dabei sieben Hauptkriterien. Aus diesen Kriterien wird ersichtlich, warum diese Protokolle in ihrer Nutzung so stark variieren und auf welcher Basis ein Protokoll eingesetzt werden sollte.



Installation und Konfiguration: Sowohl AMQP und MQTT sind einfach zu installieren. Eine Anwendung kann dann eine Nachricht an den Broker in eine bestimmte Warteschlange senden, von wo aus diese an eine andere weitergeleitet wird. AMQP kann aufwendiger zu konfigurieren sein, wenn komplexere Routing-Fähigkeiten benötigt werden. Kafka ist in der Einrichtung am kompliziertesten, weil zahlreiche Produzenten, Verbraucher und Konnektoren installiert und korrekt konfiguriert werden müssen, was umfassendere Kenntnisse erfordert.

Komplexes Routing: MQTT ermöglicht lediglich ein Routing anhand von enthaltenen Warteschlangennamen („Topics“); Nachrichten mit den Topics der jeweiligen Warteschlange werden an diese gesendet. Kafka tut dies ebenfalls, kann jedoch jede Warteschlange partitionieren, so dass Verbraucher diese separat handhaben können. AMQP bietet dagegen eine Vielzahl verschiedener Routing-Optionen. Es kann wie die anderen beiden Protokolle Nachrichten anhand von Topic-Namen organisieren und es kann Nachrichten an alle verbundenen Abonnenten veröffentlichen. Für eine komplexere Lösung kann AMQP Nachrichten durch komplexe Berechnungen im Header trennen (z. B. im Header enthaltene Bedingungen, die Abonnenten erfüllen müssen). Eine zusätzliche Funktionalität in AMQP ist eine Standard-Warteschlange, an die alle Nachrichten ohne Angabe zur Warteschlange automatisch gesendet werden.

Skalierbarkeit der Infrastruktur: Während MQTT und AMQP auf einem einzelnen Broker beruhen, der die Warteschlangen enthält und verwaltet, kann nur AMQP mit mehreren Knoten funktionieren, was eine bessere horizontale Skalierung ermöglicht. Für Kafka liegt der Großteil der Logik beim Verbraucher, wodurch im Vergleich zu den beiden anderen eine bessere Skalierung möglich wird.

Nachrichtenreihenfolge: Sowohl MQTT als auch AMQP gewährleisten in gewissem Maße die Reihenfolge innerhalb der Warteschlange, doch beide haben Schwierigkeiten mit der Reihenfolge, nachdem die Nachrichten von den Abonnenten gelesen wurden. Kafka garantiert dagegen durch seine protokollähnlichen Warteschlangen die Nachrichtenreihenfolge unter allen Bedingungen.

Speicherung: Nachrichten werden in MQTT nur einmal zugestellt, während in AMQP mehr Bedingungen für die Nachricht hinzugefügt werden können (mehrfaches Lesen, Bestätigungen usw.). Wenn die Bedingungen einmal erfüllt sind, gehen die Nachrichten jedoch für immer verloren. Kafka entfernt die Nachrichten nicht aus seiner Warteschlange, sondern jeder Verbraucher verschiebt sein Offset in die zu lesende Nachricht, wodurch Nachrichten unbegrenzt nachgehalten werden können (eingeschränkt lediglich durch Hardware-Aspekte).

Vernachlässigbare Latenz: Durch die einfache Logik von MQTT und die geringe Nachrichtengröße weist es eine zusätzlich zur Latenz der Netzwerkübertragung vernachlässigbare Latenz auf. Bei Kafka dauert die Bestätigung der Nachricht länger, weil eine strikte Reihenfolge und ein korrektes Einfügen der Nachricht in die Warteschlange gewährleistet werden muss. Dadurch nimmt die Latenz zu. Abhängig vom Setup mit AMQP und dem konfigurierten komplexen Routing kann dessen Latenz sich auf nahezu das Doppelte der beiden anderen Protokolle erhöhen. Mit einem einfachen Setup kann es dagegen so schnell wie Kafka sein.

Bandbreitenbelegung: MQTT ist für eingeschränkte Umgebungen ausgelegt, in denen sich seine Bandbreitenbelegung als optimal erweist. Kafka nutzt mehr Bandbreite, bedingt durch seine Nachrichtenzusammensetzung und die verwendeten Zeitstempel. Die Bandbreitenbelegung von AMQP ist die schlechteste unter den drei Protokollen, weil die Header der Nachrichten extrem groß sein können, wodurch ein doppelt so großes Datenvolumen übertragen werden muss.


Schlussfolgerung

IoT hat in den letzten fünf Jahren mehr Aufmerksamkeit erhalten, bedingt durch Investitionen in den Bereichen Smart Homes, Smart Cities, vernetzte Fahrzeuge, industrielles IoT und vielen anderen mehr. Es ist eine hervorragende Lösung für diese Bereiche, da es die Kommunikation zwischen Geräten drastisch verbessern kann und eine Datensammlung und -analyse in Echtzeit ermöglicht. Unter Anwendung des Pub/Sub Pattern kann es die Nachteile herkömmlicher Kommunikationspattern ausgleichen.

  • MQTT kann zur Kommunikation zwischen Geräten bei unzuverlässiger Netzwerkstabilität und Bandbreite eingesetzt werden.
  • AMQP ist eine exzellente Lösung, wenn komplexe Routing-Möglichkeiten in einer stabilen Umgebung benötigt werden.
  • Kafka kann dagegen eine effizientere Lösung für Situationen darstellen, in denen die Reihenfolge und Wiederherstellung der Nachrichten sowie eine geringe Ressourcen-Skalierbarkeit wichtigere Faktoren darstellen. Diese Fälle sind in der Regel mit der Aufnahme und Analyse von Daten verbunden.

Concept Reply hat bereits sehr komplexe Anwendungsfälle umgesetzt und Architekturen erstellt, die verschiedene Kombinationen aus IoT-Protokollen sowie unterschiedliche Pattern nutzen, um die jeweils optimale Lösung für einen Kunden zu erreichen. Praxisszenarien können äußerst komplex sein; beispielsweise kann ein Kunde Daten sammeln und auswerten müssen. Dieses Szenario kann mit einem MQTT-Service gelöst werden, der Daten sammelt und zur Durchführung der Analyse an einen Kafka-Service weitergibt. Ein weiteres Beispiel: Ein Kunde will Daten sammeln und benötigt direkten Zugriff auf Industriemaschinen, weshalb sowohl ein Pub/Sub Pattern als auch ein Request/Response Pattern eingesetzt werden müssen.


  • strip-0

    Concept Reply ist ein auf die Erforschung, Entwicklung und Validierung innovativer Lösungen spezialisierter IoT-Softwareentwickler und unterstützt seine Kunden aus der Automobil-, Fertigungs- und Smart-Infrastructure-Industrie sowie anderen Branchen in allen Fragen rund um das Internet der Dinge (IoT) und Cloud Computing. Ziel ist es, End-to-End-Lösungen entlang der gesamten Wertschöpfungskette anzubieten: von der Definition einer IoT-Strategie über Testing und Qualitätssicherung bis hin zur Umsetzung einer konkreten Lösung.
    www.reply.com/concept-reply/de/