Suche
Softwareupdate im IoT

Eclipse hawkBit: Bei Dingen einfach die Software aktualisieren

Kai Zimmermann, Michael Hirsch

© Shutterstock.com / Mikko Lemola

Eclipse hawkBit ist ein Projekt der Eclipse IoT Working Group, die eine offene Plattform für das Internet der Dinge schaffen will. Ziel des hawkBit-Projekts ist es, ein Framework bereitzustellen, das es einfach möglich macht, die Funktionalität „Softwareupdate“ in eine IoT-Lösung oder -Plattform zu bringen.

Das Ausrollen von Software auf Embedded-Steuergeräte bis hin zu mächtigeren Gateways ist eine typische Anforderung, die uns in den meisten IoT-Projekten begegnet. Softwareupdates für Geräte abbilden zu können, eröffnet dem jeweiligen Projekt eine Reihe neuer Möglichkeiten: Zunächst einmal einen Weg, um der zunehmenden Anzahl von Sicherheitsproblemen zu begegnen. Sobald ein Gerät „connected“ ist, bietet sich eine komplett neue Angriffsfläche, auf die Embedded-Software- und Hardwareentwickler nun vorbereitet sein müssen.

Erfreulicher ist die Möglichkeit, mit Softwareupdate den Embedded-Software-Entwicklern ein agiles Entwicklungsmodell zu ermöglichen, das nicht mehr verlangt, alle Funktionen des Geräts zum Fertigungszeitpunkt der Hardware komplett ausimplementiert haben zu müssen.

Hier und dort ist Softwareupdate per se auch ein Geschäftsmodell. Es kann ein Produkt für den Konsumenten deutlich attraktiver machen, da er es nicht nur mit einem Umfang X kauft, sondern mit dem Versprechen auf die zukünftige Entwicklung des Produkts. Bei Smartphones oder PCs ist das schon lange selbstverständlich. In traditionellen Branchen, für die das IoT jetzt spannend wird, bisher weniger. Tesla ist ein Beispiel für die Vermarktung des Softwareupdates als Produktfeature aus einer Branche, in der bisher nur wenig „connected“ war. Zusätzlich kann auch das Verkaufen von nachgelieferten Funktionen („Apps“) ein interessantes Geschäftsmodell in den neuen IoT-Domänen sein.

Wir müssen dabei beachten, dass Cloud-gestützte Softwareupdates im IoT-Kontext eine ganze Reihe Herausforderungen mit sich bringen, die wir aus dem Aktualisieren von Servern, PCs oder Smartphones so nicht kennen. Positiv steht dem gegenüber, dass Softwareupdate als Funktion im IoT aus Backend-Sicht relativ unabhängig von der konkreten Domäne ist und daher auch nur einmal implementiert werden muss. Das Aktualisieren eines „Smart Homes“, einer Fertigungsstraße oder eines Fahrzeugs bringt im Kern die gleichen Anforderungen mit sich, unterscheidet sich aber sicherlich zum Beispiel hinsichtlich der Sicherheitsanforderungen und natürlich bei dem, was auf dem Gerät selbst passiert.

Eclipse hawkBit wurde als Projekt gestartet, um genau diesen domänenunabhängigen Anforderungen gerecht zu werden. Dazu stellt hawkBit eine Reihe Fähigkeiten bereit:

  • Ein Geräte- und Software-Repository
  • Schnittstellen zur flexiblen Geräteintegration
  • Benutzeroberfläche und Schnittstellen zum Durchführen der Softwareupdateoperationen und dem Verwalten des Repositories
  • Eine moderne, auf Spring Boot basierende Architektur, die es einfach ermöglicht, hawkBit an die eigenen Bedürfnisse anzupassen

Nicht funktional geht es dazu noch um:

  • Schnittstellenstabilität für langlebige Geräte
  • Schnittstellenflexibilität für die Geräteintegration im Projekt
  • Funktionale Skalierbarkeit für große Roll-outs im IoT-Kontext
  • Ende-zu-Ende-Sicherheit im Softwareupdateprozess

Eclipse hawkBit bringt bisher allerdings keine fertigen Geräteclients mit. Hier hofft das Projekt auf die aktive Mitarbeit der Community.

Die Anforderungen

