Over-the-Air (OTA) Software Updates

In dieser Fallstudie geht es um einen Premium-Automobilhersteller aus Süddeutschland, der Firmenfahrzeuge nutzt, um Over-the-Air (OTA) Softwareupdates zu erproben. Dadurch kann der Hersteller Softwareaktualisierungen unter realistischen Bedingungen testen, bevor diese an den Endkunden ausgerollt werden.

Problemstellung

Für die sichere und reibungslose Veröffentlichung von Softwareaktualisierungen in Fahrzeugen sind umfangreiche Tests notwendig, insbesondere dann, wenn diese Over-the-Air (OTA) erfolgen. Da es im Interesse des Herstellers ist, das Risiko für fehlerhafte Softwarepatches auf ein Minimum zu reduzieren, werden diverse Testzyklen durchlaufen, bevor Updates veröffentlicht werden. So müssen z.B. im Laufe eines Produktlebenszyklus unterschiedliche Hardware- und Softwareversionen unterstützt werden, was zusätzliche Komplexität bedeutet. Folglich ist eine umfangreiche und verlässliche Teststrategie notwendig, um den hohen Qualitätsanforderungen des Herstellers gerecht zu werden.

Neben der Fahrzeugsimulation nutzt unser Kunde auch reale Fahrzeuge, um OTA-Softwareaktualisierungen massenhaft zu testen. Hierzu bedient sich der Hersteller am Bestand der Firmenfahrzeuge, bei dem ihm eine Vielzahl von Fahrzeugmodellen zur Verfügung stehen. Da die Fahrzeuge aktiv genutzt werden, bilden sie eine ideale Zielgruppe, um OTA-Softwareaktualisierungen unter realistischen Bedingungen zu erproben, bevor diese an den Endkunden ausgerollt werden.

Die Herausforderung dieser Fallstudie lag zum einen darin, dass die Daten, die zur Erprobung der Softwareupdates für Firmenfahrzeuge notwendig sind, lediglich in einem Altsystem vorlagen und der Zugriff darauf mit hohem Aufwand verbunden war. Zum anderen plant der Hersteller mit einem deutlichen Wachstum an Fahrzeugmodellen, die in Zukunft über OTA-Updates versorgt werden müssen; der aktuelle Ansatz wäre dafür ökonomisch nicht mehr tragbar.

Unsere Aufgabe war es, die notwendigen Daten, unter Berücksichtigung des prognostizierten Wachstums, über moderne Schnittstellen automatisiert und kosteneffizient zur Verfügung zu stellen, sodass Firmenfahrzeuge weiterhin als essenzieller Bestandteil der Teststrategie für OTA-Updates genutzt werden können.

Unsere Lösung

Wie bei all unseren Lösungen orientierte sich unser Lösungsdesign an den fachlichen Anforderungen und den technischen Gegebenheiten. Bei dieser Fallstudie war die Ausgangslage so, dass die Anwender vorhersehbar und in Intervallen auf die Daten der Firmenfahrzeuge zugegriffen haben. Lediglich in Ausnahmefällen, wo z.B. der Besitzer eines Fahrzeuges ermittelt werden muss, würden Adhoc-Anfragen an die Schnittstellen gestellt werden.

Aufgrund der o.a. Prämissen und Anforderungen, dass die Lösung skalierbar und mit minimalen Kosten betrieben werden soll, haben wir folgende Lösungen implementiert:

Architektur

Bei der Architektur haben wir uns für eine klassische Microservice-Architektur entschieden. Durch die Entkoppelung mit dem Altsystem konnten die Microservices unabhängig skaliert und für die Zielinfrastruktur optimiert werden.

Infrastruktur

