Software Defined Vehicle Warum die Elektronikarchitektur das neue Schlachtfeld ist

Anbieter zum Thema

Parametric Technology GmbH

MicroConsult Academy GmbH

emlix GmbH

RTI Real-Time Innovations

Das Software-Defined Vehicle stellt die klassische Fahrzeugentwicklung auf den Kopf: Nicht mehr einzelne Steuergeräte, sondern vernetzte, zentralisierte Elektronikarchitekturen bilden die Grundlage für neue Funktionen und kontinuierliche Software-Updates. Damit wächst der Druck auf Entwicklungsprozesse, Datenmanagement und Variantenbeherrschung.

Das Auto wird zum fahrenden Computer. Diese Aussage ist inzwischen so selbstverständlich geworden, dass sie die Komplexität dahinter eher verdeckt als erklärt.. Und genau das ist das Problem: Während die Branche über Software-Defined Vehicles (SDV) redet, kämpfen Entwicklungsteams täglich mit einer Realität, die dieser Vision noch weit hinterherhinkt. Steuergeräte sprechen nicht miteinander, Anforderungen werden in Excel-Tabellen verwaltet, und Softwarestände sind für niemanden mehr vollständig nachvollziehbar.

Der eigentliche Engpass ist die Electrical/Electronic Architecture, kurz E/E-Architektur, auf der die Software läuft, und die Art, wie sie entwickelt wird. Sie entscheidet darüber, ob Funktionen verteilt nebeneinander existieren oder als vernetztes, updatefähiges System zusammenspielen können.

Von verteilter Hardware zu zentralisierten Plattformen

Jahrzehntelang folgte die Fahrzeugentwicklung einem bewährten Muster. Jede Funktion bekam ihr eigenes Steuergerät (ECU), egal ob Fensterheber oder Antriebssteuerung. Alles war separat, alles in Hardware gegossen. Das führte dazu, dass moderne Fahrzeuge heute bis zu 150 ECUs enthalten, die durch kilometerlange Kabelbäume miteinander verbunden sind. Dieses Modell trägt die wachsende Komplexität jedoch nicht mehr. Neue Fahrzeugfunktionen lassen sich nicht mehr einfach durch ein weiteres Steuergerät abbilden, während gleichzeitig die Anforderungen an

Over-the-Air-Updates und funktionale Sicherheit steigen.

Die Antwort der Industrie auf diese wachsenden Anforderungen ist die Zentralisierung: Hochleistungs-Compute-Plattformen übernehmen Aufgaben, die früher auf Dutzende ECUs verteilt waren, Zonenarchitekturen ersetzen funktionale Domänen, und Software wird soweit möglich von der Hardware entkoppelt. In der Praxis ist diese Transformation jedoch ein tiefgreifender Einschnitt in bestehende Entwicklungsprozesse. Wer hier keine durchgängige Datenbasis hat, verliert den Überblick, bevor das Fahrzeug die Straße sieht.

Das eigentliche Problem: Fragmentierte Entwicklungslandschaften

Etablierte OEMs und Tier-1-Zulieferer arbeiten mit komplexen, über Jahre entstandenen Tool-Landschaften, in denen Anforderungen, Systemarchitektur und Softwareentwicklung in voneinander getrennten Systemen leben. Zwischen diesen Welten entstehen manuelle Übergaben und Schnittstellendokumente, die im schlimmsten Fall Inkonsistenzen erzeugen, die erst im Fahrzeugtest sichtbar werden.

Im Kern ist das ein Architekturproblem. Solange Application Lifecycle Management (ALM) und Product Lifecycle Management (PLM) nicht durchgängig miteinander verbunden sind, entstehen zwangsläufig Lücken. Ändert sich eine Anforderung, bleiben betroffene Systemkomponenten oft unerkannt, und aktualisierte Softwarestände verlieren ihre Rückverfolgbarkeit zur ursprünglichen Anforderung. Für sicherheitskritische Systeme ist das keine Kleinigkeit. ISO 26262 und ASPICE verlangen lückenlose Nachvollziehbarkeit, und wer diese mit manuellen Prozessen sicherstellen will, zahlt einen hohen Preis in Zeit und Fehlerrisiko.

Durchgängiges Engineering als Grundlage

