Komponenten für Cloud-basierte Software-Updates im IoT

Das Aktualisieren von Software (Komponenten) auf eingeschränkten Edge-Geräten sowie auf leistungsfähigeren Controllern und Gateways ist in den meisten IoT-Szenarien eine häufige Anforderung.

Softwareaktualisierungsfunktionen gewährleisten ein sicheres IoT indem sie IoT-Projekten eine Chance gegen die Büchse der Pandora gaben, die sie in dem Moment öffneten, als ihre Geräte verbunden wurden . Von diesem Moment an stehen die Geräte an vorderster Front der IT-Sicherheitsbedrohungen, denen sich viele Entwickler von Embedded-Software in der Vergangenheit nie stellen mussten. Heutzutage kommt es einem Selbstmord gleich, beispielsweise ein Linux-betriebenes, mit dem Internet verbundenes Gerät zu versenden, ohne dass während seiner Lebensdauer jemals Sicherheitsupdates angewendet wurden.

Ein charmanteres Argument für Softwareupdates ist, dass sie eine agile Entwicklung von Hardware und hardwarenahen Komponenten ermöglichen. Konzepte wie das Minimum Viable Product können auf Geräte angewendet werden, da nicht alle Funktionen zum Zeitpunkt der Herstellung fertig sein müssen. Änderungen auf der Cloud-Seite der IoT-Lösung können auch zur Laufzeit auf Geräte angewendet werden.

Manchmal ist die Softwareaktualisierung ein eigenständiges Geschäftsmodell, da Geräte für den Kunden viel attraktiver sind, wenn sie aktualisierbar sind. Mit anderen Worten, Verbraucher wissen, dass sie nicht nur einen festen Satz an Funktionen erhalten, sondern auch von zukünftigen Produktupdates profitieren können. Darüber hinaus können sich durch die potenzielle Monetarisierung von Funktionserweiterungen (z. B. Apps .) neue Einnahmequellen ergeben ) ohne dass ein neues Gerät entwickelt, hergestellt und versendet werden muss (Überarbeitung).

Geräteverbindung

Es gibt verschiedene Möglichkeiten, ein Gerät mit einem Cloud-Dienst zu verbinden. Aus architektonischer Sicht muss entschieden werden, ob sich Geräte direkt verbinden sollen an den Softwareaktualisierungsdienst oder indirekt durch eine Gerätekonnektivitätsschicht (z. B. Bosch IoT Hub, AWS IoT, IBM Watson IoT, Azure IoT Hub usw.), die selbst auch ein IoT-Lösungsdienst sein könnte. Ich selbst glaube fest an den direkten Ansatz und mein Produkt Bosch IoT Rollouts unterstützt tatsächlich beides. Ich werde unten erklären, warum.

Lasst uns also loslegen:Die direkte Konnektivität ermöglicht es IoT-Lösungen, Bedenken zu trennen, indem sie zusätzlich zu ihrem eigenen Kanal, den die IoT-Lösungen für Geräteereignisströme und -befehle verwenden, unterschiedliche Kanäle für Softwareupdates haben.

Dies ist aus zwei Gründen ein interessanter Ansatz:Erstens macht es es viel einfacher, die API des Software-Update-Kanals stabil zu halten, wenn Sie sich nicht um alle Geschäftsanforderungen des anderen Kanals kümmern müssen . Wir sollten nicht vergessen, dass es im IoT Szenarien gibt, in denen angeschlossene Geräte längere Zeit ohne Kontakt zum Backend bleiben können. In manchen Fällen kann es Jahre dauern, insbesondere zwischen der Herstellung und der ersten Konnektivität. Es ist einfach, eine Transportschicht für diese Zeit stabil zu halten, aber das gilt sicherlich nicht für die Business-Schicht. Dies gilt insbesondere im IoT, wo sich viele Cloud-Lösungen noch in der frühen Reifephase befinden.

Zweitens ermöglicht Ihnen ein separater Kanal auch eine Trennung von Geschäfts- und Aktualisierungsfunktionen auf dem Gerät selbst . Wollen Sie gerade in einem komplexen Stack (z. B. auf einem IoT-Gateway) wirklich riskieren, dass ein potenziell kaputter Stack sich selbst aktualisieren muss, um das Problem zu beheben? Und kann es garantiert werden, dass es das immer kann? Stellen Sie sich ein Szenario vor, in dem Sie eine OSGi-Laufzeit auf Ihrem Gateway mit einem Bundle haben, die Ausnahmen wegen unzureichenden Arbeitsspeichers verursacht und Ihr Softwareaktualisierungsclient in derselben Laufzeit ausgeführt wird. Es könnte sehr schwierig sein, das Ergebnis vorherzusagen.

