- Open source spielt auch im IoT eine wichtige Rolle
- Lernen Sie als ein Beispiel den IoT Stack der Eclipse Foundation kennen
- Was sind die Stärken oder Schwächen
Open Source ist aus der Software Landschaft im Internet und in Unternehmen nicht mehr weg zu denken. 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.
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:
Bild 1: Eclipse Constrained Device Stack.
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 IO Pins oder lokalen Speicher (EEPROM). Darauf setzt das Projekt Paho auf, dass 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 das Open Mobile Alliance Lightweight Machine-2-Machine (OMA LWM2M) Standard.
Bild 2: 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 Netzwerkbedingungen mit mehreren Cloud Backends sprechen. Dazu implementiert Kura nicht nur ein MQTT basiertes Messaging, sondern hat auch die Messaging 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 with die Philips Hue oder Sonos Technologien werden genauso unterstützt wie lokale Text to Speech und Speech to Text Frameworks. Auch das Updaten der Firmware von verbundenen Devices kann Eclipse SmartHome. Andere Java-basierte Smarthome 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, dass weniger Echtzeit orientiert ist und mehr mit Internet Latenzen umgeht, wie eben ein Kura Gateway.
Bild 3: Eclipse Cloud Plattform Stack.
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-Anbietern begeben möchte. Der Eclipse IoT Cloud Stack ist durchaus leistungsfähig und profitiert vor allem von den Enterprise Erfahrungen von Redhat. 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 Redhat 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 AG’s Cumulocity oder Microsoft’s IoT Central. Der entscheidende Unterschied ist natürlich die Erweiterbarkeit auf Produkt-Ebene. Wenn hier etwas fehlt um zum Beispiel ein Legacy Device zum managen oder branchenspezifischen Datentypen nativ dargestellt werden sollen, 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 wenig das Connectivity Management, was besonders bei drahtlos-verbundenen oder batteriebetriebenen IoT Devices notwendig ist (siehe dazu auch der Analyst View zu IoT Connectivity). Telcos und größere Unternehmen nutzen dazu Beispielsweise Cisco Jasper.
- Connectivity & 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 hier rein gebundelt. 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.
Bild 4: Eclipse Device Management Kapua
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, das man sich mit den Konzepten im Detail vertraut machen muss und besonders die Operations-Aspekte 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 Redhat’s 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, in vielen Situationen weit performanter.