Ein einheitlicher Ansatz für die Feature-Entwicklung von SDV-verteilten Architekturen

Nutzung eines funktionsorientierten Workflows zur Verknüpfung von Anforderungen, Architektur, Simulation und Bereitstellung.

Zusammenfassung

• Sie können einen funktionsorientierten Workflow verwenden, um Anforderungen, Architekturentscheidungen und einsetzbare Software für die softwaredefinierte Fahrzeugentwicklung zu verknüpfen.
• Die Vereinheitlichung von modellbasierter Systementwicklung und modellbasiertem Design hilft Ihnen, verteilte Funktionen frühzeitig mittels Simulation zu validieren, bevor die Integration in das Gesamtfahrzeug erfolgt.
• Die durchgängige Rückverfolgbarkeit während der gesamten Feature-Entwicklung, einschließlich Anforderungen, Architektur, Design, Implementierung und Tests, trägt zu einem effizienten Änderungsmanagement bei.
• Anhand eines Beispiels zur Ladeklappensteuerung wird gezeigt, wie der Workflow über einen Zentralrechner, einen Zonenregler und ein Edge-Steuergerät skaliert.

Wie können SDV-Entwicklungsteams frühzeitig die richtigen Architektur- und Softwareentscheidungen treffen und diese kontinuierlich validieren, wenn sich die Funktionen über zentrale Computer, Zonensteuerungen und Edge-Geräte erstrecken und serviceorientierte und signalbasierte Architekturen über komplexe Integrationsgrenzen hinweg miteinander verschmelzen?

SDVs definieren die Automobiltechnik neu – und das nicht nur durch mehr Code. Sie gestalten sie um. Wo Die Software läuft, Wie Die Merkmale setzen sich zusammen, und Was “Was ”Integration“ wirklich bedeutet, ist, dass die Funktionen über verschiedene Rechenbereiche, Kommunikationsprotokolle und sogar unterschiedliche Organisationen hinwegreichen. Daher benötigen Teams Ansätze, die von Anfang an dafür sorgen, dass Architekturabsicht und Softwareverhalten übereinstimmen.

Diese architektonische Freiheit hat jedoch ihren Preis: Es gibt mehr Schnittstellen, mehr Zeitabläufe, mehr Fehlermöglichkeiten und mehr Wege, wie kleine Abweichungen erst spät sichtbar werden können, insbesondere wenn Fahrzeuge, Zulieferer und Zeitpläne bereits feststehen. In diesem Umfeld müssen System- und Softwareentwickler frühzeitig die richtigen Entscheidungen treffen und diese kontinuierlich mithilfe von Modellen und Simulationen validieren.

Um Unternehmen bei dieser Herausforderung zu unterstützen, vereinen KPIT und MathWorks bewährte Methoden, umfassendes Fachwissen im Automobilbereich und eine integrierte Toolchain, die Systemabsichten mit ausführbaren Modellen verknüpft. Das Ergebnis ist ein durchgängiger, nachvollziehbarer Workflow, der frühzeitige Architektur- und Softwareentscheidungen sowie die kontinuierliche Validierung durch Simulation unterstützt und die Absichten der Stakeholder (als zentrale Informationsquelle) mit Architekturentscheidungen, einsetzbarer Software und Verifizierungsnachweisen verbindet.

Wichtigste Herausforderungen bei verteilten SDV-Funktionen

Die Entwicklung von SDV-Funktionen scheitert selten an “schlechtem Code” eines einzelnen Teams. Sie scheitert vielmehr daran, dass die Funktion die Grenzen von Steuergeräten überschreitet, serviceorientierte und signalbasierte Interaktionen vermischt und Lücken zwischen Design und Implementierung aufdeckt. Diese Lücken bleiben oft bis zur späten Integration verborgen – daher entscheiden die folgenden Herausforderungen häufig darüber, ob ein Programm komplexe Funktionen schnell und zuverlässig bereitstellen kann:

