Continuous Integration bei Updates im Auto: für OTA gerüstet

Wer einen PC benutzt, ein Handy oder ähnliche Alltagselektronik, ist daran gewöhnt: in mehr oder minder langen Abständen werden online Updates geliefert. Was in diesem Bereich effizient geschieht, bietet sich auch für den automobilen Bereich an. Und warum sollte nicht ein Autofahrer, der Probleme mit seiner Software hat, das Update/Upgrade per Funk oder übers Internet erhalten? Allerdings müsste man die Steuerungssoftware für die Fahrzeugelektronik schneller aktualisieren können. Die letzte Diskussion mit den Abgaswerten von Dieselfahrzeugen hat die Notwendigkeit deutlich gezeigt, hier kurzfristiger und unkomplizierter Updates/Upgrades liefern zu müssen. Abhilfe schafft da nur Continuous Integration (CI).

Updates können auch für den automobilen Bereich per Funk oder übers Internet erfolgen. Dr. Barbara Stumpp

CI oder permanente Integration ist eine Methodik in der Software-Entwicklung, bei der häufig neue Software-Sequenzen in die Basissoftware integriert werden. Jede Integration verlangt, Tests um Fehler möglichst schnell zu erkennen. Das verringert Integrationsprobleme, und komplexe Software lässt sich so schneller erweitern.

Sollen aber zum Beispiel Motorfunktionen optimiert werden, erhält der Applikateur erst nach mehreren Wochen die erweiterte Software zum Testen. Im Bereich Consumer-Elektronik und dazugehöriger Software geht dies wesentlich schneller; die neue Funktionalität steht früher zu Tests bereit und der Einlaster erhält regelmäßig sein Update.

Das Problem klassischer Lösungen

Außer dieser Verzögerung generiert die normale/klassische Integration ein weiteres Problem: die Verantwortlichen warten normalerweise bis sich einiges angesammelt hat. Dann gilt es, viele neue Funktionen einzubauen und entsprechend zu testen. Die Funktionsentwickler und Applikateure bekommen ihre Software zu ihren neuen Funktionen oft erst Wochen später. Deshalb können sie die neuen Funktionen nicht zeitnah testen und der Fokus geht verloren.  So hinkt alles dem Bedarf hinterher. Nur wünschen sich die Integrationskunden regelmäßige Sonderstände.

Bisher: Bei der „normalen“ Integration wartet man normalerweise bis sich einiges angesammelt hat. Dann müssen viele neue Funktionen eingebaut und entsprechend getestet werden. Dr. Barbara Stumpp

Continuous Integration

Bei der Continuous Integration dagegen sammelt sich weniger an, in der Regel nur ein bis drei neue Funktionen. Das verlangt weniger Testarbeit, denn bei weniger neuen Funktionen findet man die Fehler einfacher und schneller.  So wäre es möglich, praktisch jeden Tag einen Sonderstand auszuliefern. Damit erreicht man die erste Stufe zu CI, den Nightly Build.

Um höchste Effizienz zu bieten, arbeiten die Teams IAV daran, alles zu automatisieren. Andre Larberg, Team Manager Software and Algorithms in der Business Area Powertrain Mechatronics Diesel bei IAV, kennt die Lösung: „Jeder Schritt einer solchen Update-Kette soll automatisch ablaufen. Dazu schreibt man eine Software, die diese Updates und passende Simulationsumgebungen für Testzwecke automatisch generiert, um so den steigenden Bedarf an Software-Updates bedienen zu können.“ Und das ist kein Wunschtraum, es funktioniert! Was noch fehlt, ist die fächendeckende Anwendung. Der Vorteil: Hat man eine Update-Idee, wäre diese dann zeitnah zu testen, was Qualität und Komfort für den Entwickler erhöht.

Zeitnah umsetzen

In Zukunft könnte es dann folgendermaßen ablaufen: Ein Entwickler stellt am Vormittag fest, dass er gerne eine kleine Änderung in einem Modul umgesetzt haben möchte und lastet diese entsprechend vollständig ein. Bei IAV sitzt ein kleines Dev-Ops-Team und setzt diesen Änderungswunsch zeitnah am Nachmittag um. Die Softwarefabrik erkennt ein Update selbstständig, der Sonderstand wird über Nacht automatisiert gebaut, validiert und abgelegt. Der Ingenieur lädt am nächsten Morgen seine neue Software herunter, probiert jetzt zeitnah seine Änderung aus und baut dies in das System ein.

Lesen Sie auf der nächsten Seite, was Entwickler von Lego lernen können.

Von Lego lernen

Pate bei dieser Entwicklung stand Lego mit Mindstorms. Andre Larberg: „Wir haben mit Mindstorms gelernt, wie wir Continuous Integration im Embedded-Bereich nutzen können.“ Das wichtigste ist aber das Mindset. Die Softwareentwickler müssen auch nach der Methodik von CI arbeiten. Hier wird nach Prinzipien wie „check in early, check in often“ gearbeitet. So lassen sich automatisiert neue Funktionen in Software einbauen, dokumentieren und automatisiert Softwarestände ablegen, inklusive Benachrichtigungsemail an den Kunden.

Das System hierzu ist verhältnismäßig einfach. Das Versionsmanagement liegt auf dem CI-Server bei IAV. Auf dem Buildserver bauen Software-Agenten die Dokumentation, laden die Quelletexte, kompilieren  die Steuergeräte-Software, versenden Benachrichtigungen und ähnliches.

Nicht zu vernachlässigen ist ebenfalls der Sicherheitsaspekt. Fehlverhalten einer Software macht sich viel früher bemerkbar, und es ist auch schnell klar, welches Softwarepaket einen Fehler verursacht hat. Sollte es einen sicherheitsrelevanten Bug in der Software geben, besteht die Möglichkeit, die neue Software innerhalb von Stunden zu erstellen. Es ist alles eine Vorbereitung für die Zukunft mit OTA-Updates (Over the Air), wonach Kunden zu jeder Zeit die sicherste Software, die es gibt, in ihrem Fahrzeug nutzen.

Wohin geht nun die Reise?

CI ist nur der Anfang. Sinnvoll ist es, wie bei der Consumer-Elektronik Continuous Verification, Continuous Deployment und vor allem Continuous Delivery zu ermöglichen. IAV bezeichnet diesen gesamten Prozess in Zukunft einfach als „Continuous“. So bietet IAV hier ein spezielles Produkt für Continuous Integration der Zukunft und darüber hinaus. Ein frühzeitiges, kontinuierliches Integrieren von erweiterten Funktionen bringt so große Vorteile für OEM, Zulieferer und vor allem Entwickler.