Internet der Dinge: IoT-Geräte-Updates automatisieren mit Over-the-Air-Updates

Inhaltsverzeichnis

Die Zahl der vernetzten Geräte steigt weltweit ununterbrochen: Schätzungen prognostizieren für Ende 2022 bereits über 16 Milliarden Geräte im Internet of Things (IoT). Smart Home und Automatisierung, aber auch Datenaufzeichnung und Sicherheitsfunktionen zählen zu den Haupteinsatzgebieten.

Ein essenzieller Baustein in der Pflege dieser Geräte sind Software-Updates, die großflächig automatisiert und verlässlich eingespielt werden sollen. Allerdings behandeln viele Hersteller Updates immer noch sehr stiefmütterlich. Die europäische Richtlinie ETSI 303 645 (PDF) soll diesen Zustand nun endlich beenden.

Wir erläutern ausführlich die Anforderungen an die Hersteller. An dieser Stelle kommen Over-the-Air-Updates (OTA) ins Spiel, wobei der Name nicht allzu wörtlich zu verstehen ist: Darunter fasst man das Ausrollen von Updates aus der Ferne und meist ohne Benutzerinteraktion am eigentlichen Gerät zusammen – unabhängig von der tatsächlich genutzten Verbindungsart.

Die folgenden Begriffe sind gebräuchlich:

• Artifact – ein Softwarepaket, etwa ein zur Verteilung bereitgestelltes Update;
• Deployment – Verteilen und Einspielen von Artifacts;
• Unattended – Einspielen eines Updates oder Softwarepaketes ohne Benutzerinteraktion.

Besonders beim Unattended Deployment unterscheiden sich OTA-Updates damit grundsätzlich von Updates, die Benutzer aktiv herunterladen und einspielen. Eine Sonderform sind Aktualisierungen, die zwar automatisiert heruntergeladen, aber erst nach Bestätigung durch den Benutzer angewendet werden. Dies dient meist dazu, unerwünschte Ausfallzeiten zu vermeiden, da diese im Automatisierungsumfeld gravierende Folgen haben können. Der Albtraum von der stillstehenden Fertigungslinie ist hier nahe an der Realität.

Damit dieser Fall nicht eintritt, müssen mehrere Abläufe perfekt aufeinander abgestimmt sein. Das Kernstück ist dabei der A/B-Mechanismus: Er ermöglicht im Fall eines Fehlers während des Updates die Rückkehr, das Rollback zum funktionsfähigen Zustand vor dem Update.

Notwendige Abwechslung

Das Kernstück des A/B-Mechanismus sind zwei Systempartitionen, A und B genannt. Sie wechseln beim Einspielen eines Systemupdates zwischen den Zuständen aktiv und inaktiv, wobei das System die aktive Partition momentan zum Starten verwendet. Der Wechsel bedeutet auch, dass alle Daten auf den Systempartitionen als transient zu behandeln sind, da sie bei einem Update im Ganzen ersetzt werden. Als letzte Bausteine benötigt ein solcher Mechanismus daher immer zumindest eine persistente Datenpartition sowie einen Bootprozess, der das Umschalten der Partitionen beherrscht.

Der in der folgenden Abbildung gezeigte Ablauf eines Systemupdates beginnt im aktiven, laufenden System. Das neue System wird auf die inaktive Partition geschrieben und anschließend ein für den Bootprozess sichtbarer Merker zum Partitionswechsel gesetzt. Beim nächsten Neustart werden aktive und inaktive Partition getauscht, womit das System im neuen Zustand startet. Läuft der Bootvorgang erfolgreich durch, löscht der Updatemechanismus den Merker und macht den Wechsel damit permanent. Schlägt der Systemstart fehl und wird nicht durch den Updatemechanismus bestätigt, wechselt der Bootloader beim nächsten Neustart die Partitionen zum vorherigen Zustand zurück und ersetzt den Update- durch einen Fehlermerker. Durch diese Rückkehr kann das System sicher wieder starten und über den Fehlermerker ein fehlgeschlagenes Update erkennen.

Das Umschalten der Partitionen sowie das Setzen und Lesen der Merker zur Boot-Zeit kann unterschiedliche Formen annehmen. Im einfachsten Fall lässt sich der Bootloader um die erforderliche Logik erweitern, etwa durch ein Skript oder einen Patch. Alle populären Bootloader wie U-Boot, GRUB und zu einem gewissen Grad (U)EFI stellen weitgehend vorbereitete und gut dokumentierte Vorgehensweisen bereit. Dieser Ansatz hat allerdings den Nachteil, dass ein essenzieller Teil des Updatemechanismus im softwarebasierten Bootloader hinterlegt ist. Dadurch lässt sich dieser meist nicht auf vergleichbare Weise mit Updates versorgen, da er keine vorgelagerte Stufe besitzt, A/B-Mechanismen abzubilden. Der Bootloader mutiert damit zum Single Point of Failure.

Die SoC-Hersteller (System-on-a-Chip) haben die Notwendigkeit robuster Updates erkannt. Eine OTA-Lösung muss üblicherweise eine Anpassung der Bootloader-Integration vornehmen, um solche meist sehr herstellerspezifischen Features zu nutzen. Ein Beispiel ist Nvidias Tegra-Plattform, die A/B-Updates bis zur Bootloader-Ebene hinab ermöglicht.

System-on-a-Chip

Die überwiegende Mehrzahl der in IoT-Geräten verbauten CPUs gehört zur Kategorie der Systems-on-a-Chip. Der Begriff verdeutlicht, dass ein Großteil der für ein funktionierendes Gesamtsystem benötigten Baugruppen auf einem Chip vereint sind: ein oder mehrere CPU-Kerne, Caches, Speichercontroller, Timer und Schnittstellen sowie oft ein substanzieller Teil des Energiemanagements und der Takterzeugung. Bei Systemen, die ein Display ansteuern, beispielsweise Mobiltelefonen, sind die Grafikeinheiten üblicherweise ebenfalls integriert.

Ein SoC benötigt je nach Ausbau und Leistungsfähigkeit zum Betrieb nur eine Stromversorgung, RAM und Flashspeicher. Der Markt wird stark von ARM dominiert, nahezu alle Linux-tauglichen SoCs basieren auf dieser Architektur. Alternativen wie x86, RISC-V oder auch MIPS und PowerPC sind Nischenerscheinungen. Eng verwandt, aber nicht mit SoCs zu verwechseln sind die Systems-on-Module, kurz SoM. Diese vereinen ein SoC mit Speicherbausteinen und Stromversorgung auf einer Leiterplatte, die als Basissystem fungiert. Der Begriff wird allerdings fließend verwendet, und je nach Kontext kann alles von einem aus zwei Dice bestehenden SoC bis hin zum Raspberry Pi gemeint sein.