Softwarearchitektur (in Praxis)

Im folgenden Artikel werden die Methoden für die Entwicklung der Softwarearchitektur im Embedded-Automotive-Bereich veranschaulicht.

Diese Methoden und Praktiken können auch für die Entwicklung anderer Steuergeräte verwendet werden.

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

Die Aktivitäten im Software-Engineering fangen mit der Ableitung von Software-Anforderungen an. Im Kapitel: Anforderungsmanagement-Methode nach dem “Strict Decomposition (SDEC)”-Prinzip ist eine ausführliche Anleitung für Anforderungsmanagement enthalten. Diese Vorgehensweise kann sowohl für System-Engineering als auch für Software-Engineering benutzt werden.

Dort befinden sich Beispiele für unterschiedliche Abstraktionsebenen; zudem sind die Software-Anforderungen für das FMS_PCB-System ebenfalls vorhanden.

In diesem Dokument werden die Implementierungsanforderungen (wie und was zu implementieren ist) nicht detailliert behandelt, vielmehr liegt hier der Fokus auf der Softwarearchitektur und den Anforderungen aus ASPICE und ISO 26262 [5].

Die Anforderungen von Cyber Security ISO/SAE 21434 werden hier auch nicht behandelt, da die zusätzliche Umsetzung von Anforderungen den Rahmen dieses Dokuments sprengen würde. An der Stelle könnte man erwähnen, dass die Vorgehensweise für die Erfüllung der Anforderungen aus diesem Dokument analog zu der Vorgehensweise für Functional Safety ist.

Der nächste Schritt, nachdem die Software-Anforderungen festgelegt sind, ist, die Softwarearchitektur zu entwerfen. Auch hier spielen drei Standards eine übergeordnete Rolle: ISO 26262, ASPICE (und ISO/SAE 21434).

In diesem Dokument werden wir uns auf die Anforderungen aus ISO 26262 und ASPICE konzentrieren.

In einem industriellen Automotive-Projekt kann allein die Entwicklung der Softwarearchitektur je nach Komplexität des Projekts bis zu 1–1,5 Jahre dauern. Hier versuche ich, die wichtigsten Informationen zur Softwarearchitektur darzustellen.

Eine beispielhafte Struktur des Softwarearchitekturdokuments:

• Prinzipen der Softwarearchitektur
  • Beschreibungssprache
  • Konfigurierbarkeit
  • Designprinzipien (Testbarkeit, Wartbarkeit, Einfachheit etc.)
  • Interrupts
  • Scheduling
  • etc.
• Statische Aspekte
• Dynamische Aspekte
• Verifikation
• Traceability

Die Prinzipien der Softwarearchitektur können aus dem ISO 26262-2 zum größten Teil entnommen werden. Die Prinzipien beschreiben, nach welchen Richtlinien die Softwarearchitektur für sicherheitskritische Systeme entwickelt werden soll.

Des Weiteren gibt es in diesem Dokument auch Hinweise für die Verifikation und Traceability (Rückverfolgung).

In den folgenden Abschnitten möchte ich die statischen und dynamischen Aspekte der Softwarearchitektur anhand von Beispielfunktionen: Window Control und Anti Pinch Funktion untersuchen. Damit möchte ich eine solide Basis für die Entwicklung analoger Softwarearchitektur vermitteln.

Was ist eine statische Softwarearchitektur? Die statische Softwarearchitektur beschreibt die unveränderliche Struktur der Software:

• Schnittstellen
• Software-Komponenten (SWCs)
• Ressourcenverbrauch
• Konfiguration und Konfigurationsparameter
• Kalibrierungsparameter etc.

Die statische Ansicht der Softwarearchitektur ist im untenstehenden Diagramm ersichtlich. Ich werde hier nicht alle Software-Komponenten samt sämtlicher Schnittstellen beschreiben. Hier findet ihr auch keine Angaben zu Leistungsanforderungen, wie beispielsweise RAM, ROM und EEPROM (bzw. Flash), sowie keine UDS-Diagnose.

Vielmehr gehe ich auf die zwei Software-Komponenten ein, welche eine zentrale Rolle für dieses Steuergerät sind:

• Window Control (WINC) und
• Anti Pinch Funktion (APIF).

Die WINC-SWC ist dafür verantwortlich, die Fensterbewegung anhand eines LIN-Kommandos zu steuern, auf ein Hindernis zu reagieren und das System in einen Safe State (Sicheren Zustand) zu versetzen.

