Anforderungen an Fail-Operational-Systeme in Fahrzeugen

Fail-Operational-Systeme müssen weiterhin funktionieren, auch wenn ihre Steuerungssysteme ausfallen. Gerade in Fahrzeugen müssen sie hohen Ansprüchen hinisichtlich Safety, Security, harte Echtzeit oder Robustheit gerecht werden. Zeit für einen Überblick über Anforderungen an und Entwicklungen in betriebssicheren Systemen.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Die Anforderungen durch automatisiertes Fahren werden zu kostengünstigen Lösungen für Fail-Operational Systeme bzw. betriebssichere Systeme führen. Neben dem hohen Kostendruck müssen aber auch die hohen Anforderungen der Automobilindustrie bei Safety, Security, harter Echtzeit, Qualität, Robustheit und langer Bauteilverfügbarkeit erfüllt werden.

In diesem Artikel wird eine Übersicht über die Anforderungen an solche Systeme gegeben und wie sie mit evolutionären und nachhaltigen System-, Software- und Hardwarearchitekturen adressiert werden können. Ähnliche Architekturen können auch außerhalb der Automobilindustrie verwendet werden, die kostengünstigen Bauteile und die lange Verfügbarkeit machen diesen Ansatz attraktiv.

Bildergalerie

Von Fail-Safe zu Fail-Operational

Fail-Safe bedeutet, dass ein System erkennen kann, wenn es nicht mehr funktioniert, und dann in einen passiven sicheren Zustand geht. Dieses Verhalten ist akzeptabel für die Lenkkraftunterstützung eines Fahrers, aber nicht für eine automatische Lenkung. Eine solche Lenkung muss als Fail-Operational ausgelegt werden.

Die Fehlererkennung für Fail-safe und Fail-operational ist eine sehr große Herausforderung. Auf der HW Ebene ist der Stand der Technik (z.B. Infineons AURIX™ Mikrocontrollerfamilie) Speicher und Busse mit Error Correction Codes (ECC) die Multi-Bit Fehler erkennen und Prozessor Kerne mit redundanten Rechenwerken (Lockstep). Daneben unterstützt die Hardware die Erkennung von Fehlern in der Software z.B. mit adressbasierten Speicherschutzvorrichtungen in gemeinsam genutzten Speichern und Peripherie-Modulen und auch direkt in den Prozessorkernen (MPU).

Es gibt noch viele andere Maßnahmen, die Fehler erkennen und teilweise sogar korrigieren können. Letzteres ist lokal für Bitfehler in Speichern möglich (ECC), bei anderen Alarmen in den Hardware- und Software-Überwachungseinheiten wird die Fehlerreaktion fast immer ein Reset und Neustart sein. Falls man die genaue systematische Fehlerursache kennen würde, beseitigt man diese schon in der Entwicklungsphase, anstatt komplexe und damit auch wieder anfällige Fehlerbehandlungsstrategien zu entwickeln.

Der Fehlerbehandlungscode ist auch häufig der am schlechtesten getestete Code, da er oft schwer zu stimulieren ist und zu beliebigen Zeitpunkten aktiviert werden kann. Wenn das Fehlersymptom nicht eindeutig ist, könnte er auch in Situationen aktiviert werden, für die er gar nicht vorgesehen ist, und damit wie ein falsches Medikament unkontrollierbaren Schaden verursachen. Für traditionelle Mikrocontroller mit embedded Flash ist die Totzeit durch einen Reset im Bereich von bis zu wenigen 10 ms– und damit akzeptabel für langsame physikalische Systeme wie ein Fahrzeug.

Dieses gut verstandene und kostenoptimierte Grundelement eines Fail-Safe-Steuerungskanals von den Sensoren bis zu den Aktoren lässt sich für ein Fail-Operational-System wiederverwenden (Bild 1). Im einfachsten Fall wird der Steuerungskanal komplett verdoppelt, mit eigenen Sensoren, Aktuatoren, deren Verkabelung und insbesondere auch einem völlig unabhängigem Stromversorgungs-, Clock- und Resetsystem. Eine gewisse Asymmetrie der Kanäle aus Kostengründen ist möglich, da nicht alle Funktionen sicherheitsrelevant sind, und diese deshalb ohne Redundanz gerechnet werden können.

Ein Lenkungssystem hat eine klare und gut überprüfbare Aufgabe. Es muss einen vorgegebenen Lenkwinkel durch die Ansteuerung der Motoren umsetzen. Das erfolgt durch überprüfbare kausale Abläufe, was eine einfache Fehlererkennung erlaubt. Die beim Automatischen Fahren benötigte Steuerung, die aus Kamera- und Radardaten den Lenkwinkel berechnet, hat hier eine weit komplexere Aufgabe.

Einfache und kostenoptimierte Fail-Operational-Systeme

Für solche komplexen Systeme kann eine hierarchische Architektur mit einer Fail-Operational ausgelegten Überprüfungs- und Rückfallebene eingesetzt werden. Einen ähnlichen Ansatz hat auch die Evolution mit Großhirn, Kleinhirn, zentralem und vegetativem Nervensystem entwickelt. Die meisten Menschen können zum Beispiel nicht durch bewusstes Anhalten des Atems ohnmächtig werden. Und selbst wenn, dann setzt mit der Ohnmacht die Atmung wieder ein (Bild 2).