• Unklare Anforderungen im großen Maßstab: Funktionale und nichtfunktionale Anforderungen müssen Verteilung, Zeitplanung, Teilausfälle, Sicherheit und Cybersicherheit berücksichtigen.
• Architekturentscheidungen wirken sich nachgelagert aus: Service- versus Signalwahl und Steuergerätezuordnung steuern Schnittstellen, Softwarepartitionierung und Verifizierungsaufwand.
• Teamübergreifende Abstimmung: Multidomänen-Teams benötigen gemeinsam genutzte, nachvollziehbare Modelle, um Nacharbeiten im Nachhinein zu vermeiden.
• Toolchain-Fragmentierung: Unverbundene Tools behindern die Rückverfolgbarkeit und die Validierung im “Shift-Left”-Verfahren; die virtuelle Integration erfordert konsistente Architektur- und Verhaltensmodelle.

Ein einheitlicher Workflow für modellbasierte Systementwicklung und modellbasiertes Design

Dieser Artikel stellt einen funktionsorientierten Entwicklungsansatz vor, der modellbasierte Systementwicklung (System-/Funktionsabsicht, Anforderungen und Architektur) mit modellbasiertem Design (ausführbare Softwaremodelle, Simulation und Codegenerierung) vereint. Der Workflow folgt einem systematischen Top-Down-Ansatz für die Architektur- und Anforderungsentwicklung, wobei in jeder Phase der jeweils passende Abstraktionsgrad angewendet wird. Er eignet sich zur Entwicklung von SDV-Funktionen, die heterogene Steuergeräte umfassen und serviceorientierte sowie signalbasierte Interaktionen kombinieren.

Dieser Ansatz beschleunigt die Bereitstellung neuer Funktionen durch die Integration und Validierung verteilter Funktionen in einer simulierten Umgebung mithilfe vernetzter Steuergeräte- und Softwarekomponentenmodelle. Er verbessert zudem die durchgängige Rückverfolgbarkeit für Wirkungsanalysen und die Einhaltung von Vorschriften und reduziert Nacharbeiten in späten Phasen bei der Bereitstellung auf zentralen, zonalen und Edge-Steuergeräten.

In der Praxis benötigen Teams eine Möglichkeit, Architekturentscheidungen frühzeitig testbar zu machen: Kann diese Funktion die Timing-Anforderungen in verschiedenen Zonen erfüllen, Teilausfälle überstehen, Sicherheits- und Cybersicherheitsauflagen erfüllen und dennoch konsistent auf AUTOSAR® Classic/Adaptive-Zielen implementiert werden? Ein einheitlicher modellbasierter Systementwicklungs- und modellbasierter Design-Workflow macht diese Fragen explizit – und beantwortbar – vor der Hardware- und Fahrzeugintegration.

Lassen Sie uns die wichtigsten Arbeitsschritte des funktionsorientierten Ansatzes durchgehen:

• Funktionsumfang: Die Bedürfnisse der Stakeholder erfassen, Funktionsgrenzen, Akteure und Abhängigkeiten definieren.
• Anforderungen: Anwendungsfälle und Verhaltensweisen definieren, Systemanforderungen (funktionale und nichtfunktionale) mit klaren Akzeptanzkriterien ableiten.
• Systemarchitektur: Funktionale Architektur (Funktionen und Interaktionen), plattformunabhängige Subsystemidentifizierung und -architektur sowie plattformabhängige Systemarchitektur (Steuergeräte/Netzwerke und Service- versus Signalentscheidungen) erstellen und validieren.
• Softwarearchitektur: Ableitung von Softwareanforderungen und Softwarearchitektur pro Steuergerät (HPC/Zone/Edge), abgestimmt auf AUTOSAR Classic/Adaptive oder kundenspezifische Anforderungen.
• Detailliertes Software-Design: Entwickeln Sie ausführbare Modelle für Algorithmen und Komponentenverhalten und nutzen Sie nach Möglichkeit vorhandene Ressourcen wieder.
• Funktionale Verifizierung: Führen Sie Modell-in-the-Loop-/Closed-Loop-Simulationen durch, um das Verhalten zu validieren, bevor die Hardware verfügbar ist.
• Codegenerierung und -integration: Generieren Sie produktionsreifen AUTOSAR Classic/Adaptive- oder benutzerdefinierten Code mit nahtloser Integration in CI- und Verifizierungsworkflows.

