In diesem Artikel wird das Thema Software Engineering (Softwaretechnik) angesprochen. Die Besonderheiten der Softwareentwicklung im Bereich Automotive Embedded Systems werden erläutert.
Da in diesem Artikel der Fokus auf Softwarearchitektur liegt, werden die Bestandteile des Softwarearchitekturdokuments dargestellt.
Inhaltsverzeichnis
Für wen ist dieser Artikel?
| Ziel des Artikels: | Einführung in das Thema: Software Engineering (SWE) |
| Artikelzielgruppe: | Die Software Engineering-Einsteiger, sowie diejenigen, die diese Disziplin näher kennenlernen möchten. |
| Sprache: | technisch, englisch, Automotive, mit vielen spezifischen Begriffen |
| Empfohlene Vorkenntnisse: | ASPICE [1], ISO 26262 [2], ISO/SAE 21434 [3], Automotive-Umfeld |
| Hilfsmittel: | Vokabular, Standards und Normen, *1) |
| Lesedauer: | ca. 15 Minuten |
*1) Um Grafiken zu vergrößern, benutzen Sie die rechte Maustaste und die Option: “Bild in neuem Tab öffnen”.
Einführung
Bei der Entwicklung von eingebetteten Systemen sind Projekte mit zunehmender Softwarekomplexität innerhalb vernetzter Systeme konfrontiert.
Der Integrationsaufwand von Systemelementen wie Hardware, Software und Kommunikationsschnittstellen ist erheblich.
Seit dem Jahr 2011 spielt die Norm ISO 26262 eine wesentliche, wenn nicht gar die entscheidende Rolle bei der Gestaltung von Entwicklungsprozessen im embedded Automotive-Softwarebereich.
Der ASPICE-Standard beschreibt Entwicklungsprozesse und dazugehörige Arbeitsprodukte im Bereich Software Engineering.
Der Standard ISO/SAE 21434 definiert die Anforderungen für Cybersecurity.
In diesem Artikel werden die Anforderungen dieser Standards erläutert und mögliche Lösungswege beschrieben. Obwohl nicht alle Anforderungen einzeln in diesem Dokument eingegangen werden können, da der Artikel sonst viel zu lang wird, versuchen wir hier uns am Wesentlichen zu konzentrieren.
Software Engineering Definitionen
Das Software Engineering verbindet die Lösungsmethoden und Ansätze, welche die Entwicklungsteams in Projekten während des gesamten Produktlebenszyklus (PLC) benutzen. In den folgenden Abschnitten kann man drei Definitionen des Software Engineering finden.
Laut der Norm ISO/IEC/IEEE 24765:2017:
“Bezieht sich die Softwareentwicklung auf die Anwendung systematischer, disziplinierter und quantifizierbarer Ansätze für die Entwicklung, den Betrieb und die Wartung von Software sowie auf das Studium dieser Ansätze.“ [4]
Eine weitere Definition des Software Engineering kann man im Dokument „Guide to the Software Engineering Body of Knowledge (SWEBOK)“ der IEEE Computer Society finden:
“Das Software Engineering ist eine Sammlung von Best Practices, theoretischen Grundlagen und kontinuierlicher Verfeinerung von Tools, die zuverlässige und wartungsfreundliche Softwarelösungen schaffen.” [5]
In der akademischen Literatur ist eine ähnliche Definition, die sich auf Modelle, Standards und Qualitätsmaßstäbe konzentriert, vorhanden. Hier die Definition aus dem Buch: „Software Engineering: Theory and Practice“ von Pfleeger und Atlee:
“Das Software Engineering ist ein Feld, das technische Prinzipien, Risikomanagement und domänenspezifische Einschränkungen integriert, um robuste Anwendungen zu erstellen, die vordefinierte Ziele erfüllen.” [6]
Besonderheiten von Software Engineering im Automotive-Bereich
Dieses Kapitel befasst sich mit den fünf am häufigsten verwendeten Softwarearchitekturtypen in eingebetteten Automobilsystemen. Des Weiteren werden wir für jeden Architekturtyp verwendete Tools und moderne Teststrategien untersuchen.
Die Rolle des V-Modells in der Softwareentwicklung wird hier auch angesprochen.
Abhängigkeiten zu Standards: ASPICE, ISO 26262 und ISO/SAE 21434
Als Erstes möchte man die Standards und Normen überprüfen und die Gemeinsamkeiten bzw. Abhängigkeiten in der Disziplin Software Engineering finden, um diese während der weiteren Analyse zu berücksichtigen.
| Standard/Norm: | Relevant zum Software Engineering: | Überschneidungen mit anderen Standards: |
| ASPICE | – gibt vor, dass alle Aktivitäten im Softwareentwicklungszyklus, einschließlich Requirements Engineering, Design, Implementierung, Test, Verifikation und Validierung, durch dokumentierte und definierte Prozesse gesteuert werden, – bewertet die Prozessreife anhand einer Skala von 0 bis 5, – verlangt durchgehende Rückverfolgbarkeit zwischen Anforderungen, Design, Implementierung und Testfällen. | mit ISO 26262 und ISO/SAE 21434: – ASPICE gibt einen Überblick über die Prozesse während der Softwareentwicklung. Die Anforderungen aus ISO 26262 und ISO/SAE 21434 sollen in dieses Rahmenwerk integriert werden (siehe die Punkte unten). |
| ISO 26262 | – Anforderungen an die Software-Implementierung hängen von der ASIL-Einstufung (A bis D) der zu implementierenden Funktion ab, – definiert einen Sicherheitslebenszyklus, der in den Softwareentwicklungsprozess eingebettet werden muss, – gibt die Richtlinien für die Ermittlung spezifischer sicherheitsrelevanter Softwareanforderungen, – hilft bei der Analyse potenzieller Softwarefehler (z. B. durch FMEA oder FTA), – definiert spezifische Verifikations- und Validierungsmethoden (z. B. MC/DC-Coverage Tests bei ASIL D), – gibt die Anforderungen an die zu verwendeten Tools vor (z. B. Compiler oder Konfigurationsmanagementsysteme müssen qualifiziert oder zertifiziert werden, um ihre Eignung nachzuweisen). | mit ASPICE: – Software Requirements Analysis (SWE.1): Sicherheitsanforderungen aus ISO 26262 werden hier erfasst und weiter während der Entwicklung berücksichtigt, – Software Architecture Design (SWE.2): Umsetzung der Sicherheitsarchitektur für die Software, – Software Detailed Design und Unit Construction (SWE.3): Angaben für den Entwurf und die Implementierung von Software-Einheiten, – Software Testing (SWE.5, SWE.6): Testanforderungen aus ISO 26262 (z. B. für ASIL D) fließen direkt in die Implementierung ein. |
| ISO/SAE 21434 | – TARA: Ähnlich wie die Gefahren- und Risikoanalyse (HARA) in ISO 26262, aber mit Fokus auf Cyber-Bedrohungen, – Sicherheitsanforderungen aus Cybersecurity müssen im Softwareentwicklungsprozess berücksichtigt werden, – SDLC: Die Entwicklung muss auf Security by Design und Security Testing ausgerichtet sein, – Nutzung von Static Analysis Tools und Penetration-Testing während der Softwareverifikation, – Implementierung von Schutzmaßnahmen wie Verschlüsselung, sichere Kommunikation und Authentifizierung, – Prozesse zur Reaktion auf Sicherheitsvorfälle müssen etabliert sein | mit ASPICE: – (indirekt) SYS.3: Analyse und Definition von Cybersecurity-Anforderungen – SWE.1-6: Berücksichtigung der Cybersecurity-Anforderungen bei Implementierung und Test der Software mit ISO 26262: – Sicherstellen, dass Sicherheitsmaßnahmen keine Sicherheitsrisiken verursachen (z. B. Deadlock durch Authentifizierungsmechanismen) |
Rolle des V-Modells im Software Engineering
Das V-Modell, das in ASPICE definiert und verständlich beschrieben ist, spielt in den meisten Automotive-Projekten während der Entwicklung eine wesentliche Rolle und beschreibt Prozesse für die Softwareentwicklung und -test.
Hier sind wichtigste Punkte von ASPICE welche die Entwicklung unterstützen und erleichtern.
- Sequentielle Entwicklung:
- Es gibt unterschiedliche Entwicklungsphasen: Anforderungserstellung bzw. Anforderungsänderung, Design, Implementierung und Testing.
- Verifizierung und Validierung:
- Jede Entwicklungsphase hat eine entsprechende Testphase, wodurch die Qualität des Produkts gewährleistet wird.
- Rückverfolgbarkeit:
- Jedes Entwicklungselement (Artefakt) hat eine eindeutige Zuordnung im Projekt, damit wird für eine konsistente Dokumentation gesorgt.
- Frühzeitige Fehlererkennung:
- Die meisten Fehler werden während eines umfassenden Tests festgestellt und damit werden die hohen Änderungskosten später reduziert.
Mehr zum V-Modell kann man in dem Artikel: V-Modell als Projektmanagementmethode lesen.
Softwarearchitekturen im Automotive Embedded Bereich
Die Tabelle unten zeigt die gängigsten Softwarearchitekturen im Automotive-Embedded-Bereich, deren häufige Verwendung in Steuergeräten und die wichtigen Eigenschaften.
| Softwarearchitektur Typ: | Wird häufig verwendet in: | Eigenschaften: |
| Schichtarchitektur | – Engine Control Unit / Motorsteuergerät (ECU) – Transmission Control Unit / Getriebesteuergerät (TCU) – Body Control Unit / Zentralsteuergerät (BCM) | – Unterteilt die Funktionen in unterschiedliche Schichten – Jede Schicht interagiert mit benachbarten Schichten über gut definierte Schnittstellen – Erleichtert das Hinzufügen neuer Funktionen, ohne vorhandene Schichten zu beeinträchtigen. – Einzelne Schichten können isoliert getestet werden |
| Ereignisgesteuerte Architektur (EDA) | – Brake Control Unit / Bremssteuergerät (BCU) – Steering Control Unit / Lenksteuergerät (SCU) – Stability Control Unit / Stabilitätskontrolle Steuergerät (ESC) | – Bewältigt zunehmende Ereignislasten ohne Leistungseinbußen – Erleichtert nicht blockierende Interaktionen zwischen Komponenten – Effiziente Verarbeitung von Echtzeitereignissen – Reduziert Abhängigkeiten zwischen Komponenten |
| Serviceorientierte Architektur (SOA) | – Infotainment Control Unit / Infotainment-Steuergerät (ICU) – ADAS Fahrerassistenzsysteme – Telematik-Steuergerät (TCU) | -Passt sich an sich entwickelnde Anforderungen an, ohne dass die Architektur wesentlich überarbeitet werden muss – Dienste arbeiten unabhängig voneinander – Isolierte Dienste und reduziertes Risiko weitverbreiteter Schwachstellen |
| Komponentenbasierte Architektur | – Climate Control Unit / Klimaanlage (CCU) – Lighting Control Module / Lichtkontrollsteuergerät (LCM) – Power Control Unit / Antriebsstrangsteuerung (PCU) | – Fördert die Wiederverwendung standardisierter Software-Komponenten – Ermöglicht den einfachen Austausch oder die Aktualisierung von Komponenten – Unterstützt den komponentenbasierten Ansatz von AUTOSAR und gewährleistet die Einhaltung von Automobilstandards – Vereinfachte Aktualisierungen und Wartung durch Isolierung von Komponenten |
| Mikrokernel-Architektur | – Electronic Parking Brake / Elektronische Parkbremse (EPB) – Adaptive Cruise Control / Adaptive Geschwindigkeitsregelungen (ACC) – Line Keeping Assist / Spurhalteassistent (LKA) | – Reduziert die Systemkomplexität und minimiert das Ausfallrisiko. – Die Kernfunktionen sind leichtgewichtig gehalten, was die Systemleistung verbessert. – Trennt Kernfunktionen von Peripheriemodulen und verbessert so die Stabilität. – Vereinfachte Updates und Wartung durch Isolierung von Modulen. |
Softwarearchitektur Dokument
Als Erstes werden die Informationen aus unterschiedlichen Standards dargestellt, die für das Softwarearchitekturdokument nötig sind.
Hier betrachten wir drei wichtigste Standards: ASPICE, ISO 26262 und ISO/SAE 21434.
ASPICE – Vorgaben für Softwarearchitektur
Im ASPICE-Standard, Kapitel 4.4.2 SWE.2 Software Architectural Design, wird eine Liste von Base Practices aufgezeigt, die im Softwarearchitekturdokument vorhanden und beschrieben sein müssen.
Hier werden nur die Anforderungen für die Softwarearchitektur dargestellt.
Andere Anforderungen aus ASPICE für das Software Engineering wie SWE.1, SWE.3, SWE.4, SWE.5 und SWE.6 müssen während des Software Engineerings ebenfalls berücksichtigt werden. Diese Vorgaben sind im Standard ASPICE zu finden.
In folgender Tabelle sind die Praktiken für die Softwarearchitektur aus ASPICE aufgelistet:
| Base Practice (BP): | Beschreibung: |
| SWE.2.BP1: | Specify static aspects of the software architecture. (Spezifiziere die statischen Aspekte in der Softwarearchitektur). |
| SWE.2.BP2: | Specify dynamic aspects of the software architecture. (Spezifiziere die dynamischen Aspekte in der Softwarearchitektur). |
| SWE.2.BP3: | Analyze software architecture. (Analysiere die Softwarearchitektur). |
| SWE.2.BP4: | Ensure consistency and establish bidirectional traceability. (Sicherstellung der bidirektionalen Rückverfolgbarkeit der Softwarearchitekturartefakten). |
| SWE.2.BP5: | Communicate agreed software architecture. (Kommunikation der abgestimmten Softwarearchitektur) |
ISO 26262 – Vorgaben für Software Engineering und Softwarearchitektur
Weitere Software relevanten Anforderungen, die für die sicherheitskritischen Projekte erfüllt werden müssen, kommen aus den ISO 2626 – Road vehicles – Functional safety Vorgaben:
| Kapitel: | Beschreibung: |
| ISO 26262-6, Kapitel 6 | Anforderungen, wie die technischen Implementierungsanforderungen spezifiziert werden sollen. |
| ISO 26262-6, Kapitel 7 | Anforderungen an die Softwarearchitektur. |
| ISO 26262-6, Kapitel 8 | Anforderungen für das Design und die Implementierung der Softwarekomponenten. |
| ISO 26262-6, Kapitel 9 | Anforderungen für die Tests von Softwarekomponenten. |
| ISO 26262-6, Kapitel 10 | Anforderungen für Softwareintegration und Softwareverifizierung. |
| ISO 26262-8, Kapitel 11 | Anforderungen für das Testen der Software auf der Systemebene. |
ISO/SAE 21434 – Vorgaben für Software Engineering
Der ISO/SAE 21434 – Road Vehicles – Cybersecurity Engineering beschreibt die notwendigen Maßnahmen und Prozesse, um sicherzustellen, dass elektronische Systeme in Fahrzeugen sicher gegen Cyberangriffe sind.
Der Standard wird in verschiedenen Phasen des Lebenszyklus eines Fahrzeugs verwendet, von der Entwicklung über die Produktion bis hin zur Wartung. Hier sind einige spezifische Punkte erläutert, welche bei der Softwareentwicklung berücksichtigt werden müssen:
| Kapitel: | Beschreibung: |
| ISO/SAE 21434, Kapitel: 10 (Product development) | Grundlage für die Softwareentwicklung, die die Cybersecurity-Anforderungen berücksichtigt. (Coding-Richtlinien, Design-Richtlinien, Softwarearchitektur) |
| ISO/SAE 21434, Kapitel: 11 (Cybersecurity validation) | Überprüfung, ob die Cybersecurity-Ziele erreicht sind. |
Moderne Automotive-Software-Teststrategien
Die Testansätze der Software werden in den folgenden Kapiteln angesprochen.
SWE.4 – Software Unit Verification (Verifizierung der Software-Einheiten)
In den folgenden Kapiteln ist die Beschreibung für SWE.4 Software Unit Verification aus dem ASPICE-Standard.
Während dieser Tests werden die Software-Einheiten gegen Software Detailed Design Anforderungen getestet.
Verwendungszweck:
Sicherstellen, dass jede Funktion auf der Software-Einheit-Ebene entsprechend den Anforderungen implementiert ist.
Verwendungsfall und Beispiel:
- Die Überprüfung, dass die Implementierung der Funktionen den Anforderungen entspricht.
- Beispiel 1: Überprüfen, ob die Software-Funktion das Fahrzeugfenster anhält (über Variablenwert), wenn der Strom-Sensor ein Hindernis erkennt (über Variablenwert).
- Beispiel 2: Sicherstellen, dass die Fenstersteuerungsfunktion bei maximaler und minimaler Fenstergeschwindigkeit korrekt ausgeführt wird (anhand von Variablen).
- Die Überprüfung, ob die Software-Funktion die Fehler ordnungsgemäß behandelt.
- Beispiel 3: Überprüfen, ob die Software auf unerwartete Sensorfehler durch Eingaben der korrupten Daten entsprechend den Anforderungen reagiert (anhand von Variablen).
- Die Überprüfung, ob die Software-Funktion innerhalb der vorgegebenen Zeitanforderungen ausgeführt wird.
- Beispiel 4: Überprüfen, ob die Software-Funktion für die Fenstermotoransteuerung auf Benutzerbefehle innerhalb der vorgegebenen Zeit reagiert (anhand von Variablen).
Tools:
Google Test: Unterstützt Unittests für C und C++ Software-Komponenten, die häufig in Automobil-Software verwendet werden.
SWE.5 – Software Component Verification and Integration Verification (Softwarekomponenten-Verifizierung und Integrationsverifizierung)
Das Ziel von SWE.5 Softwarekomponenten-Verifizierung und Integrationsverifizierung ist zu überprüfen, ob die Software-Komponenten (SWCs) untereinander die Daten korrekt austauschen und entsprechend den Anforderungen implementiert sind.
Des Weiteren wird hier überprüft, dass die Softwarekomponenten korrekt integriert und konsistent mit der Softwarearchitektur implementiert sind.
Verwendungszweck:
Validierung der Interaktionen zwischen Softwarekomponenten und Subsystemen.
Erkennung von Problemen, die durch Datenaustausch und Kommunikationsprotokolle entstehen.
Sicherstellen, dass integrierte Software-Komponenten die Anforderungen auf der Software-Architekturebene und Software-Designebene erfüllen.
Verwendungsfall und Beispiel:
- Bestätigung, dass der Datenaustausch zwischen Software-Komponenten den Spezifikationen entspricht.
- Beispiel 1: Testen der Kommunikation zwischen zwei Softwarekomponenten (Überprüfen, ob Sensordaten von der Fenstersteuerung-ECU korrekt empfangen und verarbeitet werden).
- Fehlerausbreitung: Überprüft, wie sich Fehler in einer Software-Komponente auf andere SWCs auswirken.
- Beispiel 2: Sicherstellen, dass ein Sensorfehler (in einem SWC) keine Fehler an das Motorsteuermodul (andere SWC) weitergibt.
- Die Überprüfung, ob integrierte Komponenten gemeinsam die Systemanforderungen erfüllen.
- Beispiel 3: Testen des gesamten Fensterhebemechanismus von der Benutzereingabe bis zur Motorbetätigung.
Tools:
Vector CANoe: Erleichtert die Simulation und das Testen von CAN-Bus-Interaktionen zwischen ECUs.
IBM Rational Integration Tester: Unterstützt automatisierte Integrationstests für komplexe Automobilsysteme.
SWE.6 – Software Verification (Software-Verifizierung)
Die Softwarequalifikationstests verfolgen das Hauptziel, die Software auf die Übereinstimmung mit den Softwareanforderungen auf der Systemebene zu prüfen.
Verwendungszweck:
Validierung der Software-Funktionalitäten auf Systemebene.
Sicherstellung, dass die Software korrekt unter unterschiedlichen Umweltbedingungen funktioniert.
Sicherstellung, dass die Software alle nötigen Standards erfüllt.
Verwendungsfall und Beispiel:
- Die Bestätigung, dass die Systemfunktionen entsprechend den Anforderungen umgesetzt sind.
- Beispiel 1: Die Funktionalität des Fensters (Auf- und Abwärtsbewegung) wird überprüft (im Kontext des Mikrocontrollers oder/und der Gesamtsystemebene).
- Die Evaluation, ob die Benutzerfreundlichkeit des Systems entsprechend den Anforderungen umgesetzt wurde.
- Beispiel 2: Überprüfung, ob die Fensterbedienungsfunktion softwareseitig intuitiv und “flüssig” funktioniert (im Kontext des Mikrocontrollers oder/und der Gesamtsystemebene).
- Die Bestätigung, dass die Leistungsanforderungen unter unterschiedlichen Umweltbedingungen getestet sind und korrekte Funktion aufweisen.
- Beispiel 3: Überprüfung, dass die Fensterfunktion im ganzen Temperaturbereich die Anforderungen erfüllt (im Kontext des Mikrocontrollers oder/und der Gesamtsystemebene).
- Beispiel 4: Überprüfung, dass das System unter unterschiedlichen Netzwerkauslastungen die Anforderungen erfüllt (im Kontext des Mikrocontrollers oder/und der Gesamtsystemebene).
Tools:
Vector CANoe und VN/VT Hardware: Ermöglicht Testen von Software auf dem System.
Ergänzend zu den Anforderungen aus ASPICE sollen die Anforderungen für die Tests aus der Norm ISO 26262 berücksichtigt werden.
Die Norm schreibt z. B. vor, dass bestimmte Testmethoden angewandt werden sollen, z. B.:
- Error Guessing Tests
- Code-Abdeckung Tests (MC/DC)
- Fault-Injection Tests etc.
Unterschiedliche Testmethoden sind bei sämtlichen ASIL-Levels empfohlen. Diese Information kann aus der Norm ISO 26262 entnommen werden.
Des Weiteren schreibt die Norm vor, welche ergänzenden Dokumente für die Tests erstellt werden müssen.
Softwarearchitektur Tools
In der Tabelle unten sind die bekanntesten Tools für unterschiedliche Architekturtypen mit kurzer Feature-Beschreibung vorhanden.
Diese Tabelle kann behilflich sein, um mit der Wahl des Engineering-Tools zu starten.
| Tool: | Eigenschaften: |
| MATLAB/Simulink | Code-Generierung: Ermöglicht Generierung vom Code. Visualisierung: Bietet robuste Visualisierungstools für Architekturdiagramme und Systeminteraktionen. Verifizierung: Unterstützt automatisiertes Testen und Verifizieren. Capability Mapping: Erleichtert modellbasiertes Design und ermöglicht die Simulation und Analyse des Modells. Funktionsunterstützung: Bietet umfangreiche Bibliotheken für Automobilsysteme, Echtzeitsimulationsfunktionen und automatische Codegenerierung. Integration: Lässt sich gut in andere Entwicklungstools integrieren. |
| Enterprise Architect | Capability Mapping: Hilft beim Entwerfen und Dokumentieren von mehrschichtigen Architekturen. Code-Generierung: Generierung vom Code (Code-Skeleton). Berichterstellung: Generiert detaillierte Berichte und Dokumentationen. Funktionsunterstützung: Bietet UML-Unterstützung, Rückverfolgbarkeitsfunktionen und Integration mit Versionskontrollsystemen. Zusammenarbeit: Erleichtert die Teamzusammenarbeit durch gemeinsam genutzte Modelle. Anpassung: Ermöglicht die Anpassung von Modellierungsvorlagen. |
| IBM Rational Software Architect | Capability Mapping: Ermöglicht die Entwicklung und Implementierung von SOA-basierten Systemen. Funktionsunterstützung: Unterstützt die Zusammenstellung, Steuerung und Bereitstellung von Diensten in verteilten Umgebungen. Integration: Lässt sich in andere IBM-Tools integrieren und ermöglicht Vereinfachung der Entwicklungsabläufe. Sicherheit: Enthält Sicherheitsfunktionen zum Schutz von Dienstinteraktionen und Datenaustausch. |
| AUTOSAR Builder | Code-Generierung: Generierung vom Code (aus .arxml Dateien). Anpassung: Ermöglicht die Anpassung von Komponentenvorlagen, um spezifische Projektanforderungen zu erfüllen. Capability Mapping: Spezialisiert auf die Entwicklung AUTOSAR-kompatibler komponentenbasierter Architekturen. Funktionsunterstützung: Erleichtert die Erstellung standardisierter Softwarekomponenten, Schnittstellen und Kommunikationsprotokolle. Integration: Lässt sich nahtlos in andere AUTOSAR-Tools integrieren und unterstützt End-to-End-Entwicklungsworkflows. Compliance: Stellt die Einhaltung von AUTOSAR-Standards sicher und fördert Interoperabilität und Wiederverwendbarkeit. |
| Vector DaVinci Developer | Code-Generierung: Generierung vom Code (aus .arxml Dateien) Zusammenarbeit: Erleichtert die Teamzusammenarbeit durch gemeinsam genutzte Modelle und Echtzeit-Updates. Capability Mapping: Unterstützt die Entwicklung von AUTOSAR-Softwarekomponenten und deren Integration. Funktionsunterstützung: Bietet umfassende Modellierungs-, Codegenerierungs- und Testfunktionen. Rückverfolgbarkeit: Erhält die Rückverfolgbarkeit zwischen Anforderungen, Designelementen und Testfällen aufrecht. Validierung: Bietet Tools zur Validierung von Komponenteninteraktionen und Systemverhalten. |
Bei einer Tool-Auswahl und -Einführung ist es wichtig, einen Pilot-Versuch durchzuführen, um herauszufinden, wie die Prozessabläufe und Entwicklungsschritte funktionieren. Es kann unter Umständen sein, dass die Aufwände in Realität anderer Größenordnung sind, als beim Planen angenommen war.
Außerdem gibt es meistens beim Einführen eines neuen Tools nicht das Wissen, welche Funktionalität zur Verfügung steht und wie das Tool bedient wird.
Die Projekte bekommen nicht rechtzeitig eine Tool-Unterstützung (oder überhaupt nicht). Manche Projektmitarbeiter erforschen die Dokumentation und nach einem riesigen zeitlichen Aufwand weiß nur 10 % des Teams, wie man das neue Tool überhaupt bedient. Eine solche Situation kann man in fast jedem Projekt beobachten, in dem neue Tools eingeführt werden.
Software Engineering und Softwarearchitektur: Umsetzung in Praxis
In dem Artikel: Systems Engineering (SYS) haben wir ein Beispiel des Systems Engineerings der Fensterheber-ECU angesprochen. Dieses Beispiel beinhaltet ein Blockdiagramm mit Fensterheber-ECU Elementen mit Verbindungen für Systemelementkommunikation für die Systemübersicht.
Das Blockiagramm: Systemarchitektur – Fenstermotorsteuerung FMS_PCB und kritische Pfade dient als Grundlage für die weitere Softwareentwicklung.
In dem Artikel Softwarearchitektur (in Praxis) ist die Teilumsetzung der Softwarearchitektur in Praxis dargestellt. Anhand dieses Beispiels kann man das Prinzip des Software-Engineerings und die wichtigsten Bausteine der Softwarearchitektur verstehen.
In folgenden Absätzen werden die Aktivitäten und die entsprechende Dokumentation der Softwarearchitektur kurz erläutert.
Quellenangabe:
- [1] Automotive SPICE Process Assessment / Reference Model, Version 4.0,
- [2] ISO 26262-1:2018 Road vehicles — Functional safety
- [3] ISO/SAE 21434 Road vehicles — Cybersecurity engineering
- [4] ISO/IEC/IEEE 24765:2017 Systems and software engineering—Vocabulary
- [5] IEEE Computer Society, “SWEBOK V3.0: Guide to the Software Engineering Body of Knowledge,” 2014
- [6] Shari Lawrence Pfleeger, Joanne M. Atlee, “Software Engineering: Theory and Practice”, Pearson Education, 4th edition.
Autor: Dipl.-Ing. Nachrichtentechnik (FH) Oleg Czaikowsky, den 14.04.2025