Offene Standards für das Internet of Things

Open Source spielt auch im IoT eine wichtige Rolle.

 

von Dr. Stefan Ried

Open Source ist aus der Software-Landschaft im Internet und in Unternehmen nicht mehr wegzudenken. So ist es nicht verwunderlich, dass auch im Internet der Dinge (IoT) Open Source eine wichtige Rolle spielt. Wir möchten mit diesem Analyst-View einen ersten Einblick in die IoT-Open-Source-Landschaft geben. Weitere Analyst-Views werden andere Stacks oder die Open-Source-Aktivitäten bestimmter Hersteller beleuchten und grundsätzliche Hilfe bei Plattform-Entscheidungen geben.

 

Kernaussagen

Open Source spielt eine wesentliche Rolle bei der Entwicklung von IoT-Technologien.

Anwendern muss bewusst sein, dass man sich mit den Konzepten im Detail vertraut machen muss und besonders die Operationsaspekte gut verstehen und lernen sollte.

Die führenden Cloud-Provider können helfen, die operative Seite von Open Source zu vereinfachen. Viele IoT-Dienste von AWS und Google GCP, aber auch von Azure, basieren auf Open Source. Grundsätzlich sollte der Cloud-Provider wenig an der Standardkonformität des Services ändern.

 

Schon recht lange am Markt ist der IoT-Stack von Eclipse. Wir gehen die Komponenten einmal von unten nach oben, also von den kleineren „Constrained“ Controllern bis hoch in die Cloud, durch:

Der Constraint-Device-Stack setzt auf einem sehr einfachen kleinen Betriebssytem oder direkt als Firmware auf. Wir reden hier über kleine Controller mit 1 Megabyte RAM, ohne Filesystem oder gar einen ganzen Linux-Kern. Das sind zum Beispiel ATMEL-Controller, die auch in der bekannten Prototyping-Plattform Arduino zum Einsatz kommen. Darauf baut das Eclipse-Edje-Projekt auf. Es abstrahiert die Hardware und bietet so einen High-Level-Access auf Dinge wie I / O-Pins oder lokalen Speicher (EEPROM). Darauf setzt das Projekt Paho auf, das eine Implementierung des MQTT-Standards darstellt. Neben der Abstraktion der Hardware und der Kommunikation von Sensorik und Aktorik ist das Remote Management wichtig. Eclipse setzt mit dem Projekt Wakaama auf den „Open Mobile Alliance Lightweight Machine-2-Machine“(OMA LWM2M)-Standard.

 

Eclipse Constrained Device Stack	Eclipse Gateway & Smart Devices Stack

 

Eine Etage höher, bei den Gateways und „Smart“ Devices, ist schon etwas mehr Leistung vorhanden. Wir reden hier von Geräten der Raspberry-Pi-Klasse, die ein vollständiges Linux mit Filesystem und einen Java-Stack performant genug ausführen können. Dort stellt die Eclipse Foundation gleich mehrere Optionen zur Verfügung:

• Eclipse Kura ist ein Java / OSGi-basierter Container für M2M-Gateways. Dabei aggregiert es auch andere Open-Source-Komponenten oder implementiert die notwendige Middleware-Funktionalität. Damit bietet ein Kura-basiertes Gateway die direkte Kommunikation zu Schnittstellen an dem Device und den konsistenten Zugriff von vielen kleineren Constrained Devices, die vielleicht über lokale Feldbusse angeschlossen sind. Kura kann auch unter instabilen Netzwerk­bedingungen mit mehreren Cloud-­Backends sprechen. Dazu implementiert Kura nicht nur ein MQTT-basiertes Messaging, sondern hat auch die Mes­saging- und Routing-Engine „Camel“ von den Apache-Kollegen im Bauch. Zu guter Letzt bringt Kura einen professionellen Remote-Management-Client mit, der von der Ferne viele Wartungsarbeiten ermöglicht. Damit adressiert Kura insgesamt professionelle Gateways oder Smart Devices.
• Eclipse SmartHome adressiert mit viel Konnektivität und einem guten Ecosystem das andere Extrem der Consumer- oder semi-professionellen Gebäude-Systeme. Lokale Devices wie die Philips Hue oder die Sonos-Technologien werden genauso unterstützt wie lokale „Text to Speech“- und „Speech to Text“-Frameworks. Auch das Updaten der Firm­ware von verbundenen Devices kann Eclipse SmartHome. Andere Java-basierte Smart­home-Systeme wie das Qivicon der Deutschen Telekom nähern sich immer mehr an Eclipse SmartHome an. Modernere Node.JS-basierte Smarthome-Gateways, die auch im professionellen Umfeld erste Anwendungen finden, wie der ioBroker, stehen in Konkurrenz zu dem Eclipse SmartHome.
• Eclipse 4diac ist neben Kura eine zweite Gateway-Option für den professionellen Bereich. Es richtet sich speziell an verteilte industrielle Mess- und Regelungsaufgaben sowie Automatisierung nach dem IEC61499-Standard. Damit lassen sich sogar in massiv verteilten Systemen, zum Beispiel mit mehreren Robotern, von denen jeder ein Eclipse 4diac Smart Device hat, eine Echtzeit steuern und eine definierte Ausführungsreihenfolge von Aktionen realisieren. Im Gegensatz zu Kura ist 4diac viel fokussierter auf industrielle IoT-Anwendungen oder Industrie-4.0-Anwendungen. Meist liegt dann zwischen 4diac und der Public Cloud noch ein anderes Gateway, das weniger Echtzeit-orientiert ist und mehr mit Internet-Latenzen umgeht, wie eben ein Kura-Gateway. (Siehe Bild 3.)

 

