Brückenschlag zwischen System und Software: Ein einheitlicher Ansatz für die Funktions-Entwicklung von verteilten Architekturen für SDVs

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 verändern die Automobiltechnik – und das nicht nur durch das Hinzufügen von mehr Code. Sie verändern, wo Software läuft, wie Features zusammengesetzt werden und was „Integration“ wirklich bedeutet. Da sich Funktionen über verschiedene Rechenbereiche, Kommunikationsprotokolle und sogar unterschiedliche Organisationen erstrecken, benötigen Teams Ansätze, die dafür sorgen, dass architektonischer Zweck und Softwareverhalten vom ersten Tag an aufeinander abgestimmt sind.

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

Um Unternehmen bei der Bewältigung dieser Herausforderung zu unterstützen, vereinen KPIT und MathWorks die Anwendung bewährter Methoden, tiefgreifende Expertise im Automobilbereich und eine integrierte Toolchain, die den Systemzweck mit ausführbaren Modellen verbindet. Das Ergebnis ist ein durchgängiger, nachvollziehbarer Workflow, der frühe Architektur- und Softwareentscheidungen sowie die kontinuierliche Validierung durch Simulation unterstützt und die Absicht der Stakeholder (als zentrale Referenzquelle – Single Source of Truth) mit Architekturentscheidungen, einsetzbarer Software und Verifizierungsnachweisen verknüpft.

Wichtigste Herausforderungen bei verteilten SDV-Funktionen

Die Entwicklung von SDV-Funktionen scheitert selten daran, dass ein Team „schlechten Code“ geschrieben hat. Das Problem besteht darin, dass die Funktion die Grenzen des Steuergeräts überschreitet, serviceorientierte und signalbasierte Interaktionen vermischt und Lücken zwischen Design und Implementierung aufdeckt. Diese Lücken bleiben meist erst bis zur späten Integration unsichtbar – daher entscheiden oft die folgenden Herausforderungen 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: Teams aus verschiedenen Domänen 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 Model-Based Systems Engineering und Model-Based Design

Dieser Artikel stellt einen funktionsorientierten Entwicklungsansatz vor, der Model-Based Systems Engineering (System-/Funktionszweck, Anforderungen und Architektur) mit Model-Based Design (ausführbare Softwaremodelle, Simulation und Codegenerierung) vereint. Der Arbeitsablauf folgt einem systematischen Top-Down-Ansatz für die Architektur- und Anforderungsentwicklung, wobei in jeder Phase der richtige Abstraktionsgrad angewendet wird. Es kann angewendet werden, um SDV-Funktionen zu entwickeln, die heterogene Steuergeräte umfassen und serviceorientierte und signalbasierte Interaktionen kombinieren.

Dieser Ansatz beschleunigt die Bereitstellung von Funktionen durch die Integration und Validierung verteilter Funktionen in einer simulierten Umgebung unter Verwendung von vernetzten Steuergeräte- und Softwarekomponentenmodellen. Zudem verbessert es die durchgängige Rückverfolgbarkeit für Wirkungsanalysen und die Einhaltung von Vorschriften und reduziert Nacharbeiten in späten Phasen bei der Bereitstellung über zentrale, zonale und periphere ECUs hinweg.

In der Praxis benötigen Teams eine Möglichkeit, Architekturentscheidungen frühzeitig testbar zu machen: Kann diese Funktion die zeitlichen Anforderungen in verschiedenen Zonen erfüllen, Teilausfälle überstehen, Sicherheits- und Cybersicherheitsauflagen erfüllen und dennoch konsistent über AUTOSAR^® Classic/Adaptive-Ziele hinweg implementiert werden? Ein einheitlicher Workflow für Model-Based Systems Engineering und Model-Based Design macht diese Fragen explizit und beantwortbar, bevor Hardware und das gesamte Fahrzeug integriert werden.

Lassen Sie uns die wichtigsten Arbeitsschritte des funktionsorientierten Ansatzes durchgehen:

1. Funktionsumfang: Die Bedürfnisse der Stakeholder erfassen, Funktionsgrenzen, Akteure und Abhängigkeiten definieren.
2. Anforderungen: Anwendungsfälle und Verhaltensweisen definieren, Systemanforderungen (funktionale und nichtfunktionale) mit klaren Akzeptanzkriterien ableiten.
3. 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.
4. Softwarearchitektur: Ableitung von Softwareanforderungen und Softwarearchitektur pro Steuergerät (HPC/Zone/Edge), abgestimmt auf AUTOSAR Classic/Adaptive oder kundenspezifische Anforderungen.
5. Detailliertes Software-Design: Entwickeln ausführbarer Modelle für Algorithmen und Komponentenverhalten und vorhandene Ressourcen nach Möglichkeit wiederverwenden.
6. Funktionale Verifizierung: Modell-in-the-Loop-/Closed-Loop-Simulationen durchfürhren, um das Verhalten zu validieren, bevor die Hardware verfügbar ist.
7. Codegenerierung und -integration: Generieren von produktionsreifem AUTOSAR Classic/Adaptive- oder benutzerdefiniertem 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 Arbeitsablauf zu veranschaulichen, gehen wir ein konkretes Beispiel durch, das Benutzer, Hardware, Netzwerktechnik und Sicherheitsbeschränkungen betrifft: die Ladeklappensteuerung eines Elektrofahrzeugs. Dieses Beispiel zeigt, wie ein funktionsorientierter Prozess von der Abgrenzung und den Anforderungen zur Architekturzuordnung, Simulation und Produktionscodegenerierung übergeht, ohne dabei die Rückverfolgbarkeit zu verlieren.

Ein Klappenmanagementsystem steuert die Ladeklappe des Fahrzeugs (Abbildung 1). Es gleicht kontinuierlich die physikalische Welt (z. B. Positionserfassung, Aktorzustand und Verriegelungs-/Sperrrückmeldung) mit dem Ladekontext (z. B. Fahrzeugzustand, Status des Bordladegeräts) ab, um zu entscheiden, wann die Klappe geöffnet werden kann, geschlossen werden muss oder verriegelt werden soll. Das System veröffentlicht anschließend Statusaktualisierungen und Warnungen für den Fahrer und andere Fahrzeugfunktionen. Durch die Integration von Sensorik, Aktorik und ECU-Koordination bietet das Klappenmanagementsystem einen kleinen, aber realistischen Stellvertreter für die Entwicklung umfassenderer verteilter SDV-Funktionen.

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 Feature-Grenzendiagramm abzuleiten, das die vom Klappenmanagement betroffenen Features und die zwischen diesen Features ausgetauschten Informationen erfasst. Die Grenzansicht verdeutlicht, welche Fahrzeugfunktionen und externen Akteure mit der Klappensteuerung interagieren und welche Informationen ausgetauscht werden (Abbildung 2).

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).

Sobald die beiden Anwendungsfälle identifiziert sind, besteht der nächste Schritt darin, die verschiedenen Aktivitäten zu definieren, die das Feature in jedem Anwendungsfall ausführt. Dies wird dazu beitragen, das Verhalten der Funktion zu beschreiben und eine erste Reihe von Systemanforderungen für das Klappenmanagement zu erfassen. Anschließend verwenden wir System Composer, um Aktivitätsdiagramme zu erstellen (Abbildung 4).

Auf Grundlage der vorangegangenen Analysen und Diagramme können wir nun mithilfe des Anforderungseditors, der Teil der Requirements Toolbox™ ist, die Systemanforderungen erstellen (Abbildung 5). Wir haben Anforderungen an die Abläufe, wie das Öffnen und Schließen der Klappe und die Meldung des Klappenstatus.

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

• Systemfunktionen: technische Funktionseinheiten, die gemeinsam die Funktion realisieren
• Interaktionen: Wie diese Funktionen kommunizieren und zusammenarbeiten

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

• Ladebuchsenstrom messen
• Klappenstatus abrufen und Benutzer benachrichtigen
• Klappe schließen
• Klappe öffnen

Im Rahmen der Definition der funktionalen Architektur ordnen wir jede Systemanforderung der Funktion bzw. den Funktionen zu, die für deren Erfüllung zuständig sind, und gegebenenfalls der Interaktion, die die benötigten Informationen übermittelt. Diese Zuordnung gewährleistet, dass jede Anforderung durch Designelemente abgedeckt wird, macht Lücken/Überschneidungen frühzeitig sichtbar und bietet Rückverfolgbarkeit von Anforderungen zu Funktionen für nachgelagerte logische/physikalische Konstruktion und Verifizierung. In der Praxis kann diese Zuordnung effizient durch Ziehen und Ablegen von Anforderungen auf System Composer-Komponenten durchgeführt werden (Abbildung 7).

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 und 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.

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).

Softwarearchitektur, Simulation und Codegenerierung

