IoT-Konnektivität So läuft der Datenaustausch zwischen Edge und Cloud

Ein Gastbeitrag von Janek Bettinger*

In einer IoT-Lösung spielen Hardware, Software und Daten zusammen. Um die Potenziale zu nutzen, gilt es, die drei genannten Aspekte aufeinander abzustimmen. Wie die Datenauswertung zu den gewünschten Resultaten führt, indem die Verbindung zwischen Edge- und Cloud-Schicht durchgängig, signalstark und störungsfrei ist.

Anbieter zum Thema

Es gibt nicht die eine Lösung für perfekten Konnektivität. Je nach Anwendungsfall gilt es, andere Kriterien und Anforderungen zu beachten.
Es gibt nicht die eine Lösung für perfekten Konnektivität. Je nach Anwendungsfall gilt es, andere Kriterien und Anforderungen zu beachten.
(Bild: gemeinfrei / Unsplash)

Jeder unkontrollierte Abbruch des Datenstroms führt zu Unstimmigkeiten und Fehlern in der Datenauswertung. Stabile Konnektivität in einer IoT-Lösung herzustellen, ist jedoch keine geringe Herausforderung und je nach Anwendungsfall müssen die jeweils passenden Funktechnologien, Protokolle und Datentypen gewählt werden. Fundiertes Know-how sowohl auf der Hardware- als auch auf der Software-Seite ist daher unumgänglich. Der folgende Artikel zeigt auf, was es in beiden Bereichen zu beachten gilt – und wie sich die richtige IoT-Plattform als Middleware zwischen Edge und Cloud finden lässt.

Anwendungsfälle für Hardware erfordern verschiedene Funktechnologien

An IoT-Geräte werden sehr unterschiedliche Konnektivitätsanforderungen gestellt. Dabei sind vor allem die Faktoren Reichweite, Stromverbrauch und Datenübertragungsrate von Interesse. Für manche Geräte ist es lediglich erforderlich, dass sie im Umfeld unter einem Meter kommunizieren. Ein typisches Beispiel sind Lesegeräte für kontaktloses Bezahlen durch Kreditkarten, Tokens oder Smartphones. Bei anderen Geräten ist es wiederum von Vorteil, wenn sie über dutzende Meter oder sogar Kilometer hinweg kommunizieren. Während manche Geräte über einen festen Stromanschluss verfügen, müssen andere bis zu mehreren Jahren mit einer Batterieladung auskommen.

Mittlerweile sind daher – je nach Anwendungsfall – viele verschiedene drahtlose Kommunikationsprotokolle in Gebrauch. Im Rahmen von IoT-Systemen sind die folgenden drei besonders relevant:

  • Bluetooth-Low-Energy (BLE): Insbesondere, wenn Consumer-Geräte angebunden werden sollen, bietet sich die stromsparende Bluetooth-Variante an, da sie von so gut wie allen Smartphones unterstützt wird.
  • Zigbee: Hierbei handelt es sich um ein drahtloses, energiesparsames Mesh-Netzwerk. Der Standard ist proprietär und basiert auf IEEE 802.15.4 (Low-Rate WPAN). Die Mesh-Struktur bildet komplexe IoT-Umgebungen mit vielen Geräten gut ab.
  • LoRaWAN: Geräte im ‚Long-Range-Wide-Area-Network‘ können Nachrichten über bis zu 15 km übertragen werden und erfordern dabei nur einen sehr geringen Stromverbrauch. Damit ist das Protokoll ideal für Sensordaten ohne Echtzeitanforderungen in Smart Cities, der Landwirtschaft oder etwa zum Überwachen von Fahrzeugen geeignet.

Darüber hinaus gibt es von den verbreiteten Protokollen WiFi und LTE jeweils Varianten, welche speziell auf IoT-Anforderungen ausgelegt sind und beispielsweise einen geringeren Stromverbrauch oder eine höhere Reichweite als ihre Pendants aufweisen, die man als Privatanwender kennt.