Die Grundidee ist, dass die Rückfallebene ein vereinfachtes und konservatives Zustandsmodell und Steuerungsregeln hat, mit dem die Entscheidung des Hauptrechners überprüft werden kann. Falls diese nicht plausibel erscheint (z.B. Hindernisse im Fahrkanal beim Überholvorgang), übernimmt die Rückfallebene mit einer konservativen Fahrstrategie (z.B. wir bleiben hinter dem LKW). Die Rückfallebene kann dann den Hauptrechner wieder neu starten, und wenn dieser plausible Ergebnisse liefert, übernimmt er wieder die Steuerung (Bild 2).

Dieser Ansatz hat mehrere Vorteile: Zum einen muss nur die Rückfallebene den höchsten Automotive-Sicherheitsanforderungen (ASIL-D) genügen und Fail-Operational sein. Das spart nicht nur Kosten und Verlustleistung, sondern es ist auch für leistungsfähige, PC-artige Prozessorarchitekturen nur schwer möglich, ASIL-D zu unterstützen. Die Software des Hauptrechners ist auch so komplex, dass sie in der Praxis kaum vollständig nach ASIL-D entwickelt werden kann.

Komplexitätstreiber Safety, Security und Software

Nach Einschätzung der meisten Experten für funktionale Sicherheit (Safety) werden die Risiken von Hardware-Fehlern (z.B. Soft-Errors durch radioaktive Strahlung) durch konservatives Addieren der Fehlerwahrscheinlichkeiten systematisch überschätzt. Gleichzeitig werden die Risiken der Software unterschätzt, da es hier keine belastbaren Fehlermodelle gibt. Das Problem wird noch größer, wenn die Software nicht auf einer Hardware läuft, die verlässlich Hardware-Fehler erkennt, und wenn Security und harte Echtzeitanforderungen hinzukommen.

Alles, was die Software-Komplexität und damit die Fehleranfälligkeit erhöht, sollte vermieden werden. Die Datensicherheit (Security) muss z.B. sehr stark an den Außengrenzen des Systems sein (Gateway, Software-Updates). Innerhalb des Systems muss, basierend auf realistischen Angriffsszenarien, ein vernünftiger Kompromiss zwischen Security, Safety und Komplexität gefunden werden.

Auswirkungen auf die Software

Multicore Architekturen bieten flexible und kostengünstige Möglichkeiten, Safety Architekturen zu implementieren. Hier geht es häufig darum, mehrere (oder redundante) Software Algorithmen zu implementieren und ihre Unabhängigkeit darzustellen. Wenn die Kerne hinreichend unabhängig sind (z. B. getrennte Caches), vorhersagbares Timing-Verhalten besitzen und unabhängig voneinander auf getrennte Speicher zugreifen können, kann eine weitgehende Isolation der auf den einzelnen Kernen ablaufenden Software erreicht werden.

Alleine durch das Zuweisen auf verschiedene Kerne wird die gegenseitige zeitliche Beeinflussung der Software Teile minimiert, wenn das Verbindungsnetzwerk zu keiner oder einer vorhersagbaren Beeinflussung führt (z.B. Cross-Bar mit Priorisierungsstrategie). Um den Entwicklungs- und Verifikationsaufwand für den Nachweis der Unabhängigkeit gering zu halten, kann auf Hardwaremechanismen wie z.B. eine Memory Protection Unit (MPU) oder geeignete Software Tools (z.B. Compiler und Linker mit eingebauter Adressenüberprüfung für Speicherzugriffe) zurückgegriffen werden.

Idealerweise werden die die Isolation unterstützenden Mechanismen (wie Memory Protection, Interrupt Routing, Zugriffschutz für gemeinsame Ressourcen) durch Virtualisierung abstrahiert und so für den User transparent. Der Hypervisor stellt also in diesem Fall virtuelle Maschinen zur Verfügung, die sicher (safe and secure) voneinander getrennt sind und sich temporal kaum beeinflussen (durch separate Kerne). Für den Software Entwickler entsteht so der Eindruck, dass er separate, komplett unabhängige Algorithmen entwickeln kann, die dann kostengünstig auf einem Multi-Core Chip instanziiert werden können, ohne die Safety-Anforderungen, zu verletzen.

Neben der Unterstützung für ein korrektes Software Design, sei es durch die Hardware selbst oder durch zusätzliche hardwarenahe Softwareschichten wie einem Hypervisor, werden ausgeklügelte Methoden zur Überwachung des Gesundheitsstatus des Systems immer wichtiger werden. Diese Methoden werden zum Beispiel die Kommunikation zwischen verschiedenen Softwarekomponenten beobachten, Kommunikation zwischen verschiedenen Kernen und auf den Bussystemen.

Mit solchen Methoden wird es viel differenzierter als mit dem Service für einen Watchdog Timer möglich sein, problematische Zustände eines Steuergerätes oder innerhalb einer Steuergerätedomäne zu erkennen. Für die AURIX Mikrocontroller wird ebenfalls an einer Methodik zur Erkennung ‚krankhafter‘ Zustände der Software gearbeitet, im Rahmen eines speziellen Analysetools. Vorerst dient das Analysetool der eigentlichen Softwareentwicklung, aber in Zukunft könnten einige der Analysemethoden auch noch zur Laufzeit eingesetzt werden.

Software-Entwicklung für Multicore-Systeme

(R)Evolution der Automotive-Software-Architekturen

(Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband Embedded Software Engineering Kongress 2016 entnommen.)

* Dr. Albrecht Mayer ist seit 2015 verantwortlich für die Systemarchitektur der dritten Generation der AURIX Multicore Mikrocontroller Familie.

* Jens Harnisch ist Tool Partner Manager und Senior Staff Expert für Multi-Core Tooling.

* Gerhard Wirrer ist Lead Principal SW Architect Automotive Microcontrollers bei Infineon Technologies.

(ID:44852028)