Die APIF-SWC dient dazu, anhand der Strommessung am DC-Motor und der Hall-Sensor-Daten ein Hindernis während des Fensterlaufs nach oben zu detektieren.

Hier ist die Zuordnung zwischen den System-Funktionen und Software-Komponenten:

Als Schnittstellennamen werden die Port-Interfaces dargestellt.

Die WINC-SWC verfügt über die in den Softwarearchitekturanforderungen (SWE.2) definierten Ports. Die APIF SWC hat in den Softwarearchitekturanforderungen (SWE.2) beschriebenen Ports.

Die Schnittstellen in den Anforderungen werden unter Angabe von Quelle‑SWC und Ziel‑SWC dargestellt, sodass bereits aus dem Namen ersichtlich ist, welche SWC das Signal sendet und welche das Signal empfängt.

Die nicht funktionalen Anforderungen werden hier ausgelassen, um den Artikel und das Diagramm nicht weiter zu verkomplizieren.

Weitere wichtige statische Aspekte der Softwarearchitektur, die in der SWA-Dokumentation vorhanden sein sollten (Vorgaben aus ISO 26262 und ASPICE):

• Schnittstellenbeschreibung
  • für die SWC-Kommunikation
  • Kommunikation nach außen (HSI)
• Datentypen
• Kommunikationsprotokolle (LIN, CAN etc.)
• Verwendung von globalen Variablen
• Konfigurationsparameter
• Kalibrierungsparameter
• Ressourcen-Verbrauch

Da der Infineon‑Baustein TLE9879QXA40 keine MPU besitzt, verwendet man die Softwarekomponente LINW als ASIL‑B‑Wrapper für die LIN‑Kommunikation.

In diesem Abschnitt werden die Tasks angesprochen. Zu Beginn der Entwicklung können die Tasks nicht zu hundert Prozent korrekt dimensioniert werden, da die Freiheiten in der Implementierung und mögliche Einschränkungen diese Klarheit beeinflussen.

Daher ist es ratsam, in der ersten Annäherung grobe Umrisse für die Tasks festzulegen und für den Anfang nur diese zu konfigurieren.

Hier werden wir nur die Tasks für die Softwarekomponente WINC dargestellt.

Es gibt verschiedene Möglichkeiten, den Speicherverbrauch abzuschätzen:

• anhand von Erfahrungswerten aus früheren Projekten
• anhand von Ergebnissen aus statischer Analyse und Approximation
• anhand der geplanten Code-Zeilen

Für die Abschätzung wird hier die dritte Variante gewählt.

Man geht davon aus, dass die Anzahl der im Blockdiagramm der statischen Softwarearchitektur dargestellten SWCs 7 beträgt. Als Nächstes wird anhand der Komplexität der Komponenten geschätzt, wie viele Codezeilen die zukünftigen Komponenten umfassen werden. Hier gehen wir davon aus, dass eine SWC ungefähr 500 Zeilen Code hat.

RAM-Abschätzung

Unsere SWA-Designprinzipien – in Übereinstimmung mit den Vorgaben der ISO 26262 – verlangen, dass in den Softwarekomponenten lediglich wenige globale Variablen (und Arrays) verwendet werden. Der Hauptverbrauch entfällt dann auf die Stacks.

Daraus ergibt sich ein ungefährer Wert: Für eine Komponente mit 500 Codezeilen werden etwa 4 bis 5 Variablen (@ 32 Bit) benötigt, was ca. 20 Bytes entspricht. Es muss berücksichtigt werden, dass Parameter oder Kalibrierungsdaten eventuell ebenfalls in den RAM geladen werden können (dies wird in der untenstehenden Memory Map nicht berücksichtigt).

ROM-Abschätzung

Bei der ROM-Abschätzung ist die Vorgehensweise analog zur RAM-Abschätzung.

Wir gehen von einem Bootloader mit einem Speicherverbrauch von ca. 10 bis 15 KB aus (bei einem komplexen AUTOSAR-Bootloader etwa 30 KB). Die Basissoftware benötigt etwa 45 bis 50 KB ROM. Für die Applikation verbleiben somit etwa 50 bis 60 KB, was ausreichend ist.

Für einen SWC mit 500 Codezeilen werden etwa 3 bis 5 KB Flashspeicher benötigt.

CPU-Load Abschätzung

Die CPU-Last wird entsprechend der geplanten Komplexität und Größe einer Softwarekomponente abgeschätzt.

