Inhalte

Fachartikel

Mit Timing-Design die Freedom-from-Interference Anforderungen der ISO 26262 erfüllen

Wie man Mixed-Critical Systems mit der richtigen Software-Architektur gleichzeitig effizient und sicher gestaltet.

Inhaltsverzeichnis

Die ISO 26262, Part 6, Clause 7, formuliert sehr strenge Anforderungen an Softwarearchitekturen von Steuergeräten sowie deren Verifikation. Dabei werden die dynamischen Aspekte wie Schedules und Echtzeitverhalten besonders betont, wie auch die unbedingte Forderung nach Freedom-from-Interference (Requirement 4.11 sowie Annex D) bei Sys­temen mit heterogenen Sicherheitsanforderungen (mixed-criticality).  Es muss beispielsweise ausgeschlossen werden, dass ASIL-C-Software durch ASIL-B- oder A-Komponenten blockiert oder verdrängt wird (im Schedule), speziell im Fehlerfall der nieder kritischen Komponenten.
Dies führt zu völlig neuen Fragestellungen und Einschränkungen der Design-Möglichkeiten. Beispielsweise sind die in Single-criticality-Systemen etablierten Echtzeit-Überwachungs-Mechanismen 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 Echtzeit-Fehlern, z.B. „Funktion X verpasst die Deadline“. Für Mixed-Criticality-Systeme müssen wir aber auch die Ursachen unterscheiden, und die können sehr vielfältig sein, z.B.
a) „Funktion X hat aufgrund eines Fehlers eine zu lange eigene Laufzeit“ oder
b) „eine andere Funktion Y hat einen Fehler, dadurch eine zu lange Laufzeit und bremst nun Funktion X aus“ (Interferenz).
Derartige Fragestellungen sind heute als Folge der Hochintegration in immer mehr Steuergeräteprojekten an der Tagesordnung. Für den Projekterfolg wird somit die Festlegung einer geeigneten dynamischen Software-Architektur mit ihrem Schedule essentiell. Dies beinhaltet insbesondere die Auswahl von Schedule-Prioritäten sowie die Nutzung modernerer Überwachungsfunktionen. Nur so können wir die Anforderungen an Ressourceneffizienz und Sicherheit gleichermaßen erfüllen

Prioritätenverteilung

RMS (Rate Monotonic Scheduling) ist ein einfaches, weltweit etabliertes Verfahren zur Vergabe von Schedule-Prioritäten. Häufiger ausgeführte Tasks (kleine Periode) erhalten eine höhere Priorität als seltener ausgeführte (große Periode). Beispielsweise bekommt eine 1 ms-Funktion eine höhere Priorität als eine 5 ms-Funktion. Schedules nach diesem Prinzip können sehr hohe CPU-Lasten noch zuverlässig ausführen, ohne dass Deadlines verpasst werden. Jedoch ignoriert dieses Verfahren die Forderung nach Freedom-from-Interference. Tritt z.B. in der 1ms-Funktion (z.B. ASIL-A) ein Fehler auf, etwa eine Endlosschleife, so wird die 5 ms-Funktion (z.B. ASIL-C) dauerhaft verdrängt.
Das CAPA-Verfahren (Criticality As Priority Assignment) vermeidet derartige Interferenzen, indem es die Prioritäten nach den Kritikalitätsstufen verteilt. So erhält die 5ms-ASIL-C-Funktion aus dem o.g. Beispiel eine höhere Priorität als die 1 ms-ASIL-A-Funktion. Freedom-from-Interference ist per Design sichergestellt und folgt einer Empfehlung der ISO 26262. Doch dieser Ansatz ignoriert diverse zeitliche Aspekte. Wenn z.B. die 5 ms-ASIL-C-Funktion eine Laufzeit von 2 ms aufweist (entspricht 40% CPU-Last), so wird die 1 ms-ASIL-A-Funktion ihre Deadline regelmäßig und vorhersehbar verpassen; d.h. ein CAPA Schedule ist zwar sicher, aber nicht effizient.

AUTOSAR Timing Protection