Dies sind die wichtigsten Vorteile, die sich durch die Befolgung des vorgeschlagenen Ansatzes ergeben:

• Früherkennung von Mängeln: Ausführbare Modelle und Simulationen decken Integrations- und Timingprobleme vor der Hardware- und Komplettfahrzeugintegration auf.
• Schnellere Iterationen: Virtuelle Integrationstests reduzieren Nachbearbeitungszyklen und beschleunigen die Funktionsbereitstellung.
• Nachvollziehbare Entwicklung: Durch konsistente Verknüpfungen zwischen den Artefakten können Abdeckungsprüfungen durchgeführt und die Auswirkungen bei Änderungen der Anforderungen effizient analysiert werden.
• Wiederverwendbare Architekturelemente: Die logische Architektur bietet eine plattformunabhängige Referenz für wiederverwendbare Systeme in verschiedenen Fahrzeugprogrammen.
• Einsatzbereite Ausgaben: Die Softwarearchitektur und die Codegenerierung sind auf AUTOSAR Classic/Adaptive und gemischte SOA/Signal-Kommunikation abgestimmt.

Im weiteren Verlauf des Artikels werden wir den Ansatz anhand eines realen Anwendungsfalls demonstrieren.

Beispiel: Entwicklung einer Ladeklappen-Verwaltungsfunktion

Um diesen Workflow zu veranschaulichen, betrachten wir ein konkretes Beispiel, das Benutzer, Hardware, Netzwerk und Sicherheitsanforderungen betrifft: die Ladeklappensteuerung eines Elektrofahrzeugs. Dieses Beispiel zeigt, wie ein funktionsorientierter Prozess von der Abgrenzung und den Anforderungen über die Architekturzuordnung und Simulation bis hin zur Generierung des Produktionscodes reicht, ohne dabei die Nachvollziehbarkeit zu verlieren.

Ein Klappenmanagementsystem steuert die Ladeklappe des Fahrzeugs (Abbildung 1). Es gleicht kontinuierlich die physikalischen Gegebenheiten (z. B. Positionserfassung, Aktuatorstatus und Verriegelungsrückmeldung) mit dem Ladekontext (z. B. Fahrzeugzustand, Status des Onboard-Ladegeräts und Signale der Ladestation) ab, um zu entscheiden, wann die Klappe geöffnet, geschlossen oder verriegelt werden soll. Anschließend sendet das System Statusaktualisierungen und Warnungen an den Fahrer und andere Fahrzeugfunktionen. Durch die Integration von Sensorik, Aktorik und Steuergerätekoordination bietet das Klappenmanagementsystem ein kleines, aber realistisches Modell für die Entwicklung umfassenderer verteilter Funktionen für autonomes Fahren.

Abbildung 1. Ladeklappe des Fahrzeugs.

Funktionsumfang

Wir definieren die Feature-Grenzen (Akteure, Eingaben/Ausgaben und Abhängigkeiten), um einen gemeinsamen Rahmen festzulegen und die Anforderungserhebung und -analyse zu unterstützen.

In diesem Beispiel gehen wir davon aus, dass das Fahrzeug eine bestehende elektrische/elektronische (E/E) Zonenarchitektur nutzt, die aus einem leistungsstarken Zentralrechner (HPC), einem Zonen-Steuergerät, das auch als Gateway dient, und Edge-Steuergeräten besteht, die für die Echtzeit-Erfassung und -Aktorik zuständig sind.

In diesem Schritt führen wir eine Wirkungsanalyse durch und verwenden System Composer™, um ein Funktionsgrenzendiagramm zu erstellen. Dieses Diagramm erfasst die vom Klappenmanagement betroffenen Funktionen sowie die zwischen ihnen ausgetauschten Informationen. Die Grenzansicht verdeutlicht, welche Fahrzeugfunktionen und externen Akteure mit dem Klappenmanagement interagieren und welche Informationen ausgetauscht werden (Abbildung 2).

