SDVs verändern die Fahrzeugentwicklung
Plattformunabhängiges Softwaredesign für neue E/E-Architekturen
Fortsetzung des Artikels von Teil 1
Die Software Factory
In der Vergangenheit fand die Entwicklung von Software für Kraftfahrzeuge vor deren Produktionsstart (Start of Production, SoP) statt. Sobald die Fahrzeugsoftware im Einsatz war, blieb sie in der Regel unverändert (Bild 5, oben links). Im Gegensatz dazu werden SDVs in regelmäßigen Abständen Updates (Bild 5, oben rechts) erhalten. Die Realisierung dieser Fähigkeit erfordert eine durchgängige und robuste Umgebung für die Entwicklung, Integration, Validierung und Freigabe von Software, die oft als »Software Factory« bezeichnet wird. Es handelt sich dabei um einen etablierten Ansatz, der in anderen Branchen sowie bei Infotainmentsystemen in der Automobilindustrie eingesetzt wird und sich dort bewährt hat.
Um Fahrzeugsoftware generell aktualisierbar zu machen, muss dieser Ansatz der Software Factory aber nun auf High-Integrity-Systeme mit sicherheitsrelevanter Software ausgeweitet werden, die Normen wie etwa ISO 26262 erfüllen muss. Das schafft jedoch einen Konflikt, denn die Zulassung sicherheitsrelevanter Software ist ein Prozess, der in der Regel Monate dauert und erst am Ende des Entwicklungsprozesses und vor dem SoP erfolgt.
Obwohl man sicherheitsrelevante Software nicht zu häufig aktualisieren möchte, kann dies aus Sicherheitsgründen wie z. B. Schwachstellen oder laufenden Cyberangriffen notwendig werden, die eine rasche Reaktion erfordern. Die Auslieferung von Software-Updates an vernetzte Fahrzeuge ist eine der großen Chancen, die durch SDVs entstehen und die es Ingenieuren ermöglicht, Fahrzeuge im Laufe der Zeit immer weiter zu verbessern. Die bestehende Software Factory muss darum so erweitert werden, dass sie den Anforderungen an Automobilsoftware mit hohen Integritätsanforderungen gerecht wird. Zwei Ansätze hierzu werden derzeit umgesetzt.
Der erste Ansatz ist einfach und basiert auf einer bereits weit verbreiteten Praxis, Test- und Verifikationsprozesse an den Anfang des Entwicklungsprozesses zu verlagern und sie so weit wie möglich zu automatisieren. Dies wird in Anlehnung an das V-Modell auch als Shift-Left bezeichnet (Bild 5, unten links) und setzt sich zunehmend durch. Dies bedeutet, dass das Testen und insbesondere die formale Verifikation von Code den Entwicklungsprozess durchgängig begleiten. Das beschleunigt die Homologation erheblich und reduziert den erforderlichen Arbeitsaufwand nach der Bereitstellung einer sicherheitskritischen Funktion.
Für die Validierung komplexer Fahrzeugfunktionen reicht diese Form des Shift-Left allein aber nicht aus. Die Software Factory muss zusätzlich virtuelle Darstellungen des Fahrzeugs, der Fahrzeugkomponenten und -teile sowie der verwendeten Rechnerplattfor- men in Form von Modellen enthalten (Bild 5, unten rechts). Zudem braucht es virtuelle Dar- stellungen der Fahrzeugumgebung wie 3D-Modelle, um sicherheitsrelevante Funktionen für Fahrerassistenzsysteme oder das automatisierte Fahren in virtuellen Szenarien zu testen. Mithilfe dieser Modelle lässt sich das Verhalten automatisiert in Si- mulationen vali- dieren, was etwa die Zahl der nötigen Testfahrten erheblich verringert. Automobilunternehmen und -partner melden häufig zurück, dass Software Factories nur aus Code bestehen sollten. Dies liegt vor allem daran, dass Softwareentwickler und IT-Mitarbeiter, die Software Factories aufbauen und mit ihnen arbeiten, heute in der Regel Funktionen ohne Sicherheitsrelevanz wie Infotainmentsysteme entwerfen, die nicht im Gesamtkontext des Fahrzeugs und seiner Umgebung validiert werden müssen. In dem herkömmlichen Prozess hat man bis nach der Codeentwicklung gewartet und dann Methoden wie Hardware-in-the-Loop(HiL)-Tests genutzt.
Wenn Ingenieure aber die Software Factory nicht nutzen, um bereits das Verhalten mithilfe von Modellen zu validieren, verpassen sie eine Chance für zusätzlichen Shift-Left. Daher müssen Modelle in die bestehende Automatisierungsstrukturen integriert werden, die typischerweise nicht nur aus Code bestehen können. Entscheidend ist, dass die Tools zur Ausführung dieser Modelle vollständig skriptfähig und automatisierbar sind. Dieser in der Regel als Infrastructure-as-Code (IaC) bezeichnete Ansatz reduziert den Administrationsaufwand für Software Factories erheblich. Ziel ist es, so selten wie möglich manuell eingreifen zu müssen.
Der Einsatz einer erweiterten Software Factory macht physische Tests zwar nicht völlig überflüssig, reduziert aber deren Anzahl erheblich und ermöglicht es Ingenieuren, den Aktualisierungszyklus von Monaten auf Wochen zu verkürzen. JTEKT, ein Automobilzulieferer für sicherheitskritische Systeme, hat erfolgreich gezeigt, dass ein solcher Ansatz realisierbar ist. Dort wurde eine um Model-Based Design erweiterte Software Factory eingerichtet, welche die Erfüllung der ISO 26262 gestattet. Das Ergänzen von Modellen zusammen mit Tools, die bereits für die Validierung sicherheitsrelevanter Funktionen verwendet worden sind, bringt die Software Factory somit einen Schritt näher an die von SDVs gestellten Anforderungen.
Jobangebote+ passend zum Thema
Die DevOps-Schleife schließen
Für Automobilingenieure galt bisher, dass ihre Entwicklungsarbeit an einem Fahrzeug mit dessen SoP endete. Vernetzte Fahrzeuge haben aber den Vorteil, dass sie ständig Daten generieren, die – neben Flottenmanagement und Fahrzeugdiensten – genutzt werden können, um die im Betrieb befindliche Fahrzeugflotte mit den Entwicklungsprozessen zu verknüpfen.
Die Betrachtung und Optimierung des Zusammenspiels von Entwicklung und Betrieb wird als DevOps bezeichnet. MathWorks sieht seine Aufgabe darin, den gesamten DevOps-Kreislauf aus dieser für den Automobilbau neuen Perspektive zu unterstützen. Das Beispiel der Reaktion auf einen Zwischenfall veranschaulicht die Prozesse, die nach einem auftretenden Softwareproblem in der Flotte bis hin zu einem Update zur Problembehebung und dessen flottenweiter Auslieferung ablaufen (Bild 6).
Angenommen es kommt in einer Fahrzeugflotte zu einem Zwischenfall (1). Dieser muss gemeldet und – was entscheidender ist – Daten über den Zwischenfall müssen an die Entwickler übermittelt werden (2). Einem Ingenieur helfen aber Datenkolonnen wenig, und es braucht mehr als nur Diagramme, um diese Daten richtig interpretieren zu können. Um zu verstehen, was passiert ist und warum, eignet sich viel besser eine erneute Simulation des Vorfalls anhand von Modellen – die gleichen, die in der Softwarefabrik zur Validierung verwendet werden (3).
Die Ingenieure können damit eine Situation in einer virtuellen Welt nachstellen, alle Sensoren-, Steuerungs- und Umweltdaten im Blick behalten und so die Gründe für das Problem nachvollziehen. Je nach Fall kann dies die Verarbeitung riesiger Mengen von Flottendaten erfordern, wofür sich am besten die von Cloud-Plattformen angebotenen elastischen Ressourcen eignen. In der Simulation gewonnene Erkenntnisse werden anschließend genutzt, um Rückschlüsse auf die Grundursache des Vorfalls zu ziehen und geeignete Gegenmaßnahmen zu ergreifen – in der Regel in Form eines Software-Updates.
Anschließend kann eine Abhängigkeitsanalyse hilfreich sein (4), etwa unter Verwendung von Architekturmodellen, auf deren Grundlage nun das Update entwickelt wird (5). Die erforderlichen Komponenten werden dann mit der bestehenden Software Factory neu erstellt (6). Da Updates zu unerwarteten Problemen führen können, ist es wichtig, die betroffene Funktionalität erneut im Fahrzeugkontext zu simulieren, um sicherzustellen, dass alles weiterhin wie vorgesehen funktioniert (7).
Diese abschließende Validierung erfordert eine Validierung des Verhaltens auf den im Fahrzeug vorhandenen Rechenplattformen vor der Übertragung des Updates an eine bestehende Flotte. Angesichts der Vielfalt der Fahrzeuge und der Notwendigkeit, so viel wie möglich zu automatisieren, müssen die Verhaltensweisen der Rechnerplattformen mit der darauf laufenden Software ebenfalls als Modelle – so genannte virtuelle Steuergeräte (vECUs) – in die Software Factory integriert werden.
Da der Rechenaufwand für die Ausführung von Modellen mit ihrem Detaillierungsgrad zunimmt, wurden in der Automobilindustrie Niveaus von vECUs festgelegt, die miteinander kombiniert werden, um einen Kompromiss zwischen Simulationsgeschwindigkeit und Detailtiefe zu finden. Abschließend wird das Update auf die Fahrzeuge der Flotte aufgespielt, wobei nur die notwendigen Teile und nicht das gesamte System oder gar die gesamte Fahrzeugsoftware aktualisiert werden (8).
Ein aktuelles Beispiel für die Erprobung des vorgestellten DevOps-Zyklus ist eine Kooperation mit Elektrobit und AWS Automotive (Bild 7). Dabei werden elastische AWS-Cloud-Ressourcen und MathWorks-Tools für die Datenanbindung und die Simulation (oben links), die Integration und das Testen (unten links) und schließlich das Testen der sicherheitsrelevanten Funktionen auf einer von Elektrobit bereitgestellten Level 3 vECU (unten rechts) genutzt.
Plattformunabhängiges Design
Für die neuen Technologien und E/E-Architekturen von SDVs ermöglicht ein plattformunabhängiges Softwaredesign die Verlagerung, die Wiederver-wendung und den Schutz des geistigen Eigentums bestehender Software und schöpft gleichzeitig die Leistung neuer Rechenplattformen voll aus.
Die Entwicklungsprozesse, einschließlich Verifikation und Validierung, werden so weit wie möglich automatisiert, sodass Software Factories entstehen. Solche Plattformen können erweitert werden, um die höheren Anforderungen in Bezug auf funktionale Sicherheit und Cybersicherheit für Automobilsoftware zu erfüllen.
Vernetzte Fahrzeuge bieten die Chance, Flottendaten zu nutzen und Software-Updates an die Fahrzeuge zu senden. Die Betrachtung des gesamten Kreislaufs vom Betrieb bis zur Entwicklung (DevOps) kann den Prozess von einem Zwischenfall in der Flotte hin zu einem verifizierten und validierten Update, das das Problem behebt, erheblich effizienter gestalten.
Die Transformation zum SDV erfordert ein Neudenken der Zusammenarbeit von OEMs, Zulieferern und Softwarefirmen, um die Komplexität der Entwicklung einerseits und die Interessen hinsichtlich offener und geschlossener Software und Plattformen andererseits adressieren zu können.
Literatur
[1] SoC Blockset Support Package for
Infineon Aurix Microcontrollers:
https://www.mathworks.com/hardwaresupport/infineon-aurix-soc.html
Der Autor
Dr. Hans Martin Ritt
promovierte an der Rheinisch-Westfälischen Technischen Hochschule Aachen (RWTH) zum Dr.-Ing. in Regelungstechnik. In seiner ersten Industrieposition als Solution Manager bei Ericsson war er an der Einführung der damals neuen Mobilfunktechnologie 3G und dem Start eines der ersten 3G-Netze in Deutschland beteiligt. Nach verschiedenen Positionen bei MathWorks leitet er nun das Application Engineering in Central-EMEA. Sein Team hilft Kunden, MathWorks-Technologie erfolgreich einzusetzen, um ihre Entwicklungsprozesse zu verbessern. Gleichzeitig nutzt das Team die Erfahrungen aus diesen Kundenprojekten, um die MathWorks-Produktentwicklung zu unterstützen.
- Plattformunabhängiges Softwaredesign für neue E/E-Architekturen
- Die Software Factory
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Serverleistung in Kofferraum und Labor
Anforderungen an Hardwareplattformen für ADAS- und AD-Tests
Kooperation für die Formula Student
Mit Elektronik an die Pole-Position
SmartCode von Tasking
Einfachere Entwicklung KI-basierter Automotive-Anwendungen
Vereinfachte Laufzeitanalyse von ECUs
Neues Timing-Bundle von Vector und PLS
Erhältlich bei Beck Elektronik
FAKRA-Steckverbinder von BJD für Automobilanwendungen
Robotik Challenge 2025
Die vollautomatisierte Leitungssatzfertigung durch Roboter
Hundertprozentige Übernahme von Öhlins
Brembo kauft Hersteller von Hochleistungs-Fahrwerktechnik
Microchip erweitert Portfolio fürs SDV
Multi-Gigabit-Ethernet-Switches plus Ethernet-Switch-Software
