Safety Automotive
Fehlertolerante Systeme im Fahrzeug – von "fail-safe" zu "fail-operational"
Fortsetzung des Artikels von Teil 2
Beispiele für Fail-Operational-Architekturen
Bild 2 zeigt beispielhaft eine klassische 2-aus-3-Systemarchitektur für einen Fail-Operational-Betrieb. Das System besteht aus drei Subsystemen, die jeweils mit Sensorik, Verarbeitung und Aktuatorik ausgestattet sind.
Jobangebote+ passend zum Thema
Typischerweise findet eine Konsolidierung der Eingangsdaten entweder durch eine direkte Verteilung der Sensorwerte bei räumlicher Nähe oder durch Austausch auf seriellen Datenverbindungen zwischen den Subsystemen statt. In jedem Fall muss die Konsolidierungsstrategie der Eingangsdaten in Bezug auf die Konsolidierungsstrategie der Ausgangsdaten – das Voting – hinreichend Replica-Determinismus gewährleisten. Das Voting und die Konsolidierung der Ausgangsdaten findet meistens auf der logischen Ebene durch entsprechenden Datenaustausch statt. Zusätzlich findet oft auch eine entsprechende Aktuatorik mit Eigenschaften wie Flux-Superposition Anwendung. Hinsichtlich der Anzahl der Verarbeitungseinheiten erscheint dieser Architekturansatz zunächst recht ökonomisch. Weil jedoch nicht bekannt ist, welche der drei Fehlereinheiten ausfallen wird, entsteht schnell eine Situation mit entsprechender Redundanz aller kritischen externen Ressourcen, wie Spannungsversorgung, Clock-Domänen und Reset-Domänen pro Subsystem. Gerade hohe Redundanzen der Spannungsversorgung sind im Fahrzeug technisch durchaus heikel und aus techno-ökonomischer Sicht unattraktiv.
Bild 3 zeigt eine typische Duo-Duplex-Systemarchitektur, die ebenfalls für einen Fail-Operational-Betrieb geeignet ist. Das System besteht in diesem Fall aus zwei Subsystemen, die jeweils für sich eine Überwachung ausweisen. Die zugrunde liegende Idee ist, dass jedes Subsystem für sich fail-silent ausgeführt ist und somit den Aktuator entweder richtig oder gar nicht ansteuert. Fällt ein Subsystem aus, ist das System weiterhin unter der Kontrolle des anderen Subsystems. Zumeist findet auch bei diesem Ansatz eine Konsolidierung der Eingangs- und Ausgangsdaten statt. Einerseits, um wieder je nach Aktuatorik hinreichend für Replica-Determinismus zu sorgen und andererseits, um eine entsprechende Systemdiagnose durchzuführen. Aus längerfristigen Sicherheitsbetrachtungen ist es wichtig zu wissen, ob das System seine Funktion durch beide Subsysteme oder nur noch durch ein Subsystem erbringt und die Fehlertoleranz somit verloren gegangen ist.
Aus Sicht der Verarbeitungseinheiten betrachtet erscheint dieser Architekturansatz etwas aufwendiger. Die Überwachung innerhalb des jeweiligen Subsystems ist jedoch meistens ökonomischer als eine komplette Aufdopplung des Subsystems selbst. Die Redundanz an kritischen externen Ressourcen ist in diesem Ansatz geringer als in der 2-aus-3-Architektur, was besonders hinsichtlich der Spannungsversorgungen vorteilhaft ist. In der Praxis ist gerade bei Fahrzeugen eine volle Symmetrie oftmals nicht notwendig, da nur ein kurzer Notbetrieb – eine sogenannte „Limp home“-Phase – notwendig ist, um das System aus einer Fail-Operational- in eine Fail-Safe-Betriebsphase überzuführen.
Bild 4 zeigt einen hybriden Redundanzansatz. Dieser Ansatz besteht aus einem primären Steuerungssystem, das mit entsprechenden Überwachungseinheiten selbstüberwachend ausgeführt ist, und aus einem Limp-home-System, das durch das primäre Steuerungssystem überwacht wird. Sollte das primäre Steuerungssystem ausfallen, übernimmt für kurze Zeit das Limp-home-System die Kontrolle. Sollte das Limp-home-System ausfallen, verbleibt die Kontrolle beim primären Steuerungssystem. Ein solcher Architekturansatz ist hilfreich, wenn es dem System möglich ist, in relativ kurzer Zeit aus einer Fail-Operational-Betriebsphase in eine Fail-Safe-Betriebsphase zu wechseln. In diesem Fall könnte zum Beispiel die Spannungsversorgung des Limp-home-Systems aus einer Batterie oder Ähnlichem erfolgen. Eine Konsequenz dieser Reduktion besteht unter anderem darin, dass es beim Starten nicht möglich ist, ohne weitere Testmaßnahmen die Fehlerfreiheit und damit die Betriebstauglichkeit des Gesamtsystems festzustellen, wenn das primäre Steuerungssystem fehlerbehaftet ist. Das ist nicht unbedingt ein Nachteil, da ein Übergang in Fail-Operational-Betriebsphasen nur erfolgen sollte, wenn hinreichend Redundanz für den Fehlerfall vorhanden ist. Meistens bedingt eine sinnvolle Überwachung jedoch eine räumliche Nähe – Spatial Proximity –, was unter Umständen wiederum besondere Argumentationen hinsichtlich abhängiger Fehler bedingt.
Ausblick
Der Einzug fehlertoleranter Systeme im Fahrzeug ist unaufhaltsam. Neue Wertschöpfungen im Bereich des teilautonomen und vollautonomen Fahrens beflügeln die Entwicklung von Fail-Safe-Systemen, bei denen es zwar zulässig, aber unerwünscht ist, das System im Fehlerfall abzuschalten – und zwar unabhängig von der Betriebsphase. Auch Fail-Operational-Systeme, bei denen es Betriebsphasen gibt, wo im Fehlerfall zumindest für eine beschränkte Zeit eine Notfunktion aufrecht erhalten werden muss, werden von neuen Entwicklungen positiv beeinflusst. Neben Fehlerraten, in denen im wesentlichen systeminterne Faktoren einfließen, müssen insbesondere abhängige Fehler und externe Einflussfaktoren, die schwer probabilistisch erfasst werden können, bei der Auslegung solcher Systeme entsprechend berücksichtigt werden. Auf dem Weg von Fail-Safe- hin zu vollständigen Fail-Operational-Systemen gibt es vorerst verfügbarkeitssteigernde Maßnahmen, um nicht bei jedem kleinen Fehler das System abschalten zu müssen. Moderne Mikrocontroller, wie die der Aurix-Familie, bieten hierfür schon heute eine veritable Infrastruktur.
Literatur
[1] A. Avizienis, J.-C. Laprie, B. Randell, C. Landwehr: „Basic Concepts and Taxonomy of Dependable and Secure Computing,“ IEEE Transactions on Dependable and Secure Computing, vol. 1, pp. 11–33, 2004. [2] K. Echtle: „Fehlertoleranzverfahren“, Springer-Verlag, Berlin, Heidelberg, 1990. [3] ISO 26262, „International Standard Road vehicles – Functional safety”, Parts 1 to 10, First edition, International Standards Organization, Switzerland, 2011.
Die Autoren
| Dr. Christopher Temple |
|---|
| studierte Elektrotechnik an der TU Wien und promovierte zum Thema fehlertoleranter verteilter Echtzeitsysteme. Er ist seit fast 20 Jahren auf dem Gebiet der funktionalen Sicherheit tätig. Seit 2013 ist er am Hauptsitz von Infineon in Neubiberg bei München im Geschäftsbereich Automobilelektronik für Themen im Bereich der funktionalen Sicherheit und Cyber-Security verantwortlich. |
| Antonio Vilela |
|---|
| ist ebenfalls im Bereich Automobilelektronik von Infineon in Neubiberg tätig. Als Principal für Mikrocontroller-Safety ist er weltweit für die Sicherheitsarchitektur der Mikrocontroller zuständig und arbeitet zum Thema Halbleiter bei den internationalen Aktivitäten der ISO 26262 mit. Er studierte Physik und Mikroelektronik (Dipl.-Ing.) an der Technischen Universität von Pierre et Marie Curie (Paris, Frankreich). Er ist seit 2008 bei Infineon. |
- Fehlertolerante Systeme im Fahrzeug – von "fail-safe" zu "fail-operational"
- Fail-Safe-Systeme
- Beispiele für Fail-Operational-Architekturen
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Forum Funktionale Sicherheit 2014
Fehler sind menschlich
Fahrerassistenz
Subaru bringt Eyesight nach Deutschland
Verkehrszeichenerkennung
Smartphone-App von Bosch im Google-Play-Store verfügbar