Kommen wir nun zu den Spezialitäten bei den Anforderungen. Sie hängen stark mit der einfachen Wahrheit zusammen, dass der Softwareupdateprozess der eine Prozess ist, der niemals versagen darf. Er kann die größte Rettung für ein IoT-System sein, da mit einem erfolgreichen Update fast jedes Problem auf dem Gerät behoben werden kann. Schnittstellen in die Cloud können zudem angepasst und erweitert werden, um zu dortigen Änderungen kompatibel zu bleiben. Auf der anderen Seite ist das Update aber auch das größte Risiko für das Gerät, da damit praktisch jeder Sicherheitsmechanismus ausgehebelt werden kann.

Auch hängt die Überlebensfähigkeit des Geräts davon ab, dass der Softwareupdatemechanismus stabil über die Lebensdauer des Geräts funktioniert. Dies sind oftmals Jahre oder gar Jahrzehnte. Auch ist das manuelle Eingreifen eines Gerätebenutzers im IoT-Kontext, anders als bei PC und Smarthone, oftmals keine (bezahlbare) Option.

Auf drei der wichtigsten Anforderungen wollen wir etwas detaillierter eingehen. Dazu haben wir noch eine Anforderung in petto, die Eclipse hawkBit bewusst nicht adressiert, die aber nicht minder wichtig ist.

Schnittstellenstabilität

IoT-Geräte haben oftmals eine Lebensdauer, die von einigen Jahren im Consumer-Markt bis hin zu einigen Jahrzenten im industriellen und Automotive-Markt reichen kann. Zu berücksichtigen ist dabei, dass es durchaus Szenarien gibt, in denen vernetzte Geräte sich über lange Zeiträume gar nicht erst im Backend melden. Ein Gerät kann gefertigt sein, wandert dann jedoch für ein oder zwei Jahre ins Lager. Noch länger könnte es bei einem Gerät dauern, das bereits verkauft, installiert, aber nie connected wurde, zum Beispiel weil ein Kunde zwar eine „Cloud-ready“-Heizanlage oder einen Wechselrichter im Haus hat, aber nie dazu gekommen ist, die Internetverkabelung dorthin zu legen.

Im Ergebnis sind wir mit der Situation konfrontiert, dass ein Gerät erst nach Jahren das erste Mal auf eine Cloud treffen kann. Niemand verlangt, dass das fachliche Backend noch mit gleicher Schnittstelle existiert wie zum Fertigungszeitpunkt. Die Funktionalität „Softwareupdate“ muss aber zumindest noch funktionieren.

Schnittstellenflexibilität

Zunächst im Widerspruch zu dem Anspruch an stabile Schnittstellen müssen diese gleichermaßen flexibel sein, da im IoT bis heute kein verbreiteter Standard für die Gerätekonnektivität oder das Devicemanagement existiert. Auf Ebene des Transportprotokolls sehen wir von HTTP über MQTT, AMQP oder CoAP so ziemlich alles im Einsatz. Im Devicemanagement existieren mit OMA-DM, LWM2M oder TR-069 zwar einige Standards, in der Praxis konnte sich aber bisher keiner wirklich domänenübergreifend durchsetzen.

Die Folge ist, dass in vielen Projekten das Devicemanagement tendenziell über ein selbst entwickeltes Protokoll erledigt wird. Zudem wird üblicherweise auch nur ein Kanal verwendet, um Operationen wie das Softwareupdate auf dem Gerät und fachlichem Datentransport vom Gerät in die Cloud zu bewerkstelligen.

Funktionale Skalierbarkeit

Neben der technischen Skalierbarkeit, also der flexiblen Bereitstellung von Rechen- oder Bandbreitenkapazitäten während eines Updates, die uns heutzutage viele Cloud-Plattformen kostengünstig zur Verfügung stellen, ist es auch von elementarer Bedeutung, bei großen IoT-Projekten mit Tausenden oder gar Millionen von Geräten, den gesamtem Update-Roll-out-Prozess fachlich unter Kontrolle zu haben. Dazu gehört die Fähigkeit, die Geräte in mehrere Untergruppen zu unterteilen und den Roll-out dann Gruppe für Gruppe zum Beispiel nacheinander oder auf Basis eines Ablaufplans durchzuführen und im Fehlerfall kontrolliert abzubrechen. Des Weiteren gehört das Überwachen des Roll-outs während der Ausführung bis hin zur Auswertung nach Abschluss dazu.