Die Basissoftware verbraucht erfahrungsgemäß ca. 20 % CPU-Last. Ausgehend von ca. 500 Zeilen-Code pro SWC (sehr grob geschätzt) ergibt sich für eine Applikations-SWC ein Bedarf von etwa 5000 bis 25000 CPU-Zyklen (~1 % bis ~5 % der CPU-Last bei Taskzeit von 10 ms). Bei 7 SWCs und BSW beläuft sich die Gesamt-CPU-Last auf ca. 40 bis 70 %.

In diesem Abschnitt möchte ich eine mögliche Memory Map für RAM und ROM aufstellen:

Die Daten stammen aus dem Datenblatt [3], [4].

Die dynamische Softwarearchitektur beschreibt das Verhalten der Software während des Betriebs bezüglich:

• logischem Verhalten
• zeitlichem Verhalten
• Interaktion zwischen Softwareelementen
• Systemleistung

Der größte Teil des dynamischen Verhaltens kann durch Sequenzdiagramme dargestellt werden. Im Allgemeinen stellen die Sequenzdiagramme den Datenfluss zwischen verschiedenen Modellierungsobjekten im zeitlichen Ablauf dar. In AUTOSAR werden diese Objekte durch Software-Komponenten repräsentiert.

Es gibt zwei Kommunikationsarten in Classic AUTOSAR, die die Datenübertragung zwischen SWCs (und BSWCs) realisieren:

• Client-Server
• Sender-Receiver

Da die Tasks in eigenen zeitlichen Slots laufen und nicht nacheinander ausgeführt werden, soll der Datenfluss gut durchgedacht und entsprechend konfiguriert werden. Die genaue Reihenfolge bei Datenänderung kann geringfügig variieren und von der Aktualität abweichen.

Für die Sequenzdiagrammdarstellung bedeutet es, dass die Zeitpunkte, bei denen die Sender-Receiver-Ports ausgelesen werden, nicht mit den Schreibvorgängen auf der anderen Seite der Verbindung synchronisiert sind.

Die SR-Verbindungen werden als asynchrone Verbindungen auf dem Sequenzdiagramm dargestellt. Die Schreiben- oder Lesen-Vorgänge liefern keine Rückgabewerte (wie z. B. beim Aufruf einer Funktion), daher gibt es bei SR-Verbindungen keine UML-Antwortnachrichten. Die Änderung des Wertes auf der Senderseite wird nicht explizit im Diagramm dargestellt.

Des Weiteren kommunizieren die Software-Komponenten miteinander über die Rte-Schicht.

Die Rte-Schicht-Schnittstellen werden in Sequenzdiagrammen nicht dargestellt, da diese Darstellung die Diagrammkomplexität unnötig erhöht und kaum Vorteile bietet.

Die SR-Ports werden erst in der Rte-Schicht von einer SWC geschrieben und von einer anderen SWC ausgelesen. Das Lesen von SR-Variablen wird nicht mit einem Rückgabewert bestätigt.

Der Kontext des Diagramms beschränkt sich auf die gesamte Software. Weil die Software auf der Mikrocontroller-Hardware ausgeführt wird, bleibt der Kontext der Softwarearchitektur logischerweise auf HSI (HW des Mikrocontrollers) beschränkt. Das entspricht dem logischen Kontext der Software.

Wichtige Punkte der dynamischen Softwarearchitektur, welche hier ausgelassen sind:

• verschiedene Power-Modes und Initialisierungen
• State-Machine(s) (Zustandsmaschine(n))
• Start-up (Initialisierung von BSW, PWMs, GPIOs)
• Self-Tests (Selbsttests)
• Watchdog-Verhalten
• Safe State (Sicherer Zustand)
• Degradation Mode (Degradationsmodus)
• UDS-Diagnose
• Parametrierung und Kalibrierung
• etc.

Die LIN-Kommunikation wird ausschließlich durch BSWC ComM (auf BSW-Ebene) repräsentiert. Die LIN-BSWCs wie LinTrcv, LinDrv, LinIf und PduR müssen zwar konfiguriert werden, tauchen aber nicht im Diagramm auf. Die Fehlerbehandlung von LIN-Signalen wird in diesem Diagramm ebenfalls nicht berücksichtigt.

Die BSWCs für das Flash-Speichern (NvM) und für die LIN-Kommunikation (ComM) sind als Hauptakteure für die Applikation zu betrachten. Die unteren BSW-Schichten werden in diesem Diagramm nur indirekt angesprochen. Informationen zu diesen Komponenten sind in der AUTOSAR-Dokumentation nachzulesen.

