Zusammenfassung<\/h2>\n\n- Sie k\u00f6nnen einen funktionsorientierten Workflow verwenden, um Anforderungen, Architekturentscheidungen und einsetzbare Software f\u00fcr die softwaredefinierte Fahrzeugentwicklung zu verkn\u00fcpfen.<\/li>\n
- Die Vereinheitlichung von modellbasierter Systementwicklung und modellbasiertem Design hilft Ihnen, verteilte Funktionen fr\u00fchzeitig mittels Simulation zu validieren, bevor die Integration in das Gesamtfahrzeug erfolgt.<\/li>\n
- Die durchg\u00e4ngige R\u00fcckverfolgbarkeit w\u00e4hrend der gesamten Feature-Entwicklung, einschlie\u00dflich Anforderungen, Architektur, Design, Implementierung und Tests, tr\u00e4gt zu einem effizienten \u00c4nderungsmanagement bei.<\/li>\n
- Anhand eines Beispiels zur Ladeklappensteuerung wird gezeigt, wie der Workflow \u00fcber einen Zentralrechner, einen Zonenregler und ein Edge-Steuerger\u00e4t skaliert.<\/li>\n<\/ul>\n
Wie k\u00f6nnen SDV-Entwicklungsteams fr\u00fchzeitig die richtigen Architektur- und Softwareentscheidungen treffen und diese kontinuierlich validieren, wenn sich die Funktionen \u00fcber zentrale Computer, Zonensteuerungen und Edge-Ger\u00e4te erstrecken und serviceorientierte und signalbasierte Architekturen \u00fcber komplexe Integrationsgrenzen hinweg miteinander verschmelzen?<\/p>\n
SDVs definieren die Automobiltechnik neu \u2013 und das nicht nur durch mehr Code. Sie gestalten sie um.\u00a0Wo<\/i>\u00a0Die Software l\u00e4uft,\u00a0Wie<\/i>\u00a0Die Merkmale setzen sich zusammen, und\u00a0Was<\/i>\u00a0\u201cWas \u201dIntegration\u201c wirklich bedeutet, ist, dass die Funktionen \u00fcber verschiedene Rechenbereiche, Kommunikationsprotokolle und sogar unterschiedliche Organisationen hinwegreichen. Daher ben\u00f6tigen Teams Ans\u00e4tze, die von Anfang an daf\u00fcr sorgen, dass Architekturabsicht und Softwareverhalten \u00fcbereinstimmen.<\/p>\n
Diese architektonische Freiheit hat jedoch ihren Preis: Es gibt mehr Schnittstellen, mehr Zeitabl\u00e4ufe, mehr Fehlerm\u00f6glichkeiten und mehr Wege, wie kleine Abweichungen erst sp\u00e4t sichtbar werden k\u00f6nnen, insbesondere wenn Fahrzeuge, Zulieferer und Zeitpl\u00e4ne bereits feststehen. In diesem Umfeld m\u00fcssen System- und Softwareentwickler fr\u00fchzeitig die richtigen Entscheidungen treffen und diese kontinuierlich mithilfe von Modellen und Simulationen validieren.<\/p>\n
Um Unternehmen bei dieser Herausforderung zu unterst\u00fctzen, vereinen KPIT und MathWorks bew\u00e4hrte Methoden, umfassendes Fachwissen im Automobilbereich und eine integrierte Toolchain, die Systemabsichten mit ausf\u00fchrbaren Modellen verkn\u00fcpft. Das Ergebnis ist ein durchg\u00e4ngiger, nachvollziehbarer Workflow, der fr\u00fchzeitige Architektur- und Softwareentscheidungen sowie die kontinuierliche Validierung durch Simulation unterst\u00fctzt und die Absichten der Stakeholder (als zentrale Informationsquelle) mit Architekturentscheidungen, einsetzbarer Software und Verifizierungsnachweisen verbindet.<\/p>\n
Wichtigste Herausforderungen bei verteilten SDV-Funktionen<\/h2>\n
Die Entwicklung von SDV-Funktionen scheitert selten an \u201cschlechtem Code\u201d eines einzelnen Teams. Sie scheitert vielmehr daran, dass die Funktion die Grenzen von Steuerger\u00e4ten \u00fcberschreitet, serviceorientierte und signalbasierte Interaktionen vermischt und L\u00fccken zwischen Design und Implementierung aufdeckt. Diese L\u00fccken bleiben oft bis zur sp\u00e4ten Integration verborgen \u2013 daher entscheiden die folgenden Herausforderungen h\u00e4ufig dar\u00fcber, ob ein Programm komplexe Funktionen schnell und zuverl\u00e4ssig bereitstellen kann:<\/p>\n
\n- Unklare Anforderungen im gro\u00dfen Ma\u00dfstab:<\/strong> Funktionale und nichtfunktionale Anforderungen m\u00fcssen Verteilung, Zeitplanung, Teilausf\u00e4lle, Sicherheit und Cybersicherheit ber\u00fccksichtigen.<\/li>\n
- Architekturentscheidungen wirken sich nachgelagert aus:<\/strong> Service- versus Signalwahl und Steuerger\u00e4tezuordnung steuern Schnittstellen, Softwarepartitionierung und Verifizierungsaufwand.<\/li>\n
- Team\u00fcbergreifende Abstimmung:<\/strong> Multidom\u00e4nen-Teams ben\u00f6tigen gemeinsam genutzte, nachvollziehbare Modelle, um Nacharbeiten im Nachhinein zu vermeiden.<\/li>\n
- Toolchain-Fragmentierung:<\/strong> Unverbundene Tools behindern die R\u00fcckverfolgbarkeit und die Validierung im \u201cShift-Left\u201d-Verfahren; die virtuelle Integration erfordert konsistente Architektur- und Verhaltensmodelle.<\/li>\n<\/ul>\n
Ein einheitlicher Workflow f\u00fcr modellbasierte Systementwicklung und modellbasiertes Design<\/h2>\n
Dieser Artikel stellt einen funktionsorientierten Entwicklungsansatz vor, der modellbasierte Systementwicklung (System-\/Funktionsabsicht, Anforderungen und Architektur) mit modellbasiertem Design (ausf\u00fchrbare Softwaremodelle, Simulation und Codegenerierung) vereint. Der Workflow folgt einem systematischen Top-Down-Ansatz f\u00fcr 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\u00e4te umfassen und serviceorientierte sowie signalbasierte Interaktionen kombinieren.<\/p>\n
Dieser Ansatz beschleunigt die Bereitstellung neuer Funktionen durch die Integration und Validierung verteilter Funktionen in einer simulierten Umgebung mithilfe vernetzter Steuerger\u00e4te- und Softwarekomponentenmodelle. Er verbessert zudem die durchg\u00e4ngige R\u00fcckverfolgbarkeit f\u00fcr Wirkungsanalysen und die Einhaltung von Vorschriften und reduziert Nacharbeiten in sp\u00e4ten Phasen bei der Bereitstellung auf zentralen, zonalen und Edge-Steuerger\u00e4ten.<\/p>\n
In der Praxis ben\u00f6tigen Teams eine M\u00f6glichkeit, Architekturentscheidungen fr\u00fchzeitig testbar zu machen: Kann diese Funktion die Timing-Anforderungen in verschiedenen Zonen erf\u00fcllen, Teilausf\u00e4lle \u00fcberstehen, Sicherheits- und Cybersicherheitsauflagen erf\u00fcllen und dennoch konsistent auf AUTOSAR\u00ae Classic\/Adaptive-Zielen implementiert werden? Ein einheitlicher modellbasierter Systementwicklungs- und modellbasierter Design-Workflow macht diese Fragen explizit \u2013 und beantwortbar \u2013 vor der Hardware- und Fahrzeugintegration.<\/p>\n
Lassen Sie uns die wichtigsten Arbeitsschritte des funktionsorientierten Ansatzes durchgehen:<\/strong><\/p>\n\n- Funktionsumfang:<\/strong> Die Bed\u00fcrfnisse der Stakeholder erfassen, Funktionsgrenzen, Akteure und Abh\u00e4ngigkeiten definieren.<\/li>\n
- Anforderungen:<\/strong> Anwendungsf\u00e4lle und Verhaltensweisen definieren, Systemanforderungen (funktionale und nichtfunktionale) mit klaren Akzeptanzkriterien ableiten.<\/li>\n
- Systemarchitektur:<\/strong> Funktionale Architektur (Funktionen und Interaktionen), plattformunabh\u00e4ngige Subsystemidentifizierung und -architektur sowie plattformabh\u00e4ngige Systemarchitektur (Steuerger\u00e4te\/Netzwerke und Service- versus Signalentscheidungen) erstellen und validieren.<\/li>\n
- Softwarearchitektur:<\/strong> Ableitung von Softwareanforderungen und Softwarearchitektur pro Steuerger\u00e4t (HPC\/Zone\/Edge), abgestimmt auf AUTOSAR Classic\/Adaptive oder kundenspezifische Anforderungen.<\/li>\n
- Detailliertes Software-Design:<\/strong> Entwickeln Sie ausf\u00fchrbare Modelle f\u00fcr Algorithmen und Komponentenverhalten und nutzen Sie nach M\u00f6glichkeit vorhandene Ressourcen wieder.<\/li>\n
- Funktionale Verifizierung:<\/strong> F\u00fchren Sie Modell-in-the-Loop-\/Closed-Loop-Simulationen durch, um das Verhalten zu validieren, bevor die Hardware verf\u00fcgbar ist.<\/li>\n
- Codegenerierung und -integration:<\/strong> Generieren Sie produktionsreifen AUTOSAR Classic\/Adaptive- oder benutzerdefinierten Code mit nahtloser Integration in CI- und Verifizierungsworkflows.<\/li>\n<\/ul>\n
Dies sind die wichtigsten Vorteile, die sich durch die Befolgung des vorgeschlagenen Ansatzes ergeben:<\/p>\n
\n- Fr\u00fcherkennung von M\u00e4ngeln:<\/strong> Ausf\u00fchrbare Modelle und Simulationen decken Integrations- und Timingprobleme vor der Hardware- und Komplettfahrzeugintegration auf.<\/li>\n
- Schnellere Iterationen:<\/strong> Virtuelle Integrationstests reduzieren Nachbearbeitungszyklen und beschleunigen die Funktionsbereitstellung.<\/li>\n
- Nachvollziehbare Entwicklung:<\/strong> Durch konsistente Verkn\u00fcpfungen zwischen den Artefakten k\u00f6nnen Abdeckungspr\u00fcfungen durchgef\u00fchrt und die Auswirkungen bei \u00c4nderungen der Anforderungen effizient analysiert werden.<\/li>\n
- Wiederverwendbare Architekturelemente:<\/strong> Die logische Architektur bietet eine plattformunabh\u00e4ngige Referenz f\u00fcr wiederverwendbare Systeme in verschiedenen Fahrzeugprogrammen.<\/li>\n
- Einsatzbereite Ausgaben:<\/strong> Die Softwarearchitektur und die Codegenerierung sind auf AUTOSAR Classic\/Adaptive und gemischte SOA\/Signal-Kommunikation abgestimmt.<\/li>\n<\/ul>\n
Im weiteren Verlauf des Artikels werden wir den Ansatz anhand eines realen Anwendungsfalls demonstrieren.<\/strong><\/p>\nBeispiel: Entwicklung einer Ladeklappen-Verwaltungsfunktion<\/strong><\/p>\nUm 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 \u00fcber die Architekturzuordnung und Simulation bis hin zur Generierung des Produktionscodes reicht, ohne dabei die Nachvollziehbarkeit zu verlieren.<\/p>\n
Ein Klappenmanagementsystem steuert die Ladeklappe des Fahrzeugs (Abbildung 1). Es gleicht kontinuierlich die physikalischen Gegebenheiten (z. B. Positionserfassung, Aktuatorstatus und Verriegelungsr\u00fcckmeldung) mit dem Ladekontext (z. B. Fahrzeugzustand, Status des Onboard-Ladeger\u00e4ts und Signale der Ladestation) ab, um zu entscheiden, wann die Klappe ge\u00f6ffnet, geschlossen oder verriegelt werden soll. Anschlie\u00dfend sendet das System Statusaktualisierungen und Warnungen an den Fahrer und andere Fahrzeugfunktionen. Durch die Integration von Sensorik, Aktorik und Steuerger\u00e4tekoordination bietet das Klappenmanagementsystem ein kleines, aber realistisches Modell f\u00fcr die Entwicklung umfassenderer verteilter Funktionen f\u00fcr autonomes Fahren.<\/p>\n
![](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/vehicle-charging.jpg\")
\nAbbildung 1. Ladeklappe des Fahrzeugs.<\/em><\/strong><\/p>\nFunktionsumfang<\/h2>\n
Wir definieren die Feature-Grenzen (Akteure, Eingaben\/Ausgaben und Abh\u00e4ngigkeiten), um einen gemeinsamen Rahmen festzulegen und die Anforderungserhebung und -analyse zu unterst\u00fctzen.<\/p>\n
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\u00e4t, das auch als Gateway dient, und Edge-Steuerger\u00e4ten besteht, die f\u00fcr die Echtzeit-Erfassung und -Aktorik zust\u00e4ndig sind.<\/p>\n
In diesem Schritt f\u00fchren wir eine Wirkungsanalyse durch und verwenden System Composer\u2122, 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).<\/p>\n
![\"Feature-Grenzendiagramm](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/feature-boundary-diagram.jpg\")
\nAbbildung 2. Merkmalsgrenzendiagramm.<\/em><\/strong><\/p>\nFunktionsebene<\/strong>
\nWir erfassen die wichtigsten Anwendungsf\u00e4lle und leiten das Funktionsverhalten mithilfe eines Anwendungsfalldiagramms ab. Anschlie\u00dfend \u00fcbersetzen wir dieses Verhalten in klare Systemanforderungen. Wir identifizieren zwei Anwendungsf\u00e4lle: \u201cLadevorgang starten\u201d und \u201cLadevorgang beenden\u201d (Abbildung 3).<\/p>\n![\"Anwendungsfalldiagramm](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/use-case.jpg\")
\nAbbildung 3. Anwendungsfalldiagramm.<\/em><\/strong><\/p>\nNachdem die beiden Anwendungsf\u00e4lle identifiziert wurden, werden im n\u00e4chsten Schritt die verschiedenen Aktivit\u00e4ten definiert, die das Feature in jedem Anwendungsfall ausf\u00fchrt. Dies hilft, das Verhalten des Features zu beschreiben und erste Systemanforderungen f\u00fcr das Flap-Management zu erfassen. Anschlie\u00dfend erstellen wir mit System Composer Aktivit\u00e4tsdiagramme (Abbildung 4).<\/p>\n
![\"Aktivit\u00e4tsdiagramm](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/activity-diagram.jpg\")
\nAbbildung 4. Aktivit\u00e4tsdiagramm zur Veranschaulichung der Ladeklappenbet\u00e4tigung.<\/em><\/strong><\/p>\nAufbauend auf der vorangegangenen Analyse und den Diagrammen k\u00f6nnen wir nun mithilfe des Anforderungseditors, der Teil der Requirements Toolbox\u2122 ist (Abbildung 5), die Systemanforderungen erstellen. Wir haben Anforderungen, die sich auf die Vorg\u00e4nge beziehen, wie z. B. das \u00d6ffnen und Schlie\u00dfen der Klappe und die Meldung des Klappenstatus.<\/p>\n
![\"Systemanforderungen,](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/system-level.jpg\")
\nAbbildung 5. Systemanforderungen im Anforderungseditor.<\/em><\/strong><\/p>\nAls N\u00e4chstes erstellen wir eine funktionale Architektur und ordnen Anforderungen Funktionen zu, um die Nachvollziehbarkeit zu gew\u00e4hrleisten. Dies beinhaltet die Definition von:<\/p>\n
\n- Systemfunktionen:<\/strong> technische Funktionseinheiten, die gemeinsam das Merkmal realisieren<\/li>\n
- Interaktionen:<\/strong> wie diese Funktionen kommunizieren und zusammenarbeiten<\/li>\n<\/ul>\n
Auf Grundlage der Analyse der Systemanforderungen unterteilen wir die Ladeklappenfunktion in vier Funktionen (Abbildung 6):<\/p>\n
\n- Messen Sie den Strom der Ladebuchse<\/li>\n
- Klappenstatus abrufen und Benutzer benachrichtigen<\/li>\n
- Klappe schlie\u00dfen<\/li>\n
- Klappe \u00f6ffnen<\/li>\n<\/ul>\n
![\"Funktionale](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/functional-architecture.jpg\")
\nAbbildung 6. Funktionale Architektur.<\/em><\/strong><\/p>\nIm Rahmen der Definition der funktionalen Architektur ordnen wir jede Systemanforderung der\/den f\u00fcr ihre Erf\u00fcllung zust\u00e4ndigen Funktion(en) und gegebenenfalls der Interaktion zu, die die ben\u00f6tigten Informationen \u00fcbertr\u00e4gt. Diese Zuordnung stellt sicher, dass jede Anforderung durch Designelemente abgedeckt ist, macht L\u00fccken und \u00dcberschneidungen fr\u00fchzeitig sichtbar und gew\u00e4hrleistet die R\u00fcckverfolgbarkeit von Anforderungen zu Funktionen f\u00fcr den nachfolgenden logischen\/physikalischen Entwurf und die Verifizierung. Praktisch l\u00e4sst sich diese Zuordnung effizient per Drag & Drop von Anforderungen auf System Composer-Komponenten durchf\u00fchren (Abbildung 7).<\/p>\n
![\"Zuordnung](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/allocation.jpg\")
\nAbbildung 7. Zuordnung der Systemanforderungen zur funktionalen Architektur.<\/em><\/strong><\/p>\nPlattformunabh\u00e4ngige Subsystemidentifizierung und Architektur<\/h2>\n
Wir ordnen Funktionen logischen Subsystemen zu und definieren die logischen Schnittstellen zwischen ihnen, um eine wiederverwendbare, plattformunabh\u00e4ngige Architektursicht zu erstellen (Abbildung 8):<\/p>\n
\n- Ein Ladeschnittstellen-Subsystem, das f\u00fcr das \u00d6ffnen und Schlie\u00dfen der Klappe sowie f\u00fcr die Meldung des Klappenstatus zust\u00e4ndig ist.<\/li>\n
- Ein Ladekontrollsubsystem, das f\u00fcr die Koordination der Anfragen von der Kommunikationsschnittstelle und die Verwaltung aller Ladevorg\u00e4nge zust\u00e4ndig ist.<\/li>\n
- Ein Ladekommunikationssubsystem, das die Kommunikation mit dem Benutzer und dem Rest des Systems verwaltet.<\/li>\n<\/ul>\n
![\"Plattformunabh\u00e4ngige](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/platform-architecture.jpg\")
\nAbbildung 8. Detailansicht der plattformunabh\u00e4ngigen Architektur.<\/em><\/strong><\/p>\nPlattformabh\u00e4ngige Systemarchitektur<\/h2>\n
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\u00dflich derjenigen Interaktionen, die als Dienste oder Signale implementiert werden.<\/p>\n
Sobald wir die verschiedenen Komponenten identifiziert haben, k\u00f6nnen wir in System Composer ein Systemarchitekturdiagramm erstellen, das die Komponentengrenzen und die Informationen hervorhebt, die die Komponenten austauschen m\u00fcssen, um die Klappenverwaltungsfunktion zu implementieren (Abbildung 9).<\/p>\n
![\"Systemarchitekturdiagramm](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/system-architecture.jpg\")
\nAbbildung 9. Systemarchitekturdiagramm.<\/em><\/strong><\/p>\nSoftwarearchitektur, Simulation und Codegenerierung<\/h2>\n
Aus den Systemanforderungen und der Systemarchitektur leiten wir die Softwareanforderungen und die Architektur pro Steuerger\u00e4t (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\u00e4hrend Zonen-\/Edge-Knoten zeitkritische Sensor-\/Aktorfunktionen (z. B. AUTOSAR Classic oder \u00c4quivalent) hosten. Schnittstellen (Dienste, Signale und Datentypen) werden konsistent von der physischen Architektur in Software-Ports und -Konnektoren \u00fcbertragen. Dies erm\u00f6glicht fr\u00fchzeitige Konsistenzpr\u00fcfungen, die Modellierung des ausf\u00fchrbaren Verhaltens und die Integration von Simulations-Hooks (f\u00fcr MIL\/SIL- und Closed-Loop-Simulationen), bevor die Zielhardware verf\u00fcgbar ist.<\/p>\n
Zun\u00e4chst erstellen wir die Softwarearchitektur auf oberster Ebene f\u00fcr HPC-, zonale ECU- und Edge-ECU-Kompositionen, die mit der Systemarchitektur verkn\u00fcpft sind (Abbildung 10).<\/p>\n
![\"Softwarearchitektur\u00fcbersicht](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/software-architecture.jpg\")
\nAbbildung 10. \u00dcbersicht der Softwarearchitektur auf oberster Ebene.<\/em><\/strong><\/p>\nWir haben Softwarekomponenten f\u00fcr jede Architekturkomposition innerhalb der Architekturmodellierungsoberfl\u00e4che in System Composer definiert und modelliert. Die HPC-Komposition umfasst drei AUTOSAR Adaptive Servicekomponenten, die in Simulink\u00ae unter Verwendung eines SOA-Paradigmas implementiert wurden (Abbildung 11).<\/p>\n
![\"HPC-Softwarekomponenten,](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/hpc-software.jpg\")
\nAbbildung 11. Ansicht der HPC-Softwarekomponenten.<\/em><\/strong><\/p>\nSobald die Implementierung der Funktion in den drei Steuerger\u00e4ten modelliert ist, kann ein geschlossenes Simulationsmodell erstellt werden, das die Steuerger\u00e4te mit einem Systemmodell der Klappe verbindet \u2013 einschlie\u00dflich Modellen des Stromsensors, des Positionssensors und des Aktuators \u2013 und so eine schnelle \u00dcberpr\u00fcfung des Funktionsverhaltens unter realistischen Bedingungen erm\u00f6glicht. Beispielsweise kann die Simulation genutzt werden, um zu bewerten, wie das System auf eine Benutzeranforderung zum \u00d6ffnen der Klappe bei unterschiedlichen Fahrzeuggeschwindigkeiten reagiert (Abbildung 12).<\/p>\n
![\"Simulation](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/simulation-charging.jpg\")
\nAbbildung 12. Simulation eines geschlossenen Regelkreises einer Ladeklappe.<\/em><\/strong><\/p>\nNach Abschluss der Verifizierung besteht der n\u00e4chste Schritt im Workflow darin, mit Embedded Coder\u00ae produktionsreifen Code f\u00fcr die Integration und den Einsatz zu generieren (Abbildung 13). Simulink bietet standardm\u00e4\u00dfig Unterst\u00fctzung f\u00fcr die Generierung von AUTOSAR Classic- und AUTOSAR Adaptive-konformem Code und erm\u00f6glicht so die weitere Integration und den Einsatz.<\/p>\n
![\"C++-Produktionscode-Generierung](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/production-code.jpg\")
\nAbbildung 13. Generierung von C++-Produktionscode f\u00fcr die Flap-Request-Arbitrator-Software.<\/em><\/strong><\/p>\nWird eine neue Anforderung eingef\u00fchrt, kann diese auf Systemebene erfasst und einer Auswirkungsanalyse unterzogen werden, um betroffene Elemente zu identifizieren. Die resultierenden \u00c4nderungen werden visualisiert und an die relevanten System- und Softwareschnittstellen weitergegeben. Anschlie\u00dfend wird der Workflow iterativ angepasst, um den sich \u00e4ndernden Anforderungen gerecht zu werden. Dieser Prozess wird durch durchg\u00e4ngige R\u00fcckverfolgbarkeit erm\u00f6glicht, wobei das R\u00fcckverfolgbarkeitsdiagramm (Abbildung 14) zur Verwaltung dynamischer \u00c4nderungen w\u00e4hrend des gesamten SDV-Entwicklungszyklus dient.<\/p>\n
![\"R\u00fcckverfolgbarkeitsdiagramm](\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/traceability.jpg\")
\nAbbildung 14. R\u00fcckverfolgbarkeitsdiagramm zur Verdeutlichung der Auswirkungen auf verschiedenen Ebenen.<\/em><\/strong><\/p>\nMigration von Altanwendungen<\/h2>\n
\u00dcber die Entwicklung neuer Funktionen hinaus unterst\u00fctzt derselbe integrierte Workflow auch die systematische Migration bestehender, signalbasierter Funktionen hin zu serviceorientierten, verteilten Softwarearchitekturen. Konkret lassen sich bestehende Funktionen, die urspr\u00fcnglich als eng gekoppelte, ausf\u00fchrbare 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\u00e4gen umstrukturieren. Dadurch bleibt das validierte Funktionsverhalten erhalten, w\u00e4hrend die Verantwortlichkeiten zwischen HPCs, Zonencontrollern und Edge-ECUs neu verteilt werden. Zudem erm\u00f6glicht es die Bewertung der Auswirkungen von Kommunikations\u00e4nderungen auf Timing, Sicherheit und Integration. Da Anforderungen, Architekturelemente, Softwarekomponenten und Verifizierungsartefakte nachvollziehbar miteinander verbunden bleiben, k\u00f6nnen Teams bestehende Implementierungen schrittweise modernisieren \u2013 Testf\u00e4lle und Konformit\u00e4tsnachweise wiederverwenden und gleichzeitig die \u00dcbereinstimmung zwischen migrierten Diensten und der urspr\u00fcnglichen Designabsicht wahren.<\/p>\n
Abschluss<\/h2>\n
Die Integration von modellbasierter Systementwicklung und modellbasiertem Design bietet einen praktischen, durchg\u00e4ngigen Workflow f\u00fcr die SDV-Funktionsentwicklung. Dies erm\u00f6glicht eine klarere Systemabsicht, eine fr\u00fchere Verifizierung durch Simulation und die Bereitstellung von Softwareartefakten. Dieser Ansatz ist explizit funktionsorientiert und so strukturiert, dass die R\u00fcckverfolgbarkeit \u00fcber alle Designphasen hinweg gew\u00e4hrleistet ist. Dadurch bleiben die technischen Entscheidungen von der Konzeption bis zur Implementierung konsistent. Der Nutzen ist sp\u00fcrbar: Der Workflow erm\u00f6glicht schnellere Iterationen, weniger \u00dcberraschungen bei der sp\u00e4ten Integration und eine konsistentere Implementierung in heterogenen Steuerger\u00e4ten und gemischten SOA-\/Signalarchitekturen.<\/p>\n
W\u00e4hrend die Branche KI-gest\u00fctzte Entwicklungsmethoden \u2013 einschlie\u00dflich neuartiger agentenbasierter KI-Ans\u00e4tze \u2013 erforscht, stellen sich Fragen zur Rolle etablierter Entwicklungsmethoden. In diesem neuen Kontext wird der Wert modellbasierter Systementwicklung und modellbasierter Designans\u00e4tze noch deutlicher: In einem Entwicklungsprozess, in dem Mensch und KI zunehmend zusammenarbeiten, bieten diese Ans\u00e4tze die notwendige Strenge, um Anforderungen zu verankern, die Systemabsicht zu kl\u00e4ren und Architektur, Verhalten und Verifikation aufeinander abzustimmen. Damit bilden sie eine entscheidende Grundlage f\u00fcr die Entwicklung von SDV-Software, die nicht nur innovativ, sondern auch vertrauensw\u00fcrdig und wartungsfreundlich ist.<\/p>\n
Durch die Nutzung der Automobilexpertise von KPIT und der von MathWorks bereitgestellten Toolchain-Kontinuit\u00e4t st\u00e4rkt das vorgeschlagene Framework die Zusammenarbeit zwischen Architekten, Softwareentwicklern und Integrationsingenieuren, verbessert die R\u00fcckverfolgbarkeit von Anforderungen zu Architekturen und unterst\u00fctzt zunehmend komplexe Systemdefinitionen, ohne die Machbarkeit zu beeintr\u00e4chtigen.<\/p>\n
Verwendete Produkte<\/h2>\n\n- System Composer<\/li>\n
- AUTOSAR Blockset<\/li>\n
- Simulink-Anforderungen<\/li>\n
- Eingebetteter Coder<\/li>\n<\/ul>\n
<\/p>","protected":false},"excerpt":{"rendered":"
A Unified Approach for Feature Development of SDV Distributed Architectures Using a Feature-Driven Workflow to Connect Requirements, Architecture, Simulation, and Deployment. Summary You can use a feature-driven workflow to connect requirements, architecture decisions, and deployable software for software-defined vehicle development. Unifying model-based systems engineering with Model-Based Design helps you validate distributed features early with simulation, […]<\/p>\n","protected":false},"author":23,"featured_media":29485,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"insight-style-landing-page.php","meta":{"_acf_changed":false,"footnotes":""},"class_list":["post-29499","page","type-page","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\n
A Unified Approach to SDV Distributed FeatureDevelopment | KPIT<\/title>\n<meta name=\"description\" content=\"See how a feature-driven MBSE and Model-Based Designworkflow connects requirements, architecture, simulationand deployable code across HPC, zonal and edge ECUs inSDVs.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"A Unified Approach for Feature Development of SDV Distributed Architectures\" \/>\n<meta property=\"og:description\" content=\"See how a feature-driven MBSE and Model-Based Designworkflow connects requirements, architecture, simulationand deployable code across HPC, zonal and edge ECUs inSDVs.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/\" \/>\n<meta property=\"og:site_name\" content=\"KPIT\" \/>\n<meta property=\"article:modified_time\" content=\"2026-09-16T07:21:04+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"960\" \/>\n\t<meta property=\"og:image:height\" content=\"540\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data1\" content=\"14\u00a0Minuten\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/\",\"name\":\"A Unified Approach to SDV Distributed FeatureDevelopment | KPIT\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg\",\"datePublished\":\"2026-09-15T12:04:26+00:00\",\"dateModified\":\"2026-09-16T07:21:04+00:00\",\"description\":\"See how a feature-driven MBSE and Model-Based Designworkflow connects requirements, architecture, simulationand deployable code across HPC, zonal and edge ECUs inSDVs.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg\",\"contentUrl\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg\",\"width\":960,\"height\":540},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.kpit.com\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"A Unified Approach for Feature Development of SDV Distributed Architectures\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/#website\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/\",\"name\":\"KPIT\",\"description\":\"Technology, Mobility, Software, Automotive\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":[\"Organization\",\"Place\"],\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/#organization\",\"name\":\"KPIT Technologies\",\"alternateName\":\"KPIT\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/\",\"logo\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#local-main-organization-logo\"},\"image\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#local-main-organization-logo\"},\"sameAs\":[\"https:\\\/\\\/www.linkedin.com\\\/company\\\/kpit\\\/\",\"https:\\\/\\\/www.instagram.com\\\/kpittechnologies\\\/?hl=en\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UC6AZI50H33ni75FAi-5mgqw\"],\"telephone\":[],\"openingHoursSpecification\":[{\"@type\":\"OpeningHoursSpecification\",\"dayOfWeek\":[\"Monday\",\"Tuesday\",\"Wednesday\",\"Thursday\",\"Friday\",\"Saturday\",\"Sunday\"],\"opens\":\"09:00\",\"closes\":\"17:00\"}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#local-main-organization-logo\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2025\\\/06\\\/favicon-1.png\",\"contentUrl\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2025\\\/06\\\/favicon-1.png\",\"width\":512,\"height\":512,\"caption\":\"KPIT Technologies\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Ein einheitlicher Ansatz f\u00fcr die verteilte Feature-Entwicklung mit SDV | KPIT","description":"Erfahren Sie, wie ein funktionsorientierter MBSE- und modellbasierter Design-Workflow Anforderungen, Architektur, Simulation und bereitstellbaren Code \u00fcber HPC-, zonale und Edge-ECUs in SDVs hinweg verbindet.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/","og_locale":"de_DE","og_type":"article","og_title":"A Unified Approach for Feature Development of SDV Distributed Architectures","og_description":"See how a feature-driven MBSE and Model-Based Designworkflow connects requirements, architecture, simulationand deployable code across HPC, zonal and edge ECUs inSDVs.","og_url":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/","og_site_name":"KPIT","article_modified_time":"2026-09-16T07:21:04+00:00","og_image":[{"width":960,"height":540,"url":"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_misc":{"Gesch\u00e4tzte Lesezeit":"14\u00a0Minuten"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/","url":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/","name":"Ein einheitlicher Ansatz f\u00fcr die verteilte Feature-Entwicklung mit SDV | KPIT","isPartOf":{"@id":"https:\/\/www.kpit.com\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#primaryimage"},"image":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#primaryimage"},"thumbnailUrl":"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg","datePublished":"2026-09-15T12:04:26+00:00","dateModified":"2026-09-16T07:21:04+00:00","description":"Erfahren Sie, wie ein funktionsorientierter MBSE- und modellbasierter Design-Workflow Anforderungen, Architektur, Simulation und bereitstellbaren Code \u00fcber HPC-, zonale und Edge-ECUs in SDVs hinweg verbindet.","breadcrumb":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.kpit.com\/de\/bridging-system-and-software\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#primaryimage","url":"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg","contentUrl":"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg","width":960,"height":540},{"@type":"BreadcrumbList","@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.kpit.com\/"},{"@type":"ListItem","position":2,"name":"A Unified Approach for Feature Development of SDV Distributed Architectures"}]},{"@type":"WebSite","@id":"https:\/\/www.kpit.com\/de\/#website","url":"https:\/\/www.kpit.com\/de\/","name":"KPIT","description":"Technologie, Mobilit\u00e4t, Software, Automotive","publisher":{"@id":"https:\/\/www.kpit.com\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.kpit.com\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":["Organization","Place"],"@id":"https:\/\/www.kpit.com\/de\/#organization","name":"KPIT Technologies","alternateName":"KPIT","url":"https:\/\/www.kpit.com\/de\/","logo":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#local-main-organization-logo"},"image":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#local-main-organization-logo"},"sameAs":["https:\/\/www.linkedin.com\/company\/kpit\/","https:\/\/www.instagram.com\/kpittechnologies\/?hl=en","https:\/\/www.youtube.com\/channel\/UC6AZI50H33ni75FAi-5mgqw"],"telephone":[],"openingHoursSpecification":[{"@type":"OpeningHoursSpecification","dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday","Sunday"],"opens":"09:00","closes":"17:00"}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#local-main-organization-logo","url":"https:\/\/www.kpit.com\/wp-content\/uploads\/2025\/06\/favicon-1.png","contentUrl":"https:\/\/www.kpit.com\/wp-content\/uploads\/2025\/06\/favicon-1.png","width":512,"height":512,"caption":"KPIT Technologies"}]}},"_links":{"self":[{"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/pages\/29499","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/users\/23"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/comments?post=29499"}],"version-history":[{"count":3,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/pages\/29499\/revisions"}],"predecessor-version":[{"id":29511,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/pages\/29499\/revisions\/29511"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/media\/29485"}],"wp:attachment":[{"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/media?parent=29499"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
Wie k\u00f6nnen SDV-Entwicklungsteams fr\u00fchzeitig die richtigen Architektur- und Softwareentscheidungen treffen und diese kontinuierlich validieren, wenn sich die Funktionen \u00fcber zentrale Computer, Zonensteuerungen und Edge-Ger\u00e4te erstrecken und serviceorientierte und signalbasierte Architekturen \u00fcber komplexe Integrationsgrenzen hinweg miteinander verschmelzen?<\/p>\n
SDVs definieren die Automobiltechnik neu \u2013 und das nicht nur durch mehr Code. Sie gestalten sie um.\u00a0Wo<\/i>\u00a0Die Software l\u00e4uft,\u00a0Wie<\/i>\u00a0Die Merkmale setzen sich zusammen, und\u00a0Was<\/i>\u00a0\u201cWas \u201dIntegration\u201c wirklich bedeutet, ist, dass die Funktionen \u00fcber verschiedene Rechenbereiche, Kommunikationsprotokolle und sogar unterschiedliche Organisationen hinwegreichen. Daher ben\u00f6tigen Teams Ans\u00e4tze, die von Anfang an daf\u00fcr sorgen, dass Architekturabsicht und Softwareverhalten \u00fcbereinstimmen.<\/p>\n
Diese architektonische Freiheit hat jedoch ihren Preis: Es gibt mehr Schnittstellen, mehr Zeitabl\u00e4ufe, mehr Fehlerm\u00f6glichkeiten und mehr Wege, wie kleine Abweichungen erst sp\u00e4t sichtbar werden k\u00f6nnen, insbesondere wenn Fahrzeuge, Zulieferer und Zeitpl\u00e4ne bereits feststehen. In diesem Umfeld m\u00fcssen System- und Softwareentwickler fr\u00fchzeitig die richtigen Entscheidungen treffen und diese kontinuierlich mithilfe von Modellen und Simulationen validieren.<\/p>\n
Um Unternehmen bei dieser Herausforderung zu unterst\u00fctzen, vereinen KPIT und MathWorks bew\u00e4hrte Methoden, umfassendes Fachwissen im Automobilbereich und eine integrierte Toolchain, die Systemabsichten mit ausf\u00fchrbaren Modellen verkn\u00fcpft. Das Ergebnis ist ein durchg\u00e4ngiger, nachvollziehbarer Workflow, der fr\u00fchzeitige Architektur- und Softwareentscheidungen sowie die kontinuierliche Validierung durch Simulation unterst\u00fctzt und die Absichten der Stakeholder (als zentrale Informationsquelle) mit Architekturentscheidungen, einsetzbarer Software und Verifizierungsnachweisen verbindet.<\/p>\n
Wichtigste Herausforderungen bei verteilten SDV-Funktionen<\/h2>\n
Die Entwicklung von SDV-Funktionen scheitert selten an \u201cschlechtem Code\u201d eines einzelnen Teams. Sie scheitert vielmehr daran, dass die Funktion die Grenzen von Steuerger\u00e4ten \u00fcberschreitet, serviceorientierte und signalbasierte Interaktionen vermischt und L\u00fccken zwischen Design und Implementierung aufdeckt. Diese L\u00fccken bleiben oft bis zur sp\u00e4ten Integration verborgen \u2013 daher entscheiden die folgenden Herausforderungen h\u00e4ufig dar\u00fcber, ob ein Programm komplexe Funktionen schnell und zuverl\u00e4ssig bereitstellen kann:<\/p>\n
- \n
- Unklare Anforderungen im gro\u00dfen Ma\u00dfstab:<\/strong> Funktionale und nichtfunktionale Anforderungen m\u00fcssen Verteilung, Zeitplanung, Teilausf\u00e4lle, Sicherheit und Cybersicherheit ber\u00fccksichtigen.<\/li>\n
- Architekturentscheidungen wirken sich nachgelagert aus:<\/strong> Service- versus Signalwahl und Steuerger\u00e4tezuordnung steuern Schnittstellen, Softwarepartitionierung und Verifizierungsaufwand.<\/li>\n
- Team\u00fcbergreifende Abstimmung:<\/strong> Multidom\u00e4nen-Teams ben\u00f6tigen gemeinsam genutzte, nachvollziehbare Modelle, um Nacharbeiten im Nachhinein zu vermeiden.<\/li>\n
- Toolchain-Fragmentierung:<\/strong> Unverbundene Tools behindern die R\u00fcckverfolgbarkeit und die Validierung im \u201cShift-Left\u201d-Verfahren; die virtuelle Integration erfordert konsistente Architektur- und Verhaltensmodelle.<\/li>\n<\/ul>\n
Ein einheitlicher Workflow f\u00fcr modellbasierte Systementwicklung und modellbasiertes Design<\/h2>\n
Dieser Artikel stellt einen funktionsorientierten Entwicklungsansatz vor, der modellbasierte Systementwicklung (System-\/Funktionsabsicht, Anforderungen und Architektur) mit modellbasiertem Design (ausf\u00fchrbare Softwaremodelle, Simulation und Codegenerierung) vereint. Der Workflow folgt einem systematischen Top-Down-Ansatz f\u00fcr 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\u00e4te umfassen und serviceorientierte sowie signalbasierte Interaktionen kombinieren.<\/p>\n
Dieser Ansatz beschleunigt die Bereitstellung neuer Funktionen durch die Integration und Validierung verteilter Funktionen in einer simulierten Umgebung mithilfe vernetzter Steuerger\u00e4te- und Softwarekomponentenmodelle. Er verbessert zudem die durchg\u00e4ngige R\u00fcckverfolgbarkeit f\u00fcr Wirkungsanalysen und die Einhaltung von Vorschriften und reduziert Nacharbeiten in sp\u00e4ten Phasen bei der Bereitstellung auf zentralen, zonalen und Edge-Steuerger\u00e4ten.<\/p>\n
In der Praxis ben\u00f6tigen Teams eine M\u00f6glichkeit, Architekturentscheidungen fr\u00fchzeitig testbar zu machen: Kann diese Funktion die Timing-Anforderungen in verschiedenen Zonen erf\u00fcllen, Teilausf\u00e4lle \u00fcberstehen, Sicherheits- und Cybersicherheitsauflagen erf\u00fcllen und dennoch konsistent auf AUTOSAR\u00ae Classic\/Adaptive-Zielen implementiert werden? Ein einheitlicher modellbasierter Systementwicklungs- und modellbasierter Design-Workflow macht diese Fragen explizit \u2013 und beantwortbar \u2013 vor der Hardware- und Fahrzeugintegration.<\/p>\n
Lassen Sie uns die wichtigsten Arbeitsschritte des funktionsorientierten Ansatzes durchgehen:<\/strong><\/p>\n
- \n
- Funktionsumfang:<\/strong> Die Bed\u00fcrfnisse der Stakeholder erfassen, Funktionsgrenzen, Akteure und Abh\u00e4ngigkeiten definieren.<\/li>\n
- Anforderungen:<\/strong> Anwendungsf\u00e4lle und Verhaltensweisen definieren, Systemanforderungen (funktionale und nichtfunktionale) mit klaren Akzeptanzkriterien ableiten.<\/li>\n
- Systemarchitektur:<\/strong> Funktionale Architektur (Funktionen und Interaktionen), plattformunabh\u00e4ngige Subsystemidentifizierung und -architektur sowie plattformabh\u00e4ngige Systemarchitektur (Steuerger\u00e4te\/Netzwerke und Service- versus Signalentscheidungen) erstellen und validieren.<\/li>\n
- Softwarearchitektur:<\/strong> Ableitung von Softwareanforderungen und Softwarearchitektur pro Steuerger\u00e4t (HPC\/Zone\/Edge), abgestimmt auf AUTOSAR Classic\/Adaptive oder kundenspezifische Anforderungen.<\/li>\n
- Detailliertes Software-Design:<\/strong> Entwickeln Sie ausf\u00fchrbare Modelle f\u00fcr Algorithmen und Komponentenverhalten und nutzen Sie nach M\u00f6glichkeit vorhandene Ressourcen wieder.<\/li>\n
- Funktionale Verifizierung:<\/strong> F\u00fchren Sie Modell-in-the-Loop-\/Closed-Loop-Simulationen durch, um das Verhalten zu validieren, bevor die Hardware verf\u00fcgbar ist.<\/li>\n
- Codegenerierung und -integration:<\/strong> Generieren Sie produktionsreifen AUTOSAR Classic\/Adaptive- oder benutzerdefinierten Code mit nahtloser Integration in CI- und Verifizierungsworkflows.<\/li>\n<\/ul>\n
Dies sind die wichtigsten Vorteile, die sich durch die Befolgung des vorgeschlagenen Ansatzes ergeben:<\/p>\n
- \n
- Fr\u00fcherkennung von M\u00e4ngeln:<\/strong> Ausf\u00fchrbare Modelle und Simulationen decken Integrations- und Timingprobleme vor der Hardware- und Komplettfahrzeugintegration auf.<\/li>\n
- Schnellere Iterationen:<\/strong> Virtuelle Integrationstests reduzieren Nachbearbeitungszyklen und beschleunigen die Funktionsbereitstellung.<\/li>\n
- Nachvollziehbare Entwicklung:<\/strong> Durch konsistente Verkn\u00fcpfungen zwischen den Artefakten k\u00f6nnen Abdeckungspr\u00fcfungen durchgef\u00fchrt und die Auswirkungen bei \u00c4nderungen der Anforderungen effizient analysiert werden.<\/li>\n
- Wiederverwendbare Architekturelemente:<\/strong> Die logische Architektur bietet eine plattformunabh\u00e4ngige Referenz f\u00fcr wiederverwendbare Systeme in verschiedenen Fahrzeugprogrammen.<\/li>\n
- Einsatzbereite Ausgaben:<\/strong> Die Softwarearchitektur und die Codegenerierung sind auf AUTOSAR Classic\/Adaptive und gemischte SOA\/Signal-Kommunikation abgestimmt.<\/li>\n<\/ul>\n
Im weiteren Verlauf des Artikels werden wir den Ansatz anhand eines realen Anwendungsfalls demonstrieren.<\/strong><\/p>\n
Beispiel: Entwicklung einer Ladeklappen-Verwaltungsfunktion<\/strong><\/p>\n
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 \u00fcber die Architekturzuordnung und Simulation bis hin zur Generierung des Produktionscodes reicht, ohne dabei die Nachvollziehbarkeit zu verlieren.<\/p>\n
Ein Klappenmanagementsystem steuert die Ladeklappe des Fahrzeugs (Abbildung 1). Es gleicht kontinuierlich die physikalischen Gegebenheiten (z. B. Positionserfassung, Aktuatorstatus und Verriegelungsr\u00fcckmeldung) mit dem Ladekontext (z. B. Fahrzeugzustand, Status des Onboard-Ladeger\u00e4ts und Signale der Ladestation) ab, um zu entscheiden, wann die Klappe ge\u00f6ffnet, geschlossen oder verriegelt werden soll. Anschlie\u00dfend sendet das System Statusaktualisierungen und Warnungen an den Fahrer und andere Fahrzeugfunktionen. Durch die Integration von Sensorik, Aktorik und Steuerger\u00e4tekoordination bietet das Klappenmanagementsystem ein kleines, aber realistisches Modell f\u00fcr die Entwicklung umfassenderer verteilter Funktionen f\u00fcr autonomes Fahren.<\/p>\n
\nAbbildung 1. Ladeklappe des Fahrzeugs.<\/em><\/strong><\/p>\nFunktionsumfang<\/h2>\n
Wir definieren die Feature-Grenzen (Akteure, Eingaben\/Ausgaben und Abh\u00e4ngigkeiten), um einen gemeinsamen Rahmen festzulegen und die Anforderungserhebung und -analyse zu unterst\u00fctzen.<\/p>\n
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\u00e4t, das auch als Gateway dient, und Edge-Steuerger\u00e4ten besteht, die f\u00fcr die Echtzeit-Erfassung und -Aktorik zust\u00e4ndig sind.<\/p>\n
In diesem Schritt f\u00fchren wir eine Wirkungsanalyse durch und verwenden System Composer\u2122, 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).<\/p>\n
\nAbbildung 2. Merkmalsgrenzendiagramm.<\/em><\/strong><\/p>\nFunktionsebene<\/strong>
\nWir erfassen die wichtigsten Anwendungsf\u00e4lle und leiten das Funktionsverhalten mithilfe eines Anwendungsfalldiagramms ab. Anschlie\u00dfend \u00fcbersetzen wir dieses Verhalten in klare Systemanforderungen. Wir identifizieren zwei Anwendungsf\u00e4lle: \u201cLadevorgang starten\u201d und \u201cLadevorgang beenden\u201d (Abbildung 3).<\/p>\n
\nAbbildung 3. Anwendungsfalldiagramm.<\/em><\/strong><\/p>\nNachdem die beiden Anwendungsf\u00e4lle identifiziert wurden, werden im n\u00e4chsten Schritt die verschiedenen Aktivit\u00e4ten definiert, die das Feature in jedem Anwendungsfall ausf\u00fchrt. Dies hilft, das Verhalten des Features zu beschreiben und erste Systemanforderungen f\u00fcr das Flap-Management zu erfassen. Anschlie\u00dfend erstellen wir mit System Composer Aktivit\u00e4tsdiagramme (Abbildung 4).<\/p>\n
\nAbbildung 4. Aktivit\u00e4tsdiagramm zur Veranschaulichung der Ladeklappenbet\u00e4tigung.<\/em><\/strong><\/p>\nAufbauend auf der vorangegangenen Analyse und den Diagrammen k\u00f6nnen wir nun mithilfe des Anforderungseditors, der Teil der Requirements Toolbox\u2122 ist (Abbildung 5), die Systemanforderungen erstellen. Wir haben Anforderungen, die sich auf die Vorg\u00e4nge beziehen, wie z. B. das \u00d6ffnen und Schlie\u00dfen der Klappe und die Meldung des Klappenstatus.<\/p>\n
\nAbbildung 5. Systemanforderungen im Anforderungseditor.<\/em><\/strong><\/p>\nAls N\u00e4chstes erstellen wir eine funktionale Architektur und ordnen Anforderungen Funktionen zu, um die Nachvollziehbarkeit zu gew\u00e4hrleisten. Dies beinhaltet die Definition von:<\/p>\n
- \n
- Systemfunktionen:<\/strong> technische Funktionseinheiten, die gemeinsam das Merkmal realisieren<\/li>\n
- Interaktionen:<\/strong> wie diese Funktionen kommunizieren und zusammenarbeiten<\/li>\n<\/ul>\n
Auf Grundlage der Analyse der Systemanforderungen unterteilen wir die Ladeklappenfunktion in vier Funktionen (Abbildung 6):<\/p>\n
- \n
- Messen Sie den Strom der Ladebuchse<\/li>\n
- Klappenstatus abrufen und Benutzer benachrichtigen<\/li>\n
- Klappe schlie\u00dfen<\/li>\n
- Klappe \u00f6ffnen<\/li>\n<\/ul>\n
\nAbbildung 6. Funktionale Architektur.<\/em><\/strong><\/p>\nIm Rahmen der Definition der funktionalen Architektur ordnen wir jede Systemanforderung der\/den f\u00fcr ihre Erf\u00fcllung zust\u00e4ndigen Funktion(en) und gegebenenfalls der Interaktion zu, die die ben\u00f6tigten Informationen \u00fcbertr\u00e4gt. Diese Zuordnung stellt sicher, dass jede Anforderung durch Designelemente abgedeckt ist, macht L\u00fccken und \u00dcberschneidungen fr\u00fchzeitig sichtbar und gew\u00e4hrleistet die R\u00fcckverfolgbarkeit von Anforderungen zu Funktionen f\u00fcr den nachfolgenden logischen\/physikalischen Entwurf und die Verifizierung. Praktisch l\u00e4sst sich diese Zuordnung effizient per Drag & Drop von Anforderungen auf System Composer-Komponenten durchf\u00fchren (Abbildung 7).<\/p>\n
\nAbbildung 7. Zuordnung der Systemanforderungen zur funktionalen Architektur.<\/em><\/strong><\/p>\nPlattformunabh\u00e4ngige Subsystemidentifizierung und Architektur<\/h2>\n
Wir ordnen Funktionen logischen Subsystemen zu und definieren die logischen Schnittstellen zwischen ihnen, um eine wiederverwendbare, plattformunabh\u00e4ngige Architektursicht zu erstellen (Abbildung 8):<\/p>\n
- \n
- Ein Ladeschnittstellen-Subsystem, das f\u00fcr das \u00d6ffnen und Schlie\u00dfen der Klappe sowie f\u00fcr die Meldung des Klappenstatus zust\u00e4ndig ist.<\/li>\n
- Ein Ladekontrollsubsystem, das f\u00fcr die Koordination der Anfragen von der Kommunikationsschnittstelle und die Verwaltung aller Ladevorg\u00e4nge zust\u00e4ndig ist.<\/li>\n
- Ein Ladekommunikationssubsystem, das die Kommunikation mit dem Benutzer und dem Rest des Systems verwaltet.<\/li>\n<\/ul>\n
\nAbbildung 8. Detailansicht der plattformunabh\u00e4ngigen Architektur.<\/em><\/strong><\/p>\nPlattformabh\u00e4ngige Systemarchitektur<\/h2>\n
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\u00dflich derjenigen Interaktionen, die als Dienste oder Signale implementiert werden.<\/p>\n
Sobald wir die verschiedenen Komponenten identifiziert haben, k\u00f6nnen wir in System Composer ein Systemarchitekturdiagramm erstellen, das die Komponentengrenzen und die Informationen hervorhebt, die die Komponenten austauschen m\u00fcssen, um die Klappenverwaltungsfunktion zu implementieren (Abbildung 9).<\/p>\n
\nAbbildung 9. Systemarchitekturdiagramm.<\/em><\/strong><\/p>\nSoftwarearchitektur, Simulation und Codegenerierung<\/h2>\n
Aus den Systemanforderungen und der Systemarchitektur leiten wir die Softwareanforderungen und die Architektur pro Steuerger\u00e4t (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\u00e4hrend Zonen-\/Edge-Knoten zeitkritische Sensor-\/Aktorfunktionen (z. B. AUTOSAR Classic oder \u00c4quivalent) hosten. Schnittstellen (Dienste, Signale und Datentypen) werden konsistent von der physischen Architektur in Software-Ports und -Konnektoren \u00fcbertragen. Dies erm\u00f6glicht fr\u00fchzeitige Konsistenzpr\u00fcfungen, die Modellierung des ausf\u00fchrbaren Verhaltens und die Integration von Simulations-Hooks (f\u00fcr MIL\/SIL- und Closed-Loop-Simulationen), bevor die Zielhardware verf\u00fcgbar ist.<\/p>\n
Zun\u00e4chst erstellen wir die Softwarearchitektur auf oberster Ebene f\u00fcr HPC-, zonale ECU- und Edge-ECU-Kompositionen, die mit der Systemarchitektur verkn\u00fcpft sind (Abbildung 10).<\/p>\n
\nAbbildung 10. \u00dcbersicht der Softwarearchitektur auf oberster Ebene.<\/em><\/strong><\/p>\nWir haben Softwarekomponenten f\u00fcr jede Architekturkomposition innerhalb der Architekturmodellierungsoberfl\u00e4che in System Composer definiert und modelliert. Die HPC-Komposition umfasst drei AUTOSAR Adaptive Servicekomponenten, die in Simulink\u00ae unter Verwendung eines SOA-Paradigmas implementiert wurden (Abbildung 11).<\/p>\n
\nAbbildung 11. Ansicht der HPC-Softwarekomponenten.<\/em><\/strong><\/p>\nSobald die Implementierung der Funktion in den drei Steuerger\u00e4ten modelliert ist, kann ein geschlossenes Simulationsmodell erstellt werden, das die Steuerger\u00e4te mit einem Systemmodell der Klappe verbindet \u2013 einschlie\u00dflich Modellen des Stromsensors, des Positionssensors und des Aktuators \u2013 und so eine schnelle \u00dcberpr\u00fcfung des Funktionsverhaltens unter realistischen Bedingungen erm\u00f6glicht. Beispielsweise kann die Simulation genutzt werden, um zu bewerten, wie das System auf eine Benutzeranforderung zum \u00d6ffnen der Klappe bei unterschiedlichen Fahrzeuggeschwindigkeiten reagiert (Abbildung 12).<\/p>\n
\nAbbildung 12. Simulation eines geschlossenen Regelkreises einer Ladeklappe.<\/em><\/strong><\/p>\nNach Abschluss der Verifizierung besteht der n\u00e4chste Schritt im Workflow darin, mit Embedded Coder\u00ae produktionsreifen Code f\u00fcr die Integration und den Einsatz zu generieren (Abbildung 13). Simulink bietet standardm\u00e4\u00dfig Unterst\u00fctzung f\u00fcr die Generierung von AUTOSAR Classic- und AUTOSAR Adaptive-konformem Code und erm\u00f6glicht so die weitere Integration und den Einsatz.<\/p>\n
\nAbbildung 13. Generierung von C++-Produktionscode f\u00fcr die Flap-Request-Arbitrator-Software.<\/em><\/strong><\/p>\nWird eine neue Anforderung eingef\u00fchrt, kann diese auf Systemebene erfasst und einer Auswirkungsanalyse unterzogen werden, um betroffene Elemente zu identifizieren. Die resultierenden \u00c4nderungen werden visualisiert und an die relevanten System- und Softwareschnittstellen weitergegeben. Anschlie\u00dfend wird der Workflow iterativ angepasst, um den sich \u00e4ndernden Anforderungen gerecht zu werden. Dieser Prozess wird durch durchg\u00e4ngige R\u00fcckverfolgbarkeit erm\u00f6glicht, wobei das R\u00fcckverfolgbarkeitsdiagramm (Abbildung 14) zur Verwaltung dynamischer \u00c4nderungen w\u00e4hrend des gesamten SDV-Entwicklungszyklus dient.<\/p>\n
\nAbbildung 14. R\u00fcckverfolgbarkeitsdiagramm zur Verdeutlichung der Auswirkungen auf verschiedenen Ebenen.<\/em><\/strong><\/p>\nMigration von Altanwendungen<\/h2>\n
\u00dcber die Entwicklung neuer Funktionen hinaus unterst\u00fctzt derselbe integrierte Workflow auch die systematische Migration bestehender, signalbasierter Funktionen hin zu serviceorientierten, verteilten Softwarearchitekturen. Konkret lassen sich bestehende Funktionen, die urspr\u00fcnglich als eng gekoppelte, ausf\u00fchrbare 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\u00e4gen umstrukturieren. Dadurch bleibt das validierte Funktionsverhalten erhalten, w\u00e4hrend die Verantwortlichkeiten zwischen HPCs, Zonencontrollern und Edge-ECUs neu verteilt werden. Zudem erm\u00f6glicht es die Bewertung der Auswirkungen von Kommunikations\u00e4nderungen auf Timing, Sicherheit und Integration. Da Anforderungen, Architekturelemente, Softwarekomponenten und Verifizierungsartefakte nachvollziehbar miteinander verbunden bleiben, k\u00f6nnen Teams bestehende Implementierungen schrittweise modernisieren \u2013 Testf\u00e4lle und Konformit\u00e4tsnachweise wiederverwenden und gleichzeitig die \u00dcbereinstimmung zwischen migrierten Diensten und der urspr\u00fcnglichen Designabsicht wahren.<\/p>\n
Abschluss<\/h2>\n
Die Integration von modellbasierter Systementwicklung und modellbasiertem Design bietet einen praktischen, durchg\u00e4ngigen Workflow f\u00fcr die SDV-Funktionsentwicklung. Dies erm\u00f6glicht eine klarere Systemabsicht, eine fr\u00fchere Verifizierung durch Simulation und die Bereitstellung von Softwareartefakten. Dieser Ansatz ist explizit funktionsorientiert und so strukturiert, dass die R\u00fcckverfolgbarkeit \u00fcber alle Designphasen hinweg gew\u00e4hrleistet ist. Dadurch bleiben die technischen Entscheidungen von der Konzeption bis zur Implementierung konsistent. Der Nutzen ist sp\u00fcrbar: Der Workflow erm\u00f6glicht schnellere Iterationen, weniger \u00dcberraschungen bei der sp\u00e4ten Integration und eine konsistentere Implementierung in heterogenen Steuerger\u00e4ten und gemischten SOA-\/Signalarchitekturen.<\/p>\n
W\u00e4hrend die Branche KI-gest\u00fctzte Entwicklungsmethoden \u2013 einschlie\u00dflich neuartiger agentenbasierter KI-Ans\u00e4tze \u2013 erforscht, stellen sich Fragen zur Rolle etablierter Entwicklungsmethoden. In diesem neuen Kontext wird der Wert modellbasierter Systementwicklung und modellbasierter Designans\u00e4tze noch deutlicher: In einem Entwicklungsprozess, in dem Mensch und KI zunehmend zusammenarbeiten, bieten diese Ans\u00e4tze die notwendige Strenge, um Anforderungen zu verankern, die Systemabsicht zu kl\u00e4ren und Architektur, Verhalten und Verifikation aufeinander abzustimmen. Damit bilden sie eine entscheidende Grundlage f\u00fcr die Entwicklung von SDV-Software, die nicht nur innovativ, sondern auch vertrauensw\u00fcrdig und wartungsfreundlich ist.<\/p>\n
Durch die Nutzung der Automobilexpertise von KPIT und der von MathWorks bereitgestellten Toolchain-Kontinuit\u00e4t st\u00e4rkt das vorgeschlagene Framework die Zusammenarbeit zwischen Architekten, Softwareentwicklern und Integrationsingenieuren, verbessert die R\u00fcckverfolgbarkeit von Anforderungen zu Architekturen und unterst\u00fctzt zunehmend komplexe Systemdefinitionen, ohne die Machbarkeit zu beeintr\u00e4chtigen.<\/p>\n
Verwendete Produkte<\/h2>\n
- \n
- System Composer<\/li>\n
- AUTOSAR Blockset<\/li>\n
- Simulink-Anforderungen<\/li>\n
- Eingebetteter Coder<\/li>\n<\/ul>\n
<\/p>","protected":false},"excerpt":{"rendered":"
A Unified Approach for Feature Development of SDV Distributed Architectures Using a Feature-Driven Workflow to Connect Requirements, Architecture, Simulation, and Deployment. Summary You can use a feature-driven workflow to connect requirements, architecture decisions, and deployable software for software-defined vehicle development. Unifying model-based systems engineering with Model-Based Design helps you validate distributed features early with simulation, […]<\/p>\n","protected":false},"author":23,"featured_media":29485,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"insight-style-landing-page.php","meta":{"_acf_changed":false,"footnotes":""},"class_list":["post-29499","page","type-page","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\n
A Unified Approach to SDV Distributed FeatureDevelopment | KPIT<\/title>\n<meta name=\"description\" content=\"See how a feature-driven MBSE and Model-Based Designworkflow connects requirements, architecture, simulationand deployable code across HPC, zonal and edge ECUs inSDVs.\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/\" \/>\n<meta property=\"og:locale\" content=\"de_DE\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"A Unified Approach for Feature Development of SDV Distributed Architectures\" \/>\n<meta property=\"og:description\" content=\"See how a feature-driven MBSE and Model-Based Designworkflow connects requirements, architecture, simulationand deployable code across HPC, zonal and edge ECUs inSDVs.\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/\" \/>\n<meta property=\"og:site_name\" content=\"KPIT\" \/>\n<meta property=\"article:modified_time\" content=\"2026-09-16T07:21:04+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg\" \/>\n\t<meta property=\"og:image:width\" content=\"960\" \/>\n\t<meta property=\"og:image:height\" content=\"540\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/jpeg\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Gesch\u00e4tzte Lesezeit\" \/>\n\t<meta name=\"twitter:data1\" content=\"14\u00a0Minuten\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/\",\"name\":\"A Unified Approach to SDV Distributed FeatureDevelopment | KPIT\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg\",\"datePublished\":\"2026-09-15T12:04:26+00:00\",\"dateModified\":\"2026-09-16T07:21:04+00:00\",\"description\":\"See how a feature-driven MBSE and Model-Based Designworkflow connects requirements, architecture, simulationand deployable code across HPC, zonal and edge ECUs inSDVs.\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#breadcrumb\"},\"inLanguage\":\"de\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#primaryimage\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg\",\"contentUrl\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2026\\\/09\\\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg\",\"width\":960,\"height\":540},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/www.kpit.com\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"A Unified Approach for Feature Development of SDV Distributed Architectures\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/#website\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/\",\"name\":\"KPIT\",\"description\":\"Technology, Mobility, Software, Automotive\",\"publisher\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"de\"},{\"@type\":[\"Organization\",\"Place\"],\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/#organization\",\"name\":\"KPIT Technologies\",\"alternateName\":\"KPIT\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/\",\"logo\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#local-main-organization-logo\"},\"image\":{\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#local-main-organization-logo\"},\"sameAs\":[\"https:\\\/\\\/www.linkedin.com\\\/company\\\/kpit\\\/\",\"https:\\\/\\\/www.instagram.com\\\/kpittechnologies\\\/?hl=en\",\"https:\\\/\\\/www.youtube.com\\\/channel\\\/UC6AZI50H33ni75FAi-5mgqw\"],\"telephone\":[],\"openingHoursSpecification\":[{\"@type\":\"OpeningHoursSpecification\",\"dayOfWeek\":[\"Monday\",\"Tuesday\",\"Wednesday\",\"Thursday\",\"Friday\",\"Saturday\",\"Sunday\"],\"opens\":\"09:00\",\"closes\":\"17:00\"}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"de\",\"@id\":\"https:\\\/\\\/www.kpit.com\\\/de\\\/bridging-system-and-software\\\/#local-main-organization-logo\",\"url\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2025\\\/06\\\/favicon-1.png\",\"contentUrl\":\"https:\\\/\\\/www.kpit.com\\\/wp-content\\\/uploads\\\/2025\\\/06\\\/favicon-1.png\",\"width\":512,\"height\":512,\"caption\":\"KPIT Technologies\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Ein einheitlicher Ansatz f\u00fcr die verteilte Feature-Entwicklung mit SDV | KPIT","description":"Erfahren Sie, wie ein funktionsorientierter MBSE- und modellbasierter Design-Workflow Anforderungen, Architektur, Simulation und bereitstellbaren Code \u00fcber HPC-, zonale und Edge-ECUs in SDVs hinweg verbindet.","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/","og_locale":"de_DE","og_type":"article","og_title":"A Unified Approach for Feature Development of SDV Distributed Architectures","og_description":"See how a feature-driven MBSE and Model-Based Designworkflow connects requirements, architecture, simulationand deployable code across HPC, zonal and edge ECUs inSDVs.","og_url":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/","og_site_name":"KPIT","article_modified_time":"2026-09-16T07:21:04+00:00","og_image":[{"width":960,"height":540,"url":"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg","type":"image\/jpeg"}],"twitter_card":"summary_large_image","twitter_misc":{"Gesch\u00e4tzte Lesezeit":"14\u00a0Minuten"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/","url":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/","name":"Ein einheitlicher Ansatz f\u00fcr die verteilte Feature-Entwicklung mit SDV | KPIT","isPartOf":{"@id":"https:\/\/www.kpit.com\/de\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#primaryimage"},"image":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#primaryimage"},"thumbnailUrl":"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg","datePublished":"2026-09-15T12:04:26+00:00","dateModified":"2026-09-16T07:21:04+00:00","description":"Erfahren Sie, wie ein funktionsorientierter MBSE- und modellbasierter Design-Workflow Anforderungen, Architektur, Simulation und bereitstellbaren Code \u00fcber HPC-, zonale und Edge-ECUs in SDVs hinweg verbindet.","breadcrumb":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#breadcrumb"},"inLanguage":"de","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.kpit.com\/de\/bridging-system-and-software\/"]}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#primaryimage","url":"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg","contentUrl":"https:\/\/www.kpit.com\/wp-content\/uploads\/2026\/09\/KPIT-AND-Mathwork-WHITEPAPER-960x540-1.jpg","width":960,"height":540},{"@type":"BreadcrumbList","@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/www.kpit.com\/"},{"@type":"ListItem","position":2,"name":"A Unified Approach for Feature Development of SDV Distributed Architectures"}]},{"@type":"WebSite","@id":"https:\/\/www.kpit.com\/de\/#website","url":"https:\/\/www.kpit.com\/de\/","name":"KPIT","description":"Technologie, Mobilit\u00e4t, Software, Automotive","publisher":{"@id":"https:\/\/www.kpit.com\/de\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.kpit.com\/de\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"de"},{"@type":["Organization","Place"],"@id":"https:\/\/www.kpit.com\/de\/#organization","name":"KPIT Technologies","alternateName":"KPIT","url":"https:\/\/www.kpit.com\/de\/","logo":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#local-main-organization-logo"},"image":{"@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#local-main-organization-logo"},"sameAs":["https:\/\/www.linkedin.com\/company\/kpit\/","https:\/\/www.instagram.com\/kpittechnologies\/?hl=en","https:\/\/www.youtube.com\/channel\/UC6AZI50H33ni75FAi-5mgqw"],"telephone":[],"openingHoursSpecification":[{"@type":"OpeningHoursSpecification","dayOfWeek":["Monday","Tuesday","Wednesday","Thursday","Friday","Saturday","Sunday"],"opens":"09:00","closes":"17:00"}]},{"@type":"ImageObject","inLanguage":"de","@id":"https:\/\/www.kpit.com\/de\/bridging-system-and-software\/#local-main-organization-logo","url":"https:\/\/www.kpit.com\/wp-content\/uploads\/2025\/06\/favicon-1.png","contentUrl":"https:\/\/www.kpit.com\/wp-content\/uploads\/2025\/06\/favicon-1.png","width":512,"height":512,"caption":"KPIT Technologies"}]}},"_links":{"self":[{"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/pages\/29499","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/users\/23"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/comments?post=29499"}],"version-history":[{"count":3,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/pages\/29499\/revisions"}],"predecessor-version":[{"id":29511,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/pages\/29499\/revisions\/29511"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/media\/29485"}],"wp:attachment":[{"href":"https:\/\/www.kpit.com\/de\/wp-json\/wp\/v2\/media?parent=29499"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Interaktionen:<\/strong> wie diese Funktionen kommunizieren und zusammenarbeiten<\/li>\n<\/ul>\n
- Schnellere Iterationen:<\/strong> Virtuelle Integrationstests reduzieren Nachbearbeitungszyklen und beschleunigen die Funktionsbereitstellung.<\/li>\n
- Anforderungen:<\/strong> Anwendungsf\u00e4lle und Verhaltensweisen definieren, Systemanforderungen (funktionale und nichtfunktionale) mit klaren Akzeptanzkriterien ableiten.<\/li>\n
- Architekturentscheidungen wirken sich nachgelagert aus:<\/strong> Service- versus Signalwahl und Steuerger\u00e4tezuordnung steuern Schnittstellen, Softwarepartitionierung und Verifizierungsaufwand.<\/li>\n