Um diese Fragmentierung zu überwinden, benötigen OEMs und Tier-1-Zulieferer eine durchgängige digitale Datenbasis, die als Single Source of Truth fungiert und Anforderungen, Systemarchitektur und Validierungsnachweise miteinander verknüpft. Nur so lassen sich Medienbrüche zwischen ALM und PLM vermeiden und manuelle Übergaben zwischen Disziplinen reduzieren.

Model-Based Systems Engineering (MBSE) ist dabei das Werkzeug, mit dem Entwicklungsteams Systemverhalten beschreiben, Abhängigkeiten sichtbar machen und Änderungsauswirkungen frühzeitig bewerten können. Wer ein Systemmodell pflegt, das mit Anforderungen und Softwarestand synchronisiert ist, kann eine Frage beantworten, die in klassischen Prozessen oft offen bleibt: nämlich was passiert, wenn sich eine Anforderung ändert.

Im Kontext des Software-Defined Vehicle ist das besonders relevant, denn Over-the-Air-Updates bedeuten, dass Software nach dem Serienstart weiterentwickelt wird. Wer dann keine durchgängige Traceability hat, kann nicht zuverlässig bewerten, ob ein Update die funktionale Sicherheit eines Systems beeinflusst.

Variantenmanagement: Die unterschätzte Herausforderung

Das Variantenmanagement bleibt in der SDV-Diskussion häufig im Hintergrund, dabei ist es eine der komplexesten Herausforderungen der Fahrzeugentwicklung. Ein modernes Fahrzeugprogramm umfasst Hunderte von Varianten mit unterschiedlichen Märkten, Ausstattungslinien und Antriebskonzepten, und jede Variante hat ihre eigene Kombination aus Hardware und Software. In fragmentierten Entwicklungslandschaften bedeutet das, dass Anforderungen, Architekturen und Softwarestände für jede Variante separat gepflegt werden. Der Aufwand skaliert linear mit der Variantenanzahl, und Fehler tun es auch.

Durchgängiges Engineering löst dieses Problem durch Konfigurationsmanagement auf Modellebene. Varianten werden als Konfigurationen eines gemeinsamen Systemmodells behandelt, sodass Änderungen einmal vorgenommen und kontrolliert in alle betroffenen Varianten übertragen werden.

Was das für Entwicklungsteams bedeutet

Die Transformation zur zentralisierten E/E-Architektur ist kein Projekt, das man einmal abschließt. Sie ist ein kontinuierlicher Prozess, der die Arbeitsweise und Entscheidungsfindung von Teams aktiv verändert. Wer heute noch Anforderungen manuell verwaltet und Architekturentscheidungen ohne durchgängige Dokumentation trifft, wird morgen nicht mehr nachvollziehen können, warum Entscheidungen für bestimmte Systeme getroffen wurden. Automatisiertes Änderungsmanagement entwickelt sich dementsprechend von einer reinen Komfortfunktion zu einer Notwendigkeit, denn bei der Komplexität moderner Fahrzeugprogramme sind manuelle Impact-Analysen schlicht nicht mehr skalierbar. Das gilt auch für die Integration von ALM und PLM: Wer beide Welten weiterhin getrennt betreibt, baut Silos auf, die im SDV-Kontext früher oder später zum Problem werden.

Was das SDV wirklich braucht

Das Software-Defined Vehicle ist vor allem eine Frage der Entwicklungsinfrastruktur. Wer die E/E-Architektur transformiert, ohne gleichzeitig Entwicklungsprozesse und Datenbasis zu modernisieren, schafft neue Komplexität anstatt alte zu lösen. MBSE, integriertes ALM und PLM und Variantenmanagement sind erprobte Ansätze, die in der Praxis bereits Wirkung zeigen: Sie schaffen Transparenz über Anforderungen, Architekturen und Softwarestände, reduzieren manuelle Übergaben und machen Varianten beherrschbar. Die Herausforderung liegt in ihrer konsequenten Umsetzung über Disziplinen und Organisationsgrenzen hinweg. Wer das schafft, hat eine belastbare Grundlage für das Software-Defined Vehicle. Wer es nicht schafft, wird feststellen, dass die nächste Softwaregeneration auf denselben Problemen aufbaut wie die letzte.  (sg)

* Michele Del Mondo ist Global Advisor Automotive bei PTC

(ID:50946789)