{"id":10193,"date":"2023-04-06T08:27:09","date_gmt":"2023-04-06T06:27:09","guid":{"rendered":"https:\/\/www.iese.fraunhofer.de\/blog\/?p=10193"},"modified":"2024-01-22T10:44:32","modified_gmt":"2024-01-22T09:44:32","slug":"continuous-engineering-in-devops","status":"publish","type":"post","link":"https:\/\/www.iese.fraunhofer.de\/blog\/continuous-engineering-in-devops\/","title":{"rendered":"Warum Software-defined Vehicles an Continuous Engineering in DevOps nicht vorbeikommen"},"content":{"rendered":"

Software-defined Cars<\/strong> oder auch Software-defined Vehicles<\/strong> charakterisieren, dass die Fahrzeugentwicklung \u2013 langj\u00e4hrigen Vorhersagen folgend \u2013 mittlerweile durch den Einsatz von Software dominiert ist. Die Begriffe beschreiben, dass sich andere Disziplinen nun an den Anforderungen der Software orientieren m\u00fcssen und nicht umgekehrt, wie es jahrelang der Fall war. Dieser Trend hat gro\u00dfen Einfluss auf die Art, wie Fahrzeuge entwickelt werden, und ist auch damit begr\u00fcndet, wie diese heutzutage in das \u00d6kosystem Mobilit\u00e4t<\/em> integriert sind. In diesem kurzen Artikel m\u00f6chten wir, das Fraunhofer IESE<\/a>, darauf eingehen, welche Faktoren dazu f\u00fchren, dass ein Fahrzeug \u00bbdurch die Software definiert\u00ab wird und welche Anforderungen und \u00c4nderungen sich dadurch u. a. an das Continuous Engineering in DevOps ergeben.<\/p>\n

Warum Softwareeinsatz in der Produktentwicklung Continuous Engineering in DevOps erfordert<\/h2>\n

Eine Fahrzeugentwicklung in Zyklen von Jahren ist nicht mehr zeitgem\u00e4\u00df \u2013 \u00e4hnlich wie Smartphone-Apps werden Funktionen kontinuierlich weiterentwickelt und per Software-Update \u00bbover-the-air\u00ab (OTA), also ohne Werkstattbesuch, \u00fcber das Mobilfunknetz verteilt. Dies setzt voraus, dass die Funktionen in kurzer Zeit entwickelt und validiert werden k\u00f6nnen und erfordert eine Fahrzeugarchitektur, die flexibel genug ist, um neue und ge\u00e4nderte Funktionen umzusetzen. Neben der generellen Update-F\u00e4higkeit des Fahrzeugs sind hierzu auch im \u00bbBackend\u00ab, also in der Regel in der Cloud-IT-Infrastruktur der Hersteller, Anpassungen f\u00fcr ein entsprechendes Software Update Management System (SUMS) notwendig. Gleiches gilt f\u00fcr ein unterst\u00fctzendes und begleitendes Cyber Security Management System (CSMS) \u2013 beide gefordert von den Richtlinien UN ECE 155\/156.<\/p>\n

Eine Verk\u00fcrzung von Entwicklungszeiten bei gleichzeitig hohem Anspruch an die Qualit\u00e4t kann nur mithilfe entsprechender Automatisierung erreicht werden. \u00bbEverything-in-the-loop\u00ab \u2013 oder kurz xXiL \u2013 lautet hier das Zauberwort. Durch modellbasiertes, automatisiertes Testen auf unterschiedlichen Abstraktionsebenen, von den Anforderungen bis hin zum ausf\u00fchrbaren 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\u00dfe Herausforderungen.<\/p>\n

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\u00f6gliche Iterationen und sogar parallele Ausf\u00fchrungen von V-Modell-Aufgaben erm\u00f6glichen. Das resultierende Vorgehensmodell wird auch als \u00bbII-Modell\u00ab (siehe Abbildung 1) bezeichnet. In dem Modell erfolgt die Verbindung von Spezifikation und Design mit Integration und Tests kontinuierlich. \u00dcber verschiedene X-in-the-Loop (XiL)-Aktivit\u00e4ten (virtuellen Prototypen entsprechend) werden unterschiedliche Systemeigenschaften kontinuierlich integriert und verifiziert (siehe Abbildung 1). Durch die Automatisierung dieses Prozesses k\u00f6nnen kleinere \u00c4nderungen sehr schnell alle Entwicklungsphasen durchlaufen.<\/p>\n