Systems Engineering (SYS)

In diesem Artikel sind Informationen über das Systems Engineering enthalten. Die Geschichte des Systems Engineering sowie die Besonderheiten der Systementwicklung im Automotive-Bereich werden unten erklärt.

Des Weiteren sind in diesem Artikel die praktischen Herausforderungen und zukünftigen Aussichten erörtert.

*1) Um Grafiken zu vergrößern, benutzen Sie die rechte Maustaste und die Option: “Bild in neuem Tab öffnen”.

Eine der größten Herausforderungen im Systems Engineering liegt in der Bewältigung zunehmender Komplexität, strenger Sicherheitsanforderungen und erhöhter Zuverlässigkeitsansprüche. Entwicklungsteams benötigen daher klar definierte, dokumentierte und strukturierte Prozesse, die bereits zu Beginn eines Projekts eine systematische Arbeitsweise ermöglichen.

Im Folgenden werden die zentralen Schritte und Abläufe im Systems Engineering zusammengefasst:

• Identifizierung und Analyse von relevanten Kundenanforderungen für die beteiligten elektronischen Komponenten, Softwaremodule, Aktuatoren, Sensoren und Kommunikationsnetzwerke
• Erstellung des Systementwurfs/Systemarchitektur und Sicherheitskonzeptes
• Erstellung der technischen Spezifikation
• Integration von Software, Hardware und Test

Dieses strukturierte Vorgehen fördert in eingebetteten Automobilsystemen das reibungslose Zusammenspiel der Disziplinen – von Software und Hardware über mechanische Komponenten bis zu Kommunikationsprotokollen – und stärkt die bereichsübergreifende Zusammenarbeit zwischen Designteams, Embedded-Software-Entwicklern und Testteams.

An dieser Stelle beabsichtige ich einen prägnanten historischen Exkurs und fasse zusammen die wesentlichen historischen Informationen nebst einigen spannenden Fakten zur Entwicklung des Systems Engineerings zusammen.

Seit dem Aufkommen größerer und komplexerer Projekte in den 1940er Jahren im militärischen und industriellen Sektor strebte man insbesondere in Nordamerika [7] danach, die gestiegenen Komplexitätsanforderungen zu bewältigen. In dieser Zeit etablierte sich der Begriff “Systems Engineering” (oder auf Deutsch “Systemtechnik”) als eigenständige Disziplin [6].

Mit dem Beginn der Weltraummissionen in den 1960er und 1970er Jahren gewann der Einsatz eines systematischen Systems Engineerings erheblich an Bedeutung [4], da die strukturierten Methoden im Systems Engineering es ermöglichten, die Projektentwicklung auf ein neues, höheres Niveau zu heben.

Im Jahr 1990 wurde INCOSE (International Council on Systems Engineering) gegründet, eine Organisation, die maßgeblich zur Internationalisierung und Standardisierung der Systems-Engineering-Praktiken und Best Practices beitrug.

2002 wurde der international anerkannte Standard ISO/IEC 15288 [5] eingeführt, welcher ein einheitliches Rahmenwerk für die Planung, Realisierung und Wartung von Lebenszyklusprozessen bereitstellt.

Der Standard ISO 26262 hat seit seiner Einführung im Jahr 2011 einen signifikanten Einfluss auf die Entwicklung sicherheitskritischer Systeme in der Automobilindustrie gewonnen. Dieser Standard dient insbesondere der Absicherung gegen Verletzungen von Insassen, Passanten und anderen Verkehrsteilnehmern im Straßenverkehr.

Es gibt viele Definitionen von Systems Engineering, welche aber gemeinsame wesentliche Merkmale besitzen: die systematische Entwicklung und Zusammenführung von unterschiedlichen Disziplinen in der Art, dass am Ende ein robustes und sicheres Produkt entsteht, welches allen Kundenanforderungen entspricht.