Das System muss auch damit zurechtkommen, dass viele Geräte in einem Roll-out nur sehr verzögert oder nie ein Update durchführen, beispielsweise weil sie zwar registriert, aber nie online sind. In diesem Sinn ist ein Roll-out in sehr großen Szenarien wahrscheinlich nie „fertig“.

Ende-zu-Ende-Sicherheit

In einem Softwareupdateprozess brauchen wir zwischen dem Gerät selbst und dem Ersteller der Software Vertrauen. Zwischen diesen beiden Instanzen steht allerdings der Softwareupdateservice; es ist nun einmal seine Aufgabe, die erstellte Software auf das Gerät zu transportieren. Im Ergebnis ist er damit auch die Stelle, die die Gefahr der Korrumpierung birgt. Er sollte als „Man-in-the-Middle“ daher niemals verpflichtet werden, die Authentizität der Softwareartefakte abschließend zu bestätigen. Er kümmert sich um die Verschlüsselung des Transports, um Authentifizierung und Autorisierung von Geräten und Benutzern, aber am Ende des Tages muss das Gerät selbst die Authentizität zum Beispiel durch eine Signatur prüfen. Daher wird die Ende-zu-Ende-Sicherheit bewusst nicht von hawkBit garantiert.

Eclipse hawkBit

Eclipse hawkBit begegnet bereits einigen dieser Herausforderungen. Die Schnittstellenstabilität zum Gerät wird durch das einfache RESTful-Direct-Device-Integration-API ermöglicht, das vom Gerät direkt aufgerufen wird und dort vollkommen auf Softwareupdate fokussiert einfach stabil gehalten werden kann. Eine hohe Flexibilität für die Geräteintegration wird alternativ durch das Device-Management-Federation-API gewährleistet, das es ermöglicht, verschiedene Gerätekonnektoren einzuklinken.

Funktionale Skalierbarkeit ist hingegen noch innerhalb der Community in Arbeit, mehr dazu im Ausblick am Ende dieses Artikels. Wie bereits angedeutet, wird Ende-zu-Ende-Sicherheit bewusst nicht von hawkBit garantiert, hier ist zusätzliche Arbeit im jeweiligen Projekt gefordert.

Neben diesen besonderen Anforderungen muss hawkBit natürlich den heute üblichen Standards genügen. Dazu gehören flexibel nutzbare Schnittstellen, eine moderne „Cloud-ready“-Softwarearchitektur und, besonders wichtig für ein Open-Source-Projekt, ein hoher Grad an Flexibilität in der Nutzung der Software in eigenen Projekten.

Integrationsszenarien

Eclipse hawkBit kann als eigenständige Applikation benutzt werden, um Softwareupdates direkt auf Geräte durchzuführen. In dieser einfachsten Variante nutzt der Administrator das hawkBit-Management-UI, um das Repository zu verwalten und die Updates durchzuführen. Geräte werden hierbei über das Direct-Device-Integration-API an den hawkBit-Server angebunden.

hawkbit_integration_einfach_variante_1

Abb. 1: hawkBit, einfachste Variante zur Benutzung

Eine weitergehende Integration ermöglicht das RESTful-Management-API, das featurekompatibel zum Mangement-UI ist. Mögliche Anwendungsfelder sind zum Beispiel:

  • Eine einfache Statusabfrage des Softwarestands eines Geräts beispielsweise für ein Supportportal
  • Triggern eines Updates aus einer Workflow-Engine
  • Betanken des Software-Repositories aus einer Continous Integration Engine mit anschließendem Update auf Testgeräte für Integrationstests
  • Integration aller Funktionalitäten in eine Geräteverwaltungsapplikation.

Das Device-Management-Federation-API rundet das Bild schließlich ab, da es über einen AMQP (0.9) Broker ermöglicht, Geräte indirekt über (bestehende) Konnektoren anzubinden. Werden beide Schnittstellen voll genutzt, kann hawkBit sich auf das Verwalten des Repositories und das Steuern der Updates konzentrieren.

hawkbit_voll_integration_variante_2

Abb. 2: hawkBit-Integrationsmöglichkeiten

Ein Softwareupdate ist nicht nur eine Datei

