Safety-by-Wire® — Sicherheit, die man prüfen kann

Der Safety Case hinter Safety-by-Wire®: vom ersten Requirement bis in den laufenden Betrieb

Irgendwann in jedem Sicherheitsprojekt kommt der Moment, in dem jemand von außen ein beliebiges Sicherheitsziel aufschlägt und drei Worte sagt: „Zeigen Sie mir." Drei Teile dieser Serie haben beschrieben, was es dann zu zeigen gibt — die Normenstrategie, den Zielkatalog mit der strengsten Anforderung, die Fully-Fail-Operational-Architektur. Dieser vierte und letzte Teil handelt von dem Moment selbst. Und von einer Besonderheit, die ihn bei Safety-by-Wire® entschärft: Die Antwort wurde vorbereitet, bevor es das System überhaupt gab — und sie wird weitergeschrieben, wenn andere ihre Akten längst geschlossen haben.

Auf einen Blick

• Der Safety Case ist ein Argumentationsgebäude, kein Papierstapel: eine nachvollziehbare Kette vom Sicherheitsziel bis zum Testergebnis — und zurück.
• Der Nachweis von Safety-by-Wire® hat zwei ungewöhnliche Enden: Er beginnt vor der ersten Zeile Seriencode — und er endet nicht mit dem Produktionsstart.
• Requirements-in-the-Loop stellt bereits die Anforderungen selbst auf den Prüfstand der Simulation — in der Automobilindustrie unüblich, inspiriert von anderen hochsicherheitskritischen Industrien.
• Dazwischen liegt die volle Beweiskette: FMEDA und Fehlerbaumanalyse in der Auslegung, Software-, Hardware- und Vehicle-in-the-Loop auf dem Weg in den Realbetrieb.
• Und über allen Phasen läuft eine fünfte Spur mit: die unabhängige Begutachtung — begleitend, nicht abnickend.

„Zeigen Sie mir": der Safety Case als Gebäude

Der Safety Case ist die strukturierte Antwort auf diese drei Worte. Er verbindet jedes Sicherheitsziel mit den Anforderungen, die daraus abgeleitet wurden, mit den Architekturentscheidungen, die sie umsetzen, und mit den Analysen und Tests, die ihre Wirksamkeit belegen. Entscheidend ist dabei nicht der Umfang der Dokumentation, sondern ihre Durchgängigkeit: Wer ein beliebiges Ziel aufschlägt, muss den Weg bis zum Testergebnis verfolgen können — und von jedem Testergebnis zurück zu der Frage, warum es dieses Ziel überhaupt gibt.

In Teil 2 stand ein Satz, der damals wie eine Randnotiz wirken konnte: Rückverfolgbarkeit ist unspektakulär, bis jemand danach fragt — dann ist sie alles. Dieser vierte Teil ist der Teil, in dem gefragt wird. Und was das Gebäude von Safety-by-Wire® dabei von den meisten unterscheidet, ist seine Bauzeit: Der Beweis hat zwei Enden, die man in der Automobilindustrie selten sieht.

Beweisen, bevor es etwas gibt: Requirements-in-the-Loop

Die teuerste Fehlerklasse der Systementwicklung sind nicht Programmierfehler — es sind Anforderungsfehler. Eine widersprüchliche, lückenhafte oder schlicht unerfüllbare Anforderung vererbt sich in jede spätere Stufe: in die Architektur, in den Code, in Tests, die dann gewissenhaft das Falsche prüfen. Im Text entdeckt, ist ein Anforderungsfehler eine Änderung. Im Feld entdeckt, ist er ein Rückruf.