Die INCOSE- Definition: „Systems Engineering ist ein transdisziplinärer und integrativer Ansatz, der die erfolgreiche Realisierung, Nutzung und Stilllegung technischer Systeme unter Verwendung von Systemprinzipien und -konzepten sowie wissenschaftlichen, technologischen und Managementmethoden ermöglicht“ [3].

Hier ist noch eine Definition, welche im NASA Systems Engineering Handbook zu finden ist: „Systems Engineering ist ein methodischer, multidisziplinärer Ansatz zur Konzeption, Realisierung und Ausmusterung technischer Systeme“.

Der Standard ISO/IEC/IEEE 15288 beschreibt Systems Engineering als: „Satz von Aktivitäten, der sich über den Lebenszyklus eines Systems erstreckt, einen Problemraum und einen Lösungsraum identifiziert und Ergebnisse liefert, die den Bedürfnissen der Stakeholder entsprechen“.

In modernen Fahrzeugen gibt es unterschiedliche Architekturen. Früher wurde in der Regel die zentralisierte Architektur verwendet. Diese Architektur wird zunehmend von Domänenarchitektur ersetzt, die auch heute noch aktuell ist. Die heutige Entwicklung führt von der Domänenarchitektur zur zonalen Architektur.

In den Abschnitten unten wird die Domänenarchitektur thematisiert.

Es sind folgende Domänen in der Fahrzeugarchitektur vorhanden:

• Antriebsstrang (Powertrain),
• Infotainment-Module,
• Fahrwerkskomponenten (Chassis),
• Systeme für Advanced Driver Assistance Systems (ADAS)
• Elektromobilitätstechnologien (EV)

Jede Domäne stützt sich auf Steuergeräte wie Electronic Control Units (ECU), Sensoren, Aktuatoren und Kommunikationsbusse wie den Controller Area Network (CAN), Local Interconnect Network (LIN), Ethernet oder MOST (Media Oriented Systems Transport), um reibungslos zu funktionieren.

Unten findet man eine Übersicht über die Fahrzeug-Domänen und kurze Erklärung dafür:

• Powertrain:
  • In der Powertrain-Domäne sind die Komponenten vorhanden, die Antriebsleistung erzeugen und an die Fahrzeugräder übertragen. Zu diesen Systemen zählen unter anderem: Motor-/Elektromotor-Steuergeräte, Getriebe und andere Antriebssysteme. Diese Systeme verfolgen Ziele, wie:
    • Zurverfügungstellung von Antriebsleistung,
    • Steuerung und Überwachung von effizienter Kraftstoff-/Batterienutzung,
    • Steuerung von Drehmomentübertragung und
    • Kommunikation mit anderen Domänen über Systembusse wie Ethernet, CAN etc.
  • Es gibt im Powertrain folgende Steuergeräte:
    • Engine Control Unit (ECU),
    • Transmission Control Unit (TCU),
    • Hybrid Control Unit (HCU)
    • Batteriemanagement System (BMS) (Niedervoltbattery) etc.

• Infotainment:
  • Diese Domäne beinhaltet die Steuergeräte, welche einem Insassen ermöglichen, das Fahrzeug zu bedienen und unterschiedliche Infotainment-Funktionen zu nutzen. Darunter fallen folgende Steuergeräte:
    • Head-Units (HU),
    • Display (DISP),
    • Navigationssysteme (NAV),
    • Telematik Control Unit (TCU),
    • Audio-Systeme etc.

• Chassis:
  • Die Chassis-Domäne beinhaltet Fahrwerksregelungen, Lenkungssysteme, Bremsmodule und Stabilitätskontrolle. Die Entwicklung stellt sicher, dass diese Systeme schnell reagieren, unter harten Bedingungen Stabilität aufrechterhalten und für ein sicheres, zuverlässiges und komfortables Fahrerlebnis sorgen.
  • In der Domäne sind folgende Steuergeräte vorhanden:
    • Antiblockiersystem (ABS),
    • Traktionskontrolle (TSC),
    • elektronisches Stabilitätsprogramm (ESP),
    • Suspension Control Unit (SCU),
    • Elektronische Parkbremse (EPB) etc.

