Ausfallsichere Sicherheitsarchitektur für autonome Fahrzeuge

Auf Level 4 muss sich das Vertrauen eines Menschen in eine Maschine im Design eines vollautomatisierten Fahrsystems als hoch-zuverlässiges System widerspiegeln. Kritische Fehler dürfen nur selten, in etwa ein Fehler alle zehntausend Jahre, auftreten. Eine derart geringe Fehlerrate stellt sicher, dass der Fahrer bei einem vollautomatisieren Fahrsystem mit sehr hoher Wahrscheinlichkeit niemals einen kritischen Systemfehler erlebt. Dies zu erreichen, ist eine Herausforderung, denn die Bausteine dieser Systeme – Komponenten wie Hardware, Chips und Software – versagen deutlich häufiger. Es gibt jedoch eine umfangreiche wissenschaftliche Literatur und technische Praxis dazu, wie sich aus weniger zuverlässigen Systemen hochzuverlässige Systeme entwickeln lassen. So müssen in der Luft- und Raumfahrt Flugsteuer- und Überwachungssysteme zwangsläufig noch sicherer sein (Bild 1).

Bottom-up ist zu riskant

Höchstzuverlässige Systeme lassen sich nur durch eine entsprechende Zerlegung des Gesamtsystems in Teilsysteme und Fehlereingrenzungseinheiten (fault-containment units) mit ausreichender Redundanz aufbauen. E/E-Architekturen im Automobilbereich folgen heute nicht immer einem solchen systematischen Top-down-Designansatz für ultra-hochzuverlässige Systeme. So werden Subsysteme und Fehlereingrenzungseinheiten auch nach dem Bottom-up-Prinzip erst spät in ein Systemdesign eingearbeitet. Das riskante an diesem Ansatz ist, dass Systementwickler dadurch Sicherheitsziele verfehlen könnten und so gezwungen wären „architektonische Bandagen“ anzulegen, um Erste Hilfe in Sachen Zuverlässigkeit zu leisten. Solche Lösungen haben das Potenzial, zu nicht gewollten, gefährlichen Verhaltensweisen zu führen.

Sicherheit ist eine Eigenschaft des Gesamtsystems und ist binär: Entweder ein autonom fahrendes Auto ist sicher, oder es ist es nicht. Bei der Entwicklung des Systems wird diese Sicherheitseigenschaft in Anforderungen auf höchster Ebene umgesetzt, die die Systemimplementierung leiten. Dies ist typischerweise ein schrittweiser Prozess, aus dem mehrere Ebenen von Anforderungen und Entwürfe abgeleitet werden. Dabei lässt sich immer nur Schritt für Schritt überprüfen und verifizieren, dass ein Entwurf und eine Implementierung die Anforderungen auf der jeweiligen Ebene erfüllt.

Dieser anforderungsorientierte Systementwicklungsprozess hat bereits nachweislich zu sicheren Systemen in der Luft- und Raumfahrt geführt, ist aber auch ein gängiger Ansatz im Automobilbereich. Würde Sicherheit erst spät in der Systementwicklung berücksichtigt, würde sie rückwirkend eingeführt. So würde eine Sicherheits-Bandage über die andere gelegt, mit dem Risiko, dass größere Sicherheitslücken bestehen bleiben und keine ausreichende Systemsicherheit erreicht wird.

Sicherheitsstandards und Risikobewusstsein unterscheiden sich stark, je nachdem, wo auf der Welt man sich grade befindet. In der hiesigen Gesellschaft ist das Verlangen nach Sicherheit hoch. Die jährlichen Unfallstatistiken geben Aufschluss über die gesellschaftlich akzeptierte Sterblichkeitsrate. Es wird darüber diskutiert, ob ein autonom fahrendes Auto bereits hinreichend sicher ist, wenn es weniger Unfälle mit Todesfolge verursacht als eines, das von einem Menschen gesteuert wird. Oder ob es erst sicher genug ist, wenn es um mehrere Größenordnungen besser abschneidet. Tatsächlich sollten die Systeme, auf denen das autonome Fahren basiert, mindestens hundertmal besser als der menschliche Fahrer sein.