Die Trennung hat jedoch ihren Preis:Zwei Kanäle bedeuten normalerweise einen höheren Implementierungsaufwand auf der Geräteseite und können in einigen Szenarien auch Ihr Traffic-Budget oder die Akkulaufzeit erhöhen.

Die zweite Möglichkeit besteht darin, die Anwendungsfälle in einem einzigen Kanal zu kombinieren. Wir nennen das indirekt Integration mit dem Software-Update-Dienst, da die Cloud-Konnektivitätsschicht tatsächlich mit dem Gerät verbunden ist und die Lösung vom Update-Traffic in der Cloud trennen muss.

Dies hat den großen Vorteil einer vereinfachten Konnektivitätsarchitektur. Es ermöglicht auch die Nutzung allgemeiner Geräteverwaltungsprotokollstandards (z. B. LWM2M, OMA-DM, TR-069), die normalerweise nur als Unterabschnitt ihrer Standards Softwareaktualisierungen enthalten. Darüber hinaus ermöglicht es die Verwendung proprietärer Protokolle, die vom Gerät (Hersteller) selbst definiert werden.

Am Ende des Tages hat der IoT-Lösungsingenieur die Wahl:Trennung der Bedenken vs. Einfachheit. Mit unseren Bosch IoT Rollouts haben wir uns entschieden, beide Optionen zu unterstützen, und wir haben Kunden, die beide verwenden. Es stellte sich heraus, dass die direkte Konnektivität für die IoT-Lösung viel einfacher zu warten ist, während die indirekte Konnektivität die Gesamtarchitektur viel komplexer macht.

Die meisten IoT-Ingenieure beziehen Software-Update-Probleme jedoch erst sehr spät im Projekt in ihren Designprozess ein, da dies in den meisten Fällen nicht Teil der Kerngeschäftsfunktion ist und wenn sie dazu kommen, möchten sie keine Änderungen mehr vornehmen zu ihrer Architektur. Daher verfolgen die meisten Lösungen den indirekten Ansatz, der möglicherweise nach dem Go-Live an den Folgen leidet.

Die zweite Entscheidung für Cloud-basierte Software-Updates im IoT betrifft das Protokoll. Sollte ich ein Standardprotokoll für die Geräteverwaltung verwenden oder ein benutzerdefiniertes Protokoll erstellen? Viele IoT-Lösungen bevorzugen heutzutage MQTT mit einem benutzerdefinierten Protokoll darüber. Darüber hinaus bieten viele der IoT-Konnektivitätsschichten auf dem Markt zusätzlich zu HTTP, MQTT oder AMQP ein proprietäres Protokoll.

Ich persönlich glaube, dass einige der Standards einen Wert haben und zumindest in Betracht gezogen werden sollten. OMA-DM v2 sieht vielversprechend aus und wir haben auch einige Erfahrungen mit LWM2M gemacht. Wie immer bieten Standards einen guten Rahmen, aber sie sind normalerweise mit einer Reihe von Einschränkungen verbunden; Besonders in den frühen Phasen eines IoT-Projekts kann dies die Komplexität erheblich erhöhen. Ein guter Standard, der Software-Updates abdeckt, ermöglicht es der IoT-Lösung jedoch, Software-Updates als Funktion bereitzustellen, ohne dass auch nur eine Zeile Code geschrieben werden muss, wenn sowohl das Gerät als auch der Software-Update-Dienst dies standardmäßig unterstützen.

Zu guter Letzt stellt sich die Frage der Geräteauthentifizierung. Dies ist natürlich eine generelle Frage für jede IoT-Lösung. Aber gerade für den direkten Integrationsweg muss die Wahl getroffen werden, ob für Softwareupdates und den IoT-Lösungskanal der gleiche Authentifizierungsmechanismus verwendet werden kann. Normalerweise plädiere ich dafür, denselben Mechanismus zu verwenden. Dies ist mit asymmetrischer Authentifizierung (z. B. X.509-Zertifikat) eigentlich einfach zu realisieren. Bosch IoT Rollouts unterstützt dies für seine Direct Device Integration API sowie die meisten der im IoT typischerweise verwendeten Konnektivitätsschichten. Wenn asymmetrisch keine Option ist (was bei eingeschränkten eingebetteten Geräten häufig der Fall ist), würde ich empfehlen, einen zentralen (symmetrischen) Schlüsselspeicher zu verwenden, der von den verschiedenen Kanälen verwendet werden kann.

Wie oben erwähnt, müssen Entscheidungen getroffen und Fragen beantwortet werden. Leider befindet sich das IoT noch nicht in einem Zustand, in dem wir eine Architektur gefunden haben, die zumindest für die meisten Szenarien geeignet ist. Die gute Nachricht ist jedoch, dass es Optionen gibt und sie funktionieren.