Safety-by-Wire® — wenn der sichere Zustand Weiterfahren heißt

Fully Fail-Operational by Design: die Architektur hinter Safety-by-Wire®

Teil 1 dieser Serie hat die Normenlandkarte ausgebreitet, Teil 2 den konsolidierten Zielkatalog — bis hinauf zu ASIL D für Lenken, Bremsen und Antrieb. Jetzt wird es konkret: Wie werden aus Zielen technische Strukturen? Die Antwort beginnt mit einer Annahme, die man aufgeben muss. Solange ein Mensch am Steuer sitzt, darf sich ein System im Fehlerfall abschalten — der Fahrer übernimmt. Im hochautomatisierten und fahrerlosen Betrieb existiert diese Rückfallebene nicht mehr. Der sichere Zustand ist dann nicht mehr „aus". Er heißt: die Kontrolle behalten. Bereits im März haben wir argumentiert, warum Fail-safe nicht reicht. Dieser Beitrag zeigt, wie Safety-by-Wire® diesen Anspruch architektonisch umsetzt — als Fully Fail-Operational Design.

Auf einen Blick

Ohne Fahrer als Rückfallebene ändert sich die wichtigste Größe der Sicherheitsarchitektur: Der sichere Zustand ist nicht mehr das Abschalten, sondern der Erhalt der Fahrzeugkontrolle.
Vom Zielkatalog zur Struktur führen zwei Konzeptstufen: Das funktionale Sicherheitskonzept verteilt die Ziele auf Funktionen, das technische Sicherheitskonzept übersetzt sie in Architektur.
Die Architektur von NX NextMotion folgt durchgängiger Redundanz: zwei unabhängige ASIL-D-Kanäle über die gesamte Wirkungskette, mehrfach ausgelegte Sensorik mit 2oo3-Voting, kontinuierliche Diagnose auf allen Ebenen.
Degradation statt Abschaltung: Fehler führen in definierte, getestete Zustände reduzierter Funktion — innerhalb festgelegter Fehlertoleranzzeiten und ohne Verlust der Kontrollierbarkeit.
Fail-operational ist erst dann ein belastbarer Begriff, wenn er vollständig gedacht ist. Genau dafür steht Fully Fail-Operational: Vollständigkeit über vier Achsen — Funktion, Kanal, Steuerquelle und Energie.

Vom Ziel zur Struktur: zwei Konzeptstufen, ein Weg

Zwischen einem Sicherheitsziel und einer Leiterplatte liegen zwei Übersetzungsschritte. Das funktionale Sicherheitskonzept ordnet jedem Ziel Funktionen und Mechanismen zu: Was muss das System leisten, damit das Ziel erreicht wird — erkennen, beherrschen, degradieren? Das technische Sicherheitskonzept übersetzt diese Funktionen anschließend in Architektur: Kanäle, Sensorik, Rechenpfade, Diagnosen, Schnittstellen. Beide Schritte klingen nach Methodenlehre. Tatsächlich sind sie der Ort, an dem sich entscheidet, ob ein System Sicherheit behauptet oder besitzt — denn jede Architekturentscheidung muss sich auf ein Ziel aus dem Katalog zurückführen lassen. Diese Rückverfolgbarkeit war das stille Versprechen aus Teil 2. Hier wird sie eingelöst.

Fail-safe war gestern: Warum Abschalten keine Option ist

Die klassische Sicherheitslogik der Maschinen- und Fahrzeugtechnik kennt eine bewährte Antwort auf Fehler: den sicheren Halt. Ventil zu, Strom weg, Anlage steht. Diese Logik funktioniert, solange Stillstand ungefährlich ist — oder ein Mensch übernehmen kann. Ein fahrerloses Fahrzeug auf dem mittleren Autobahnstreifen erfüllt keine der beiden Bedingungen. Ein plötzlich stehender Autokran im Schwenkvorgang auch nicht.

