Warum Software-defined Vehicles an Continuous Engineering in DevOps nicht vorbeikommen

Software-defined Cars oder auch Software-defined Vehicles charakterisieren, dass die Fahrzeugentwicklung – langjährigen Vorhersagen folgend – mittlerweile durch den Einsatz von Software dominiert ist. Die Begriffe beschreiben, dass sich andere Disziplinen nun an den Anforderungen der Software orientieren müssen und nicht umgekehrt, wie es jahrelang der Fall war. Dieser Trend hat großen Einfluss auf die Art, wie Fahrzeuge entwickelt werden, und ist auch damit begründet, wie diese heutzutage in das Ökosystem Mobilität integriert sind. In diesem kurzen Artikel möchten wir, das Fraunhofer IESE, darauf eingehen, welche Faktoren dazu führen, dass ein Fahrzeug »durch die Software definiert« wird und welche Anforderungen und Änderungen sich dadurch u. a. an das Continuous Engineering in DevOps ergeben.

Warum Softwareeinsatz in der Produktentwicklung Continuous Engineering in DevOps erfordert

Eine Fahrzeugentwicklung in Zyklen von Jahren ist nicht mehr zeitgemäß – ähnlich wie Smartphone-Apps werden Funktionen kontinuierlich weiterentwickelt und per Software-Update »over-the-air« (OTA), also ohne Werkstattbesuch, über das Mobilfunknetz verteilt. Dies setzt voraus, dass die Funktionen in kurzer Zeit entwickelt und validiert werden können und erfordert eine Fahrzeugarchitektur, die flexibel genug ist, um neue und geänderte Funktionen umzusetzen. Neben der generellen Update-Fähigkeit des Fahrzeugs sind hierzu auch im »Backend«, also in der Regel in der Cloud-IT-Infrastruktur der Hersteller, Anpassungen für ein entsprechendes Software Update Management System (SUMS) notwendig. Gleiches gilt für ein unterstützendes und begleitendes Cyber Security Management System (CSMS) – beide gefordert von den Richtlinien UN ECE 155/156.

Eine Verkürzung von Entwicklungszeiten bei gleichzeitig hohem Anspruch an die Qualität kann nur mithilfe entsprechender Automatisierung erreicht werden. »Everything-in-the-loop« – oder kurz xXiL – lautet hier das Zauberwort. Durch modellbasiertes, automatisiertes Testen auf unterschiedlichen Abstraktionsebenen, von den Anforderungen bis hin zum ausführbaren Maschinencode, kann dies erreicht werden. Neben dem Aufbau entsprechender Modelle und der Testinfrastruktur stellt auch die jeweilige Simulation der Umgebung bzw. das Bereitstellen von Testdaten viele Unternehmen vor große Herausforderungen.

Die erforderliche Dynamik, die ein kontinuierliches Software Engineering mit sich bringt, erfordert eine Abkehr vom traditionellen V-Modell (siehe Abbildung 1). Die System- und Softwareentwicklung muss verschiedene mögliche Iterationen und sogar parallele Ausführungen von V-Modell-Aufgaben ermöglichen. Das resultierende Vorgehensmodell wird auch als »II-Modell« (siehe Abbildung 1) bezeichnet. In dem Modell erfolgt die Verbindung von Spezifikation und Design mit Integration und Tests kontinuierlich. Über verschiedene X-in-the-Loop (XiL)-Aktivitäten (virtuellen Prototypen entsprechend) werden unterschiedliche Systemeigenschaften kontinuierlich integriert und verifiziert (siehe Abbildung 1). Durch die Automatisierung dieses Prozesses können kleinere Änderungen sehr schnell alle Entwicklungsphasen durchlaufen.

Generell verwendet das II-Modell Prinzipien der agilen Entwicklung und kann an bestehende Prozesse und Werkzeugketten angepasst werden.

Eine stärkere digitale Vernetzung geht mit einem erhöhten Bedarf an Cyber Security einher