Das Cloud-Plattform-Team unseres Kunden hat die grundlegende Cloud-Infrastruktur vorgegeben: Als Cloud-Plattform kam AWS und als Container-Orchestrierungsplattform Kubernetes (EKS) zum Einsatz. Es wäre auch denkbar gewesen, auf ein EKS zu verzichten und auf eine Serverless-Infrastruktur (z.B. AWS Fargate) zu setzen. Dies wäre dann zu empfehlen, wenn der Business-Value die Kosten eines EKS-Clusters nicht rechtfertigen würde.

Bei den EC2-Instanzen haben wir uns für Amazons T3-Allzweckknoten entschieden (siehe EC2-Instanzen). Diese haben den Vorteil, dass sie sehr kostengünstig sind. Des Weiteren bieten sie die Möglichkeit, CPU-Ressourcen in lastarmen Zeiten zu sparen, die unter hoher Last wieder verwendet werden können. In Verbindung mit dem AWS Cluster Autoscaler und dem Kubernetes Horizontal Pod Autoscaler eignen sie sich ideal für unser skalierbares Service-Design.

Daten

Um die Daten der Firmenfahrzeuge aus dem Altsystem kosteneffizient in unserer Zielinfrastruktur (AWS) zur Verfügung zu stellen, haben wir uns für einen klassischen ETL-Ansatz entschieden. Dabei werden die Daten in der Zielinfrastruktur in einer Amazon Aurora Serverless V2 verwaltet. Der Vorteil des Serverless-Designs besteht darin, dass die Kapazitäten des Datenbankdienstes automatisch am Lastprofil der Anwendung ausgerichtet werden. D.h. die Ressourcen der Datenbank erhöhen sich bei steigender Last und reduzieren sich in lastarmen Zeiten. Somit werden die verfügbaren Ressourcen zu jeder Zeit optimal genutzt und es entstehen keine unnötigen Kosten.

Dienste

Die Microservices wurden mit dem Cloud-Native-Framework Quarkus entwickelt, das es uns ermöglicht hat, sehr schnell hoch effiziente Cloud-Native-Dienste mittels Enterprise Java (Eclipse Microprofile) zu implementieren. Insbesondere die schnellen Testzyklen haben uns geholfen, die hochwertigen Dienste in einer sehr kurzen Zeitspanne zu entwickeln.

Zudem haben wir die Möglichkeit genutzt, die in Java geschriebenen Anwendungen “native” zu kompilieren (siehe GraalVM). Die dabei resultierenden x86-Binaries haben im Vergleich zu den JVM-Artefakten einen deutlich geringeren Ressourcenverbrauch (z.B. RSS-Memory), was sich in der Cloud positiv auf die Kosten auswirkt. Zudem haben uns die schnellen Startzeiten der nativen Anwendungen geholfen, eine skalierbare Anwendungslandschaft mit einer adäquaten Reaktionszeit zu realisieren - trotz kostenoptimierter Hardware (siehe Infrastruktur).

Vorgehensmodell

Für die Umsetzung der Anforderungen haben wir ein agiles Vorgehensmodell gewählt. Dieses hat es uns ermöglicht, sowohl das Lösungsdesign als auch die Lösung selbst innerhalb von zwei Sprints (à zwei Wochen) zu realisieren. Somit haben wir von der Beauftragung bis zur Bereitstellung der Lösung (GO Live) lediglich vier Wochen benötigt.

Ergebnis

Durch unsere Cloud-Expertise konnten wir innerhalb von vier Wochen eine hochwertige Cloud-Native Lösung implementieren, die sowohl die fachlichen Anforderungen erfüllt als auch die Eigenheiten der Cloud berücksichtigt. Das Resultat sind Dienste, die von der Infrastruktur (Datenbank und EC2-Instanzen) bis hin zum Applikationscode (Pods) skalieren und das bei minimalen Kosten.

Unserer Kunde ist nun gut auf das prognostizierte Wachstum vorbereitet und kann seine Firmenfahrzeuge weiterhin als essenzieller Bestandteil seiner Teststrategie für OTA-Updates nutzen.

Techspace - Analysieren. Migrieren. Skalieren. 🚀