Abbildung 2. Merkmalsgrenzendiagramm.

Funktionsebene
Wir erfassen die wichtigsten Anwendungsfälle und leiten das Funktionsverhalten mithilfe eines Anwendungsfalldiagramms ab. Anschließend übersetzen wir dieses Verhalten in klare Systemanforderungen. Wir identifizieren zwei Anwendungsfälle: “Ladevorgang starten” und “Ladevorgang beenden” (Abbildung 3).

Abbildung 3. Anwendungsfalldiagramm.

Nachdem die beiden Anwendungsfälle identifiziert wurden, werden im nächsten Schritt die verschiedenen Aktivitäten definiert, die das Feature in jedem Anwendungsfall ausführt. Dies hilft, das Verhalten des Features zu beschreiben und erste Systemanforderungen für das Flap-Management zu erfassen. Anschließend erstellen wir mit System Composer Aktivitätsdiagramme (Abbildung 4).

Abbildung 4. Aktivitätsdiagramm zur Veranschaulichung der Ladeklappenbetätigung.

Aufbauend auf der vorangegangenen Analyse und den Diagrammen können wir nun mithilfe des Anforderungseditors, der Teil der Requirements Toolbox™ ist (Abbildung 5), die Systemanforderungen erstellen. Wir haben Anforderungen, die sich auf die Vorgänge beziehen, wie z. B. das Öffnen und Schließen der Klappe und die Meldung des Klappenstatus.

Abbildung 5. Systemanforderungen im Anforderungseditor.

Als Nächstes erstellen wir eine funktionale Architektur und ordnen Anforderungen Funktionen zu, um die Nachvollziehbarkeit zu gewährleisten. Dies beinhaltet die Definition von:

• Systemfunktionen: technische Funktionseinheiten, die gemeinsam das Merkmal realisieren
• Interaktionen: wie diese Funktionen kommunizieren und zusammenarbeiten

Auf Grundlage der Analyse der Systemanforderungen unterteilen wir die Ladeklappenfunktion in vier Funktionen (Abbildung 6):

• Messen Sie den Strom der Ladebuchse
• Klappenstatus abrufen und Benutzer benachrichtigen
• Klappe schließen
• Klappe öffnen

Abbildung 6. Funktionale Architektur.

Im Rahmen der Definition der funktionalen Architektur ordnen wir jede Systemanforderung der/den für ihre Erfüllung zuständigen Funktion(en) und gegebenenfalls der Interaktion zu, die die benötigten Informationen überträgt. Diese Zuordnung stellt sicher, dass jede Anforderung durch Designelemente abgedeckt ist, macht Lücken und Überschneidungen frühzeitig sichtbar und gewährleistet die Rückverfolgbarkeit von Anforderungen zu Funktionen für den nachfolgenden logischen/physikalischen Entwurf und die Verifizierung. Praktisch lässt sich diese Zuordnung effizient per Drag & Drop von Anforderungen auf System Composer-Komponenten durchführen (Abbildung 7).

Abbildung 7. Zuordnung der Systemanforderungen zur funktionalen Architektur.

Plattformunabhängige Subsystemidentifizierung und Architektur

Wir ordnen Funktionen logischen Subsystemen zu und definieren die logischen Schnittstellen zwischen ihnen, um eine wiederverwendbare, plattformunabhängige Architektursicht zu erstellen (Abbildung 8):

• Ein Ladeschnittstellen-Subsystem, das für das Öffnen und Schließen der Klappe sowie für die Meldung des Klappenstatus zuständig ist.
• Ein Ladekontrollsubsystem, das für die Koordination der Anfragen von der Kommunikationsschnittstelle und die Verwaltung aller Ladevorgänge zuständig ist.
• Ein Ladekommunikationssubsystem, das die Kommunikation mit dem Benutzer und dem Rest des Systems verwaltet.

Abbildung 8. Detailansicht der plattformunabhängigen Architektur.

Plattformabhängige Systemarchitektur