• ADAS (Advanced Driver Assistance Systems):
  • Die ADAS-Domäne bietet Funktionen wie Spurhalteassistent, adaptive Geschwindigkeitsregelung, Notbremsassistent und Verkehrszeichenerkennung. Die Systeme enthalten integrierte Kameras, Radare, Lidar-Sensoren, Ultraschallsensoren und leistungsstarke Prozessoren, die Sensordaten interpretieren und Echtzeit-Entscheidungen treffen.
  • Folgende ECUs sind in dieser Domäne vorhanden:
    • Spurhalteassistent (SHA),
    • Radar Control Unit (RCU),
    • Lidar Control Unit (LCU),
    • Ultrasonic Sensor Control Unit (USCU),
    • Automated Driving Control Unit (ADCU) etc.

• EV (Electric Vehicle):
  • Mit dem Aufkommen der Elektromobilität beschäftigt sich die EV-Domäne mit Batteriemanagementsystemen (BMS), Umrichtern, Elektromotoren, Ladeschnittstellen und Thermomanagement. Die Systeme in dieser Domäne stellen sicher, dass Batteriemodule korrekt kommunizieren, Sicherheitsgrenzen beim Laden und Entladen einhalten und sich nahtlos in das restliche Energiesystem des Fahrzeugs integrieren.
  • Hier ist eine Liste der wichtigsten ECUs in der EV-Domäne:
    • Batteriemanagement (Hochvoltbattery) (BMS),
    • Vehicle Control Unit (VCU),
    • Electric Motor Control Unit (EMCU),
    • On-Board-Charger (OBC),
    • DC/DC-Wandler Steuergerät (DCDC),
    • HV Junction Box (HVJB) etc.

Der Standard ASPICE (Automotive Software Process Improvement and Capability dEtermination) legt die Richtlinien für die Prozessbeschreibung während der Entwicklung eines Automotive-Produkts fest. Die Norm ISO 26262 definiert die Mechanismen, welche die Gefahren erkennen, spezifische Maßnahmen bereitstellen und letztlich sicherheitskritische Situationen für den Menschen verhindern. Das Systems Engineering muss die Anforderungen beider Normen berücksichtigen und erfüllen.

Im ASPICE-Standard sind die folgenden Kapitel für das Systems Engineering relevant:

• SYS.1 System Requirements Analysis
  • Ableitung von Systemanforderungen aus Kundenanforderungen.
• SYS.2 System Architectural Design
  • Erstellung der Systemarchitektur anhand der abgeleiteten Systemanforderungen.
• SYS.3 Systemintegration und Integration Test
  • Integration von Systemkomponenten entsprechend der Systemarchitektur. Ausführen von Systemtests (Systemintegration) anhand eines vordefinierten Integrationsplan-Dokuments.
• SYS.4 System Qualification Test
  • Test der umgesetzten Systemanforderungen auf Systemebene (ergänzend zur Systemintegration).

Hier ist ein Link für zur Übersicht der SYS-Gruppe in ASPICE.

In der Liste unten gibt es die Anforderungen für Systems Engineering aus der Norm ISO 26262:

• Teil 3, Kapitel 6: Hazard Analysis and Risk Assessment (HARA)
  • Identifizierung von potenziellen Gefährdungen, Bewertung des Schweregrads, Bestimmung von Exposition und Kontrollierbarkeit.
• Teil 3, Kapitel 7: Functional Safety Concept (FSC)
  • Ableitung von funktionalen Sicherheitsanforderungen auf Systemebene.
• Teil 4, Abschnitt 6: Technical safety concept
  • Technische Anforderungen (detailliert)