Wie schon früher erwähnt, werden nicht alle Sequenzdiagramme (also auch keine komplette dynamische Softwarearchitektur) in folgenden Abschnitten dargestellt und erläutert.

Hier konzentrieren wir uns auf die Funktion „Hinderniserkennung“, während das Fenster nach oben fährt

Die UML-Notation entspricht weitgehend der herkömmlichen. Beachten Sie, dass die Sender-Receiver-Kommunikation (in Diagrammen als [SR] dargestellt) im AUTOSAR asynchron verläuft, während die Client-Server-Kommunikation (in Diagrammen als [CS] dargestellt) synchron erfolgt.

Wenn eine Software-Komponente einen Variablenwert ändert, ist der Änderungszeitpunkt nicht deterministisch. Deshalb wird die “Lebenslinie” sowohl bei den Sendern als auch bei den Empfängern unterbrochen.

Die Rte-Schicht wird in den Diagrammen nicht dargestellt, um die Komplexität zu reduzieren. In den Diagrammen kommunizieren die SWCs direkt miteinander, ohne die Rte-Schicht zu durchlaufen.

Die Diagramme:

• [1] Watchdog
• [2] Einlesen und Schreiben der Peripherie
• [3] Lesen von DC-Motor-Strom und Hall-Sensor-Werten
• [4] Senden und Empfangen von LIN-Signalen
• [5] Lesen und Schreiben in Flash-Speicher
• [6] Einlesen von ADCs

sind Hilfsdiagramme für das Diagramm [7].

In den Diagrammen werden keine UDS-Diagnose-Services dargestellt, da diese im Artikel nicht berücksichtigt wurden.

Die SWCs CSSD und WDGM sind in folgenden Diagrammen nicht beschrieben. Die SWC DIAC berücksichtigt nicht die Interaktionen zum Schreiben im Flash-Bereich und mit Watchdog. Die Aspekte der Funktionalen Sicherheit und Cybersecurity sind auf folgenden Diagrammen ebenfalls nicht berücksichtigt.

Der Standard ISO 26262 (Teil 6) beinhaltet zum größten Teil die Anforderungen für die Softwarearchitektur.

Automotive SPICE® definiert im Prozess SWE.2 „Software Architectural Design“ die konkreten Vorgaben zur Dokumentation und Strukturierung der Softwarearchitektur.

Aufgrund des Umfangs kann nicht jeder einzelne Anforderungspunkt abgebildet und erläutert werden. Mein eigenes Template für ein Softwarearchitektur-Dokument, das alle relevanten Anforderungen aus Automotive SPICE® und ISO 26262 enthält, umfasst über 40 DIN‑A4‑Seiten.

Daher sollte der Leser wissen, dass die hier dargestellten Inhalte keinesfalls vollständig sind.

Erwähnenswert sind insbesondere die bislang nicht aufgeführten Maßnahmen zur Funktionalen Sicherheit. Die Maßnahmen leiten sich aus der Analyse auf System- und Softwareebene ab. Eine Übersicht der Maßnahmen finden Sie weiter unten: ISO 26262 – Safety Measures (Sicherheitsmaßnahmen).

In den System-Engineering-Kapiteln wird die HARA‑Analyse anhand von Beispielen erläutert. Auf der Softwareebene sind zudem spezifische Analysen vorgesehen, die in funktional-sicherheitsrelevanten Projekten durchzuführen sind.

Das Ziel dieser Analyse ist, ergänzende Maßnahmen für die Funktionale Sicherheit im Softwarebereich zu identifizieren. Im Rahmen dieser Analyse werden sowohl abhängige als auch gemeinsame Fehlerursachen untersucht. Zur Unterstützung können weitere Analysemethoden wie FTA und FMEA hinzugezogen werden (Failure Tree Analysis, Failure Mode and Effect Analysis).

Die Analyse erfolgt auf der Ebene der Softwarearchitektur und berücksichtigt sowohl die Informationsflüsse als auch die Schnittstellen selbst.

In der folgenden Tabelle ist ein Ausschnitt aus einer detaillierten Analyse der Signalflusskette des LIN‑Signals für das Benutzerkommando dargestellt.

Dieses Beispiel verwendet englische Überschriften, wie sie in ISO 26262‑6, Annex E definiert sind.

In realen Projekten kann die Analyse vereinfacht werden.

Für interne Verbindungen, die nicht im HSI‑Kontext behandelt werden, kann eine vereinfachte Schnittstellenanalyse durchgeführt werden. Wichtig ist es, die Rahmenbedingungen der Analyse zu dokumentieren.