Es ist ein wesentliches Sicherheitskriterium, dass ein autonom fahrendes Auto auch dann sicher funktionieren muss, wenn ein Teil von ihm ausfällt. Diese Systemeigenschaft wird als „fail-operational“ (ausfallsicher) bezeichnet. Die Konstruktion eines solchen ausfallsicheren Systems ist äußerst anspruchsvoll, da es viele verschiedene Bestandteile hat, die auf ganz unterschiedliche Weise fehlerhaft sein können. Daher ist die Zahl der Vorgänge, die schiefgehen können, enorm hoch.

Die einzige Möglichkeit, mit dieser enormen Anzahl möglicher Fehlerquellen umzugehen, ist es, eine Sicherheitsarchitektur aufzubauen. In dieser Sicherheitsarchitektur werden sogenannte Fault Containment Units (FCUs, Fehlereingrenzungseinheiten) definiert die Teile des Systems bezeichnen, die als Ganzes ausfallen können. Ausserdem wird auch die Interaktionen zwischen diesen FCUs spezifiziert. Bereits auf dieser Abstraktionsebene kann die richtige Sicherheitsarchitektur sicherstellen, dass der Ausfall einer FCU nicht zu einem vollständigen Systemausfall führt, sondern dass das System weiterhin funktionsfähig bleibt (Bild 2).

Ausfallsichere (fail-operational) Systeme sind in der Luft- und Raumfahrt gebräuchlich, was es ermöglicht von diesen für den Aufbau von Sicherheitsarchitekturen zu lernen. Die funktionale Komplexität eines autonom fahrenden Kraftfahrzeugs ist jedoch beispiellos. Zwar gibt es in der Luft- und Raumfahrt echte Autopiloten-Systeme, doch müssen selbstfahrende Autos viel komplexere Aufgaben bewältigen, einfach durch die sich viel dynamischer bewegenden Objekte auf Straßen.

Zudem müssen geschulte Piloten in der Luft- und Raumfahrt Autopilotsysteme während kritischer Flugphasen wie der Landung überwachen. Dadurch überschreiten diese Systeme in der Regel nicht das vergleichbare Level 2 des automatisierten Fahrens. Während des Reiseflugs lassen sich Autopilotsysteme hingegen mit Level-3-Systemen vergleichen: Der Pilot überwacht den Autopiloten nicht, sondern muss lediglich im Cockpit anwesend sein und innerhalb weniger Sekunden bereit sein, die Kontrolle zu übernehmen. Positiv ist, dass ein auf dem Boden fahrendes autonomes Auto, schnell in einen sicheren Bereich, wie einen Standstreifen einfahren kann, sobald ein Fehler erkannt ist.

Wie eine Sicherheitsarchitektur für autonom fahrende Autos aussehen könnte

Bild 3 zeigt eine Sicherheitsarchitektur (Kopetz-Architektur) für autonom fahrende Autos. Die Architektur unterscheidet vier Subsysteme:

• Computergesteuertes Subsystem fürs Fahren (Computer Controlled Driving Subsystem - CCDSS)
• Überwachungs-Subsystem (Monitoring Subsystem - MSS)
• Subsystem für die Behandlung kritischer Vorfälle (Critical Event Handling Subsystem - CEHSS)
• Fehlertolerantes Entscheidungs-Subsystem (Fault-Tolerant Decision Subsystem - FTDSS)

Sowohl das CCDSS als auch das CEHSS produzieren in regelmäßiger Folge Outputs, die dazu verwendet werden, das Verhalten des selbstfahrenden Autos zu bestimmen. Das MSS überwacht die Leistung von CCDSS und CEHSS. Das FTDSS empfängt den Output des CCDSS und des CEHSS sowie den Output des MSS-Monitors. Wenn kein Fehler vorliegt, sendet das CCDSS seinen Output zum FTDSS, und das FTDSS lässt diesen Output vom MSS überprüfen. In einem störungsfreien Szenario genehmigt das MSS den CCDSS-Output und informiert das FTDSS. Das FTDSS leitet dann diesen vom MSS zugelassenen Output an die Empfänger (z.B. die Aktoren) weiter. Ein einfaches Protokoll in den Empfängern wählt pro Zyklus einen einzigen Output.