Nach den kleinen Constrained Controllern und den größeren Gateways und Smart Devices kommen wir nun zu der Cloud. Auch hier bietet die Eclipse Foundation eine ganze Menge. Wie oben in der Tabelle veranschaulicht, ist dies besonders interessant für Firmen, die unter ihrem Brand IoT-Clouds mit begrenztem Aufwand ihren Kunden anbieten möchten, sich aber nicht in die Abhängigkeit eines IoT-PaaS-Anbieters begeben möchten.
Der Eclipse IoT Cloud Stack ist durchaus leistungsfähig und profitiert vor allem von den Enterprise-Erfahrungen von Red Hat. Hier sind die Komponenten im Überblick:

• Eclipse Device Management Kapua ist ein modulares Paket, um Smart Devices oder Gateways zu managen (siehe Bild 4). Dahinter steht beispielsweise neben Red Hat auch einer der Marktführer im Bereich IoT-Edge-Technologie, die Firma Eurotech, die wir auch in dem Vendor Universe IoT bewertet haben. Die Funktionen erinnern durchaus an kommerzielle Device-Management-Produkte wie Software AGs „Cumulocity“ oder Microsofts „IoT Central“. Der entscheidende Unterschied ist natürlich die Erweiterbarkeit auf Produkt-Ebene. Wenn hier etwas fehlt, um zum Beispiel ein Legacy-Device zu managen oder branchenspezifische Datentypen nativ darzustellen, kann man das Kapua-Framework erweitern und verändern. Im Eclipse Stack ist auch Eclipse Leshan, das der Server-Counterpart zum Wakaama-Projekt ist und das Management der OMA-LWM2M-Devices übernimmt. Kapua adressiert allerdings weniger das Connectivity-Management, was besonders bei drahtlos verbundenen oder batteriebetriebenen IoT-Devices notwendig ist (siehe dazu auch den Analyst-View zu IoT-Connectivity). Telcos und größere Unternehmen nutzen dazu beispiels­weise Cisco Jasper.
• Connectivity- und Message-Routing werden im Eclipse IoT Cloud Stack durch die Projekte Hono und Mosquitto dargestellt. Während Mosquitto die bekannteste Open-Source-MQTT-Implementierung ist, adressiert Hono die anderen Protokolle wie HTTP, CoAP, AMQP oder auch kundenspezifische Protokolle, wie sie im Industrieumfeld noch an der Tagesordnung sind.
• Device-Registry-Funktionalität wird dediziert durch das Eclipse-hawkBit-Projekt adressiert. Damit lassen sich aus der Cloud Updates zu den Devices und Gateways pushen.
• Analytics gehört eigentlich zu einer guten IoT-Cloud dazu und wird auch von den kommerziellen Produkten hierein gebündelt. Da hat Eclipse nur das etwas in die Jahre gekommene BIRT zu bieten und die meisten IoT-Architekten setzen eher moderne Tools wie Grafana auf eine Time-Serien-Datenbank.

 

Letztlich ist der Eclipse IoT Cloud Stack eine mehr oder weniger lose Sammlung von Projekten. Auch wenn Kapua vieles integriert und vereinfacht, ist der ganze Stack keine komplett integrierte Suite. Anwendern muss bewusst sein, dass man sich mit den Konzepten im Detail vertraut machen muss und besonders die Operationsaspekte gut verstehen und lernen sollte. Um dies zu beschleunigen, eignet sich die Hilfe von „Managed Public Cloud Service Providern“, die wir gerade in dem demnächst erscheinenden Vendor Universe Cloud evaluiert haben.

Diese Dienstleister können helfen, den Eclipse IoT Cloud Stack auf Kubernetes in Kombination oder auch ohne Red Hats OpenShift zu deployen, um große IoT-Cloud-Serverlandschaften zu realisieren. Dann kann dieser Tool-Stack Enterprise-Größenordnungen mit sehr vielen Daten, Devices und Events für ein Unternehmen handhaben. Architekten muss aber bewusst sein, dass es keine optimale Lösung für Telco-Scale-Multitenant-Clouds ist.

Millionen von Usern oder Devices, die möglicherweise sogar zwischen verschiedenen Tenants interagieren, erreichen schnell die Limits des Eclipse-Architektur-Blueprints für die IoT-Cloud.
Der Eclipse Stack entwickelt sich auch immer noch aktiv weiter. Beispielsweise versucht das Eclipse-OM2M-Projekt durch die Implementierung der oneM2M- und SmartM2M-Standards den Bedarf von Telcos in den USA zu befriedigen. Viele Kernkomponenten des Eclipse IoT Stacks sind jedoch traditionell in Java geschrieben, was auf Devices und in Cloud-Containern mehr Ressourcen als moderne Projekte in Node.js oder gar der Go-Language benötigt.

Ein moderneres Beispiel ist der TICK Stack um die Time-Series-Datenbank InfluxDB, der komplett in Go geschrieben wurde. Die Funktionalität ist weit kleiner, aber die Dinge, die schon fertig sind, sind in vielen Situationen weit performanter. //

 

 

Autorenvita
Dr. Stefan Ried ist IoT Practice Lead & Principal Analyst beim unabhängigen Analysten-Haus Crisp Research. Er treibt Marktforschung und berät Anwender und Hersteller im Bereich IoT und Cloud-Computing-Technologies und bei Geschäftsmodellen.

 

 

Lesen Sie auch: IoT Vendor Universe – die große Marktübersicht

 

 

Der Text ist unter der Lizenz CC BY-SA 3.0 DE verfügbar. Lizenzbestimmungen: https://creativecommons.org/licenses/by-sa/3.0/de/