Die Abkürzungen in der Spalte ‚Safety Measure‘ lauten:

• [PL] – geplante Maßnahme
• [ADD] – ergänzende Maßnahme

Am Ende der Analyse werden alle Maßnahmen komponentenübergreifend zusammengeführt und daraufhin überprüft, ob alle erforderlichen Maßnahmen berücksichtigt wurden und welche davon implementiert werden müssen.

In dem Abschnitt oben sind einige Maßnahmen für die Gewährleistung der Funktionalen Sicherheit zu sehen (siehe Tabelle: Safety Analysis and Analysis of Dependent Failures at SW-level (Ausschnitt), Spalte: “Safety Measure”).

In diesem Abschnitt sind weitere Maßnahmen aufgelistet, welche für die Gewährleistung der Funktionalen Sicherheit implementiert werden können.

Mechanismen für die Fehlerdetektierung:

• Überprüfung der Wertebereiche
• Plausibilitätsüberprüfung (z. B. mittels Referenzmodell, Assertion Checks oder Signalvergleiche)
• Fehlererkennungscodes (Parität, CRC etc.)
• Datenfehler (Erkennung von Datenfehlern wie Bitflips, Speicherfehler, Übertragungsstörungen)
• Redundante Datenspeicherung
• Überwachung des Programmablaufs
• Logische-Überwachung (Software-Watchdog, redundante Berechnung, Selbsttest, Laufzeitanalyse)
• Temporal-Überwachung (HW-Watchdog, Deadline-Überwachung, Ausführungszeitüberwachung)
• Diverse Redundanz (Software‑ und Hardware‑Diversität)
• Software-Diversität
• Hardware-Diversität
• Zugriffsschutz (z. B. MPU, MMU)

• Privilegienebenen (Nutzer- und Supervisor-Modus)
• Task-basierte Zugriffskontrolle (konfigurierbar über AUTOSAR RTE-Zugriffsrechte)
• Mutexe und Semaphore (Verhinderung gleichzeitiger Zugriffe auf Ressourcen)
• Watchdog-Überwachung (Software‑Watchdog erkennt unautorisierte Zugriffe auf Register und/oder Variablen)

Mechanismen zur Fehlerbehandlung:

• Deaktivierung von Funktionen durch Übergang in einen sicheren Zustand
• Wiederherstellungsmechanismen (z. B. Vorwärts- oder Rückwärtswiederherstellung, Retry-Mechanismen)
• Homogene Redundanz (mehrfache Ausführung derselben Software auf identischer Hardware)
• Diverse Redundanz (mehrfache Ausführung einer Funktion mit unterschiedlichen Implementierungen oder Hardware)
• Korrektur von Code und Daten
• Verwaltung von Zugriffsrechten

Diese Maßnahmen werden projektspezifisch entsprechend den Zielen und Rahmenbedingungen implementiert.

Detaillierte Erläuterungen finden sich in ISO 26262 (Teil 6) insbesondere in Annex E.

In den obenstehenden Abschnitten wurde dem Leser eine solide Basis für die Softwarearchitekturentwicklung vermittelt. Es gibt aber genügend Punkte, die zwar in diesem Dokument nicht beschrieben sind, für ein reales Projekt jedoch unerlässlich sind.

Degradierungsmodi: Ausgehend von dem Sicherheitskonzept und den Anforderungen an die Robustheit des Systems, muss ein Sicherheitskonzept definiert werden.

Implementierung der Funktionalen Sicherheit: Wir haben zwar ein Kapitel mit Sicherheitsmaßnahmen angelegt; eine reale Implementierung anhand eines Beispiels fehlt jedoch.

Kommunikation über den LIN-Bus: Die Basissoftware wird in einem realen Projekt die Umsetzung des LIN‑Stacks stark unterstützen.

Fehlerdiagnose und Safe-State: Der Safe-State ist in diesem Dokument nicht ausreichend beschrieben (er wird nur erwähnt). Die Beschreibung und Definition des Safe-States können in einem realen ASIL-relevanten Projekt ebenfalls nicht weggelassen werden.

Es gibt sicherlich viele weitere wichtige Punkte, die in diesem Dokument nicht erläutert sind. Deswegen bitte ich Sie, dieses Dokument nicht als Referenz für Ihr eigenes Projekt zu benutzen. Wenn Sie aber eine Unterstützung im Bereich des Software Engineerings benötigen, kontaktieren Sie mich gerne: