Architekturen und Degradationsmechanismen für verlässliches Verhalten im Fehlerfall
Auf alles vorbereitet sein
Fehler in Steuergeräten müssen schnell entdeckt und korrigiert werden. Grundlegende Fehlerkorrektur-Konzepte und die sogenannten Patterns, die Standardlösungen in der Software-Architektur, werden erklärt. Und schließlich zur Praxis: Wie integriert man das in eine AUTOSAR-Architektur?
In den letzten Jahren ist die Anzahl der Steuergeräte (Electronic Control Units, ECUs) und der Funktionen im Fahrzeug stark gewachsen. Neue Technologien besonders im Fahrerassistenzbereich erhöhen die Komplexität der Funktionen und die Ansprüche an die Leistungsfähigkeit der Hardware. Wo früher Single-Core-Prozessoren mit 40 MHz ausreichend waren, kommen heute Mehrkernprozessoren mit dreistelliger Taktfrequenz zum Einsatz. Um die Komplexität besser zu beherrschen, haben Standardisierungsgremien wie AUTOSAR oder GENIVI Software-Architekturen entwickelt, die mittlerweile in vielen ECUs etabliert sind. Sicherheitsstandards wie ISO 26262 oder IEC 61508 enthalten weitere Richtlinien zur Steuergeräteentwicklung nach Kriterien in Hinsicht auf die funktionale Sicherheit, ohne dabei konkrete Lösungen vorzuschreiben und damit den Lösungsraum einzuschränken.
Mit neuen Assistenzfunktionen und zunehmender Komplexität wachsen aber auch die Ansprüche an die Behandlung der Fehler, die auf Steuergeräten auftreten können. Die meisten Systeme, die bisher eingesetzt werden, basieren auf sogenannten Fail-Safe-Architekturen: Wenn mit hoher Wahrscheinlichkeit ein Fehler im Steuergerät erkannt ist, wird die Funktion ausgeschaltet und die volle Kontrolle an den Fahrer zurückgegeben, indem der Fahrer über einen Ausfall informiert wird.
Der „sichere Zustand“ für viele Assistenzsysteme ist also das Ausschalten und damit verbunden die Warnung des Fahrers. Dieser muss dann gegebenenfalls die Fahrt unterbrechen oder zeitnah eine Werkstatt aufsuchen. Diese Art der Fehlerbehandlung ist für den Fahrer zwar ärgerlich, aber unbedenklich. Sobald aber Funktionen für teilautomatisiertes oder vollständig autonomes Fahren betroffen sind, ist diese Fehlerbehandlung nicht mehr ausreichend, um die Sicherheit der Fahrzeuginsassen zu gewährleisten. Hier muss im Falle eines auftretenden Fehlers dennoch volle oder zumindest eingeschränkte Funktionalität bereitstehen. Systeme, die das ermöglichen, werden „fail-operational“ genannt. Folgende drei Prinzipien zur Realisierung haben sich dabei etabliert:
- Vorwärtsfehlerkorrektur - Bei der Vorwärtsfehlerkorrektur versucht das System so zu operieren, als ob kein Fehler aufgetreten wäre. Das geschieht zum Beispiel durch Nutzung von Default-Werten oder durch zeitnahes Umschalten auf ein Ersatzsystem.
- Rückwärtsfehlerkorrektur - Bei der Rückwärtsfehlerkorrektur versucht das System, beim Auftreten eines Fehlers in einen vorherigen Zustand zurückzukehren. Das erfolgt beispielsweise durch den Neustart einer Funktion auf dem Steuergerät im Rahmen seiner Funktions-Ausfalltoleranzzeit oder durch das Wiederherstellen eines als funktionsfähig bekannten Zwischenstandes (Recovery), vergleichbar mit den Wiederherstellungspunkten bei einigen Betriebssystemen. Im Idealfall nimmt der Nutzer hierbei einen Funktionsausfall nicht wahr.
- Externe Fehlerkorrektur - Bei der externen Fehlerkorrektur wird der Systemzustand eingefroren und die Fehlerkorrektur durch eine externe Maßnahme realisiert, wie durch ein Software Update. Dieses Vorgehen ist zwar bei Funktionen wie Bremse oder Lenkung aufgrund der entstehenden Zeitverzögerung nicht praktikabel. Für Komfortsysteme wie zum Beispiel Multimedia kann es aber die einfachste Lösung sein, insbesondere wenn sich ein solches Update „Over the Air“ (OTA) und somit ohne Werkstattbesuch einspielen lässt.
Fail-operational-Systeme sind bereits in anderen sicherheitskritischen Bereichen etabliert, beispielsweise bei Atomkraftwerken oder in der Luftfahrt. Ein Fehler darf hier nicht zu einem Komplettausfall von Grundfunktionen führen. Das Systemdesign besteht in diesen Anwendungsfällen meist aus mehrfach redundanten Teilsystemen und Monitormechanismen, die im Fehlerfall den verursachenden Pfad ausblenden oder ersetzen.
Eine ähnliche Redundanz von Sensoren, Aktuatoren und Rechnersystemen lässt sich aber aufgrund der hohen Kosten in der Automobilbranche nicht einfach realisieren. Eine mögliche Lösung wäre es, etablierte Patterns (Entwurfsmuster) für hochverfügbare sicherheitsrelevante Software auf einzelne Kerne von Mehrkernprozessoren abzubilden oder Funktionsübernahmen durch andere Steuergeräte zu realisieren. Letzteres wird eine Änderung bestehender E/E-Fahrzeugarchitekturen mit sich bringen: Funktionen werden dynamisch auf mehrere Steuergeräte verteilt und hinzu- oder abgeschaltet.
Jobangebote+ passend zum Thema
Fehlererkennung
Die meisten Fahrerassistenzfunktionen wie der Spurhalteassistent (Lane Assistant) berechnen aus einer Vielzahl von Eingabewerten wie Kamerabildern eine Ausgangsentscheidung (Bild 1). In diesem Fall sind das Fahrerwarnung oder aktiver Lenkeingriff.
Viele Assistenzfunktionen verarbeiten umfangreiche Datenmengen, die oft von mehreren Sensorsystemen stammen, zum Beispiel um aus Sicherheitsgründen redundante Pfade zu haben. Diese Daten werden aufbereitet, plausibilisiert und zu einer Funktionssicht fusioniert. Fehler in der Verarbeitung oder in der Entscheidung werden umso kritischer, je weiter rechts sie im Entscheidungsdreieck von Bild 1 auftreten, weil die Redundanz in den Daten und in den Entscheidungen abnimmt. Die Mechanismen zur Fehlererkennung sind identisch zu den Fail-Safe-Systemen. So werden beispielsweise Prüfsummen, Plausibilitätsprüfung, Threshold Analysis oder Filterung transienter Werte auf dem Datenfluss genutzt. Hinzu kommen Fehlererkennungsmechanismen, die die Systemintegrität überwachen und bei Bedarf Systemtests zur Laufzeit ausführen. Diese Systemtests werden notwendig, wenn die Betriebszeit zunimmt, weil Assistenz- und automatisierte Funktionen in immer mehr Fahrsituationen eingesetzt werden. Dadurch können vermehrt transiente Fehler auftreten.
Fehlerkorrektur
Die Rückwärtsfehlerkorrektur ist der aktuell am häufigsten verwendete Fehlerkorrekturmechanismus bei Fail-Operational-Architekturen. Es wird eine als fehlerhaft erkannte Berechnung gestoppt und die Funktion durch einen Neustart wiederhergestellt.
In diesem Szenario sollte nur die betreffende Funktion, nicht aber andere Funktionen oder gar das gesamte Steuergerät neu gestartet werden, um die Verfügbarkeit intakter Funktionen nicht zu beeinflussen. Grundanforderung ist daher ein partitioniertes System, das es ermöglicht, einzelne Partitionen oder Funktionen neu zu starten. Zusätzlich sollten dabei auch die betroffenen Hardware-Teile reinitialisierbar sein, beispielsweise weil der Zustand der Hardware die Fehlerursache war und zurückgesetzt werden muss. Der Neustart wird von einem Systemmonitor überwacht, der auch Metadaten wie die Häufigkeit der Neustarts verwaltet und sie der Maintenance bereitstellt. Einen Restart durchzuführen kann zeitlich sehr aufwändig sein. Daher bietet es sich an, zu einem bekannten und gültigen Systemzustand zurückzukehren. Dieses Pattern wird Checkpoint genannt. Zu Beginn eines neuen Berechnungszyklus wird ein Funktionszustand gespeichert – der Checkpoint. Anschließend wird die Funktion ausgeführt und muss einen Akzeptanztest bestehen. Wird dieser nicht bestanden, wird der Checkpoint wiederhergestellt und eine alternative Berechnung ausgeführt (Bild 2).
Das Checkpoint Pattern lässt sich zusätzlich noch erweitern, um den Cache und die Ergebnisse zwischenzuspeichern. Ein Voter kann darüber hinaus eine Mehrheitsentscheidung über die einzelnen Ergebnisse erzielen (Bild 3). Die Auswahl der Mechanismen hängt von den Anforderungen an die Zuverlässigkeit des Systems ab. Die Software-Architektur von AUTOSAR ist statisch konfiguriert, inklusive dem Betriebssystem (BS). Um dynamische Ersatzmechanismen in eine statische Architektur zu integrieren, bietet AUTOSAR mehrere Möglichkeiten. Für das Umschalten von Funktionen auf einen Ersatzmechanismus müssen Funktionen zu- und abschaltbar sein. AUTOSAR bietet hier verschiedene Mechanismen, zum Beispiel
RTE Mode Switches, Starten und Stoppen von Alarmen und Tasks, um somit die Ausführung von Funktionen zu beeinflussen, Starten und Stoppen von BS-Applikationen, die wiederum eine Gruppe von BS-Objekten (zum Beispiel Task und Interrupts) abbilden.
Für das unabhängige Ausführen von Funktionen und Monitoren muss das Betriebssystem einen Partitionierungsmechanismus bereitstellen. Das Betriebssystem „EB tresos Safety OS Multi-Core“ beispielsweise weist neben dem erforderlichen Partitionierungsmechanismus, der bereits bis ASIL D zertifiziert wurde, außerdem die Möglichkeit auf, Partitionen zu starten und stoppen, weil diese über BS-Applikationen abgebildet werden. Somit lässt sich auf einem Steuergerät eine effiziente Funktionsmigration realisieren.
- Auf alles vorbereitet sein
- Funktionen über Steuergerätegrenzen verteilen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
ITK Engineering
Kombiniertes Testen ermöglichen
Entwicklungsplattform für Bedienoberflächen
Elektrobit stellt EB Guide 6 vor
Professor Ferdinand Porsche Preis
Innovatives Airbag-System für Motorradfahrer
Conti TechShow 2015:
Was unsere Autos in Zukunft können werden
