Updates nach Plan – Wie man Softwareupdates organisiert (Teil 1)

Abhilfe schafft aus unserer Sicht die Entwicklung einer gesamtheitlichen Updatemanagement-Lösung, die den Funktionsumfang verfügbarer OTA-Systeme erweitert. Die damit verbundenen Themen und Herausforderungen werden in dieser mehrteiligen Blogpost-Reihe Schritt für Schritt beleuchtet. In Teil 1 der Blogpost-Reihe konzentrieren wir uns auf die Probleme klassischer OTA-Systeme sowie das Organisationsmodell dieser Updatemanagement-Lösung.

Softwareupdates sind seit vielen Jahren ein fester Bestandteil unserer Smartphone Generation. Wurden Softwareupdates anfänglich kabelgebunden und manuell durch den Benutzer auf ein mobiles Endgerät übertragen, so profitiert man heute stark von der drahtlosen Konnektivität unserer Smartphones. Bei einer Übertragung von Softwareupdates über eine Funkschnittstelle (beispielsweise Mobilfunk oder WLAN) spricht man im Allgemeinen von Over The Air (OTA)-Updates. Auf diese Weise können sicherheitsrelevante Softwareupdates oder allgemeine Optimierungen des Betriebssystems und der Anwendungssoftware in kurzen Zyklen auf Endgeräte übertragen werden. Und das meist ohne Interaktion der Benutzer.

„Over-The-Air Update ist eine Fähigkeit, die es erlaubt, Software und Konfigurationen über ein Netzwerk aus der Ferne zu aktualisieren.“
Loris Ducrée, OTA Experte bei doubleSlash

Da heutzutage sehr viele Geräte mit einer Funkschnittstelle ausgestattet werden, haben OTA-Updates mittlerweile auch im Bereich der Industrieanlagen, Haushaltsgeräte, Medizintechnik und dem Automobilsektor stark an Bedeutung gewonnen. In vielen Fällen entscheiden sich Unternehmen dazu, eine auf ihr Produktportfolio angepasste Softwarelösung zur Verteilung von OTA-Updates zu entwickeln. Dabei wird der Fokus oftmals primär auf die Entwicklung grundlegender / technischer Bausteine gelegt, um beispielsweise eine sichere Kommunikation mit den Geräten bzw. eine sichere Übertragung von Softwareartefakten über verschlüsselte Kommunikationskanäle zu ermöglichen.

Für die Entwicklung eines OTA-Systems werden zwangsläufig viele Ressourcen eingesetzt, um dabei aber in gewisser Weise (wie andere Unternehmen auch) das Rad neu zu erfinden.

Was zum Ende der Entwicklungsphase jedoch meist vernachlässigt wird, ist unter anderem die allgemeine Verwaltung von Softwareartefakten hinsichtlich

• ihrer zeitlichen Verteilung auf Basis einer vorgegebenen Kampagnenplanung
• ihrer Abhängigkeiten untereinander oder
• ihrer Kompatibilität mit den Geräten
• ihrer Absicherung und Freigabe vor der produktiven Auslieferung an Geräte
• ihrer Verfügbarkeit gegenüber bestimmten Kundengruppen in Verbindung mit Subscription Business Models (bestimmte Softwareartefakte stehen beispielsweise unter Umständen nur einer Teilmenge aller Kunden zur Verfügung, da sie eine entsprechende Subscription abgeschlossen haben)
• ihrer Zulässigkeit in bestimmten Märkten aufgrund evtl. geltender Marktregularien

Erst durch solche Bausteine kann aus unserer Sicht ein OTA-System nachhaltig eingesetzt werden. Wir sprechen an dieser Stelle von einer Updatemanagement-Lösung, die auf einem oder sogar mehreren bestehenden OTA-Systemen aufbaut bzw. diese integriert, ohne sie neu entwickeln zu müssen.

Grundlegende OTA-Funktionalitäten (insbesondere die direkte Kommunikation mit den Geräten und die Auslieferung von Softwareupdates) werden dabei wie gewohnt durch angebundene OTA-Systeme erbracht. Fehlenden Funktionalitäten zur Organisation von Softwareupdates werden wiederum durch die Updatemanagement-Lösung bereitgestellt.

Organisationsmodell

Die Schaffung einer nachhaltigen und gesamtheitlichen Updatemanagement-Lösung erfordert eine klare Organisation. Folgende Rollen sind hierfür aus unserer Sicht erforderlich:

Die Rolle des Artefaktentwickler sieht die Entwicklung von Softwareartefakten für spezifische Gerätekomponenten, wie beispielsweise Steuergeräte vor. Artefaktentwickler treten als externe Schnittstellenpartner gegenüber der Updatemanagement-Lösung auf und stellen die durch sie entwickelten und versionierten Softwareartefakte bereit. Die dem Artefaktentwickler bekannten und oftmals sehr technischen Hardware- und Softwareanforderungen (z. B. Kompatibilitäten zu Gerätekomponenten) werden in Form von Metadaten mitgeliefert.