• Teil 4, Abschnitt 7: System and item Integration and testing
  • Integration von Systemelementen gemäß der Architektur, Durchführung von Integrationstests, Dokumentation der Ergebnisse.
• Teil 4, Abschnitt 8: Safety validation
  • Validierung des integrierten Systems gegen FSC.
  • Nachweis des sicheren Agieren des Systems im Betriebsszenario.

Der MBSE-Ansatz beruht auf SysML-Diagrammen und Simulationsmodellen, um Systeme nicht nur als reine textuelle Anforderungen darzustellen, sondern auch als detailliert strukturierte Modelle abzubilden. Dadurch können die Projektingenieure systembedingte Inkonsistenzen im Systemdesign erkennen, Designänderungen zeitnah umsetzen und verschiedene Betriebsszenarien besser verstehen. MBSE erleichtert den Umgang mit Änderungen, unterstützt die frühzeitige Fehlererkennung und trägt dazu bei, die Komplexität effektiv zu beherrschen.

Der Prozessrahmen orientiert sich an den Leitfäden der INCOSE-Handbücher sowie der Arcadia/Capella-Methodik. Diese definieren die anzuwendende Methodik zur Modellierung von Architektur und Design.

Es existieren verschiedene Tools, die die Produktentwicklung beim Analysieren, Modellieren und Simulieren unterstützen.

Im Folgenden erhalten Sie eine Übersicht der benannten Tools, jeweils ergänzt durch eine kurze Beschreibung.

In dem Artikel: Systemarchitektur (in Praxis) befindet sich ein Beispiel mit Ansätzen für Fensterheber-ECU.

Wenn Sie Unterstützung im Bereich Systems Engineering benötigen, kontaktieren Sie uns bitte:

Unten findet man eine Liste von Dokumenten, welche von ASPICE und ISO 26262 erforderlich sind, um die Anforderungen des Standards zu erfüllen. Die Inhalte der Dokumente können je nach Projekt variieren.

Item-Definition-Dokument (ID-Dokument):

• Systembeschreibung: welches ECU entwickelt wird und zu welchem Zweck
• Aufteilung des Systems in Subsysteme
• Beschreibung der Funktion des Steuergerätes
• Beschreibung des Umfangs, der Schnittstellen und der Randbedingungen des Fensterheber-ECU
• Randbedienungen wie Betriebsspannung, Temperaturbereich etc.
• Relevante Standards

HARA:

