OTA-Updates

Warum OTA kritische Infrastruktur ist¶

Ein schlechtes OTA-Update kann Tausende von Geraeten gleichzeitig bricken. Und im Gegensatz zu einem Server koennen Sie IoT-Geraete im Feld nicht per SSH neu starten. Sie koennen nicht in einer Stunde hinfahren. Manche stehen auf Daechern, in Tunneln, in Schiffscontainern auf See.

OTA-Update-Infrastruktur fuer IoT erfordert einen paranoiden Ansatz. Jedes Update ist ein potenzieller Brick. Jeder Rollout ist ein kontrolliertes Experiment. Jeder Schritt hat einen Fallback.

Wir bauen OTA-Systeme, bei denen kein Geraet permanent gebrickt werden kann und kein Rollout ohne Validierung stattfindet.

A/B-Partitionsschema¶

Prinzip¶

Das Geraet hat zwei Boot-Slots: Partition A (aktiv) und Partition B (inaktiv):

1. Aktuelle Firmware laeuft auf Partition A
2. OTA-Update wird heruntergeladen und auf Partition B geschrieben
3. Bootloader wechselt zu Partition B und startet neu
4. Neue Firmware besteht den Boot-Test (Health Check)
5. Erfolg: Partition B wird aktiv, A ist Backup
6. Fehlschlag: Bootloader kehrt automatisch zu Partition A zurueck

Ergebnis: Das Geraet hat immer funktionierende Firmware. Selbst im schlimmsten Fall (beschaedigtes Update, inkompatible Firmware, Hardware-Regression) kehrt es zum vorherigen Zustand zurueck.

Boot-Test¶

Nach dem ersten Start auf der neuen Partition laeuft eine Validierung:

• Hardware-Check: Alle Sensoren und Peripheriegeraete antworten
• Konnektivitaets-Check: Verbindung zum Backend erfolgreich
• Anwendungs-Check: Hauptanwendung startet und meldet Healthy
• Watchdog: Wenn das System den Health-Status nicht innerhalb von 120 Sekunden bestaetigt, erzwingt der Watchdog einen Neustart auf der alten Partition

Erst nach erfolgreichem Boot-Test wird die neue Partition als „bestaetigt” markiert. Ohne Bestaetigung = automatischer Rollback beim naechsten Neustart.

Staged Rollout¶

Rollout-Phasen¶

Wir aktualisieren niemals die gesamte Flotte auf einmal. Staged Rollout minimiert den Blast Radius:

1. Internes Testing (0,1%) Dev- und QA-Team auf eigenen Geraeten. Smoke Tests, manuelle Validierung. Gate: null kritische Bugs.

2. Canary (1-5%) Kleine Gruppe von Produktionsgeraeten, typischerweise an einem Standort. Automatisches Monitoring: Crash-Rate, Telemetrie-Health, Fehlerrate. Gate: Metriken gleich oder besser als Baseline.

3. Early Adopters (10-20%) Breitere Gruppe ueber Standorte und Hardware-Varianten. Business-KPI-Monitoring — funktioniert es wie erwartet? Gate: keine Regression bei Business-Metriken.

4. General Availability (50% → 100%) Schrittweise Erweiterung auf die gesamte Flotte. Monitoring laeuft weiter. Halt jederzeit bei Anomalie.

Automatische Evaluierung¶

Automatisches Gate zwischen jeder Phase:

IF crash_rate > baseline * 1.05 THEN halt_rollout
IF telemetry_gap > 5min THEN halt_rollout
IF error_rate > 2% THEN rollback_stage
IF business_kpi < threshold THEN halt_and_investigate

Das Gate ist automatisch — keine Person muss um 3 Uhr morgens genehmigen. Ein Mensch greift nur bei Halt (Untersuchung) oder fuer ein Override ein.

Differentielle Updates¶

Das Problem¶

Volles Firmware-Image fuer Embedded Linux: 200-500 MB. Ueber ein Mobilfunknetz (LTE-M, NB-IoT) dauert das Dutzende Minuten und kostet Geld. Ueber Satellit ist es unpraktisch.

Die Loesung¶

Ein differentielles Update sendet nur die Aenderungen gegenueber der aktuellen Version:

Binary Diff (bsdiff/xdelta): Vergleich von altem und neuem Image auf Binaer-Ebene. Typische Kompression: 60-80%. 500 MB Image → 100-200 MB Diff.

Mender: Open-Source OTA-Plattform fuer Embedded Linux (Yocto, Debian). A/B-Updates, Delta-Updates, Device Management. Self-hosted oder SaaS.

RAUC: Leichtgewichtiges Update-Framework fuer Embedded Linux. Bundle-basierte Updates, A/B-Slot-Management, Custom Update Handler. Geringerer Overhead als Mender.

SWUpdate: Flexibler Update-Agent. Unterstuetzt verschiedene Update-Strategien, Scripted Updates, Recovery Mode.

Fortsetzbare Downloads¶

Ein unterbrochener Download wird dort fortgesetzt, wo er aufgehoert hat:

• HTTP Range Requests fuer partiellen Download
• Pruefsumme pro Chunk (nicht nur der gesamten Datei)
• Beschaedigter Chunk wird erneut heruntergeladen, nicht das gesamte Update
• Download im Hintergrund ohne Auswirkung auf den normalen Betrieb

Sicherheit¶

Firmware-Signierung¶

Jedes Firmware-Image wird digital signiert:

1. Build Server erstellt das Image
2. Signing Server (HSM-gestuetzt) signiert das Image mit einem Private Key
3. Geraet verifiziert die Signatur mit einem eingebetteten Public Key vor der Installation
4. Ungueltige Signatur = Update abgelehnt, Alert an Management-Konsole

Secure Boot Chain: Bootloader → Kernel → Rootfs → Anwendung. Jeder Schritt verifiziert die Signatur des naechsten. Kompromittierung der Anwendung kann den Kernel nicht modifizieren.

Anti-Rollback¶

Das Geraet verfolgt einen monotonen Zaehler. Jede Firmware hat eine Versionsnummer. Eine Firmware mit niedrigerer Versionsnummer als die aktuelle kann nicht installiert werden. Schutz gegen Downgrade-Angriffe — ein Angreifer kann keine aeltere Version mit bekannter Schwachstelle installieren.

Verschluesselung¶

Firmware-Image verschluesselt waehrend des Transports (TLS) und im Ruhezustand auf dem Geraet (AES-256). Entschluesselungsschluessel in Secure Enclave (TPM, TEE). IP-Schutz — Firmware kann nicht aus einem gestohlenen Geraet extrahiert und analysiert werden.

Planung und Einschraenkungen¶

Nicht jeder Moment ist fuer ein Update geeignet:

• Wartungsfenster: Updates nur ausserhalb der Spitzenzeiten (Produktionslinien: Nachtschicht)
• Batteriestand: Mindestens 30% Batterie oder angeschlossene Stromversorgung
• Konnektivitaet: Wi-Fi bevorzugt. Mobilfunk nur fuer kritische Patches. Keine Updates ueber NB-IoT (zu langsam)
• Benutzereinwilligung: Consumer-Geraete — Benachrichtigung und Bestaetigung. Industriegeraete — automatisch im Wartungsfenster
• Abhaengigkeiten: Wenn Firmware eine neue Backend-Version erfordert, wird das Backend zuerst aktualisiert

Flottenweite Koordination¶

Wir aktualisieren niemals alle Geraete am selben Standort gleichzeitig. Gestaffelter Rollout pro Standort — wenn ein Standort Probleme hat, sind die anderen nicht betroffen.

Monitoring und Reporting¶

OTA-Dashboard¶

• Rollout-Fortschritt: Wie viele Geraete aktualisiert, ausstehend, fehlgeschlagen
• Versionsverteilung: Kreisdiagramm — wie viele Geraete auf welcher Version
• Health-Metriken: Crash-Rate, Neustart-Anzahl, Konnektivitaet nach Update
• Fehleranalyse: Haeufigste Fehlergruende, betroffene Geraetetypen, Firmware-Versionen

Alerting¶

• Rollout-Erfolgsrate sinkt unter 98% → Halt + Alert
• Reboot-Schleife erkannt (3+ Neustarts in 10 Min) → automatischer Rollback + Alert
• Geraet nach Update laenger als 30 Min offline → Alert

Technologie-Stack¶

OTA-Plattformen: Mender, RAUC, SWUpdate, Hawkbit, Azure IoT Hub, AWS IoT Jobs.

Diff-Tools: bsdiff, xdelta3, zstd Compression.

Sicherheit: OpenSSL, wolfSSL, TPM 2.0, PKCS#11, Secure Boot (U-Boot Verified Boot).

Monitoring: Grafana, Prometheus, Custom OTA Analytics Dashboard.

Build: Yocto/BitBake, Buildroot, Custom CI Pipeline (GitHub Actions, GitLab CI).

Verwandt mit