Nun ordnen wir die logischen Subsysteme einer Ziel-E/E-Architektur zu (z. B. Edge-ECU, Zonen-Controller und Zentralrechner/HPC) und definieren die Hauptschnittstellen, einschließlich derjenigen Interaktionen, die als Dienste oder Signale implementiert werden.

Sobald wir die verschiedenen Komponenten identifiziert haben, können wir in System Composer ein Systemarchitekturdiagramm erstellen, das die Komponentengrenzen und die Informationen hervorhebt, die die Komponenten austauschen müssen, um die Klappenverwaltungsfunktion zu implementieren (Abbildung 9).

Abbildung 9. Systemarchitekturdiagramm.

Softwarearchitektur, Simulation und Codegenerierung

Aus den Systemanforderungen und der Systemarchitektur leiten wir die Softwareanforderungen und die Architektur pro Steuergerät (HPC, Zonen-, Edge-Knoten) ab und verfeinern diese zu einsetzbaren Softwarekomponenten. Auf dem HPC wird die Funktion in Dienste und Anwendungen (z. B. AUTOSAR Adaptive, falls zutreffend) zerlegt, während Zonen-/Edge-Knoten zeitkritische Sensor-/Aktorfunktionen (z. B. AUTOSAR Classic oder Äquivalent) hosten. Schnittstellen (Dienste, Signale und Datentypen) werden konsistent von der physischen Architektur in Software-Ports und -Konnektoren übertragen. Dies ermöglicht frühzeitige Konsistenzprüfungen, die Modellierung des ausführbaren Verhaltens und die Integration von Simulations-Hooks (für MIL/SIL- und Closed-Loop-Simulationen), bevor die Zielhardware verfügbar ist.

Zunächst erstellen wir die Softwarearchitektur auf oberster Ebene für HPC-, zonale ECU- und Edge-ECU-Kompositionen, die mit der Systemarchitektur verknüpft sind (Abbildung 10).

Abbildung 10. Übersicht der Softwarearchitektur auf oberster Ebene.

Wir haben Softwarekomponenten für jede Architekturkomposition innerhalb der Architekturmodellierungsoberfläche in System Composer definiert und modelliert. Die HPC-Komposition umfasst drei AUTOSAR Adaptive Servicekomponenten, die in Simulink® unter Verwendung eines SOA-Paradigmas implementiert wurden (Abbildung 11).

Abbildung 11. Ansicht der HPC-Softwarekomponenten.

Sobald die Implementierung der Funktion in den drei Steuergeräten modelliert ist, kann ein geschlossenes Simulationsmodell erstellt werden, das die Steuergeräte mit einem Systemmodell der Klappe verbindet – einschließlich Modellen des Stromsensors, des Positionssensors und des Aktuators – und so eine schnelle Überprüfung des Funktionsverhaltens unter realistischen Bedingungen ermöglicht. Beispielsweise kann die Simulation genutzt werden, um zu bewerten, wie das System auf eine Benutzeranforderung zum Öffnen der Klappe bei unterschiedlichen Fahrzeuggeschwindigkeiten reagiert (Abbildung 12).

Abbildung 12. Simulation eines geschlossenen Regelkreises einer Ladeklappe.

Nach Abschluss der Verifizierung besteht der nächste Schritt im Workflow darin, mit Embedded Coder® produktionsreifen Code für die Integration und den Einsatz zu generieren (Abbildung 13). Simulink bietet standardmäßig Unterstützung für die Generierung von AUTOSAR Classic- und AUTOSAR Adaptive-konformem Code und ermöglicht so die weitere Integration und den Einsatz.

Abbildung 13. Generierung von C++-Produktionscode für die Flap-Request-Arbitrator-Software.

Wird eine neue Anforderung eingeführt, kann diese auf Systemebene erfasst und einer Auswirkungsanalyse unterzogen werden, um betroffene Elemente zu identifizieren. Die resultierenden Änderungen werden visualisiert und an die relevanten System- und Softwareschnittstellen weitergegeben. Anschließend wird der Workflow iterativ angepasst, um den sich ändernden Anforderungen gerecht zu werden. Dieser Prozess wird durch durchgängige Rückverfolgbarkeit ermöglicht, wobei das Rückverfolgbarkeitsdiagramm (Abbildung 14) zur Verwaltung dynamischer Änderungen während des gesamten SDV-Entwicklungszyklus dient.

