Genau diese Ebenen verbindet der Safety Case zu einer durchgängigen Argumentations- und Nachweiskette. Von jedem Sicherheitsziel muss der Weg über Requirements und Architektur bis zum Testergebnis nachvollziehbar sein – und zurück.

Für NX NextMotion als Drive-by-Wire-basierte Control Layer für autonome und teleoperierte Fahrzeuge ist diese Rückverfolgbarkeit ein wesentlicher Bestandteil der Systementwicklung. Denn wenn Lenken, Bremsen und Antrieb vollständig elektronisch kontrolliert werden, muss nicht nur die Sicherheitsarchitektur belastbar sein. Auch der Nachweis ihrer Wirksamkeit muss es sein.

Der Safety Case ist kein Papierstapel

Ein Safety Case entsteht nicht dadurch, dass am Projektende möglichst viele Nachweisdokumente zusammengetragen werden. Entscheidend ist die Rückverfolgbarkeit. Von jedem Sicherheitsziel muss sich der Weg über Requirements und Architektur bis zu Analysen und Testergebnissen verfolgen lassen – und von jedem Testergebnis zurück zu der Frage, welche Sicherheitsanforderung damit nachgewiesen wird. Bei Safety-by-Wire^® beginnt diese Beweiskette deshalb bereits in den frühen Entwicklungsphasen und begleitet NX NextMotion über den gesamten Lebenszyklus.

Requirements-in-the-Loop: prüfen, bevor implementiert wird

Eine der teuersten Fehlerquellen in der Systementwicklung liegt nicht zwangsläufig im Code. Bereits unvollständige, widersprüchliche oder nicht erfüllbare Anforderungen können sich durch Architektur, Implementierung und Test fortsetzen. Arnold NextG setzt deshalb bereits bei den Requirements an.

Mit Requirements-in-the-Loop werden Anforderungen und Szenarien in den frühen Systemphasen simulativ überprüft – bevor die erste Zeile Seriencode entsteht. Ziel ist es, Widersprüche, Lücken oder nicht erfüllbare Kombinationen zu erkennen, solange ihre Korrektur noch auf Requirement-Ebene erfolgen kann. Der Ansatz ist in die Anforderungserhebung und -analyse eingebunden – in der Automotive-SPICE-Systematik in SYS.1 und SYS.2. Damit beginnt der Sicherheitsnachweis nicht erst auf der Verifikationsseite des Entwicklungsmodells, sondern bereits während der Spezifikation.

FMEDA und FTA: Architektur quantitativ bewerten

Parallel zur Entwicklung der Systemarchitektur kommen quantitative Sicherheitsanalysen zum Einsatz.

Die FMEDA – Failure Modes, Effects and Diagnostics Analysis – betrachtet mögliche Ausfallarten von Hardwarekomponenten, deren Auswirkungen und die Wirksamkeit der Diagnose. Sie liefert damit eine Grundlage für die Bewertung, ob gefährliche Einzelfehler erkannt und latente Fehler ausreichend beherrscht werden.

Die Fault Tree Analysis (FTA) nimmt die entgegengesetzte Perspektive ein. Ausgehend von einem unerwünschten Top-Ereignis – beispielsweise dem Verlust der Lenkfunktion – untersucht sie, welche Einzelereignisse oder Kombinationen dazu führen können.

Für eine multi-redundante, Fully Fail-Operational Drive-by-Wire-Architektur ist gerade dieses Zusammenspiel entscheidend. Es muss nicht nur plausibel sein, dass Redundanz vorhanden ist. Der Safety Case muss nachvollziehbar belegen, dass die Architektur die zugrunde liegenden Sicherheitsziele erfüllt.

Von der Simulation ins reale Fahrzeug

Mit zunehmender Systemreife verlagert sich der Nachweis schrittweise von der virtuellen in die reale Welt. Software-in-the-Loop (SiL) prüft Funktionslogik in einer simulierten Umgebung. Hardware-in-the-Loop (HiL) integriert reale Steuerungshardware und ermöglicht gezielte Fehlerinjektionen unter reproduzierbaren Bedingungen. Vehicle-in-the-Loop (ViL) verbindet schließlich das reale Fahrzeug mit einer simulierten Umgebung.