Die digitale Vernetzung erhöht die Anzahl und die Komplexität der Schnittstellen nach außen und damit die Möglichkeiten für Cyber-Security-Angriffe. Dieser Aspekt muss in die Entwicklung einfließen – geeignete Architekturen können helfen, dieses Risiko zu verringern. Wird eine Lücke entdeckt und/oder werden potenzielle Angriffe erkannt, so ist schnelles Handeln gefragt: Das oben erwähnte Cyber Security Management System soll entsprechende Updates unterstützen und überwachen – ein weiterer Grund für die Notwendigkeit eines Continuous-Engineering-Ansatzes: Notwendige Änderungen müssen sich schnell umsetzen lassen und zwar unter Berücksichtigung aller relevanten Freigabeverfahren.

Deshalb werden entsprechende Prozesse, die den gesamten Lebenszyklus darstellen, oft als Schleife dargestellt, die Entwicklung (Development) und Betrieb (Operations) verbinden – in Kurzform spricht man dabei von DevOps.

Die Möglichkeiten der digitalen Vernetzung führen auch zu neuen Geschäftsmodellen, welche auf datenbasierten Diensten aufbauen. Auch aus diesem Grund erhöhen sich Datenmengen und -arten, welche zwischen Fahrzeugen (car-to-car) oder zwischen Fahrzeugen und Infrastruktur (car-to-infrastructure) ausgetauscht werden. Durch die zusätzlichen Dienste treten Funktionen, die allein durch ein Fahrzeug erbracht werden, weiter in den Hintergrund. Der Kundennutzen wird zunehmend auch von anderen Systemen (mit-)erbracht. Dies betrifft mittelbar dann auch die Elektronik und mechanische Komponenten, z.B. für Schnittstellen.

Die Systemgrenzen zwischen Fahrzeug und Umfeld sind dabei fließend. Die dynamische Vernetzung kann zu einem emergenten Verhalten führen, was sich zur Entwicklungszeit nur begrenzt vorhersehen lässt. Deshalb wird sich mittel- bis langfristig die Entscheidung für ein bestimmtes Fahrzeugverhalten zunehmend von der Design-Zeit in die Laufzeit verlagern. Voraussetzung dafür ist eine dynamische Evaluierung von Systemmodellen zur Laufzeit. Dabei handelt es sich um einen Aspekt, der derzeit noch primär im Bereich der Forschung angesiedelt ist.

Hochautomatisierte Fahrfunktionen brauchen funktionierende Safety-Konzepte

Die Automatisierung von Prozessen wird heute fast ausschließlich durch Software gesteuert. Bei hochautomatisierten Fahrfunktionen wie Autobahnpilot oder Valet Parking ist dies natürlich der Fall. Die Fähigkeiten der Software müssen dabei eng auf die Hardware abgestimmt werden und umgekehrt. Gerade für solche Anwendungen gilt, dass das softwarebasierte Safety-Konzept eng mit der Hardware abgestimmt sein muss bzw. die Hardware flexibel sein muss, um beispielsweise auch zukünftige Features mit abzubilden. Ein entsprechendes Co-Engineering oder auch kollaboratives Engineering mit Partnern wird somit immer wichtiger. Dafür müssen Entwicklungsplattformen die Integration von unterschiedlichen Modellen einerseits, aber auch das vertrauensvolle und sichere Zusammenarbeiten mit Partnern andererseits unterstützen.

Zusammenfassung

Die technischen Entwicklungen, die zum Software-defined Car führen, sind allesamt seit vielen Jahren bekannt. Jedoch sind wir derzeit an einem Wendepunkt angelangt: Durch neue Architekturen und Lösungen im Zuge von Elektromobilität und Hochautomatisierung sind die Nöte und Chancen so groß, dass sich die Art und Weise, wie neue Fahrzeuge entwickelt, produziert und betrieben werden, im Moment in vielerlei Hinsicht – motiviert durch Softwareeigenschaften – ändert.