So gelingt die Transformation zum Software-defined Car

Software ist der zentrale Innovationstreiber in der Automobilindustrie. Zusätzlich zu Steuerungsaufgaben im Hintergrund dient sie längst der Personalisierung und fortlaufenden Funktionserweiterung moderner Fahrzeuge. Der Trend birgt technologisch und wirtschaftlich enormes Potenzial – sofern es gelingt, die zunehmende Komplexität und den stetig steigenden Zeit- und Kostenaufwand der Softwareentwicklung in den Griff zu bekommen. Das kann mit softwarezentrierter Entwicklung, dem Einbinden von Open-Source-Ansätzen, cloudbasierten Methoden und Toolchains sowie einer agilen über den gesamten Lebenszyklus der Fahrzeuge hinweg angewandten Entwicklungsphilosophie gelingen.

Neunzig von hundert Innovationen der Automobilindustrie sind heute laut Boston Consulting softwaregesteuert. Der Markt für Automobilsoftware und -elektronik wachse deutlich stärker als der gesamte Fahrzeugmarkt. Software werde als Treiber der Personalisierung, Vernetzung, Fahrzeugsicherheit und des Infotainments für Hersteller zum wichtigen Verkaufsargument und Differenzierungsmerkmal.

Aktuelle Entwicklungskonzepte für Automotive-Software werden dieser Bedeutung nicht mehr gerecht. Verteilte elektrische und elektronische (E/E)-Architekturen, monolithisch ausgelegte Softwarearchitekturen sowie stark steigende Kosten für Tests, Integration und Wartung prägen das Bild. Dass Software oft in firmen- und länderübergreifender Kollaboration entsteht, macht es nicht leichter. Alles das ist mit Plänen zur Implementierung automatisierter Fahrfunktionen und zur fortlaufenden Bereitstellung neuer Softwarefunktionen und -optimierung über Over-The-Air-(OTA)-Updates nicht vereinbar. Laut McKinsey stieg die Softwarekomplexität in den letzten zehn Jahren um Faktor vier, während die Entwicklungsproduktivität nahezu stagniert.

Ein zentraler Schritt, um das zu ändern, ist die Entkopplung der Entwicklungsprozesse für Soft- und Hardware. Die komplexen dezentralen Abläufe entlang des traditionellen V-Modells müssen dafür einem kontinuierlichen Entwicklungs- und Betriebsprozess über den Gesamtlebenszyklus der Fahrzeuge hinweg weichen. Dieser methodische Umbruch schafft Raum, um E/E-Architekturen und Softwareplattformen neu zu denken, ihre Entwicklung auf eine neue kollaborative Basis zu stellen und die Vorteile standardisierter Schnittstellen und Prozesse, cloudbasierte Toolchains sowie Open-Source-Lösungen zu nutzen. Auch wird es in dieser offenen Umgebung möglich sein, Software und Entwicklungsdaten aus Projekten für verschiedene Fahrzeugplattformen zu übernehmen, statt jedes Projekt neu aufzusetzen. Nach Analysen von Roland Berger wird der skizzierte Umbruch Synergien im Wert von bis zu 16 Milliarden Dollar jährlich freisetzen – ein Großteil davon durch Einsparungen bei Tests, Integration und Wartung. Obendrein würden die Projekte beschleunigt, was Kräfte zum Experimentieren und schnelleren Innovieren freisetze.  

Doch wie ist das umsetzbar? Was heißt es für die Entwicklungslandschaft, wenn die Software in den Mittelpunkt der Fahrzeugentwicklung rückt und softwarebasierte Funktionen über den Fahrzeugbetrieb hinweg häufig aktualisiert werden? Welche organisatorischen Maßnahmen und Tools sind erforderlich, um eine beliebige Anzahl von Softwarefunktionen automatisiert, einfach und effizient für jedes gewünschte Fahrzeug anzubieten? Kurz: Wie gelingt die Transformation zum Software-definierten Fahrzeug (Software Defined Vehicle, SDV)?

Bisher galt der Ansatz kombinierter Hardware-Software-Systeme, weil der Softwareeinsatz im Fahrzeug auf Steuerungsaufgaben von einer Handvoll Steuergeräte (ECUs) begrenzt war. Doch mit jeder weiteren ECU und jedem Subsystem steigt der Aufwand der Integration exponentiell. Um den Überblick zu wahren, werden die Rechenressourcen und die Entwicklungs-Toolchains projektspezifisch ausgelegt. Die Übernahme des implementierten Funktionscodes von Projekt zu Projekt ist so nahezu unmöglich. Für das SDV ist dieser Ansatz zu zeit- und kostenaufwändig, zumal sich damit nicht alle künftigen Anforderungen und Anwendungsfälle abdecken lassen.