• Identifizierung potenzieller Gefahren, deren Schweregrad und deren Häufigkeit, um geeignete Sicherheitsmaßnahmen abzuleiten
• Ableitung des ASIL für ECU
• Berechnung des FTTI (Fault Tolerant Time Interval)
• Ein Teil einer Beispiel-Risikobewertung für das Fensterheber-ECU (nur ein Beispiel:
  • Risiko H(x) – Einklemmen von Körperteilen
  • Gefährdung: Einklemmen von Körperteilen beim Schließen des Fensters.
  • Bewertung:
    • Severity: S3 (schwere Verletzungen möglich).
    • Exposure: E2 (gelegentlich, abhängig von Nutzungshäufigkeit).
    • Controllability: C1 (kaum kontrollierbar, wenn Einklemmschutz nicht funktioniert).
  • ASIL: ASIL B
  • Maßnahmen:
    • Sensorgestützter Einklemmschutz mit regelmäßiger Kalibrierung.
    • Fail-Safe-Funktion, um das Schließen des Fensters bei Sensorfehlern zu verhindern.
  • Validierung:
    • Testen der Hinderniserkennung und Simulation von Einklemmsituationen.

FSR-Dokument:

• Enthält die aus der HARA abgeleiteten Sicherheitsziele und -anforderungen.
• Beispiel (Schwerpunkt liegt auf der Frage: “was” gemacht werden muss):
  • Schritt 1: Das Fensterheber-ECU muss die Fensterbewegung innerhalb von 100 ms stoppen, wenn ein Hindernis erkannt wird.
  • Schritt 2: Wenn das Fensterheber-ECU ein Hindernis erkannt und die Fensterbewegung gestoppt hat, muss das Fenster in entgegengesetzte Richtung um 10 cm fahren.

Technical Safety Concept (TSC-Dokument):

• Definiert, wie die funktionalen Sicherheitsziele auf technischer Ebene erreicht werden, einschließlich Redundanzen oder sicherer Zustände.
• Beispiel (Schwerpunkt liegt auf der Frage: „wie“ gemacht werden muss):
  • Schritt 1: Das Fensterheber-ECU muss bei Hinderniserkennung (Stromüberschuss am Stromsensor ≥ 20 %) die Fensterbewegung ab Erkennung des Hindernisses innerhalb von 100 ms stoppen. Die Einhaltung der Zeitvorgabe muss unter allen spezifizierten Betriebsbedingungen gewährleistet sein.
  • Schritt 2: Nach erfolgreicher Hinderniserkennung und gestoppter Fensterbewegung muss das Fensterheber-ECU das Fenster automatisch in entgegengesetzte Richtung um 10 cm bewegen. Die Rückwärtsbewegung muss mit einer Geschwindigkeit von >=100 mm/s erfolgen und innerhalb von 50 ms nach dem Stopp der Fensterbewegung starten. Eine Kalibrierung des Rückfahrwegs muss in regelmäßigen Wartungsintervallen sichergestellt sein.

System Requirements Specification (SRS-Dokument):

• Listet alle funktionalen und nicht-funktionalen Anforderungen auf, einschließlich Sicherheit (siehe 2 Beispiele oben), Qualität und Leistung.
  • Akzeptanzkriterien für jede Anforderung (z. B. Testfälle)
  • Verifikationsmethoden (Review, Unit-Test etc.)

System Architectural Design Document (SAD-Dokument):

• Zeigt die Systemarchitektur, wie Komponenten verbunden sind und wie sie Anforderungen erfüllen. Kann aus den folgenden Punkten bestehen:
  • Systemübersicht
  • Kontextdiagramme, Schnittstellen mit anderen Systemen
  • Leitprinzipien für Architekturentscheidungen (z. B. Schichtenarchitektur, Design-Muster, Programmiersprachen, Tools etc.)
  • Wartbarkeit, Skalierbarkeit
  • Systemkomponenten und deren Interaktion (z. B. Diagramme, Datenflüsse, Kommunikationsprotokolle etc.)
  • Performance-Anforderungen

Verification & Validation Plan (V&V-Dokument):

• Festlegung des Geltungsbereichs (welches System getestet wird)
• Zusammengefasst definiert dies Teststrategien wie
  • SIL, HIL,
  • abschließende Fahrzeugtests,
  • Abdeckung aller Entwicklungsphasen und Disziplinen (SY, SW, HW)
  • Berücksichtigung von Standards
  • Testumgebung, Werkzeuge
  • Zeitliche Vorgaben als Meilensteine
  • Traceability etc.

Configuration Management and Change History Document (CM-Dokument):

• Verfolgt jede Änderung während der Entwicklung
  • Liste der Konfigurationseinheiten (SW-Module, Dokumente etc.)
  • Versionskennzeichnung
  • Beschreibung des Änderungsprozesses
  • Baseline Management etc.

Safety Case Document (SC-Dokument):

• Darstellung und kurze Beschreibung von Safety Goals (Sicherheitszielen)
• Liefert Argumentationen und Nachweise, dass das Endprodukt die Sicherheitsziele erfüllt
• Dokumente mit Maßnahmen und Tests (Validierungstests, FMEA, FMEDA)
• Bewertung von Sicherheits- und Restrisiken

Diese Dokumente stimmen mit den Vorgaben von ASPICE und ISO 26262 überein und helfen den Entwicklungsingenieuren, transparente und nachvollziehbare Entwicklungsabläufe beizubehalten.

Nehmen wir an, dass das zu entwickelnde Steuergerät das Fensterheber-ECU ist. Anhand dieses Beispiels wird die Integration von Hardware und Software thematisiert.

Das Fensterheber-ECU besteht aus folgenden Hardware- und Softwarekomponenten, die während der ECU-Entwicklung integriert werden:

• Hardwarekomponente:
  • Mikrocontroller mit Flash-/EEPROM-Speicher
  • Motortreiber-IC
  • Sensoren
  • CAN- und LIN-Treiber-ICs
• Softwarekomponente:
  • Applikation zur Steuerung der Fensterbewegung
  • Low-Level-Treiber für die Ansteuerung von Motor und Peripherie
  • CAN- und LIN-Treiber

In der Anfangsphase der Steuergeräteentwicklung werden die elektronischen Schaltkreise entworfen und erste Prototypen gebaut. Das Hardware-Entwicklungsteam testet die Hardwarekomponenten auf ihre Funktionalität.

Parallel zur Hardwareentwicklung beginnt die Softwareentwicklung. Die Entwicklungsingenieure schreiben den Code gemäß Kodierstandards wie MISRA C und führen statische Analysen, Komponententests und Integrationstests nach erfolgreicher HW-SW-Integration durch. Sie stellen sicher, dass Software und Hardware reibungslos zusammenarbeiten.

Die Entwicklungsingenieure befolgen diese Schritte während der Entwicklung:

• Anforderungserfassung:
  • Definition der Anforderungen in Abstimmung mit dem Kunden,
  • Ziel: herauszufinden, welche Funktionen das Fensterheber-ECU erfüllen muss.
• Architekturdefinition:
  • Beschreibung der Gesamtstruktur und der Architekturentscheidungen
  • Beschreibung der Komponenten:
    • Mikrocontroller,
    • Sensoren,
    • wie der Motortreiber angebunden ist,
    • und wie die Kommunikation zu anderen Steuergeräten funktioniert.
• Sicherheitsanalyse (HARA, TSC):
  • Ermittlung potenzieller Gefahren während des ECU-Betriebs und Ausarbeitung von Sicherheitszielen zur Minimierung möglicher Risiken (siehe in oberen Kapiteln).

• Design-Umsetzung:
  • Implementierung von Hardware- und Software.
• Verifikation & Validierung:
  • Durchführung von verschiedenen Tests:
    • SIL-Tests zur Überprüfung der Fensterheber-Algorithmen,
    • HIL-Tests mit echter Hardware,
    • CANalyzer-Sessions zur Kontrolle des Kommunikationstimings
    • etc.
• Verfeinerung & Rückverfolgbarkeit:
  • Wenn die Tests Probleme aufzeigen, verfeinert ein verantwortlicher Ingenieur die Anforderungen und aktualisiert die Architektur, um Lücken zu vermeiden.
• Abschließende Qualifizierung und Freigabe:
  • Sobald alle Anforderungen und Testkriterien erfüllt sind, wird das Fensterheber-ECU an eine weitere Entwicklungsinstanz für eine Freigabe übergeben.

In den folgenden Absätzen werden drei potenzielle Herausforderungen erläutert, die während der Entwicklung des Fensterheber-ECU auftreten können.

Im realen Projekt wird es weitere Herausforderungen geben, doch die im Folgenden aufgeführten sind entscheidend für den Erfolg eines Projekts:

• Ursache einer Herausforderung bzw. eines Problems:
  • Schlecht funktionierende Kommunikationskanäle zwischen Disziplinen und schlecht beschriebene Prozessabläufe, die die Koordination zwischen den Disziplinen und einen reibungsfreien Entwicklungsprozess behindern.
• Mögliche Auswirkungen:
  • Durch unkoordiniertes Handeln können Unstimmigkeiten, Missinterpretationen und letztlich Verzögerungen sowie Kostensteigerungen in der Entwicklung auftreten.

• Mögliche Lösung:
  • Eine multidisziplinäre Entwicklung erfordert eine genaue und detaillierte Definition sowie Absprache von Schnittstellen und Zeitvorgaben während der Entwicklung, die es ermöglichen, ein Steuergerät gemäß den Anforderungen und innerhalb des vorgegebenen Zeitrahmens fertigzustellen.

• Ursache einer Herausforderung bzw. eines Problems:
  • Im Falle von getrennten Subsystemen, beispielsweise durch die Aufteilung von Hardware und Software in zwei Systemkomponenten – Hauptplatine (HW+SW) und Motorsteuerungsplatine (HW+SW) – kann die Integration mit erhöhtem Aufwand verbunden sein, insbesondere wenn die Motorsteuerung an einen Drittanbieter vergeben wird.
• Mögliche Auswirkungen:
  • Dies kann in diesem Fall zu Verzögerungen führen, insbesondere wenn Anpassungen an den Hardware-Komponenten erforderlich sind.

• Mögliche Lösung:
  • Eine genaue und detaillierte Definition sowie Absprache von Schnittstellen und Zeitvorgaben während der Entwicklung.

• Ursache:
  • Alterung der Gummiführung
• Mögliche Auswirkungen:
  • Durch die Alterung der Gummiführung können die gemessenen Kräfte verfälscht werden. Dadurch kann die Hinderniserkennungsfunktion fehlerhafte Daten interpretieren und falsche Reaktionen auslösen. Im schlimmsten Fall kann dies zu einer Verletzung der Safety Goals führen.

• Mögliche Lösung:
  • Die Alterung der Gummiführung sollte über den gesamten Lebenszyklus berücksichtigt und durch entsprechende Parameter und Algorithmen kompensiert werden.

Zusammengefasst können die Automotive-Projekte sehr komplex werden. Die Einhaltung der allgemeinen Standards und Normen, wie beispielsweise Emissions- und Cybersecurity-Anforderungen, ist herausfordernd und ressourcenintensiv. Daher sollten die Prozesse sorgfältig und durchdacht geplant werden. Von der Anforderungsspezifikation bis zum Testing – ohne tiefes Verständnis können die Arbeitsabläufe ineffektiv sein, was zu Verzögerungen und steigenden Kosten führt.

Die heutige Entwicklung im Automotive-Bereich zeigt sich in Richtung Elektrifizierung, Konnektivität und autonomen Fahren. Aktuell werden noch die traditionellen Domänenarchitekturen verwendet, wobei sich die Tendenz zunehmend in Richtung Zonalarchitekturen entwickelt, bei denen die Anforderungen an die Bandbreite der Kommunikationskanäle erheblich gestiegen sind. Jedoch bietet diese Architektur enorme Einsparungen in der Verkabelung eines Fahrzeugs. So werden effizientere und kostengünstigere Vorgehensweisen bei der Entwicklung ermöglicht [8].

Ebenso muss auch die wachsende Bedeutung der Cybersecurity hervorgehoben werden. Over-the-Air-Updates müssen besonders sicher gegen Angriffe sein, sodass autonome Fahrzeuge und die dazugehörigen Systeme ein hohes Maß an Schutz vor unautorisierten Eingriffen gewährleisten.

Im großen Ganzen erweitert sich die künftige Systems-Engineering-Umgebung im Automotive-Bereich weit über das klassische V-Modell hinaus und umfasst iterative, modellbasierte sowie KI-unterstützte Prozesse. Der Einsatz von KI könnte die Entwicklung unterstützen, indem alternative Architekturansätze in Betracht gezogen werden. Es ist denkbar, dass KI zukünftig Prozessanpassungen, Implementierungen und Tests eigenständig durchführt und steuert.

Diese Transformationen ermöglichen die Entwicklung sichererer und effizienterer Fahrzeugkomponenten.