•  
  •  
  •  
  •  
  •  
Internet of Things

Das müssen Sie bei Over-the-Air-Updates beachten

Mit Over-the-Air-Updates lässt sich die Software von zahlreichen IoT-Geräten auf Knopfdruck und aus der Ferne aktualisieren. Das bringt immense Vorteile, aber auch Herausforderungen mit sich. Fest steht: Die Einführung von OTA-Updates soll gut durchdacht werden.

06.02.2020Text: bbv1 Kommentar
Over-the-Air-Updates OTA Internet of Things IoT Over-the-Air-Update
  •  
  •  
  •  
  •  

Software-Updates ohne physischen Zugriff auf Geräte installieren: Over-the-Air – kurz OTA – macht es möglich. Den meisten wohl durch Aktualisierungen beim eigenen Smartphone bekannt, gilt die Technologie auch für IoT-Landschaften im Unternehmensumfeld als zentraler Erfolgsfaktor. Aus gutem Grund: Dank der Remote-Updates lassen sich auf Knopfdruck etliche Geräte gleichzeitig aktualisieren. Es wird kein Servicetechniker mehr benötigt, der Updates manuell von Gerät zu Gerät installiert. So bewirken Over-the-Air-Updates erhebliche Kosteneinsparungen und erlauben es Entwicklern, sehr schnell auf Fehlverhalten von Software und Sicherheitslücken zu reagieren – und das bei einer Vielzahl an Geräten.

Besondere Sicherheitsvorkehrungen

Gerade hinsichtlich der Sicherheit sind Over-the-Air-Updates Segen und Fluch zugleich: Zwar ist OTA im Feld eine zentrale Voraussetzung für ein sicheres und zuverlässiges IoT-System; gleichzeitig stellen Updates aus der Luft ein erhöhtes Sicherheitsrisiko dar: «Beziehen die Geräte das Update nicht vom vorgesehenen Quellort – etwa, wenn er nicht sauber verifiziert wird – lässt sich ein IoT-System schnell kompromittieren», erklärt Silvan Wegmann, Senior Embedded Software Engineer bei bbv. «Deshalb verlangt die Implementierung von OTA nach einem starken Sicherheitskonzept.» Dazu gehören nicht nur verschlüsselte Kommunikationskanäle, auch der Quellort und die Software sollten mit Zertifikaten und Signaturen gesichert sein. Der Cloud-Server ist dabei lediglich für die Verteilung der Updates verantwortlich. Dessen Authentifizierung nimmt das IoT-Gerät selbst vor, bevor es ein verfügbares Update installiert – oder ablehnt.

Da die IoT-Geräte bei OTA im laufenden Betrieb aktualisiert werden, beanspruchen sie ausserdem viel Speicherplatz: Während der aktiven, laufenden Version muss gleichzeitig die aktualisierte Software in ähnlicher Grössenordnung aufs Gerät gespielt werden. «Deshalb muss man den Speicher der Geräte im Grunde genommen doppelt so gross auslegen, um Over-the-Air-Updates unterstützen zu können», erklärt Silvan Wegmann. «Je nachdem, wie viel Speicherplatz das Gerät schon initial benötigt, kann die Implementierung OTA-fähiger Geräte teuer werden – auch wenn sie im Betrieb zu Kosteneinsparungen verhelfen.»

Neben dem Speicherplatz muss bei Over-the-Air-Updates auch der Energieverbrauch der eingesetzten Geräte berücksichtigt werden. Denn kabellose Verbindungen ziehen oft einen hohen Energieverbrauch nach sich. Ist die Auslastung des Geräts im normalen Betrieb niedrig – etwa, wenn es nur wenige IoT-Daten verschickt – kann ein OTA-Update starke Auswirkungen auf den Energieverbrauch haben. «Auch hierzu können Unternehmen entsprechende Strategien fahren», erklärt Dominik Berner, Senior Software Engineer bei bbv. «Die Update-Häufigkeit, die Einsatzdauer des WLAN und auch die Grösse der Pakete sind Dinge, die man steuern und mit denen der Energieverbrauch des IoT-Geräts in Schach gehalten werden kann.» Michel Estermann, Senior Software Engineer bei bbv, ergänzt: «Gerade bei batteriebetriebenen Geräten wären auch Mechanismen denkbar, die Updates gar nicht erst zulassen, sollte der Energiestand zu niedrig sein – so, wie man es vom Smartphone kennt.»