Das CCDSS, das MSS und das CEHSS bilden jeweils eine einzige Fehlereingrenzungseinheit. Das bedeutet, wenn ein Teil eines Teilsystems ausfällt, liegt beim gesamten Teilsystem ein Fehler vor. Beispiel: Wenn das CCDSS als eigenständige elektronische Steuereinheit (Electronic Control Unit - ECU) ausgeführt wurde und für diese ECU ein spezieller Chip für die Objekterkennung implementiert ist, gilt die gesamte ECU als fehlerhaft, wenn es bei diesem Chip einen Fehler gibt.

Eine Sicherheitsarchitektur muss auch definieren, was bei Ausfall von FCUs passiert. In dem hier geschilderten Fall können CCDSS, MSS und CEHSS mit beliebigem Fehlerverhalten ausfallen: So ein fehlerhaftes Subsystem kann beispielsweise über dessen Schnittstellen eine beliebige Folge von Nachrichten an das FTDSS senden. Das FTDSS selbst besteht aus zwei FCUs mit eingeschränktem Fehlerverhalten, das durch gängige ausfallsichere Technologien realisierbar ist.

Fehlerszenarien

Auch in dieser eher einfachen Architektur gibt es viele verschiedene Fehlerszenarien. In einigen Szenarien scheitert das CCDSS beispielsweise daran, einen sicheren Output zu liefern, und das MSS erkennt diesen Fehler. In diesen Szenarien leitet der FTDSS den Output des CEHSS weiter und nicht den Output des CCDSS. Die hohe Anzahl an möglichen Fehlerszenarien macht die lückenlose manuelle Inspektion umständlich und fehleranfällig: Einzelne Szenarien können leicht übersehen oder falsch interpretiert werden. Daher wurden alle möglichen Fehlerszenarien durch den Einsatz von modellbasierter Fehlersimulation computergestützt überprüft. Dieses Verfahren wurde vor fast 20 Jahren im Rahmen der Verifizierung von Netzwerkprotokollen erfunden.

Durch diese ausführlichen Fehlersimulationen wurde gezeigt, dass ein System, in dem die Kopetz-Architektur implementiert ist, folgende Eigenschaften garantiert aufweist, wenn nur eine einzige FCU ausfällt:

• Konsistenz: Alle nicht fehlerhaften Empfänger verwenden dieselben Werte und diese Werte sind sicher.
• Terminierung: Alle nicht fehlerhaften Empfänger verwenden einen Wert am Ende jedes Zyklus.
• Nicht-Trivialität: Alle nicht fehlerhaften Empfänger verwenden nur die von den FCUs der FTDSS bereitgestellten Werte.

Es ist erwähnenswert, dass die vorgeschlagene Architektur die Implementierung eines einfachen Protokolls bei den Empfängern ermöglicht, um pro Zyklus einen von potenziell vielen Outputs der verschiedenen FCUs der FTDSS auszuwählen. Sie ist in dem Sinne einfach, dass die Empfänger keine Informationen untereinander austauschen müssen, um die oben definierten Eigenschaften zu erreichen. In der Regel sind zwei Kommunikationsrunden erforderlich, aber die Struktur der Architektur simuliert diese beiden Runden durch eine erste Kommunikation zwischen dem CCDSS, MSS und CEHSS zu den FCUs des FTDSS und durch eine zweite Kommunikation von den FCUs der FTDSS zu den Empfängern.

Standardisierte Sicherheitsarchitekturen

Sicherheitsstandards können zwei unterschiedliche Rollen übernehmen. Einerseits geben sie Orientierung beim Aufbau eines sicheren Systems. Andererseits ermöglichen sie den Vergleich verschiedener Lösungen miteinander. Eine standardisierte Sicherheitsarchitektur kann ein Mindest-Qualitätsniveau definieren, um insbesondere Sicherheitsabkürzungen zu vermeiden. Das ist natürlich nur dann der Fall, wenn die Norm auch tatsächlich von der Automobilindustrie akzeptiert und übernommen wird.

Als Antwort auf die Anforderungen an Sicherheitssysteme wurde die Kopetz-Architektur im Rahmen von The Autonomous vorgeschlagen. The Autonomous bietet eine offenen Plattform für alle Beteiligten, die darauf abzielt, das Ökosystem der autonomen Mobilität zusammenzubringen, um das zukünftige autonome Fahren sicher zu gestalten. (na)