Fehlererkennung und -behebung in Multifunktions-Steuergeräten

Aufstellung aller relevanten Anforderungen

In jedem Fall steht am Anfang der Überprüfung eine systematische Aufstellung der Anforderungen an die Kombinationen, die abzusichern sind:

• Echtzeitverhalten der Funktion im Nominalfall, Recovery-Fall und Safe State. Fokus auf die Rechenleistungsanforderungen: welche Prozessorlast bzw. Ausführungszeit wird in welchem Raster (1, 5, 10 ms) benötigt?
• Software-Architektur, insbesondere Funktions- (bzw. Runnable-) Mapping und Task-Prioritäten.
• Mechanismen der Fehlererkennung; dies ist wichtig, um die Grenzwerte des Nominalfalls zu verstehen.

Hieraus lässt sich nun für jede der in Bild 2 angedeuteten Kombinationen ein System-Echtzeit-Modell erstellen, das alle Anforderungen enthält. Basierend auf diesem Modell erfolgt eine Überprüfung wirklich aller Kombinationen. Mittels Scheduling-Analysen gelingt dies leicht, weil sich die benötigten Timing-Modelle automatisch aus den oben genannten Daten erstellen lassen. Zeigen die Überprüfungen, dass in allen Kombinationen immer ausreichend Rechenleistung zur Verfügung steht, um die auftretende Rechenlast zu erfüllen, ist das Design in Ordnung. Ist dies nicht der Fall, muss das Design entsprechend überarbeitet werden.

Jobangebote+ passend zum Thema

Regional Key Account (m/w/d) für Elektronische Bauteile

KOA Europe GmbH, Dägeling

---

Alle Jobangebote im Elektroniknet Karrierebereich anzeigen

Bild 3 zeigt einen beispielhaften Schedule. Dabei tritt in Task T2 der Applikation B ein Fehler auf, der zur Aktivierung der entsprechenden Recovery-Funktion führt. Dies beeinflusst nun Task T3 der Applikation A. Mit Hilfe einer Scheduling-Analyse wurde jedoch überprüft, dass diese Interferenz keinen Schaden an T3 ausübt, d.h., T3 kann innerhalb der Zykluszeit vollständig ausgeführt werden. Dies gilt jedoch nur so lange, wie die Applikation T2 sowie die Recovery-Funktion in ihrer Laufzeit beschränkt werden können. In dem Beispiel ist ebenfalls zu sehen, dass die Recovery von T2 nicht erfolgreich war und danach nur noch eine sehr kurze Ausführung im Safe State stattfindet (Notprogramm). Je nach tatsächlicher Laufzeit können Fehler zu anderen Interferenz-Effekten führen, und je nach ASIL-Stufe und Priorität kann dies nach ISO 26262 zulässig sein oder nicht.

Für den Fall von unzulässigen Interferenzen sind verschiedene Änderungen denkbar und laut ISO 26262 zulässig. Am relevantesten sind solche Maßnahmen, die die Software-Architektur und/oder die Fehlererkennungsmechanismen robust gegenüber Interferenzen machen. Hierzu wurden bereits verschiedene Vorschläge gemacht, wie etwa alternative Prioritätsverteilungen oder Anpassungen der Software-Zykluszeiten. Weiterhin können auch intelligentere Fehlererkennungs-Maßnahmen einen wesentlichen Beitrag leisten. Jedoch sind die in Einzelfunktions-Steuergeräten etablierten Echtzeit-Überwachungsmechanismen wie Deadline Monitoring (häufigste Form von Watchdogs) nicht mehr ausreichend zur Darstellung der ISO-26262-Anforderungen nach „Freedom from Interference“. Solche Watchdogs überwachen die Symptome von Echtzeitfehlern, z.B. „Funktion A verpasst die Deadline“. Für Mixed-Criticality-Systeme müssen aber auch die Ursachen unterschieden werden (warum?), die sehr vielfältig sein können, z.B. „Funktion A hat aufgrund eines Fehlers eine zu lange eigene Laufzeit und verpasst die eigene Deadline“ (Symptom erkannt beim Verursacher) oder „eine andere Funktion B hat einen Fehler, dadurch eine zu lange Laufzeit und verdrängt nun Funktion A, die dadurch ihre Deadline verletzt“ (Symptom erkannt, jedoch nicht am Verursacher).

Mittels Deadline-Monitoring sind diese grundverschiedenen Ursachen kaum unterscheidbar. Das wirft die Frage auf, ob diese Überwachungsmechanismen überhaupt angewendet werden dürfen, wenn man doch gar nicht erkennen kann, in welcher Funktion der Fehler aufgetreten ist.

Überwachung der Ausführungszeit

Neue AUTOSAR-Dienste wie „Execution Time Monitoring“ sind da genauer. Sie überwachen u.a. die Ausführungszeit (nicht mehr nur die Deadline) einer Funktion oder Task. Im Vergleich zum einfachen Watchdog erfolgt die Fehlerbehandlung dann nach dem Verursacherprinzip, erlaubt gezielte Fehlerbehandlungen und vermeidet die Fehlerfortpflanzung. Dies ist bereits in Bild 3 gezeigt.

Der hier vorgestellte Ansatz liefert das gewünschte Ergebnis, wenn man die ISO-26262-Anforderungen unter dem Gesichtspunkt von Mixed Criticality und heutigen System-entwürfen betrachtet. Dabei wird klar, dass heutige Fehlerbehandlungsmechanismen, angewendet auf diese neuen integrierten Systeme, teilweise nicht mehr (z.B. Neustart des Steuergeräts) oder nur unter gewissen Voraussetzungen anwendbar sind (reines Deadline Monitoring). Neue Mechanismen müssen entwickelt bzw. alte weiterentwickelt werden, um die Komplexität weiterhin beherrschen zu können. Auch gilt es, ein Systembewusstsein zu schaffen, um diese Komplexität in allen Phasen der Entwicklung zu erfassen. Man muss die Auswirkungen besser einschätzen können, damit auch die richtigen Fehler erkannt und effizient behandelt werden. Dabei sind nicht nur die Fehlererkennungsmechanismen selbst betroffen, sondern auch Mechanismen wie Scheduling-Analysen, die bewerten, ob ein System auch im Fehlerfall noch die Echtzeitanforderungen erfüllt.

Die Autoren:

1. Fehlererkennung und -behebung in Multifunktions-Steuergeräten
2. Aufstellung aller relevanten Anforderungen

Das könnte Sie auch interessieren

Steuergeräte

Mit Leistung und Harmonie im Takt

Entwicklung + Test

Prüfstand für den komplexen Steuergeräteverbund

MTA

Kombiinstrument fungiert als Anzeige und Bordcomputer

Pretended Networking als Alternative zum…

Funktionen statt Steuergeräte abschalten

Jedes Watt zählt

Intelligentes Energie- und Leistungs-Management für die Autos von morgen

Virtualisierung

Vision einer intelligenten Vernetzung