Over-the-Air-Updates brauchen Rollback-System

Selbst wer all diesen Faktoren bei der Implementierung des OTA-Systems Rechnung trägt, ist unter Umständen von fehlerhaften oder fehlgeschlagenen Updates betroffen – etwa, wenn die Verbindung zum Cloud-Server plötzlich unterbrochen ist. Aus diesem Grund ist ein Rollback-System für die Einführung von Over-the-Air-Updates unerlässlich. In der Regel handelt es sich dabei um A/B-Systemupdates: Die allererste – oder die letzte noch funktionierende – Softwareversion sollte stets auf einer Partition (A) des Geräts als Fallback vorhanden sein. Das Update erfolgt dann auf einer zweiten Partition (B). Schlägt es fehl, kann so wieder auf die Softwareversion der ersten Partition zurückgegriffen werden. «So wird das Endgerät zumindest nicht unbrauchbar – und die sich darauf befindende Software kann weiterhin aktualisiert werden», hält Dominik Berner fest. Handelt es sich um kritische Updates oder komplexe Änderungen an der Software, empfiehlt es sich ausserdem, die Systemaktualisierung nicht auf sämtlichen Geräten gleichzeitig, sondern nur auf einer Teilgruppe zu deployen. Im Falle von mangelhafter Software wäre so nur ein Bruchteil der ganzen Geräteflotte betroffen.

Eine Frage der Strategie

Für einen sicheren, funktionierenden OTA-Vorgang sollten Entwickler unbedingt auf bereits bestehende Frameworks und Technologien setzen. Lösungen wie jene von Mender, Rauc oder das Toradex-Projekt Torizon adressieren bereits viele dieser technologischen Herausforderungen, welche die Implementierung von OTA-Updates mit sich bringen. «Wer hier selber versucht, ein OTA-System zu entwickeln, kann damit eigentlich nur schlechter fahren als mit einer bereits existierenden Lösung», sagt Silvan Wegmann. Die Schwierigkeit bei OTA liegt auch nicht in der Integration entsprechender Frameworks und Libraries. Allem voran benötigt man einen umfassenden, gesamtheitlichen Blick auf das System, für das man OTA-Update-Funktionalitäten integrieren möchte. «Nur so können Strategien entwickelt werden, mit welchen sich die Stolpersteine von OTA-Updates aus dem Weg räumen lassen», konstatiert Wegmann. «Darin sehe ich die Komplexität von OTA-Updates.»

Der Experte

Dominik Berner

Dominik Berner ist Software-Ingenieur bei bbv. Dank seines Know-hows im MedTech-Bereich kennt er die Wachstumsgrenzen von Startups und Kleinunternehmen, aber auch die Verhältnisse in Grossfirmen. Als Agilist betrachtet Berner Softwareentwicklung als Teamsport, der eine starke Unternehmenskultur erfordert.

Der Experte

Michel Estermann

Michel Estermann ist Senior Software Engineer bei bbv. Er ist überzeugt, dass ein gemeinsames Verständnis der Vision, Ziele und Anforderungen essenziell für das Gelingen eines Projektes ist – ganz nach dem «Manifest für Agile Softwareentwicklung». Als Entwickler möchte er auch seinen Beitrag dazu leisten.

Der Experte

Silvan Wegmann

Silvan Wegmann ist Senior Embedded Software Engineer bei bbv. Mit langjähriger Erfahrung in den Bereichen Medtech, Industrie und Telekommunikation ist er besonders an modernen Architekturen und vernetzten Maschinen interessiert. Wegmann ist Co-Organisator der GNU Embedded Linux Meetups in Zürich.

Unser Wissen im Abo

Industrial IoT für Führungsentscheide

Reibungsloser Betrieb und Sicherheit für Skigebiete

IoT/Internet der Dinge
Programmiersprache

Technologiewahl: altbewährt oder neu?

Innovation
Codefehler finden und beheben

Bugfixing: So geht’s

Softwareentwicklung

1Kommentar

  1. Um das Problem des Speicherbedarfs und der zu übertragenden Datenmenge zu adressieren, werden bei Firmwareupdates oft nur die Änderungen der Firmware übertragen werden. Aus der installierten Version und dem „Delta-Paket“ wird vom Client die aktuelle, zu flashende Version berechnet.

Artikel kommentieren

Die E-Mail-Adresse wird nicht publiziert. Notwendige Felder sind mit einem * versehen.