Aus den Systemanforderungen und der Systemarchitektur leiten wir die Softwareanforderungen und die Architektur pro Steuergerät (HPC, zonal, edge) ab und verfeinern sie zu einsetzbaren Softwarekomponenten. Auf dem HPC wird das Feature in Dienste und Anwendungen zerlegt (z. B. AUTOSAR Adaptive, sofern anwendbar), während zonale/Edge-Knoten zeitkritische Sensor-/Aktorfunktionen hosten (z. B. AUTOSAR Classic oder Äquivalent). Schnittstellen (Dienste, Signale und Datentypen) werden konsistent von der physischen Architektur in Software-Ports und -Konnektoren übertragen, was frühzeitige Konsistenzprüfungen, die Modellierung des ausführbaren Verhaltens und die Integration von Simulations-Hooks (für MIL/SIL- und Closed-Loop-Läufe) ermöglicht, 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).

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

Sobald wir die Implementierung des Features über die drei Steuergeräte hinweg modelliert haben, können wir ein geschlossenes Simulationsmodell erstellen, das die Steuergeräte mit einem Anlagenmodell 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 können wir mithilfe von Simulationen beurteilen, wie das System auf eine Benutzeranfrage zum Öffnen der Klappe bei unterschiedlichen Fahrzeuggeschwindigkeiten reagiert (Abbildung 12).

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

Darüber hinaus können neue Anforderungen auf der Ebene der Systemanforderungen erfasst und einer Wirkungsanalyse unterzogen werden, um die betroffenen Elemente zu identifizieren. Die daraus resultierenden Änderungen werden visualisiert und an die entsprechenden System- und Softwareschnittstellen weitergegeben. Anschließend wird der Workflow iterativ angepasst, um den sich ändernden Anforderungen gerecht zu werden. Dieser Prozess wird durch die durchgängige Rückverfolgbarkeit ermöglicht, wobei das Rückverfolgbarkeitsdiagramm (Abbildung 14) zur Steuerung dynamischer Änderungen während des gesamten SDV-Entwicklungslebenszyklus verwendet wird.

Migration von Altanwendungen

Neben der Entwicklung neuer Funktionen unterstützt derselbe integrierte Workflow auch die systematische Migration von veralteten signalbasierten Funktionen hin zu serviceorientierten, verteilten Softwarearchitekturen. In der Praxis können bestehende Funktionen, die ursprünglich als eng gekoppelte, ausführbare Ketten implementiert wurden, welche CAN-Signale oder ECU-lokale Daten austauschen, auf der funktionalen und logischen Ebene analysiert, in klarere Verantwortlichkeiten zerlegt und in Dienstanbieter, -konsumenten und Orchestrierungslogik mit explizit definierten Schnittstellen, Ereignissen und Datenverträgen umstrukturiert werden. Dadurch ist es möglich, das validierte Funktionsverhalten beizubehalten, während gleichzeitig die Verantwortlichkeiten zwischen HPCs, Zonencontrollern und Edge-ECUs neu verteilt werden. Es ermöglicht auch die Beurteilung 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 – indem sie Testfälle und Konformitätsnachweise wiederverwenden und gleichzeitig die Übereinstimmung zwischen migrierten Diensten und den ursprünglichen Designzweck wahren.

Fazit

Die Integration von Model-Based Systems Engineering und Model-Based Design bietet einen praktischen, durchgängigen Workflow für die SDV-Funktionsentwicklung und ermöglicht so einen klareren Systemzweck, 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, damit die technischen Entscheidungen von der Planung bis zur Implementierung konsistent bleiben. Der Nutzen ist spürbar, denn der Workflow ermöglicht schnellere Iterationen, weniger Überraschungen bei der Integration in späten Phasen und eine konsistentere Implementierung über heterogene Steuergeräte und gemischte SOA-/Signalarchitekturen hinweg.

Während die Branche KI-gesteuerte Entwicklungsmethoden erforscht – einschließlich neuer Ansätze der agentenbasierten KI –, stellen sich Fragen nach der Rolle etablierter Ingenieurpraktiken. In diesem neuen Kontext wird der Wert von Model-Based Systems Engineering und Model-Based-Design-Ansätzen noch deutlicher: In einem Entwicklungszyklus, in dem Menschen und KI zunehmend zusammenarbeiten, bieten diese Ansätze die notwendige Strenge, um Anforderungen zu verankern, den Systemzweck zu verdeutlichen und Architektur, Verhalten und Verifizierung aufeinander abzustimmen. Damit bilden sie eine entscheidende Grundlage für die Bereitstellung 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 Verfolgbarkeit von Anforderungen zu Architekturen und unterstützt zunehmend komplexe Systemdefinitionen, ohne die Machbarkeit zu beeinträchtigen.

Weitere Informationen