Da Autos immer stärker von Software geprägt sind, müssen OEMs in der Lage sein, Features und Anpassungen deutlich schneller auszurollen. Welche Infrastruktur braucht es dafür?
Mit der Transformation in Richtung softwaredefinierter Wertschöpfung gibt es aktuell kaum ein drängenderes Thema in der Automobilindustrie: Wie lässt sich die Welt der agilen Softwareentwicklung mit der meist noch klassisch durchgeführten Fahrzeugentwicklung zusammenbringen?
Die große Wertschöpfung liegt zukünftig nicht mehr in der Ingenieursleistung bei der Entwicklung des Motors und des Antriebsstrangs, sondern in der möglichst schnellen Bereitstellung und Aktualisierung der Software für die Autos auf der Straße. Dabei müssen die Release-Zyklen von bisher sechs bis zwölf Monaten auf wenige Wochen oder gar Tage schrumpfen.
Für heutige Softwareentwicklungsstandards mag das simpel klingen. Für die Entwicklung von Automotive Software hat es jedoch einen immensen Einfluss auf den gesamten Entwicklungsprozess, die Software & EE-Architektur, den Prozess, wie Software getestet und released wird bis hin zur Konfiguration und dem Ausrollen in die Fahrzeugflotte.
Damit das gelingen kann, sind im weitesten Sinne zwei Dinge notwendig. Zum einen wird ein im Fahrzeug integriertes Betriebssystem (OS) benötigt, um die Auslieferung von Features und deren Integration mit den Steuergeräten (ECUs) zu vereinfachen. Dadurch wird die Kopplung zu den ECUs reduziert es ergeben sich weitere Möglichkeiten, wie zum Beispiel die Einbindung von Apps durch Drittanbieter.
Zum anderen braucht es eine hochintegrierte, digitalisierte und automatisierte Plattform, die den hochkomplexen Fahrzeugentstehungsprozess abbildet. Dadurch wird den Fahrzeugentwickler:innen ermöglicht, Features schnell und sicher zu entwickeln und die Release-Zyklen deutlich zu verkürzen. Anders ausgedrückt: Eine hochkomplexe CI/CD-Pipeline, die wiederkehrende Aufgaben vollständig automatisiert.
Gepaart mit einem Automotive Betriebssystem werden somit zwei Dinge erreicht: Erstens verkürzt sich die Developer-Journey deutlich. Und zweitens erhöht sich die Ergonomie der Entwickler:innen.
Da die Komplexität der Hardware abnimmt und der Softwareanteil immer mehr an Bedeutung gewinnt, wird das Thema Software zum vorherrschenden Faktor der Branche.
Da sich Technologien und Erwartungen der Kund:innen fortlaufend verändern, muss sich der rasante Fortschritt auch in der internen Entwicklung der Herstellenden und Zuliefer:innen spiegeln: Es werden deutlich kürzere Release-Zyklen - auch für Software Updates - erwartet.
Die klassische Trennung zwischen IT und Fachbereichen löst sich auf und die Digitalisierung erhöht den Bedarf an Mitarbeitenden mit fundierten IT-Kenntnissen, die auch Erfahrung in moderner, agiler Softwareentwicklung mitbringen.
Dabei gibt es eine zentrale Herausforderung, vor der vor allem traditionelle Automobilkonzerne stehen: Zahlreiche fragmentierte, lose integrierte und historisch gewachsene Legacy-Systeme müssen transformiert und in eine einheitliche Digitalprozesslandschaft überführt werden. Anders ausgedrückt: Technisch orientierte Software-Monolithen müssen entlang der Fachlichkeit geschnitten werden. Die einzelnen Systeme müssen den eigentlichen Prozess abbilden.
"Künftig essentiell: Software für Fahrzeuge besonders schnell bereitstellen und aktualisieren."
Es gilt also, die Altsysteme der Fahrzeugherstellenden aufzubrechen und sämtliche Informationsflüsse miteinander zu vernetzen. Dabei handelt es sich immer um einen hochkomplexen Prozess, bei dem es um die 40 oder 50 vorhandenen Legacy-Systeme miteinander zu verzahnen gibt. Zusätzlich muss sichergestellt sein, dass auch die unterschiedlichen Softwareversionen der ECUs zueinander passen, die man als Gesamtpaket auf die Fahrzeuge bringt.
Dazu unterscheiden sich die eingesetzten ECUs mitsamt Software und angebotenen Ausstattungsmerkmale von Baureihe zu Baureihe. Von der Diagnose über die Steuerung bis hin zur Parametrierung der Lösung muss man alle Abhängigkeiten bedenken. Die Software muss über die komplette Developer-Journey hinweg, also in allen Entwicklungsphasen, kompatibel, testbar und integrierbar sein. Dazu muss man nachprüfen können, welche Quality Gates erreicht werden, damit die Software einem Gesamtpaket zugeordnet werden kann.
So braucht es eine tragfähige Architektur als Grundlage, in der der gesamte Datenfluss durchgängig und automatisierbar ist. Zusätzlich müssen die eigenen Entwickler:innen mit speziellen Hilfsmitteln befähigt werden, die Informationen zu verstehen, zu verwalten und damit bessere Entscheidungen treffen zu können.
Dabei sind die Systemarchitekturen immer so komplex wie die dahinterliegenden Kommunikationsstrukturen, weshalb es zunächst gilt, alle Kommunikationswege der OEMs und Zulieferer im Detail zu verstehen. Dann lassen sich Legacy-Systeme so in Microservices schneiden, dass sie die Struktur dieser Wege abbilden. Dabei werden neue Interfaces an vorhandene Lösungen angebaut und neue Verbindungslinien erstellt – einzelne Services können sich die Infos aus verschiedenen Systemen ziehen und diese für andere Services bereitstellen.
Ein Problem, dem wir in Sachen Automotive Software begegnen, liegt darin, dass es meist kein domänenübergreifendes Wissen in der Systementwicklung gibt. Mit Domain-driven Design haben wir aber ein gutes Werkzeug zur Hand, um auch Legacy-Systeme deutlich zu verbessern und Schritt für Schritt beherrschbarer zu machen.
Zunächst nehmen wir dafür eine Aufteilung anhand fachlicher Kriterien vor. Dazu verschaffen wir uns zusammen mit den Fachexpert:innen einen Überblick über die Domäne, in der das Legacy-System eingesetzt wird. Das kann per Event Storming oder mit Domain Storytelling geschehen – also Methoden, die für alle Beteiligten gleichermaßen gut verständlich sind.
Damit fachliche Module entstehen, wird der Legacy-Code entsprechend geschnitten. Neben der Unabhängigkeit der entwickelnden Teams und der modulareren und leichter verständlichen Struktur kann man das so in einzelne Microservices zerlegte System auch besser skalieren.
Die Cloud ermöglicht es, eine Infrastruktur für die Car-Software-Delivery-Plattform bereitzustellen, die die Developer Journey vereinfacht und beschleunigt. Die aus der Plattform entstehenden Artefakte werden dann in das Fahrzeug OS eingespielt. Dazu lässt sich auch die Fahrzeug-Software via Over-the-Air-Update verwalten, konfigurieren, aktualisieren und nachträglich erweitern.
Grundsätzlich geht es darum, eine Plattform zur Verfügung zu stellen, über die man einfach und unkompliziert auf Funktionen im Auto zugreifen kann. Denn bisher ist viel Tiefenwissen über die spezifischen Lösungen in der jeweiligen Fahrzeugplattform nötig, was den Aufwand und die Entwicklungszeit erhöht.
Im Ergebnis benötigen OEMs eine Car-Software-Delivery-Plattform, die sie befähigt, schneller auf Anpassungen zu reagieren und Cloud-Infrastrukturen zu integrieren. Dann wachsen bisher getrennte Inseln zusammen, Synchronisationsprobleme lösen sich auf und es lässt sich Mehrwert entlang der softwaredefinierten Wertschöpfungskette generieren.
Dabei handelt es sich immer um einen Prozess, der nicht nur technologische und organisatorische, sondern auch menschliche Belange miteinbeziehen muss. Denn wenn man die alte Entwicklungswelt mit der neuen verbinden möchte, bleiben Transformationsschmerzen nicht aus.
Aber soviel ist klar: Wenn sich der Fokus immer stärker auf Elektrifizierung, Software, autonomes Fahren und Connectivity richtet, handelt es sich um komplexe Themen, die viele Anpassungen nach sich ziehen. Und wer diese besonders schnell bereitstellt, wird noch lange vorausfahren können.
Fahrzeuge verändern sich: Kund:innen erwarten mehr Funktionen und Komfort. Die Zukunftstechnologie dafür ist Vehicle-to-Everything-Kommunikation.
Mehr erfahren V2X: Neue Technologie für intelligente Mobilität
Um Autonomes Fahren zu realisieren, braucht es eine gute Dateninfrastruktur und damit smarte Plattformen und Machine Learning.
Mehr erfahren Wie Autonomes Fahren datengestützt zur Realität wird
Mit den Mercedes me connect Features zur neuen User Experience
Mehr erfahren Mit Mercedes-Benz zum Connected Car