Um die Forderungen der ISO 26262 einzuhalten, können nun erweiterte Schutzmechanismen eingesetzt werden. Die AUTOSAR Timing Protection bzw. ein Execution Time Monitoring überwacht u.a. die Ausführungszeit (nicht die Deadline) einer Funktion oder Task während der Laufzeit. Beim Überschreiten des zugewiesenen Laufzeit-Budgets wird dies als Fehler gewertet und entsprechend konfigurierte Fehlerbehandlungsmethoden (Beenden der Funktion, Neustart des Steuergerätes) werden aktiviert. Im Vergleich zum einfachen Watchdog erfolgt die Fehlerbehandlung nun nach dem „Verursacher-Prinzip“.
Angewendet auf das obige Beispiel könnte man die 1 ms-ASIL-A-Funktion in einem effizienten RMS-Schedule von der Timing Protection überwachen lassen. Würde die Task nun in die Endlosschleife verfallen, dann würde dies sofort bemerkt und die Funktion z.B. einfach gestoppt. Eine unkontrollierte Verdrängung der 5ms ASIL-C-Funktion wird somit in jedem Fall unterbunden. Im Ergebnis erhalten wir einen hocheffizienten RMS-Schedule, der mittels Execution Time Monitoring Interferenz-frei arbeitet.

Methodik der Sicherheitsprüfung für zuverlässige Software-Architekturen in multi-kriteriellen Systemen.

Methodik

Um die notwendigen Entscheidungen zu systematisieren, hat Symtavision zusammen mit seinen Partnern ein Vorgehensmodell entwickelt, welches bereits in der Praxis validiert wurde und in zahlreichen Projekten eingesetzt wird (Bild).
Zunächst sollte ein Ablaufplan nach RMS entworfen werden, dessen Prüfung auf Kritikalitätsinversionen vergleichsweise einfach ist. Im negativen Fall wird der Entwurfsraum durch die Timing Protection erweitert. Idealerweise ist diese für die gesamte SW-Architektur verfügbar, ansonsten wird bis zum verfügbaren ASIL-Level (z.B . ist der BSW-Service Execution Time Monitoring heute eher selten für ASIL-C/D verfügbar) RMS und  für die nicht schutzbaren ASIL-Stufen CAPA eingesetzt. Die Sicherheitsprüfung kontrolliert, ob der Schedule per Design sicher ist.
Anschließend wird die Einhaltung der zeitlichen Vorgaben geprüft. Sind diese erfüllt, wird die Timing Protection für den Schedule konfiguriert und eine optionale Optimierung für weitere Effizienzverbesserungen kann folgen. Bei Verletzung der zeitlichen Parameter sind Maßnahmen wie zum Beispiel die Anpassung der Softwarearchitektur erforderlich. Der Fehlerfall muss zusätzlich untersucht werden. Wenn beispielsweise ein gesetztes Laufzeit-Budget überschritten und die Recovery Methode gestartet wird, darf diese den Schedule nicht erneut negativ beeinflussen. Ansonsten würde zwar ein Laufzeitfehler aufgedeckt und verhindert, jedoch der Schedule durch die Fehlerbehandlung selbst gestört werden.
Um die beschriebene Optimierung bereits in einer frühen Phase der Entwicklung durchführen zu können, benötigen wir neben den typischerweise vorhandenen Konfigurationsinformationen (Tasks, Zykluszeiten, ASIL-Stufen) auch Informationen zur Ausführungszeit der Tasks bzw. Runnables. Zum Treffen grundlegender Entscheidungen sind auch grobe Abschätzungen zielführend, eine hohe Genauigkeit wird nicht benötigt.
Die vorgestellte Methodik wurde zusammen mit Kunden von Symtavision entwickelt und in der Praxis evaluiert. Ergebnis: Die Methodik erhöht die Realisierungswahrscheinlichkeit von Steuergeräte-Projekten signifikant, reduziert Sicherheitsrisiken und ermöglicht systematische Architekturoptimierungen. Gleichzeitig entsteht bei allen Beteiligten das Bewusstsein, dass Timing und Safety in Zukunft als sogenannte querschneidende Architekturaspekte sowohl beim Entwurf als auch entwicklungsbegleitend bis hin zum Test Berücksichtigung finden müssen, um die komplexen Anforderungen für die Entwicklung hochintegrierter Steuergeräte zu meistern.

Christoph Ficek, Symtavision GmbH E-Mail: ficek@symtavision.com