Startseite > Automotive > Von der Anforderung zur fertigen Safety-Software-Architektur

Theorie in die Praxis umsetzen

Von der Anforderung zur fertigen Safety-Software-Architektur

13. Juli 2016, 13:45 Uhr | Von Dietmar Kinalzyk

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Software-Architektur-Konzept: E-Gas

Das E-Gas-Konzept entstand für den Ersatz von mechanischen Komponenten durch elektrische und elektronische Komponenten zur Steuerung der Leistung eines Verbrennungsmotors (Bild 3). Es sollte der mechanische Bowdenzug vom Fahrpedal und die Drosselklappensteuerung mit Hilfe von Elektronik modernisiert werden. Dazu wurden in der Elektronik drei Ebenen mit Mikroprozessoren eingeführt.
Die Software ist in drei Ebenen aufgeteilt.

Level 1 – Funktion

Die Ebene „Funktion“ enthält die Funktionen in QM-Qualität.
Fahrpedalstellung, Geschwindigkeit, Motordrehzahl, Getriebestellung werden eingelesen, um eine Motordrehzahl und ein Drehmoment zu erzeugen.

Level 2 – Funktionsüberwachung

Die Ebene „Funktionsüberwachung“ überprüft die Korrektheit der Funktionen und die Grenzen (Range) der Signale gemäß ASIL in einer Safety-Funktion.
Die Funktionsüberwachung löst im Fehlerfall die erforderliche Reaktion aus.
Die sicherheitsrelevante Funktionsüberwachung hat meist größere Toleranzen als die QM-Funktion selbst, greift also meist nur ein, wenn die Funktion selbst außer Kontrolle geraten ist.

Level 3 – Mikrocontroller-Überwachung

Die Mikrocontroller-Überwachung stellt die System Safety Integrity (SSI) inklusive externem Watchdog mit Protokoll zwischen Mikrocontroller und Watchdog sicher. Dazu zählen auch die Prüfungen auf Fehlerfreiheit der Mikrocontroller-Hardware ROM, RAM, ADC, Error Correction Code (ECC) und Memory Protection Unit (MPU).
Die Mikrocontroller-Überwachung löst im Fehlerfall die erforderliche Reaktion aus.

Anforderungen an die Software-Architektur

Wie gut unterstützt AUTOSAR das E-Gas Konzept? Im Projekt kam AUTOSAR 3.2 zum Einsatz.

AUTOSAR unterstützt die Ebenen 1, 2 und 3 des E-Gas-Modells mit
Software-Schichtenmodell mit Partitionierung nach ASIL
Kapselung von Task und Modulen
Konfiguration nach Nutzungsanforderung
E2E-Kommunikation
Safe Watchdog, Safe Context, Safe RTE

Die Funktionspartitionierung des dritten Level muss vom Projekt erfolgen. Darauf wird in der nächsten Übersicht zur Abdeckung der ISO-Anforderungen eingegangen.

Anforderungen nach ISO 26262

Statische Anforderungen der ISO-Norm (7.4.5, Teil 6) werden gut unterstützt. Das ist die klassische Stärke von AUTOSAR. Es zwingt die Software-Architekten, die gegebene

(1) Struktur und Kapselung,
(2) die logische Reihenfolge der Verarbeitung sowie
(3) Schnittstellen

zu nutzen. Im Vergleich dazu unterstützt die ISO-Norm dynamische Anforderungen (7.4.5 Teil 6) nur bedingt. Die Hauptaufgabe im Projekt besteht darin,

(4) Funktion und
(5) Verhalten

zu bestimmen. Dynamische Anforderungen, die die ISO-Norm (7.4.5 Teil 6) gut unterstützt, sind

(6) Kontroll-/Datenfluss
(7) Software-Komponenten
(8) Timing-Abhängigkeiten

Unterstützung durch AUTOSAR

(1) Struktur und Kapselung sind schwächer als bei klassischer Objektorientierung, beispielsweise bei Compiler-Fehlern. Bei Einhaltung der Regeln zur Kapselung ist sie dennoch gut darstellbar. Es sind nur konfigurierte Zugriffe auf Daten und für die Ausführung zu verwenden (ARXML file). Systematische Fehler durch manuellen Zugriff auf den Code können nicht verhindert werden. Im Design sind sie nur durch die Code-Analyse und während des Betriebs nur durch die MPU detektierbar. (+)

(2) Die Verarbeitung der logischen Reihenfolge ist durch typische Mechanismen des Betriebssystems gegeben: Prioritäten für Tasks, Zeit-Trigger, Event-Mechanismen im Zusammenhang mit RTE. (+)

(3) Standard-Schnittstellentypen sind vorgegeben; Sender/Receiver, Client/Server, IRV Interrunnable Variable: verschiedene Runnables mit interner Kommunikation gewährleisten den konsistenten Zugriff der Flag-Methodik, um die Interrupt-Sperre abzulösen. Das wurde im Projekt verwendet. Per Instance Memory (PIM) als mehrfache Instanziierung von Software-Komponenten unterstützt Reentry. PIM kam im Projekt nicht zum Einsatz. (+)

(4, 5) Funktion und Verhalten werden nicht gut unterstützt. Funktion und Verhalten sind keine Aufgaben von AUTOSAR und werden im Wesentlichen durch den Projektumfang bestimmt. Anteile kann man dennoch in der Basis-Software – zum Beispiel COM Stack – finden, ohne Features.(–)

(6) Kontroll-/Datenfluss mit Schnittstellen und Koppelung an das Scheduling ist gegeben (Sender Interface mit Event Trigger). (+)

7) Software-Komponenten sind zentraler Bestandteil der AUTOSAR-Methodik. (+)

8) Timing-Abhängigkeiten werden im Wesentlichen durch die auszuführenden Funktionen vom Projekt bestimmt. Nach dem Design unterstützt AUTOSAR gut mit Alive Checkpoints und Program Flow Monitoring. Deadline Monitoring wurde nicht verwendet. (+)
(+) heißt, dass eine gute Unterstützung durch AUTOSAR geboten wird; bei (–) gibt es nur eine geringe Unterstützung.