Lab: Offline-Firmware-Updates über BLE – die Referenzarchitektur
Wie ein Techniker Geräte ohne Internet aktualisiert: signierte Firmware vorab aufs Telefon, Übertragung per Bluetooth, Verifikation und Rollback auf dem Gerät – von Download bis Protokoll durchdacht.
In unserem Lab arbeiten wir Architekturen aus, bevor ein Kundenprojekt sie braucht. Diese Seite zeigt unsere Referenzarchitektur für Firmware-Updates in Umgebungen ohne Internet – kein Kundenprojekt, sondern Konzeptarbeit. Wir legen sie offen, damit du prüfen kannst, ob wir wissen, wovon wir reden, bevor du mit uns sprichst.
Das Szenario: Firmware-Update ohne Internet
Der Alltag von Servicetechnikern: Die Werkhalle hat kein WLAN, der Heizungskeller keinen Empfang – und das Gerät braucht trotzdem die neue Firmware. Der Flow in drei Stationen:
1 · Büro
Online laden
Die App lädt das signierte Firmware-Paket, prüft die Signatur und legt es lokal ab – inklusive Versions-Metadaten und Release Notes.
Online · einmalig2 · Anfahrt
Offline dabei
Das Paket liegt geprüft auf dem Telefon. Ab jetzt braucht der gesamte Update-Prozess keine Internetverbindung mehr.
Offline3 · Werkhalle
Per BLE updaten
Übertragung in Blöcken über Bluetooth, Verifikation auf dem Gerät, Reboot – und die App bestätigt die neue Version.
OfflineDie Architektur: Vertrauen wird geprüft, nicht angenommen
Drei Ebenen, eine Regel: Jede Stufe verifiziert die Firmware selbst – der Transportweg ist austauschbar, die Sicherheit nicht.
Firmware-Server
Die App – der Auslieferungskanal
Lokaler Firmware-Speicher, Signaturprüfung, Chunk-Transfer mit Resume, Update-Protokoll
Gerät – z.B. nRF52 oder ESP32
Der entscheidende Punkt: Die Signatur entsteht beim Bau der Firmware, die App prüft sie vor der Übertragung, das Gerät prüft sie erneut vor der Aktivierung. Selbst ein kompromittierter Server oder ein manipuliertes Telefon kann so keine fremde Firmware auf das Gerät bringen.
Der Update-Flow im Detail
Sechs Schritte – und für jeden ist der unbequeme Fall von Anfang an mitgebaut. Genau darin steckt die Ingenieursarbeit:
Discovery & Versionsabgleich
Die App findet das Gerät per BLE-Scan und liest Firmware-Version, Hardware-Revision und Batteriestand.
Kritischer Akku ist abgefangen: Das Update startet erst, wenn genug Ladung fürs Flashen da ist.
Prüfung vor dem ersten Byte
Signatur und Kompatibilität (Hardware-Revision, Mindestversion) werden geprüft, bevor die Übertragung beginnt – nicht danach.
Inkompatible Pakete sind aussortiert, bevor ein einziges Byte gesendet wird.
Chunk-Transfer mit Resume
Die Firmware geht in kleinen Blöcken über GATT, abgestimmt auf MTU und Verbindungsparameter.
Verbindungsabrisse sind einkalkuliert: Die Übertragung setzt am gemerkten Offset fort, nicht von vorn.
Verifikation auf dem Gerät
Das komplette Image landet zuerst in der inaktiven Partition; dort prüft der Bootloader Hash und Signatur.
Manipulierte Firmware kommt nicht zur Ausführung: Ohne bestandene Prüfung wird nie umgeschaltet.
Aktivierung mit Rollback-Netz
Reboot in die neue Firmware – sie muss sich innerhalb einer definierten Frist gesund melden.
Bleibt die Gesund-Meldung aus, bootet automatisch wieder die alte Version – kein Brick, kein Technikereinsatz.
Bestätigung & Protokoll
Die App liest die neue Version zurück und protokolliert das Update – die Datenbasis für Flottenübersicht und CRA-Nachweise.
Fehlendes Netz ändert nichts: Das Protokoll wartet lokal und synchronisiert später.
Architektur-Fragen zu Offline-Updates über BLE
Die Entscheidungsfragen, die in jedem OTA-Projekt auf den Tisch kommen – kurz und technikoffen beantwortet.
Warum wir das offenlegen
Diese Referenzarchitektur ist Konzeptarbeit aus unserem Lab – kein Kundenprojekt. Genau deshalb zeigen wir sie: Du sollst prüfen können, wie wir denken, bevor du uns dein Produkt anvertraust.
Der Stack dieser Referenzarchitektur
Ob dein Gerät auf Nordic, Espressif oder etwas anderem läuft: Die Architektur bleibt, die Bausteine wechseln. Wo dein Produkt heute steht und welcher Weg zum belastbaren Update-Kanal führt, klären wir im Erstgespräch.