Firmwareupdates per Funk für IoT-Geräte

Ein Update „over the air“ (OTA) installiert neue Firmware über das Funknetz auf einem Gerät. Ein Zähler oder Sensor bleibt oft zehn Jahre oder länger im Einsatz; in dieser Zeit können Fehler im Funkprotokoll oder Anwendungscode auffallen. Bei 400 Geräten an 20 Standorten würde eine manuelle Korrektur 20 Besuche erfordern. Per Funk lässt sich dieselbe Korrektur als geplante Kampagne vom Gateway aus verteilen.

Dieser Leitfaden gehört zum Lernpfad für Netzwerke und Architektur.

Warum Feldgeräte Updates brauchen

Ein gut dokumentierter Zigbee-Fall ist der 2016 von Ronen, O’Flynn, Shamir und Weingarten veröffentlichte Angriff auf Philips-Hue-Lampen. Die Lampen authentifizierten Firmware mit einem AES-CCM-Schlüssel, den alle Lampen desselben Typs teilten. Die Forschenden gewannen den Schlüssel durch Stromverbrauchsanalyse mit Ausrüstung für wenige hundert Dollar. Damit konnten sie Firmware bauen, die jede Lampe dieses Typs als echt akzeptierte. Ein Fehler im Zigbee-Light-Link-Code ließ das schädliche Abbild von Lampe zu Lampe wandern. Philips behob den Übernahmefehler und stellte die Korrektur als OTA-Update bereit. Die Entnahme des gemeinsamen Schlüssels zeigt, warum ein Abbild eine Signatur tragen sollte, die das Gerät mit einem öffentlichen Schlüssel prüft.

Auch gewöhnliche Fehler zählen. Ein Fehler, der einen Impulszähler verfälscht oder ein Gerät nach dem Neustart seines übergeordneten Routers aus dem Netz wirft, muss auf jedem betroffenen Gerät behoben werden. NIST SP 800-82 Rev. 3, Abschnitt 6.2.11, fordert für OT-Betreiber ein dokumentiertes Patchverfahren: Wie erfahren sie von Patches, wie testen und planen sie diese, und welche Ersatzmaßnahmen gelten bei Aufschub? Patches sollen während geplanter Unterbrechungen installiert werden. Die folgenden Schritte folgen diesem Muster.

So funktioniert ein Zigbee-Update

Zigbee-Geräte verwenden den OTA Upgrade Cluster mit der Cluster-ID 0x0019 aus Kapitel 11 der Zigbee Cluster Library (ZCL). Das Gateway hält als OTA-Server die Abbilddateien bereit. Das Gerät ist OTA-Client und steuert den Download.

Jede OTA-Datei beginnt mit der Kennung 0x0BEEF11E. Ihr Header nennt Hersteller-Code, Abbildtyp, Dateiversion und Gesamtgröße; optional begrenzt er die Hardwareversionen. Der Server wählt anhand von Hersteller-Code und Abbildtyp ein mögliches Abbild aus. Prüfen Sie das genaue Modell, die Hardwareversion und die vom Hersteller freigegebene Datei; passende Header-Kennungen allein beweisen keine Eignung.

Der Ablauf ist:

1. Der Server kann mit Image Notify ein verfügbares Abbild ankündigen. Schlafende Endgeräte lassen sich nicht zuverlässig sofort benachrichtigen. Sie senden deshalb regelmäßig Query Next Image Request mit Hersteller-Code, Abbildtyp und aktueller Dateiversion.
2. Der Server antwortet mit Query Next Image Response und nennt angebotene Dateiversion und Abbildgröße.
3. Der Client fordert mit Image Block Request den benötigten Datei-Offset und die größte akzeptierte Blockgröße an. Image Block Response liefert die Daten. Der Client wiederholt dies bis zum Dateiende. Er selbst verfolgt den Fortschritt; der Server hält wenig Zustand je Gerät.
4. Der Client prüft das Abbild und sendet Upgrade End Request mit SUCCESS oder INVALID_IMAGE.
5. Der Server antwortet mit Upgrade End Response und einer Updatezeit. Zu dieser Zeit wechselt der Client auf das neue Abbild. 0xFFFFFFFF heißt, dass er auf einen späteren Befehl warten soll. Damit kann der Server eine Gerätegruppe gemeinsam umschalten.

Die ZCL verlangt einen Anwendungs-Bootloader und zusätzlichen Speicher für das vollständige neue Abbild vor dessen Aktivierung. Damit kann der Download bei laufendem altem Abbild erfolgen; unterbrechungsfreier Anwendungsbetrieb oder lückenlose Meldungen sind jedoch nicht garantiert. Prüfen Sie Geräteimplementierung und Netzlast. Der Neustart in das neue Abbild unterbricht den Betrieb.

Dauer eines Zigbee-Updates

