Um Geräte und Softwareapplikationen im Internet of Things (IoT) miteinander zu verbinden, ist eine IoT-Plattform als Middleware unerlässlich. Was sie leistet beziehungsweise wofür sie sich einsetzen lässt, wurde in unserem ersten Blogartikel zu diesem Thema beschrieben. Nun wenden wir uns der Frage zu, welche unterschiedlichen Arten von IoT-Plattformen es gibt und was die jeweiligen Angebote versprechen.
Bevor wir in den Vergleich gehen, sollte jedoch noch folgender Hinweis erfolgen: Das Angebot am Markt ist mittlerweile riesig. Derzeit listen die Marktforscher von „IoT Analytics“ über über 600 IoT-Plattformen auf – Tendenz steigend. Alle Plattformen im Einzelnen zu diskutieren, würde daher deutlich den Rahmen dieses Artikels überschreiten.
Bei den hier vorgestellten Systemen handelt es sich vielmehr um eine exemplarische Auswahl, die aus unserer Sicht die zukunftsfähigsten abdeckt. Schließlich sollte nicht vergessen werden: Eine Softwarelösung – ob proprietär oder Open Source – ist umso geeigneter für ein langfristiges Investment, je größer ihre Anwenderbasis ist.
IoT-Plattformen lassen sich grob in drei Gruppen unterteilen: Proprietäre Plattformen der großen Cloud-Anbieter; Plattformen aus der Open Source Community; sowie schließlich spezialisierte Plattformen, die einen eng definierten Funktionsbereich abbilden. Für jede der drei Gruppen sind im Folgenden ein bis drei Beispiele für IoT-Plattformen aufgeführt.
Beginnen wir mit den drei großen Cloud-Anbieter Microsoft, AWS und Google. Diese führen in ihrem Portfolio jeweils eine eigene IoT-Plattform auf. Im Folgenden werden deren Eigenheiten aufgezeigt und insbesondere im Hinblick auf ihre Konnektivität – also die Verbindungen zu und zwischen den Geräten – diskutiert:
Microsoft Azure IoT
Gartner und Counterpoint Research bescheinigen Microsoft Azure noch vor AWS das umfassendste (Industrial-)IoT-Angebot. Bereits 2015 stellte das Unternehmen die Azure IoT Suite vor, kurze Zeit später den IoT Hub zur bidirektionalen Kommunikation zwischen Geräten und Anwendungen.
Darüber hinaus stehen Dienste zur Provisionierung und Aktualisierung von Geräten zur Verfügung. Generischere Azure-Dienste, etwa zur Datenanalyse lassen sich natürlich ebenso in IoT-Setups integrieren. Mit IoT Central gibt es zudem eine vollständig gemanagte Software-as-a-Service-Lösung auf deren Basis man mit branchenspezifischen Templates diverse Standard-Use-Cases umsetzen kann. Zur weiteren Unterstützung betreibt Microsoft in München zudem ein „AI & IoT Insider Lab“.
Konnektivität – Der Azure IoT Hub ist eine zentrale Komponente und ermöglicht die Nachrichtenübertragung über HTTP, MQTT 3.1.1 und AMQP. Mit der Unterstützung von AMQP grenzt sich Microsoft von Wettbewerbern wie Amazon oder Google ab, deren IoT-Plattformen das Streaming-Protokoll aktuell nicht unterstützen.
Auf den zweiten Blick wird ersichtlich, dass der MQTT-Broker keine vollständige Implementierung des MQTT-Protokolls ist. So ist das Topic-Format vorgegeben, was insbesondere das gezielte Empfangen bestimmter Nachrichten deutlich erschwert. Geräte werden am besten mittels Azure-SDK registriert und authentifiziert. Eine eigene Implementierung ist zwar grundsätzlich möglich, aber da es ohnehin mit dem vorgegebenen Topic-Format zu arbeiten gilt, bringt ein SDK-agnostisches Vorgehen wenig Vorteile für Wiederverwendbarkeit mit anderen MQTT-Brokern.
Alternativ ließe sich die Topic-Struktur mittels einer Middleware umschreiben, was jedoch zusätzliche Komplexität mit einschließt. Die Unterstützung von MQTT 5 befindet sich bei Azure IoT derzeit in der Public-Preview-Phase, ist gegenüber der 2018 veröffentlichten Protokollversion aktuell jedoch noch unvollständig.
AWS IoT
Der Platzhirsch im Cloud-Geschäft bietet wenig überraschend mit AWS IoT seit 2015 auch auf IoT zugeschnittene Funktionalität „as a service“ an. Neben einem Message-Broker, der gängige Protokolle wie MQTT und HTTP beherrscht, bietet AWS diverse Dienste zur Geräte-Verwaltung und Analyse von IoT-Daten an.
Darüber hinaus lassen sich andere AWS-Dienste integrieren und bekannte allgemeine Konzepte wie etwa Cloud Formation (Infrastructure as Code) und Zugriffsverwaltung (Identity & Access Management – IAM) nutzen. Mit diversen Quick-Start-Wizards in der Weboberfläche versucht der Cloud-Riese, den Einstieg in sein IoT-Universum möglichst angenehm zu gestalten. Wie bei AWS üblich, lassen sich die IoT-Dienste nicht auf eigener Infrastruktur betreiben.
Konnektivität – Geräte können mittels HTTPS und MQTT 3.1.1 angesprochen werden, wobei der MQTT-Broker nur QoS 0 und 1 unterstützt. Damit wird eine Nachricht mindestens einmal, womöglich aber auch mehrfach zugestellt. Nicht unterstützt werden „Retained Messages“, die automatisch an neu angemeldete Geräte gesendet werden.
Manche Standard-Limits sind zwar etwas strikt, können jedoch bei Bedarf über die Service Quota Console angepasst werden. Dazu gehört das Retry-Interval. Es definiert, wie lange eine Nachricht bei QoS vorgehalten werden soll. Generell ist positiv hervorzuheben, dass der Broker weitgehend standardkonform ist, das angebotene SDK muss daher nicht zwingend genutzt werden.
Google Cloud IoT
Seit Anfang 2018 hat mit Google auch der dritte „Big Three“-Public-Cloud-Anbieter IoT-Lösungen im Portfolio. Die zentrale Komponente ist der IoT Core zur Verwaltung der Kommunikation mit Geräten. Die Integration in weitere generische Dienste der Google Cloud Platform (GCP) ermöglicht weitreichende Datenauswertung und -verarbeitung. Auch wenn Preisvergleiche im Cloud-Umfeld schwierig sind, zeigen viele Berichte, dass das IoT-Angebot von Google zumeist etwas teurer als die Pendants von Azure oder AWS ist.
Konnektivität – Google Cloud IoT Core stellt eine MQTT-Bridge zur Verfügung, welche direkt an den generischen „Cloud Pub/Sub“-Service angebunden ist. Wie auch Azure implementiert Google dabei den MQTT-Standard nur teilweise und gibt insbesondere die Topic-Struktur vor. QoS 2, also die exakt einmalige Zustellung von Nachrichten, wird nicht unterstützt – ebensowenig wie „Retained Messages“ und „Persistent Sessions“. Mit diesen Einschränkungen im Hinterkopf lässt sich dennoch problemlos ein beliebiger Client für MQTT 3.1.1 nutzen. Alternativ können Nachrichten auch mittels HTTP 1.1 (mit SSL) gesendet werden.
Wie in vielen anderen Softwaresegmenten hat die Open Source Community auch bei IoT-Plattformen ein attraktives Angebot hervorgebracht. Exemplarisch seien die folgenden beiden Systeme erwähnt:
ThingsBoard
ThingsBoard ist die wohl beliebteste Open-Source-IoT-Plattform und wurde erstmals Ende 2016 veröffentlicht. Neben einer kostenfreien Community-Variante mit eingeschränktem, aber dennoch praktikablem Funktionsumfang, gibt es eine preislich gestaffelte „Professional Edition“, die sich entweder selbst hosten oder anmieten lässt; auf Wunsch auch als White-Label-Lösung.
Gerade die Möglichkeit, die Plattform auf eigener Infrastruktur selbst zu betreiben, grenzt ThingsBoard von den Angeboten der großen Public-Cloud-Anbieter ab. Wie der Name bereits andeutet, sind ansprechende und komplexe Dashboards ein Schwerpunkt von ThingsBoard. Da die Daten von den Geräten aber erst einmal zu den Dashboards gelangen müssen, fehlen ebenso wenig Funktionen für das Geräte-Management und die Konnektivität. Mittels einer Rule-Engine lassen sich zudem Daten aufbereiten und Aktionen auslösen.
Für weitergehende Datenanalysen und -vorhersagen lässt sich ThingsBoard an das kommerzielle Analyseprogramm Trendz Analytics anbinden.
Intern nutzt ThingsBoard Open-Source-Tools wie Apache Kafka (kurzzeitige Persistierung eingehender Messages), Redis (Cache), Apache ZooKeeper (Koordinierung), HAProxy (Load Balancer), PostgreSQL (SQL-Datenbank), Cassandra oder TimescaleDB (als NoSQL-Datenbanken für Zeitreihen). Generell lässt sich ThingsBoard als Monolith (gegebenenfalls im Cluster-Modus) oder in einer – von den Machern empfohlenen – verteilten Architektur deployen.
Die erforderlichen Micro-Services werden als Docker-Images angeboten; darüber hinaus gibt es Skripte und Templates zum Deployment in ein Kubernetes-Cluster. Mit der gemanagten Cloud-Variante muss man sich um diese Aspekte naturgemäß weniger Gedanken machen.
Konnektivität – Bereits die kostenfreie ThingsBoard-Version unterstützt MQTT, CoAP und HTTP. Der MQTT-Broker unterstützt dabei QoS 0 (keine oder höchstens eine Zustellung) und QoS 1 (mindestens eine Zustellung) und ist kompatibel zu Standard-Clients. Wie auch die Broker der großen Cloud-Anbieter unterstützt ThingsBoard kein QoS 2 für die Nachrichtenübermittlung.
Und auch hier ist die Topic-Struktur ein Stück weit vorgegeben. Das optionale separate ThingsBoard IoT Gateway ermöglicht die Anbindung weiterer Systeme und Geräte mit weiteren Protokollen, wie unter anderem Bluetooth LE, CAN, ODBC (für Datenbanken). Darüber hinaus lassen sich auch externe MQTT-Broker oder REST-APIs integrieren.
Kaa IoT
Das im Jahr 2014 erstmals veröffentlichte Kaa IoT ist eine auf Open-Source-Technologien basierende Plattform, die sich sowohl selbst hosten als auch als Platform as a Service (PaaS) oder private Instanz anmieten lässt.
Funktional bietet Kaa IoT die zentralen Funktionen einer modernen IoT-Plattform: das Geräte-Management ermöglicht dank „digitaler Zwillinge“ den Zustand ggf. nicht erreichbarer Geräten zu persistieren, verwaltet Zugangsdaten und unterstützt bei Over-the-Air-Updates. Die Geräte lassen sich wie üblich unter anderem über MQTT oder HTTP ansprechen; empfangene Daten und Events können mit eigenen Dashboards visualisiert werden und weitere Aktionen auslösen.
Dem Open-Source-Gedanken folgt Kaa mittlerweile nur noch eingeschränkt und so ist die Plattform seit 2016 nur noch als kommerzielle Enterprise-Version im Vertrieb. Auf GitHub werden im Wesentlichen nur noch RFCs veröffentlicht, die die eigenen Kommunikationsprotokolle beschreiben, sowie kleinere Client-Libraries.
Die Plattform lässt sich nach erfolgter Lizenzierung in einem eigenen Kubernetes-Cluster deployen und nutzt unter der Haube etablierte Tools wie unter anderem Apache Kafka (Event-Streaming), Keycloak (Authentifizierung und Authorisierung), Kibana (Analytics und Alerting), Grafana (Visualisierung) und MongoDB (Datenbank).
Konnektivität – Kaa IoT implementiert ein eigenes Kommunikationsprotokoll, das auf Transportebene MQTT (optional via TLS oder WebSockets) oder HTTP nutzt. Dabei wird ausdrücklich kein vollwertiger MQTT-Broker betrieben (und keine QoS spezifiziert), sondern ein entsprechender Micro-Service agiert als Schnittstelle zwischen Plattform und Clients. Kaa IoT erweitert MQTT um ein optionales Request-Response-Pattern durch die Einführung einer Request-ID in der Topic-Bezeichnung. Diese kann schließlich zur Bestätigung nach erfolgter Verarbeitung genutzt werden.
Für schwächere Geräte, welche keinen TCP-Stack betreiben können, vertreibt Kaa IoT eigene Gateway-Boards, womit beispielsweise Bluetooth LE und LoRa unterstützt wird.
Nicht für jedes IoT-Projekt bedarf es eine vollumfängliche IoT-Plattform. Gemäß des KISS-Prinzips („keep it simple, stupid“) und der Unix-Philosophie („do one thing well“) kann es durchaus sinnvoll sein, spezialisierte Lösungen einzusetzen und diese selbst zu einer Gesamtlösung zu kombinieren. Da diese Plattformen auf sehr spezielle Anwendungsfälle zugeschnitten sind, soll hier lediglich eine bekanntere als Beispiel aufgeführt werden:
HiveMQ
HiveMQ ist ein MQTT-Broker und ermöglicht den Austausch von Nachrichten zwischen Geräten oder zusätzlichen Backend-Systemen. Dabei implementiert HiveMQ den MQTT-Standard vollständig und unterstützt bereits die Protokollversion 5. Hiermit bietet HiveMQ Funktionen auf Protokoll- und Broker-Ebene, die bei vielen Plattformen nicht oder nur anwendungsseitig möglich sind.
Dazu zählen unter anderem „Retained Messages“ in Kombination mit einem Ablaufintervall, wodurch Geräte, die sich neu mit dem Broker verbinden, für einen definierten Zeitraum die zuletzt gesendete Nachricht erhalten. Mit „Shared Subscriptions“ erhalten Empfänger die Nachrichten abwechselnd und die Last wird somit verteilt. Im Gegensatz zu den großen Cloud-IoT-Plattformen unterstützt HiveMQ den QoS 2 Message Flow – also die garantiert (exakt) einmalige Zustellung von Nachrichten.
Ein Dashboard ermöglicht das Monitoring von verbundenen Geräten, gesendeten und zwischengespeicherten Nachrichten. HiveMQ lässt sich als SaaS anmieten oder auf beliebiger Infrastruktur selbst betreiben. Die kostenfreie Community-Edition bietet bereits eine vollständige MQTT-Unterstützung, ist jedoch funktional eingeschränkt. Erweiterte Funktionen wie verbessertes Monitoring, ein Cluster-Modus zur horizontalen Skalierung oder eine Kafka-Integration erfordern eine Lizenz.
Wie aus den vorangegangenen Betrachtungen deutlich werden dürfte, gibt es nicht „die eine“ richtige IoT-Plattform. Grundlagen für die richtige Auswahl sind unter anderem eine genaue Anforderungsanalyse sowie ein langfristiger strategischer Horizont. Dazu gehört die Prognose, wie die IoT-Lösung sich voraussichtlich weiterentwickeln beziehungsweise skalieren wird. Die gewählte IoT-Plattform muss hierfür entsprechend ausgelegt sein.
Zu den weiteren Auswahlkriterien für eine IoT-Plattform gehören die folgenden:
Um den Bedarf zu ermitteln sowie eine Strategie für Ihre IoT-Plattform zu entwickeln, stehen die Experten von AUSY Technologies mit Ihrem Know-how bereit.