Abbildung 14. Rückverfolgbarkeitsdiagramm zur Verdeutlichung der Auswirkungen auf verschiedenen Ebenen.

Migration von Altanwendungen

Über die Entwicklung neuer Funktionen hinaus unterstützt derselbe integrierte Workflow auch die systematische Migration bestehender, signalbasierter Funktionen hin zu serviceorientierten, verteilten Softwarearchitekturen. Konkret lassen sich bestehende Funktionen, die ursprünglich als eng gekoppelte, ausführbare Ketten implementiert wurden und CAN-Signale oder ECU-lokale Daten austauschen, auf funktionaler und logischer Ebene analysieren, in klarere Verantwortlichkeiten zerlegen und in Serviceanbieter, -konsumenten und Orchestrierungslogik mit explizit definierten Schnittstellen, Ereignissen und Datenverträgen umstrukturieren. Dadurch bleibt das validierte Funktionsverhalten erhalten, während die Verantwortlichkeiten zwischen HPCs, Zonencontrollern und Edge-ECUs neu verteilt werden. Zudem ermöglicht es die Bewertung der Auswirkungen von Kommunikationsänderungen auf Timing, Sicherheit und Integration. Da Anforderungen, Architekturelemente, Softwarekomponenten und Verifizierungsartefakte nachvollziehbar miteinander verbunden bleiben, können Teams bestehende Implementierungen schrittweise modernisieren – Testfälle und Konformitätsnachweise wiederverwenden und gleichzeitig die Übereinstimmung zwischen migrierten Diensten und der ursprünglichen Designabsicht wahren.

Abschluss

Die Integration von modellbasierter Systementwicklung und modellbasiertem Design bietet einen praktischen, durchgängigen Workflow für die SDV-Funktionsentwicklung. Dies ermöglicht eine klarere Systemabsicht, eine frühere Verifizierung durch Simulation und die Bereitstellung von Softwareartefakten. Dieser Ansatz ist explizit funktionsorientiert und so strukturiert, dass die Rückverfolgbarkeit über alle Designphasen hinweg gewährleistet ist. Dadurch bleiben die technischen Entscheidungen von der Konzeption bis zur Implementierung konsistent. Der Nutzen ist spürbar: Der Workflow ermöglicht schnellere Iterationen, weniger Überraschungen bei der späten Integration und eine konsistentere Implementierung in heterogenen Steuergeräten und gemischten SOA-/Signalarchitekturen.

Während die Branche KI-gestützte Entwicklungsmethoden – einschließlich neuartiger agentenbasierter KI-Ansätze – erforscht, stellen sich Fragen zur Rolle etablierter Entwicklungsmethoden. In diesem neuen Kontext wird der Wert modellbasierter Systementwicklung und modellbasierter Designansätze noch deutlicher: In einem Entwicklungsprozess, in dem Mensch und KI zunehmend zusammenarbeiten, bieten diese Ansätze die notwendige Strenge, um Anforderungen zu verankern, die Systemabsicht zu klären und Architektur, Verhalten und Verifikation aufeinander abzustimmen. Damit bilden sie eine entscheidende Grundlage für die Entwicklung von SDV-Software, die nicht nur innovativ, sondern auch vertrauenswürdig und wartungsfreundlich ist.

Durch die Nutzung der Automobilexpertise von KPIT und der von MathWorks bereitgestellten Toolchain-Kontinuität stärkt das vorgeschlagene Framework die Zusammenarbeit zwischen Architekten, Softwareentwicklern und Integrationsingenieuren, verbessert die Rückverfolgbarkeit von Anforderungen zu Architekturen und unterstützt zunehmend komplexe Systemdefinitionen, ohne die Machbarkeit zu beeinträchtigen.

Verwendete Produkte

• System Composer
• AUTOSAR Blockset
• Simulink-Anforderungen
• Eingebetteter Coder

 

Autor