Die Blockgröße macht Zigbee-Updates langsam. Der Client gibt je Anfrage die maximale Datenmenge vor. Der Server darf laut ZCL weniger senden, um bei mehreren Funk-Hops Platz für Routingdaten zu lassen; verbreitete Server übertragen 50 Byte Abbilddaten je Block. Ein Abbild mit 200 kB benötigt so etwa 4.000 Blöcke. Zu jedem Block laufen Anfrage und Antwort über jeden Hop. Dauert eine Hin- und Rückübertragung über zwei Hops eine Viertelsekunde, dauert die Übertragung ungefähr 17 Minuten. Das passt zu den 10 bis 20 Minuten, die Edge vor einem Update nennt.

Zwei Faktoren verlängern sie. Der Server kann einen Client über MinimumBlockPeriod begrenzen, den Mindestabstand zwischen Blockanfragen in Millisekunden. Als Beispiel nennt die ZCL einen Block je 500 ms pro Client, während mehrere Geräte gleichzeitig laden; damit verdoppeln sich die 17 Minuten. Schlafende Endgeräte empfangen Daten nur beim Abfragen ihres übergeordneten Routers. Um ihre Batterie zu schonen, dürfen sie Blöcke seltener anfordern, als der Server sie zulässt. Ein Batteriesensor kann daher Stunden brauchen.

Signatur des Abbilds

Die ZCL empfiehlt nachdrücklich eine Signatur mit dem privaten Schlüssel des Herstellers. Nach dem Download prüft das Gerät sie mit dem passenden öffentlichen Schlüssel (Abschnitt 11.3.3.1). Die ZCL schreibt sie jedoch nicht vor; der jeweilige Anwendungsstandard legt das Minimum fest. Smart Energy kann Signaturen zusammen mit Netz- und APS-Verschlüsselung verwenden, andere Standards unter Umständen nur Netzverschlüsselung (Abschnitt 11.3.2). Ohne Signatur beweist ein Hash des Abbilds (Abschnitt 11.3.3.2) die unbeschädigte Übertragung, aber nicht den Urheber. Manche Hersteller prüfen zusätzlich im Bootloader. Fragen Sie nach dem Verfahren des konkreten Geräts. Wie der Lampenangriff zeigt, ist ein gemeinsamer symmetrischer Schlüssel nur so sicher wie das am schwächsten geschützte Gerät, das ihn enthält.

So funktioniert ein LoRaWAN-Update

LoRaWAN-Downlinks sind klein und knapp. Deshalb hat die LoRa Alliance Firmware Update Over the Air (FUOTA) als Satz von Paketen auf Anwendungsebene definiert. Die Prozessübersicht TR002 verbindet sie:

• TS003 synchronisiert die Uhr auf Anwendungsebene, damit alle Geräte eine Multicast-Sitzung zum vereinbarten Zeitpunkt beginnen.
• TS005 richtet Multicast-Adresse und gemeinsame Schlüssel ein und plant eine Sitzung in Klasse C oder B. Ein Gerät, das nur Klasse A nutzt, kann an Multicast nicht teilnehmen. Es empfängt Fragmente nur per Unicast in den Empfangsfenstern nach eigenen Uplinks.
• TS004 teilt das Abbild in Fragmente und ergänzt Vorwärtsfehlerkorrektur. Mit 10 % Redundanz kann ein Gerät ungefähr 10 % der Frames verlieren und die Datei dennoch ohne Nachfrage nach fehlenden Fragmenten zusammensetzen. Eine Sitzung umfasst höchstens 16.383 Fragmente.
• TS006 steuert die Firmwareversion auf dem Gerät und meldet sie zurück.

Hat ein Gerät genügend Fragmente, setzt es das Abbild zusammen. Es prüft die digitale Signatur mit dem öffentlichen Schlüssel des Update-Servers und gleicht den Header mit Hardware und bisheriger Firmware ab. Danach markiert es das Abbild als bereit und startet neu. Der Bootloader installiert es in einen zweiten Abbildbereich oder seitenweise mit gespeichertem Fortschritt, damit ein Stromausfall während des Schreibens das Gerät nicht ohne Firmware lässt. Dies ist der von TR002 empfohlene Ablauf. Unterstützung für Fragmenttransport allein belegt weder Signaturprüfung noch Wiederherstellung nach Stromausfall. Prüfen Sie diese Funktionen für das genaue Gerät und den Bootloader.

Dauer eines LoRaWAN-Updates

Als Beispiel dient ein Abbild mit 100 kB, das in EU868 per Klasse-C-Multicast auf der Standard-RX2-Frequenz 869,525 MHz bei DR0 (SF12, 125 kHz) gesendet wird:

• RP002 begrenzt die Anwendungsnutzlast bei DR0 auf 51 Byte. Der TS004-Befehl DataFragment belegt davon 3 Byte; 48 Byte bleiben für das Abbild.
• 100 kB entsprechen 2.084 Fragmenten. Mit 10 % Redundanz sendet der Server rund 2.300 Frames.
• Jeder Frame belegt bei SF12 ungefähr 2,8 s Funkzeit.
• ERC Recommendation 70-03 begrenzt den Duty Cycle im Band 869,40 bis 869,65 MHz auf 10 %. Das Gateway darf 360 s je Stunde senden, also etwa 129 Frames pro Stunde.