Deshalb beginnt die Beweiskette von Safety-by-Wire® vor der ersten Zeile Seriencode: Bereits die Anforderungen selbst durchlaufen die Simulation. Requirements-in-the-Loop ist dabei kein vorgelagerter Sonderprozess, sondern in den frühen Systemphasen selbst verankert — der Anforderungserhebung und -analyse, in der Sprache von Automotive SPICE: SYS.1 und SYS.2. Es spielt Szenarien durch, bevor es ein System gibt, das sie erleben könnte — und deckt so Widersprüche, Lücken und unerfüllbare Kombinationen auf, solange ihre Korrektur eine Textänderung ist und kein Redesign. In der Automobilindustrie ist dieses Vorgehen unüblich. Inspiriert ist es von anderen hochsicherheitskritischen Industrien — von Disziplinen, in denen es keinen zweiten Versuch gibt und der Beweis deshalb nie erst am fertigen System beginnt.

Rechnen, bevor gebaut wird: FMEDA und Fehlerbaum

Auch die Analytik wartet nicht auf den rechten Ast des V-Modells: FMEDA und Fehlerbaumanalyse laufen designbegleitend in Anforderungsanalyse und Systemarchitektur — SYS.2 und SYS.3 — und sie verlangen mehr als plausible Argumente, nämlich Zahlen. Zwei Analyseinstrumente tragen dabei die Hauptlast:

• Die FMEDA (Failure Modes, Effects and Diagnostics Analysis) betrachtet die Hardware von unten: Welche Ausfallarten hat jedes Bauteil, welche davon sind gefährlich — und welcher Anteil wird von der Diagnose erkannt? Aus dieser Bottom-up-Betrachtung entstehen die Hardware-Metriken der Leitnorm: der Nachweis, dass Einzelfehler beherrscht und latente Fehler aufgedeckt werden.
• Die Fehlerbaumanalyse (FTA) blickt von oben: Sie zerlegt jedes unerwünschte Top-Ereignis — etwa den Verlust der Lenkfunktion — in die Kombinationen von Einzelereignissen, die dorthin führen könnten, und quantifiziert deren Wahrscheinlichkeit. Erst dieser Blick zeigt, ob die Redundanzarchitektur hält, was sie verspricht: dass kein einzelner Fehler und keine plausible Fehlerkombination das Sicherheitsziel verletzt.

Zusammen beantworten beide Analysen die Frage, die hinter der höchsten Einstufung eigentlich steht: nicht „funktioniert es?", sondern „wie unwahrscheinlich ist es, dass es gefährlich versagt?" — belegt gegen die quantitativen Grenzwerte der Norm, nicht gegen das eigene Bauchgefühl.

Prüfen auf dem Weg in die Realität: die In-the-Loop-Kette

Was als Anforderungssimulation beginnt, setzt sich als gestufte Systemprüfung fort. Software-in-the-Loop prüft die Funktionslogik gegen simulierte Hardware — Elektronik, Motoren, Sensorik und letztlich die gesamte Fahrzeugphysik. Hardware-in-the-Loop bringt anschließend die reale Steuerung in dieselbe simulierte Welt, mit gezielt injizierten Fehlern: reproduzierbar, automatisierbar, auch für Fälle, die auf der Straße niemand provozieren möchte. Genau hier werden die unbequemen Szenarien aus Teil 3 systematisch erzeugt: der doppelte Fehler, der Übergang mitten im Manöver, die gestörte Kommunikation. Vehicle-in-the-Loop verbindet reales Fahrzeug und simulierte Umgebung. Der Realbetrieb schließlich liefert, was keine Simulation ersetzt: die Bewährung unter Bedingungen, die sich niemand ausgedacht hat.

Der Nachweis, der nicht endet

Das andere ungewöhnliche Ende der Figur liegt rechts. Wer die beiden Juli-Beiträge dieser Serie gelesen hat, ahnt es bereits: UN R185 und UN GTR 26 verstehen Sicherheit als Eigenschaft über den gesamten Lebenszyklus. Der Safety Case ist damit kein Abschlussdokument mehr, sondern ein lebendes: In-Service-Monitoring beobachtet das Verhalten im Feld, Software-Updates folgen beherrschten Prozessen statt guter Absicht, und Felderfahrung fließt zurück in die Entwicklung. Für eine Plattform heißt das konkret: Die Nachweisstrukturen müssen auf Fortschreibung ausgelegt sein, nicht auf Abschluss — jede Beobachtung aus dem Betrieb muss ihren Platz im Argumentationsgebäude finden können, ohne dass es neu gebaut wird.