Softwareupdates bestehen oftmals aus mehreren Softwarekomponenten wie Betriebssystem-, Laufzeit- und Applikationskomponenten. Diese Softwarekomponenten bestehen selbst wiederum auch meist aus mehreren Dateien, zum Beispiel dem Vollupdate, verschiedenen Binary-Deltas und Signaturen.

Eclipse hawkBit definiert ein flexibles Datenmodell, um solche komplexen Strukturen inklusive Metadaten wie Versionierung und Beschreibung zu einem Softwareupdate abbilden zu können. Auf Basis dieses Modells können Geräten mehrere Softwarepakete zugewiesen und atomar aktualisiert werden.

hawkbit_software_paket_model_3

Abb. 3: hawkBit-Softwareupdate-Paketemodell

Eclipse hawkBit zum Ausprobieren

Der Quellcode von Eclipse hawkBit kann von GitHub geklont und via Maven gebaut werden (Listing 1).

$ git clone https://github.com/eclipse/hawkbit.git
$ mvn clean install

Nach erfolgreichem Bauen des Quellcodes kann die mitgelieferte Beispielanwendung gestartet werden, die das Management-UI bereitstellt, um Software auf Geräte auszurollen. Die grafische Oberfläche kann über die Adresse http://localhost:8080/UI aufgerufen werden, und der Anwender kann sich mit den Credentials „Benutzer: admin“ und „Passwort: admin“ anmelden (Listing 2).

$ java –jar ./ examples/hawkbit-example-app/target/hawkbit-example-app-#version#.jar

Um nicht einen eigenen Geräteclient zum Testen schreiben zu müssen, gibt es in hawkBit einen Gerätesimulator, der updatefähige Geräte simulieren und über die beiden Schnittstellen an hawkBit anbinden kann (Listing 3).

$ java –jar ./ examples/hawkbit-device-simulator/target/hawkbit-device-simulator-#version#.jar

Um Geräte zu simulieren, kann die grafische Oberfläche oder alternativ das RESTful API des Simulators verwendet werden.

$ curl http://localhost:8083/start?amount=10&api=ddi

Unter den Beispielen ist auch ein Management-API-Client, der die Benutzung des Management-API demonstriert und auch automatisch einige Beispielsoftwarepakete erstellt, die gleich in der hawkBit-Beispielanwendung verwendbar sind.

$ java –jar ./ examples/hawkbit-mgmt-api-client/target/hawkbit-mgmt-api-client-#version#.jar

Mittels Management-UI der hawkBit-Beispielanwendung können dann die vorgefertigten Softwarepakete auf die simulierten Geräte „ausgerollt“ werden.

hawkbit_deployment_beispiel_4

Abb. 4: hawkBit: manuelles Softwareupdatebeispiel

Ausblick

Zum Zeitpunkt der Erstellung dieses Artikels befindet sich das hawkBit-Projekt in Vorbereitung auf das erste Release 0.1, das die beschriebenen Basisfunktionalitäten und -schnittstellen beinhalten wird. Mit dem Release 0.2 wird die funktionale Komplettierung weiter vorangebracht, um insbesondere dem für hawkBit definierten Anspruch der funktionalen Skalierbarkeit mit der Entwicklung eines Roll-out-Managements gerecht zu werden.

Technisch ist eine weitere Verbesserung von hawkBits Anpassbarkeit, Modularisierung und Integrationsfähigkeiten angestrebt. Interessant erscheint auch die Integration mit weiteren Eclipse-IoT-Projekten wie etwa Leshan, um LWM2M-Geräte mit Firmware zu versorgen, Hono, um Geräte leichter an hawkBit anzubinden oder Tiaki, um Geräte sicher und automatisch den richtigen hawkBit-Server finden zu lassen.

Geschrieben von
Kai Zimmermann
Kai Zimmermann
Kai Zimmermann ist bei der Bosch Software Innovations GmbH verantwortlicher Product Owner für den Bosch IoT Software Provisioning Cloud Service und Project Lead für Eclipse hawkBit.
Michael Hirsch
Michael Hirsch
Michael Hirsch ist bei der Bosch Software Innovations GmbH als Lead Developer für die Software-Provisioning-Entwicklungsaktivitäten verantwortlich und Committer im Eclipse-hawkBit-Projekt.
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Eclipse hawkBit: Bei Dingen einfach die Software aktualisieren"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Zubair
Gast

Listing #1 has a minor typo. Each line was appended with 😀