Die Frames benötigen rund 1,8 Stunden Gateway-Funkzeit, verteilt auf ungefähr 18 Stunden bei dieser 10-%-Grenze. Andere Downlinks auf demselben Kanal teilen sich dieses Budget. Bei DR5 (SF7) passen 239 Byte in einen Frame; dasselbe Abbild braucht etwa 460 Frames zu 0,39 s, also rund 30 Minuten unter derselben Grenze. Dafür muss jedes Gerät der Gruppe SF7 zuverlässig empfangen; am Rand der Abdeckung ist das oft nicht der Fall. Unicast an ein Klasse-A-Gerät ist noch langsamer. Mit ungefähr einem Fragment je Uplink braucht ein Gerät im 15-Minuten-Meldeintervall für dieselben 2.300 Frames mehr als drei Wochen.

Die Unterstützung unterscheidet sich je Modell. Prüfen Sie implementierte FUOTA-Pakete, Klasse-B- oder Klasse-C-Sitzungen und ausreichend Flash für ein zweites Abbild.

Updatekampagne planen

1. Erfassen Sie je Gerät Modell, Hardwareversion, Hersteller-Code, Abbildtyp und aktuelle Dateiversion.
2. Lesen Sie die Versionshinweise. Prüfen Sie, ob das Update Werte, Einheiten, Skalierungsfaktoren oder gelesene Register ändert. Ein veränderter Skalierungsfaktor kann plausibel wirkende, aber falsche Messwerte erzeugen.
3. Fragen Sie den Hersteller, ob das Abbild signiert ist, ob das Gerät ältere Dateiversionen annimmt und ob sein Bootloader das vorige Abbild aufbewahrt.
4. Aktualisieren Sie zuerst eine Pilotgruppe. Nehmen Sie die älteste Hardwareversion, ein Gerät am äußersten Rand des Mesh und gegebenenfalls ein Batteriegerät auf.
5. Arbeiten Sie danach in kleinen Gruppen, beispielsweise fünf Geräten je Gateway mit Abstand zwischen den Starts. Beobachten Sie auch Geräte, die gerade kein Update erhalten. Verspätete oder fehlende Meldungen dort deuten auf ein überlastetes Mesh; verkleinern Sie die Gruppe.
6. Lesen Sie nach jedem Abschluss die Version vom Gerät zurück. Bei Zigbee ist das das Attribut CurrentFileVersion des OTA-Clusters oder die Version aus dem Basic Cluster. Prüfen Sie dann den planmäßigen Meldetakt und vergleichen Sie Messwerte vor und nach dem Update.

Wenn ein Update scheitert

Die ZCL kennt keinen Rollback-Befehl. Der Server darf eine niedrigere Dateiversion anbieten, aber die Gerätefirmware entscheidet, ob sie diese annimmt. Das Wiederherstellungsverfahren überlässt Abschnitt 11.18 dem Hersteller. Beispiele sind ein Bootloader, der neue und vorige Abbilder tauscht, und eine Taste beim Einschalten, die das alte Abbild aktiviert. Fehlt beides, kann ein fehlerhaftes Abbild einen Standortbesuch erfordern.

Datenlücken können während des Downloads und beim Neustart entstehen. Ein kumuliertes Energieregister kann die Gesamtmenge über eine Meldelücke nur erhalten, wenn die Messung weiterläuft und der Zähler das Update ohne unbehandeltes Zurücksetzen oder Überlaufen übersteht. Der fehlende Verlauf von Momentanleistung oder Temperatur lässt sich daraus nicht wiederherstellen. Der Leitfaden zu veralteten Daten erklärt die Anzeige der Lücke.

Gerätefirmware und Gatewaysoftware getrennt aktualisieren

Das Gateway ist OTA-Server. Es hält Abbilder bereit und beantwortet alle Blockanfragen. Wird seine Software während einer Gerätekampagne neu gestartet, stoppen laufende Übertragungen. Schließen Sie eine Gerätekampagne ab oder pausieren Sie sie vor dem Gateway-Update. Beginnen Sie die nächste erst, wenn das aktualisierte Gateway stabil ist und alle Geräte wieder melden.

Firmwareupdates mit Edge

Edge auf dem ZGW-20 Gateway verwaltet einen Katalog von Firmwareabbildern auf dem Gateway. Drei Dateitypen bis je 5 MB sind möglich: Zigbee-OTA-Dateien (.ota) für Geräte anderer Hersteller, EBL-Abbilder (.ebl) für EpiSensor-Geräte und Binärabbilder (.bin) für das IO Board. Edge prüft jede Datei beim Upload und zeigt Hersteller, Modell, Version, Größe und Gültigkeit an.

Ein Update kann sofort oder zu einem geplanten Zeitpunkt beginnen und ein Gerät oder eine Auswahl betreffen. Bei einer Auswahl sendet Edge den Befehl nacheinander an jedes Gerät, mit bis zu 60 s Abstand. So starten nicht alle Übertragungen zugleich. Edge warnt vor 10 bis 20 Minuten je Gerät und einem möglichen Neustart; den Status zeigt es als laufend, abgeschlossen oder fehlgeschlagen. Edge selbst wird über seinen Snap-Kanal oder die Desktop-App aktualisiert, nicht über diesen Firmwarekatalog.