Für die Bewegungssteuerung automatisierter Fahrzeuge gilt deshalb eine härtere Anforderung: Das System muss nach einem Fehler weiter funktionieren — mindestens so lange und so gut, dass das Fahrzeug kontrolliert in einen wirklich sicheren Zustand überführt werden kann, etwa ein risikominimales Manöver bis zum sicheren Halt am geeigneten Ort. Genau das meint Fail-Operational. Es ist keine Komfortstufe über Fail-Safe, sondern eine andere Architekturphilosophie: Sicherheit durch Verfügbarkeit statt Sicherheit durch Stillstand.

Redundanz mit System: zwei Kanäle, drei Sensoren, ein Prinzip

Verfügbarkeit im Fehlerfall entsteht nicht durch bessere Bauteile, sondern durch Struktur. Die Architektur von NX NextMotion folgt dafür drei Prinzipien:

Durchgängige Zweikanaligkeit. Zwei unabhängige, jeweils nach ASIL D ausgelegte Kanäle ziehen sich durch die gesamte Wirkungskette — Rechnen, Kommunizieren, Ansteuern. Entscheidend ist das Wort durchgängig: Zwei Rechner, die sich einen Stecker, ein Bussystem oder ein Netzteil teilen, sind keine zwei Kanäle, sondern ein gemeinsamer Fehler mit zwei Gehäusen. Bewertet wird deshalb nicht das Steuergerät, sondern die Kette: Sensorik, Rechnen, Kommunikation, Leistungsansteuerung und Aktuatorik erfüllen gemeinsam je Kanal die Zielrate der höchsten Sicherheitsstufe von unter 10 FIT.
Mehrfach ausgelegte Sensorik mit Voting. Sicherheitsrelevante Größen werden mehrfach erfasst und im 2oo3-Prinzip bewertet: Weichen die Signale voneinander ab, entscheidet die Mehrheit — und der abweichende Pfad wird als verdächtig markiert, ohne dass die Funktion unterbrochen wird.
Diagnose auf allen Ebenen — bis zur einzelnen Recheneinheit. Die Überwachung endet nicht an der Kanalgrenze: Vier Mikrocontroller mit je vier Lockstep-Kernen — 16 Lockstep-Kerne insgesamt, acht je Seite — überwachen sich selbst und gegenseitig, durch Plausibilisierung, Health-Monitoring und den Vergleich der Rechenpfade untereinander. Ein Fehler, der erkannt wird, ist beherrschbar. Ein Fehler, der schlummert, ist die eigentliche Gefahr — die Architektur ist deshalb darauf ausgelegt, latente Fehler aufzudecken, bevor ein zweiter dazukommt. (Grafik , siehe oben)

Degradation: kontrolliert weiter, nicht abrupt aus

Redundanz beantwortet die Frage, ob ein System nach einem Fehler weiterarbeiten kann. Das Degradationskonzept beantwortet, wie. Statt eines binären Übergangs von „alles" zu „nichts" definiert die Architektur abgestufte Zustände reduzierter Funktion: volle Performance, eingeschränkter Betrieb, risikominimales Manöver. Jeder Übergang ist spezifiziert, jeder Zustand ist getestet — und jeder Wechsel muss innerhalb definierter Fehlertoleranzzeiten abgeschlossen sein, bevor eine Gefährdung entstehen kann.

Das klingt selbstverständlich und ist es nicht. Der Unterschied zwischen einem spezifizierten und einem beherrschten Degradationspfad zeigt sich erst unter Last: beim doppelten Fehler, beim Übergang während eines Manövers, bei gestörter Kommunikation zur Fahrentscheidungsebene. Genau diese Fälle gehören in die Auslegung — nicht in die Ausrede.

Fully Fail-Operational: die vier Achsen der Vollständigkeit

„Fail-operational" ist ein dankbares Wort für Datenblätter — und ein anspruchsvolles für Architekten. Belastbar wird es erst, wenn die Frage „operational wogegen?" vollständig beantwortet ist. Deshalb sprechen wir bei Safety-by-Wire® von Fully Fail-Operational. Die folgende Gegenüberstellung zeigt, was auf jeder der vier Achsen den Unterschied macht — links das, was in der Praxis häufig schon als fail-operational gilt, rechts der Anspruch, den wir an die Plattform stellen:

Achse	Häufige Verkürzung in der Praxis	Fully Fail-Operational
Funktion	Eine Funktion — meist die Lenkung — ist redundant ausgelegt; für den Rest gilt weiterhin die Abschaltlogik.	Jede primäre Sicherheitsfunktion ist einzeln fail-operational ausgelegt: Lenken, Bremsen, Antrieb.
Kanal	Zwei Kanäle, aber mit abgestufter Auslegung oder gemeinsam genutzten Elementen.	Zwei vollständig getrennte ASIL-D-Kanäle über die gesamte Kette — von der Sensorik bis zur Aktuatorik, je Kanal unter 10 FIT. Der Verlust einer kompletten Seite kostet keine Funktion.
Steuerquelle	Eine Steuerquelle; der Mensch bleibt die stille Rückfallebene.	Autonomie, Teleoperation und manueller Eingriff koexistieren; eine deterministische Arbitrierung wählt jederzeit den vertrauenswürdigsten Pfad.
Energie	Zwei Versorgungspfade — ohne eigenständige Pufferquelle.	Redundante Versorgung mit dedizierter Pufferquelle, ausgelegt auf die spezifizierten Degradationsfenster.

Erst wenn alle vier Achsen abgedeckt sind, verdient eine Plattform das Attribut Fully Fail-Operational. Und erst dann trägt die Architektur den Zielkatalog aus Teil 2 — in jeder Domäne, für die er formuliert wurde. Ein Hinweis zur Begriffsführung gehört dazu: „Fully Fail-Operational" ist keine in den Normen definierte Kategorie, sondern eine bewusst engere Fassung, die wir als prüfbare Eigenschaft vorschlagen — messbar entlang genau dieser vier Achsen.

In der Mitte befindet sich groß Fully Fail-operational, davon gehen 4 Felder nach außen die Jeweils eine Überschrift und ein Text enthalten. Die vier Überschriften lauten: 1. Funktion, 2. Kanal, 3. Steuerquelle und 4. Energie. — Vier Achsen der Vollständigkeit

Was OEMs, Integratoren und Betreiber jetzt klären sollten

Was ist der definierte sichere Zustand der eigenen Anwendung — sofortiger Stillstand am Ort oder kontrolliertes Weiterfahren bis zum sicheren Halt? Und wer hat das festgelegt?
Ist die Redundanz durchgängig — oder enden zwei Kanäle an einem gemeinsamen Stecker, Netzteil oder Bussystem?
Wie erkennt das System, welcher Pfad die Wahrheit sagt — gibt es Voting und Diagnose auf allen Ebenen, auch für latente Fehler?
Welche Degradationsstufen sind definiert — und sind die Übergänge unter realen Bedingungen getestet, nicht nur spezifiziert?
Trägt die Energie- und Kommunikationsversorgung dieselbe Sicherheitslogik wie die Funktion selbst?

Diese Fragen entscheiden über Architektur — und Architektur lässt sich nicht patchen. Wer sie erst im Integrationsprojekt stellt, kann nur noch dokumentieren, was ist. Arnold NextG hat sie deshalb vor der ersten Leiterplatte beantwortet: Die Fully-Fail-Operational-Struktur ist der Kern der Plattform-Vorentwicklung, nicht ihr Zubehör.

Fazit

Der Wegfall des Fahrers als Rückfallebene ist kein Detail der Automatisierung — er ist ihr architektonischer Kern. Wer ihn ernst nimmt, landet zwangsläufig bei durchgängiger Redundanz, beherrschter Degradation und einer Vollständigkeit, die alle vier Achsen umfasst. Fully Fail-Operational ist dann kein Versprechen mehr, sondern eine Struktureigenschaft.

Im vierten und letzten Teil dieser Serie zeigen wir, wie diese Architektur bewiesen wird: von FMEDA und Fehlerbaumanalyse über das unabhängige Assessment bis zur Validierung im Realbetrieb — und warum der Nachweis mit dem Produktionsstart nicht endet.