Sobald Softwareartefakte vorliegen, können diese durch den Releasemanager zu einem Release zusammengestellt und verwaltet werden. Müssen zur Umsetzung eines bestimmten Features (beispielsweise das Aktivieren eines Sprachassistenten über ein Multifunktionslenkrad) insgesamt 5 Gerätekomponenten aktualisiert werden, so könnte das fachliche Release 5 unterschiedliche Softwareartefakte in bestimmten Versionen referenzieren. Diese Tätigkeit kann eine gewisse technische Expertise voraussetzen, um aus allen vorhandenen Softwareartefakten nur die erforderlichen und vor allem untereinander kompatiblen Softwareartefakte auswählen zu können.

Nach Fertigstellung übergibt der Releasemanager das Release an den Testmanager, der das Release testen und hiernach freigeben kann. Optimalerweise werden diese Tests möglichst automatisiert und auf möglichst viele Geräte und deren Varianten angewandt, um die Aussagekraft der Testergebnisse zu erhöhen. Das primäre Ziel dieser Absicherungsphase ist eine anschließende Auslieferung der Softwareartefakte eines Releases mit möglichst geringer Fehlerrate. Denn eine hohe Fehlerrate aufgrund einer unzureichenden Absicherung kann schwerwiegende Folgen verursachen:

• Hohe Kosten für Reparatur oder Ersatz von Geräten, falls diese durch fehlerhafte Softwareartefakte beschädigt werden.
• Verlust des Vertrauens von Gerätenutzern bei Ausbleiben von Softwareupdates oder bei Einschränkung der Funktionsfähigkeit von Geräten durch fehlerhafte Softwareartefakte.
• Hohe Kosten gegenüber MNO (Mobile Network Operator) für Datenübertragung, auch wenn ausgelieferte Softwareartefakte nicht funktionsfähig sind.

Abgesicherte und freigegebene Releases können nun durch den Kampagnenmanager an Gerätegruppen ausgeliefert werden. Beispiele für solche Gerätegruppen sind:

• Alle Geräte eines bestimmten Modells im Markt „Deutschland“
• Alle Geräte eines bestimmten Kunden
• Alle Geräte mit bestimmten Softwareständen
• …

Sollte eine automatisierte Kompatibilitätsprüfung ergeben, dass das auszuliefernde Release bzw. dessen enthaltenen Softwareartefakte nicht mit den Geräten einer Gerätegruppe kompatibel sind, so muss das Release durch den Releasemanager entsprechend angepasst und erneut durch den Testmanager abgesichert und freigegeben werden.

Treten im Rahmen einer Auslieferung dennoch unerwartete und nicht unmittelbar behebbare Fehler in den Geräten auftreten, ist ggf. der Einsatz eines Servicetechnikers erforderlich. In der Regel müssen betroffene Gerätebesitzer beispielsweise eine Vertragswerkstatt aufsuchen, um die volle Funktionsfähigkeit ihrer Geräte wiederherzustellen.

Im Fokus der gesamten Updatemanagement-Lösung steht die Zufriedenheit der Gerätebesitzer. Diese profitieren primär von Produktverbesserungen und neuen Funktionen, die ihren Geräten in kurzen Zyklen bereitgestellt werden. Ein längeres Ausbleiben von Softwareupdates oder gar die Beschädigung von Geräten durch fehlerhafte Softwareupdates führt zwangsläufig zu Vertrauensverlust und Ablehnung gegenüber des Geräteherstellers.
Die kontinuierliche Weiterentwicklung und der Betrieb der Updatemanagement-Lösung selbst erfolgt durch das DevOps Team.

Da beispielsweise die direkte Datenübertragung / Kommunikation mit den Geräten sowie die Verwaltung dieser Geräte nicht im Fokus der Updatemanagement-Lösung stehen, werden geeignete Schnittstellen angebunden. Hierunter zählen unter anderem Schnittstellen zu OTA-Systemen, Gerätemanagement Systemen, CRM Systemen, Subscription Management Systemen oder Artefakt Repositories.

Fazit

In Teil 1 der Blogpost-Reihe haben wir Folgendes gelernt:

• Die kontinuierliche Optimierung von Geräten durch OTA-Updates gewinnt in vielen Branchen zunehmend an Bedeutung.
• Zwar gibt es bereits zahlreiche OTA-Systeme, jedoch verfügen diese meist über einen ähnlichen und in Bezug auf die Verwaltung von Softwareartefakten unzureichenden Funktionsumfang.
• Die Schaffung einer gesamtheitlichen Updatemanagement-Lösung bietet langfristig einen hohen Mehrwert.
• Eine Integration bereits bestehender OTA-Systeme als Fundament der Updatemanagement-Lösung verringert dabei deutlich den Entwicklungsaufwand.
• Die Schaffung einer nachhaltigen und gesamtheitlichen Updatemanagement-Lösung erfordert eine klare Definition involvierter Rollen.

Im nächsten Teil dieser Blogpost-Reihe werden die relevanten Prozessschritte sowie das Datenmodell inklusive dessen fachlichen Bestandteilen aufgezeigt.