Abbildung 1: IoT-Protokolle nach Schichten im OSI bzw. TCP/IP Stack
Abbildung 1: IoT-Protokolle nach Schichten im OSI bzw. TCP/IP Stack
(Bild: AUSY Technologies Germany AG)

Umfangreichere IoT-Lösungen schließen Geräte mit mehreren Übertragungstechnologien ein. Damit eine konsistente Übertragung der Daten aus diesen in die Cloud möglich ist, muss in der Middleware ein einheitlicher Standard gelten, der mit den hardwareseitigen Kommunikationsmodellen kompatibel ist. Wie sich die unterschiedlichen Verbindungsprotokolle nach dem OSI Stack zuordnen lassen, zeigt Abbildung 1.

Konnektivität im IoT folgt dem ‚Publish/Subscribe‘-Kommunikationsmodell

Von den jeweiligen Geräten und Protokollen abstrahiert lässt sich die Kommunikation innerhalb einer IoT-Lösung in vielen Fällen in einem ‚Publish/Subscribe‘-Modell zwischen den folgenden drei Instanzen beschreiben:

  • 1. Der Publisher sendet eine Nachricht an den Broker.
  • 2. Der Broker verbindet Clients und filtert irrelevante Daten heraus.
  • 3. Der Subscriber meldet sich zum Empfang am Broker an; wenn nötig kommt auch hier ein Filter zum Einsatz, der Daten nach bestimmten Regeln auswählt.

Abbildung 2: Beispiel für einen Broker in einem IoT-System.
Abbildung 2: Beispiel für einen Broker in einem IoT-System.
(Bild: AUSY Technologies Germany AG)

Die Kommunikation zwischen Publisher und Subscriber findet asynchron statt, also stets unter Vermittlung eines Brokers. Dieser kann auch zwischen mehreren Instanzen auf beiden Seiten vermitteln, wie Abbildung 2 zeigt.

Ein solches asynchrone Kommunikationsmodell bringt verschiedene Vor- und Nachteile mit sich, die im Hinblick auf die Konnektivität der Gesamtlösung zu beachten sind. Zu den Vorteilen gehören insbesondere die folgenden:

  • Lose Kopplung: Die Publisher müssen die Subscriber nicht kennen.
  • Zeitinvarianz: Die Nachricht kann vom Subscriber auch zeitverzögert empfangen werden; dies ist insbesondere bei Systemen mit geringer Verfügbarkeit eine wichtige Eigenschaft. Man denke an Geräte, welche sich die meiste Zeit in einem Schlafmodus befinden und nur periodisch Daten senden, oder an instabile Netzwerkverbindungen.
  • Einfache Clients: Das Senden und Empfangen erfordert vergleichsweise geringe Ressourcen, da die Hauptlast im Broker liegt.

Demgegenüber gibt es auch gewisse Nachteile. Dazu gehört vor allem, dass der ‚Contract‘ zwischen Publisher und Subscriber nicht klar nachvollziehbar ist. Da sich Sender und Empfänger prinzipbedingt zunächst nicht kennen, steigt die Komplexität für Ende-zu-Ende-Verschlüsselung. Und schließlich kann der Broker zum Flaschenhals werden – fällt er aus oder ist er überlastet, kann das Gesamtsystem nicht mehr kommunizieren.

Doch trotz der genannten Nachteile hat das asynchrone Modell den klaren Vorzug bei der Konzeption von konnektiven IoT-Lösungen. Entscheidend ist dabei, dass es auch die mitunter sehr komplexen Umgebungen mit einer Vielzahl von sendenden und empfangenden Geräten beherrschbar macht. Nicht zuletzt deshalb beruhen die meisten IoT-Protokolle auf dem asynchronen Kommunikationsmodell – im Gegensatz zum HTTP-Standard, der im World Wide Web zum Einsatz kommt.

Standard-Protokolle für den Datenaustausch im IoT: MQTT, CoAP, AMQP