Gefragt ist stattdessen die konsequente Entkopplung der Soft- und Hardware-Lebenszyklen mit drei Zielsetzungen: Mehr Rechenleistung mit weniger ECUs, um der Hardware-Komplexität zu begegnen. Harmonisierung der Basissoftware und der Entwicklungs-Toolchains im Sinne einer plattformübergreifenden Softwarekompatibilität und der Öffnung für Open-Source-Software. Und drittens offene Schnittstellen und serviceorientierte Architekturen als Basis kollaborativer Prozesse in der Entwicklung, Testdurchführung und Integration. Die Entkopplung öffnet Raum für neuartige E/E-Architekturen. So können für eine Reduzierung der Variantenvielfalt bislang verteilte Funktionalitäten auf wenigen Fahrzeugrechnern gebündelt werden.

Es gibt viele Beispiele dafür, dass das Einbinden von Open-Source-Communities valide Vorteile hat. Anstelle des Make-or-Buy proprietärer Plattformtechnologien rückt eine offene, aber auf verbindlichen Standards und Frameworks basierende Technologieplattform, in deren Zentrum ein offener Fahrzeugstack steht. Dieser Ansatz ist in Verbindung mit einem herstellerneutralen Governance-Modell ein probates Gegenmittel gegen Marktfragmentierung und Vendor-Lock-Ins. Zudem setzt er Entwicklerressourcen frei. Initiativen wie die SDV-Arbeitsgruppe on Eclipse, die COVESA-Allianz oder das SOAFEE-Projekt belegen, dass der Open-Source-Ansatz auch im Automotive-Umfeld trägt.

Über Autosar Classic für Sicherheits- und harte Echtzeit-Steuergeräte hinaus birgt der junge Standard Autosar Adaptive Potenzial für Fahrzeuge mit zentralisierter E/E-Architektur. Wo herkömmliche ECUs, POSIX-basierte Steuergeräte mit Mikroprozessoren und zentrale Vehicle Computer für Rechenperformance sorgen, stellt Autosar Adaptive Dienste bereit, mit denen die Rechnercluster fahrzeugweite Funktionen ausführen. Zugleich steigt die Flexibilität, was die Option zum Einsatz standardisierter Middleware eröffnet: Ob Automotive Operating Systems (AOS), mit denen Automobilhersteller mit Blick auf das autonome Fahren eine solide Basis für die Entwicklung und den Betrieb fortschrittlicher Assistenzsysteme (ADAS) schaffen – oder ob LINUX-Lösungen für nicht sicherheitsrelevante Funktionen, deren Einsatz mit Methoden aus dem Cloud-Computing (etwa Containerisierung) umsetzbar ist.

Der Umzug auf standardisierte Plattformsoftware und Middleware ebnet auch neue Wege zur Standardisierung der Entwicklungs-Toolchains. Cloud-Technologie ist dafür von zentraler Bedeutung. Heute verbringen Softwareentwickler zwei Drittel ihrer Zeit damit, ihre Entwicklungsumgebung zu pflegen, Tests manuell durchzuführen und dokumentieren, ehe sie ihren Code veröffentlichen. Mit Cloud-basierten Toolchains und Kollaborationsplattformen ist ein Effizienzschub möglich: Die zeitaufwändige Pflege entfällt, standardisierte Schnittstellen erlauben freie Tool-Auswahl auch von Drittanbietern – und obendrein lassen sich die Entwicklungs-, Test- und Feedbackzyklen in der Cloud-basierten Entwicklungslandschaft weiter automatisieren, virtualisieren und durch Parallelisierung beschleunigen. Zudem lässt sich die Arbeit verteilter Entwicklungsteams in der Cloud synchronisieren, was länder- und firmenübergreifende Kollaborationen auf ein neues Niveau hebt.

Wo Software zum wettbewerbsrelevanten Differenzierungsmerkmal wird, vernetzte Fahrzeuge Rundumschutz vor Cyber-Risiken brauchen und OEMs jederzeit OTA-Updates in die Fahrzeuge ihrer Kunden übertragen möchten, ist Agilität gefragt. Methoden dafür finden sich im Cloud-Computing. So eröffnet die Kombination von Container-Isolierung mit entwicklerzentrierten Toolchains und Anwendungsprogrammierschnittstellen (APIs) die Möglichkeit, die ASIL-Logik verschiedener Sicherheitsklassen auf ECUs abzulösen – und durch Qualitätsmanagement (QM)-Umgebungen ohne Sicherheitsanforderungen auf Fahrzeugrechnern zu ersetzen.