Gerade für sicherheitskritische Drive-by-Wire-Funktionen ist diese Kette wesentlich. Fehler in Kommunikation, Energieversorgung oder Steuerung sowie definierte Mehrfachfehler und Übergänge zwischen Betriebszuständen lassen sich gezielt untersuchen, ohne entsprechende Situationen erst im Straßen- oder Maschinenbetrieb erzeugen zu müssen. Der reale Fahrzeugbetrieb bleibt dennoch unverzichtbar. Er ergänzt die Simulation um Bedingungen und Wechselwirkungen, die sich nicht vollständig vorwegnehmen lassen.

Der Nachweis endet nicht mit SOP

Mit dem Produktionsstart ist ein Safety Case nicht abgeschlossen. Software-Updates verändern Systeme über ihre Lebensdauer. Felddaten liefern neue Erkenntnisse über reale Betriebsbedingungen. Monitoring kann Abweichungen sichtbar machen, die während der Entwicklung nicht aufgetreten sind.

Für eine Plattform wie NX NextMotion muss die Nachweisstruktur deshalb fortschreibbar sein. Erkenntnisse aus dem Betrieb müssen in die Sicherheitsargumentation zurückgeführt und Änderungen kontrolliert bewertet werden können. Safety-by-Wire® versteht den Safety Case damit als lebende Nachweisstruktur über den gesamten Lebenszyklus – von den ersten Anforderungen über Entwicklung und Validierung bis zu Betrieb und Updates.

Unabhängige Begutachtung als Teil des Prozesses

Ein weiterer Faktor ist der Zeitpunkt der unabhängigen Begutachtung. Findet ein Assessment erst am Ende eines Projekts statt, können Schwächen zwar erkannt werden – ihre Behebung ist dann jedoch häufig mit erheblichem Aufwand verbunden. Bei Safety-by-Wire® begleitet die unabhängige Begutachtung deshalb die Nachweisführung über die Entwicklungsphasen hinweg. Ziel ist, Architektur- und Nachweisentscheidungen zu einem Zeitpunkt kritisch zu prüfen, an dem sie noch effizient angepasst werden können.

Für Kundenprojekte entsteht damit eine vorentwickelte Nachweisbasis. Sie ersetzt weder den Safety Case des Gesamtfahrzeugs noch die Verantwortung des Herstellers für Typgenehmigung und Anwendung – schafft aber ein Fundament, auf dem die projektspezifische Sicherheitsargumentation aufsetzen kann.

Was OEMs und Integratoren prüfen sollten

Für die Bewertung einer sicherheitskritischen Drive-by-Wire-Plattform reicht deshalb die Frage nach ASIL D oder einer fail-operational Architektur allein nicht aus. Relevant ist ebenso, wann die Nachweisführung beginnt, ob Sicherheitsziele durchgängig bis zu Testergebnissen rückverfolgbar sind und welche quantitativen Analysen der Architektur zugrunde liegen. Ebenso sollte geklärt werden, welche Fehlerfälle tatsächlich in SiL, HiL oder ViL injiziert wurden, wie unabhängig die Begutachtung erfolgt und wie der Safety Case nach dem Produktionsstart fortgeschrieben wird.

Denn die Qualität einer Sicherheitsarchitektur zeigt sich nicht nur darin, was sie technisch kann, sondern auch darin, wie belastbar sich diese Fähigkeit nachweisen lässt.

Fazit: Sicherheit ist eine nachweisbare Eigenschaft

Mit dem Safety Case schließt sich die Functional-Safety-Kette von Safety-by-Wire®. Die Normen definieren den Rahmen. Die Gefährdungsanalyse führt zu Sicherheitszielen. Das Prinzip der strengsten Anforderung konsolidiert sie für unterschiedliche Fahrzeugdomänen. Die Fully Fail-Operational Architektur setzt diese Ziele technisch um. Und der Safety Case verbindet Requirements, Architektur, Analysen und Tests zu einer nachvollziehbaren Beweiskette.

Für NX NextMotion beginnt diese Kette vor der ersten Zeile Seriencode und reicht über den Produktionsstart hinaus in den laufenden Betrieb. Denn sichere Kontrolle über Lenken, Bremsen und Antrieb muss nicht nur technisch gewährleistet sein. Sie muss auch nachweisbar bleiben.

WE CONTROL WHAT MOVES