Für die Kommunikation zwischen der fünften und der siebten Schicht im OSI Stack – beziehungsweise der Anwendungsschicht im TCP/IP Stack – ist das im gewöhnlichen Internet etablierte HTTP zwar prinzipiell geeignet. Insbesondere im Hinblick auf die Energieeffizienz sind andere Protokolle demgegenüber vorzuziehen. In der Praxis kommen aktuell insbesondere die folgenden zum Einsatz:

  • Message-Queuing-Telemetry-Transport (MQTT): MQTT ist 1999 als Teil der IBM-MQ-Middleware entstanden und hat sich als Übertragungsprotokoll in der IoT-Welt fest etabliert. Dafür spricht, dass alle gängigen IoT-Plattformen eine Schnittstelle zur Datenübertragung vermittels MQTT beinhalten. Ausgelegt ist das Protokoll für limitierte Geräte in unzuverlässigen Netzwerken mit geringer Bandbreite und hoher Latenz.
  • Constrained-Application-Protocol (CoAP): CoAP ist technisch an HTTP angelehnt, jedoch unter anderem dank UDP-Unterbau deutlich leichtgewichtiger und damit besser für IoT-Lösungen geeignet. Wie bei HTTP-APIs üblich, nutzt CoAP REST-ähnliche Schnittstellen und Methoden wie GET und POST. CoAP unterstützt sowohl synchrone als auch asynchrone Kommunikation und erlaubt es, von fremden Ressourcen bei Änderungen informiert zu werden – vergleichbar mit dem ‚Observer Pattern‘ in der Programmierung. Dank Multicast-Unterstützung können einzelne Nachrichten auch an ganze Client-Gruppen gesendet werden.
  • Advanced-Message-Queuing-Protocol (AMQP): Bei AMQP handelt es sich um ein asynchrones Message-Queue-Protokoll, das mittlerweile ISO-zertifiziert ist (ISO 19464). Im Vergleich zu den bereits genannten Protokollen ist es deutlich schwergewichtiger.

Welches Protokoll ist nun für das jeweilige Projekt das richtige? Für die Auswahl kommen verschiedene Kriterien in Betracht. In IoT-Systemen geht es um eine Abwägung zwischen Ressourcenbedarf auf der einen Seite und Zuverlässigkeit, Latenz und Bandbreite auf der anderen Seite. Auch wenn die verschiedenen Protokolle am einzelnen Gerät nur einen geringen Unterschied des Stromverbrauchs ausmachen, sind die Einsparungen bei tausenden oder sogar zehntausenden Übertragungspunkten im System deutlich spürbar.

Die IoT-Plattform steuert die Konnektivität im Gesamtsystem

IoT-Plattformen sind die zentrale Komponente im Technologie-Stack für das IoT. Sie stellen die Middleware, also das Bindeglied, zwischen den Geräten und den Software-Applikationen dar. In ihrer grundlegenden Funktion ermöglicht eine IoT-Plattform Konnektivität; sie stellt also sicher, dass die Geräte im System miteinander verbunden sind und Informationen dorthin gelangen, wo sie verarbeitet werden sollen.

Um die richtige IoT-Plattform zu finden ist daher zunächst zu klären, welche Gerätetypen in der IoT-Lösung vorkommen sollen und welche Übertragungsprotokolle diese am besten abbilden. Zumindest die gängigen IoT-Plattformen unterstützen die wichtigsten Protokolle. In die Anforderungsanalyse sollten daher noch weitere Kriterien wie Support, Unterstützung der Firmware in den Geräten sowie Lizenz-, Betriebs- und Entwicklungskosten einbezogen werden.

Dieser Beitrag ist ursprünglich auf unserem Partnerportal Industry of Things erschienen.

* Janek Bettinger arbeitet bei der AUSY Technologies Germany AG als Software Engineer und Architekt im Cloud-Umfeld, darüber hinaus leitet er die unternehmensinterne Expertengruppe „Internet of Things“.

Jetzt Newsletter abonnieren

Verpassen Sie nicht unsere besten Inhalte

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

(ID:48036124)