Heterogene QM-Umgebungen haben große Vorteile: Da die Laufzeitumgebung in Kombination mit der zugrundeliegenden E/E- und Sicherheitsarchitektur dafür sorgt, dass sich das Fahrzeug immer im sicheren Zustand befindet und nur sicherheitsunkritische Funktionen ausgeführt werden, müssen Entwickler keine sicherheitsrelevanten Verpflichtungen mehr erfüllen. Und auf Basis der Containerisierung können Drittanbieter in die Anwendungsentwicklung einbezogen werden, die hierfür Entwicklungsansätze und Programmiersprachen ihrer Wahl nutzen können. Weder die Programmiersprachen C oder C++ noch automobilspezifisches Sicherheits-Know-how sind zwingend erforderlich, was den Bedarf an hochqualifizierten Spezialisten senkt.

Ein wichtiger Erfolgsfaktor für die agile Automotive-Softwareentwicklung ist es, begleitende Tests an die spezifischen Bedürfnisse von Funktionsentwicklern, Software-Integratoren sowie Sicherheits- und Testingenieuren anzupassen. Modularisierung und Standardisierung ebnen ihnen den Weg zu frei kombinierbaren, Cloud-basierten und automatisierten (Headless, CI-CD-CT) Testlösungen. Zugleich lassen sich virtualisierte Tests beliebig parallelisieren. Für die effiziente flexible Validierung und Verifizierung bieten sich innovative Lösungen zur Felddaten-Erfassung im „Shadow Mode“ an. Damit lassen sich neuentwickelte Funktionen und Algorithmen im realen Betrieb im abgeschirmten Modus ausführen. Sie greifen also nicht aktiv in die Steuerung ein, sondern laufen im Schatten mit und sammeln relevante Systemdaten. Dafür greifen sie auf konfigurierbare KI-basierte Filter und Triggerbedingungen zu. Letztere werden Over-The-Air (OTA) an eine Flotte von Fahrzeugen übertragen; ebenso gelangen die gesammelten Ausgabedaten zurück zum Cloud-Backend, wo Entwickler jederzeit Zugriff darauf haben.

Die skizzierte, standardisierte und zu großen Teilen Cloud-basierte Entwicklungslandschaft legt das Fundament für jene kontinuierliche Softwareentwicklung und -implementierung, die dem softwaredefinierten Fahrzeug als ewiger Jungbrunnen dient. Marktbeobachter erwarten pro Fahrzeug und Jahr hunderte Updates für Apps, Dienste und elektronische Funktionen. Dabei wird die nächste Generation flexibler OTA-Lösungen helfen. Cloud-native Paradigmen sorgen dafür, dass Updates für alle Fahrzeugdomänen (Linux/QNX OS, Autosar Classic/Adaptive Middleware & Anwendungen, Container/AAOS Framework & Anwendungen und ADAS/AD-Systeme) über einheitliche Schnittstellen effizient und sicher in die Fahrzeuge gelangen. Dieser Transfer muss natürlich auch in die Gegenrichtung funktionieren.

Durch die UNECE-Regelung Nr. 156 ist so ein funktionierendes Software Update Management System (SUMS) vorgeschrieben. Beim Implementieren der technischen und organisatorischen Voraussetzungen können sich OEMS künftig an der ISO/FDIS-Norm 24089 orientieren. Neben der rechtsverbindlichen UNECE-Regel gibt es einen weiteren Grund, die Datenkommunikation vernetzter Fahrzeuge auf eine solide Basis zu stellen: Cybersecurity. Um das SDV über seinen gesamten Lebenszyklus hinweg gegen Risiken abschirmen zu können, die zum Zeitpunkt seiner Entwicklung noch unbekannt waren, braucht es ein Immunsystem. Dieses setzt sich aus einem Intrusion Detection System, einem Vehicle Security Operations Center (VSOC) und der Möglichkeit zum schnellen OTA-Roll-Out von Gegenmaßnahmen auf die gesamte Flotte zusammen. Mit einer derart vernetzten Security-Organisation dient jeder Angriff auf ein einzelnes System oder Fahrzeug als Anlass, die Immunität der Gesamtflotte zu erhöhen. (av)