Fail-safe reicht nicht – warum Autonomie fail-operational gedacht werden muss

Wenn Sicherheit nicht mehr Stillstand bedeutet

Mit zunehmender Automatisierung verändert sich die Bedeutung von Sicherheit im Fahrzeug grundlegend. In klassischen Architekturen war Sicherheit eng mit dem Begriff des Stillstands verknüpft. Ein System, das im Fehlerfall abschaltet oder in einen passiven Zustand übergeht, galt als sicher – vorausgesetzt, ein Mensch konnte die Kontrolle übernehmen oder die Situation war beherrschbar.

Autonome Fahrzeuge stellen diese Logik infrage.

Ein fahrerloses System besitzt keine externe Rückfallebene. Es operiert eigenständig, häufig in dynamischen Umgebungen und mit klar definierten Aufgaben. In diesem Kontext ist Stillstand nicht automatisch ein sicherer Zustand. Er kann den Betrieb unterbrechen, neue Risiken erzeugen oder die Kontrolle über die Situation sogar verschlechtern.

Damit verschiebt sich der Fokus von der Frage, wie ein System sicher abschaltet, hin zu der Frage, wie es unter Einschränkungen handlungsfähig bleibt.

Fail-operational als betriebliche Anforderung

Fail-operational ist kein technisches Upgrade. Es ist die Voraussetzung dafür, dass autonome Fahrzeuge wirtschaftlich betreibbar sind. Ein System, das im Fehlerfall stehen bleibt, ist im autonomen Betrieb kein sicheres System – sondern ein betriebswirtschaftliches Risiko. Ein autonomes Fahrzeug muss in der Lage sein, Aufgaben kontrolliert zu Ende zu führen, definierte Zustände zu erreichen oder sich aus komplexen Situationen sicher herauszubewegen – auch dann, wenn Teile des Systems nicht mehr im Nominalzustand arbeiten.

Das setzt voraus, dass das System Fehler nicht nur erkennt, sondern aktiv mit ihnen umgeht. Es muss bewerten können, welche Funktionen in welcher Qualität noch verfügbar sind, welche Prioritäten gelten und welche Handlungsoptionen bestehen. Diese Entscheidungen dürfen nicht implizit oder zufällig entstehen, sondern müssen Teil der Systemarchitektur sein.

Fail-operationales Verhalten ist damit kein Ausnahmezustand, sondern ein vorgesehener Betriebsmodus.

Warum Fail-operational nicht nachrüstbar ist

Ein weitverbreitetes Missverständnis besteht darin, fail-operational als Erweiterung bestehender Sicherheitskonzepte zu betrachten. In der Praxis lässt sich ein solches Verhalten jedoch nicht nachträglich hinzufügen.

Fail-operational erfordert eine Architektur, in der Redundanz, Überwachung, Entscheidungslogik und Aktorik von Beginn an aufeinander abgestimmt sind. Es geht nicht nur darum, dass mehrere Komponenten vorhanden sind, sondern dass das System weiß, wie es mit ihnen umzugehen hat, wenn sie nicht mehr vollständig verfügbar sind.

Ein System, das im Fehlerfall lediglich erkennt, dass etwas nicht mehr funktioniert, ist nicht fail-operational. Erst wenn es unter diesen Bedingungen gezielt weiterarbeiten kann, erfüllt es diese Anforderung.

Der Unterschied zeigt sich im Betrieb, nicht im Lastenheft

In frühen Entwicklungsphasen lassen sich fail-safe und fail-operational oft schwer unterscheiden. Beide Konzepte können auf dem Papier plausibel erscheinen, beide können normkonform dokumentiert werden. Der Unterschied wird erst sichtbar, wenn das Fahrzeug real betrieben wird.

Im Betrieb zeigt sich, ob ein System Übergänge beherrscht, ob es degradierte Zustände stabil halten kann und ob es auch ohne optimale Bedingungen vorhersehbar reagiert. Gerade in autonomen Anwendungen ist diese Fähigkeit entscheidend, da unkontrollierte Zustandswechsel oder abrupte Betriebsabbrüche selbst zu Sicherheitsrisiken werden können.

Fail-operational ist deshalb weniger eine Frage der Zertifizierung als eine Frage der Systemreife.

Warum fail-operational oft unterschätzt wird

In vielen Autonomieprogrammen liegt der Schwerpunkt auf Wahrnehmung und Entscheidungsfindung. Fahrzeugkontrolle wird als notwendige Infrastruktur betrachtet, nicht als limitierender Faktor. Erst im Zusammenspiel mit realen Einsatzszenarien wird deutlich, dass ohne fail-operationale Steuerung viele Funktionen theoretisch möglich, praktisch aber nicht nutzbar sind.

Fail-operationales Design bestimmt, ob ein autonomes Fahrzeug lediglich funktionieren kann – oder ob es tatsächlich betrieben werden kann.

Diese Unterscheidung wird häufig erst dann relevant, wenn Systeme den Labor- oder Testbetrieb verlassen und in reale Prozesse integriert werden. An diesem Punkt lassen sich architektonische Entscheidungen nicht mehr korrigieren. Genau deshalb ist fail-operational keine Implementierungsfrage, sondern eine Grundsatzentscheidung in der Architekturphase.

Die Konsequenz für autonome Fahrzeugarchitekturen

Für autonome Systeme bedeutet dies einen grundlegenden Perspektivwechsel. Sicherheit entsteht nicht mehr durch Abschaltung, sondern durch kontrollierte Fortsetzung. Die Fähigkeit, auch unter eingeschränkten Bedingungen zu handeln, wird zur zentralen Voraussetzung für Betrieb, Skalierung und Akzeptanz.

Fail-operational ist damit kein optionales Merkmal und kein Spezialfall. Es ist die logische Konsequenz daraus, dass autonome Fahrzeuge Verantwortung für ihr eigenes Verhalten übernehmen müssen.

Ein neuer Maßstab für Fahrzeugkontrolle

Die Frage, die sich Entwickler und Betreiber autonomer Systeme stellen sollten, lautet daher nicht mehr, ob ein System im Fehlerfall sicher ist. Entscheidend ist, ob es auch im Fehlerfall noch sicher handeln kann.

Diese Fähigkeit definiert den Übergang von assistierten zu autonomen Systemen – und sie setzt eine Fahrzeugkontrollarchitektur voraus, die von Beginn an auf diesen Anspruch ausgelegt ist.