Die fünfte Spur: der unabhängige Blick

Selbstprüfung hat Grenzen; die Normenwelt fordert deshalb Bestätigungsmaßnahmen mit Unabhängigkeit. Die entscheidende Frage ist allerdings nicht, ob unabhängig geprüft wird — sondern wann und wie lange. Ein Assessment am Projektende kann nur noch bewerten, was ist. Eine Begutachtung, die mitläuft, findet Schwächen, solange sie korrigierbar sind.

Bei Safety-by-Wire® läuft diese Spur über alle vier Phasen: Die unabhängigen Gutachter, von denen in Teil 3 die Rede war, prüfen nicht nur Architekturentscheidungen — sie begleiten die Nachweisführung über die gesamte Strecke — von der ersten Anforderung bis in den Betrieb, gemäß ausgewiesener Entwicklungs- und Nachweislage. Für Kundenprojekte heißt das: Die Plattform kommt nicht mit einem Versprechen ins Projekt, sondern mit einer Nachweisbasis, die den kritischen Blick von außen bereits erlebt hat.

„Wir haben mit dem Beweisen angefangen, bevor es etwas zu zeigen gab — und wir hören nicht auf, wo andere fertig sind." Kevin Arnold, CEO der Arnold NextG GmbH

Was OEMs, Integratoren und Betreiber jetzt klären sollten

• Wann beginnt der Nachweis beim Lieferanten — beim fertigen System oder bereits bei den Anforderungen?
• Ist der Safety Case durchgängig nachvollziehbar — vom Sicherheitsziel bis zum Testergebnis und zurück — oder eine Sammlung von Einzeldokumenten?
• Welche quantitativen Nachweise liegen vor (FMEDA, FTA) — und passen deren Annahmen zur realen Einsatzumgebung und Missionsdauer?
• Welche Fehlerfälle wurden in der In-the-Loop-Kette tatsächlich injiziert — und welche nur analysiert?
• Wer hat unabhängig geprüft, und zu welchem Zeitpunkt — begleitend zur Entwicklung oder erst am Ende?
• Wie wird Sicherheit nach dem Produktionsstart weiter belegt — Monitoring, Update-Prozesse, Felderfahrung?

Wer diese Fragen erst in der Genehmigungsphase beantwortet, verhandelt mit der Behörde über Vergangenheit — und Vergangenheit lässt sich nicht nachbessern. Arnold NextG hat den Nachweis deshalb zur Eigenschaft der Plattform gemacht, nicht zum Anhang des Projekts: Er beginnt vor der ersten Zeile Code und endet nicht mit dem Produktionsstart. Zielbasis, Architektur, Analysen und begleitete Begutachtung bilden einen vorentwickelten Sockel, auf dem die fahrzeug- und anwendungsspezifische Argumentation aufsetzt. Das ersetzt weder den Gesamtfahrzeug-Safety-Case noch die Typgenehmigung des Herstellers — aber es verkürzt den Weg dorthin, weil jedes Projekt auf geprüften Antworten beginnt statt auf offenen Fragen.

Fazit der Serie

Vier Teile, ein Bogen: Die Regulatorik verlangt den durchgängigen Nachweis (Juli-Beiträge). Die Normen liefern die Sprache dafür (Teil 1). Die Konsolidierung macht daraus einen Zielkatalog mit der strengsten Anforderung als Maßstab (Teil 2). Die Architektur setzt ihn Fully Fail-Operational um (Teil 3). Und der Safety Case macht das Ganze prüfbar — bis in den laufenden Betrieb (Teil 4).

Das ist die Functional-Safety-Strategie hinter Safety-by-Wire®: keine Sammlung von Einzelmaßnahmen, sondern eine Kette ohne schwaches Glied — von der Norm bis zur Bewegung. Sicherheit ist am Ende kein Zustand, den man erreicht. Sie ist eine Eigenschaft, die man belegt. Jeden Tag, in jeder Domäne, über den gesamten Lebenszyklus.