Safety-by-Wire® — das Prinzip der strengsten Anforderung

Von fünf Normenwelten zu einem Zielkatalog: wie Safety-by-Wire® Sicherheitsziele konsolidiert

Im ersten Teil dieser Serie haben wir die Normenlandkarte hinter Safety-by-Wire® ausgebreitet: fünf Normenwelten für die funktionale Sicherheit, ergänzt um SOTIF, Cybersecurity und Homologation. Doch eine Landkarte beantwortet noch keine Frage. Sie zeigt nur, wo Antworten gefunden werden müssen. In diesem zweiten Teil geht es um den nächsten Schritt: Wie werden aus fünf Normenwelten konkrete Sicherheitsziele — und wie entsteht daraus ein einziger Katalog, der im Straßenfahrzeug genauso trägt wie auf dem Feld, auf der Baustelle und im Lager? Die kurze Antwort: durch systematische Analyse, normübergreifendes Mapping — und ein einfaches Prinzip, das im Zweifel immer gilt.

Auf einen Blick

• Sicherheitsziele fallen nicht vom Himmel: Sie entstehen aus der systematischen Gefährdungsanalyse und Risikobewertung (HARA) — Fahrsituationen mal Fehlfunktionen, bewertet nach Schwere, Exposition und Kontrollierbarkeit.
• ASIL, SIL, AgPL, MPL und PL messen dasselbe Grundrisiko in unterschiedlichen Sprachen — mit unterschiedlichen Annahmen zu Umfeld, Geschwindigkeit und Bedienerrolle. Die Buchstaben sind nicht austauschbar, aber übersetzbar.
• Die Übersetzung liefern die Normen selbst: Zuordnungstabellen bilden AgPL, MPL und PL auf die ASIL-Skala ab.
• Bei Safety-by-Wire® gilt nach der Konsolidierung ein einfaches Prinzip: Im Zweifel setzt immer die strengste Anforderung den Maßstab — bis hinauf zu ASIL D für die primären Bewegungsfunktionen.
• Das Ergebnis ist ein Zielkatalog statt fünf Parallelkataloge: einmal formuliert, in allen Domänen gültig, von Beginn der Plattformentwicklung an.

Am Anfang steht die Gefahr: die HARA

Jede Sicherheitsargumentation beginnt mit einer unbequemen Übung: dem systematischen Durchdenken dessen, was schiefgehen kann. Die Gefährdungsanalyse und Risikobewertung — in der ISO 26262 als HARA etabliert — kombiniert dafür zwei Dimensionen: die Betriebssituationen eines Fahrzeugs und die möglichen Fehlfunktionen seiner Systeme. Ein unbeabsichtigter Lenkeingriff bei Autobahngeschwindigkeit. Ein Bremsverlust im Gefälle. Ein ungewollter Vortrieb beim Rangieren in der Menschenmenge.

Jede dieser Kombinationen wird bewertet — nach der Schwere möglicher Schäden, der Wahrscheinlichkeit, sich in der jeweiligen Situation zu befinden, und der Frage, ob ein Mensch die Situation noch beherrschen könnte. Aus dieser Bewertung entsteht die Risikoeinstufung, aus der Einstufung das Sicherheitsziel. Die Logik ist in allen Normenwelten dieselbe; die Annahmen dahinter sind es nicht: Die ISO 25119 denkt in Feldarbeit und Bedienernähe, die ISO 19014 in Baustellenverkehr mit Personal im Nahbereich, die EN 1175 in engen Lagergassen. Wer eine Plattform für alle diese Welten baut, führt deshalb nicht eine Analyse durch, sondern mehrere — mit jeweils eigener Brille. (Grafik, siehe oben)

Was ASIL, SIL, AgPL, MPL und PL wirklich aussagen

Die Risikometriken der fünf Normenwelten wirken auf den ersten Blick wie dieselbe Idee in verschiedenen Alphabeten — und im Kern stimmt das. Im Detail lohnt der zweite Blick:

• ASIL (ISO 26262) stuft von A bis D und rechnet die Kontrollierbarkeit durch einen Fahrer ausdrücklich mit ein — eine Annahme, die im fahrerlosen Betrieb neu gedacht werden muss. Darauf kommen wir in Teil 3 zurück.
• SIL (IEC 61508) ist die generische, stark probabilistisch geprägte Skala: Sie denkt in Ausfallwahrscheinlichkeiten sicherheitsrelevanter Funktionen und bleibt der Bezugspunkt jenseits der Domänennormen.
• AgPL (ISO 25119) überträgt die Logik auf Land- und Forstmaschinen — mit eigenen Annahmen zu Geschwindigkeiten, Arbeitsumgebung und der Rolle des Bedieners.
• MPL (ISO 19014) tut dasselbe für Erdbaumaschinen, deren Risikobild von wechselndem Personal im unmittelbaren Arbeitsbereich geprägt ist.
• PL (ISO 13849, via EN 1175) argumentiert stärker strukturell — über Steuerungsarchitektur, Ausfallwahrscheinlichkeiten und Diagnosedeckungsgrad — und ist die Sprache der Maschinensicherheit und Intralogistik.

Die wichtigste Erkenntnis daraus: Ein „ASIL D" ist kein „SIL 4", und ein „PL e" ist kein „AgPL e" — die Skalen tragen ihre Domänenannahmen in sich. Wer sie gleichsetzt, ohne zu übersetzen, vergleicht Vokabeln statt Bedeutungen.

Das Mapping: Wenn Normen einander übersetzen

Die gute Nachricht: Die Normenwelt hat das Übersetzungsproblem erkannt — und selbst gelöst. Die Normen liefern Zuordnungstabellen, die die Skalen aufeinander abbilden, etwa in den Anhängen der ISO 25119 und der ISO 19014. Damit lässt sich ein AgPL- oder PL-bewertetes Sicherheitsziel auf die ASIL-Skala übertragen — nicht als grobe Analogie, sondern normativ abgestützt. Die Machine Performance Level der ISO 19014 werden dabei über die PL-Skala geführt, bevor der Schritt auf die ASIL-Skala erfolgt.

Genau hier setzt die Konsolidierung von Safety-by-Wire® an: Die Sicherheitsziele aus allen durchgeführten Analysen werden über diese Tabellen auf eine gemeinsame Skala gebracht — die ASIL-Skala der Leitnorm ISO 26262. Wo dasselbe Ziel in mehreren Domänen auftaucht, aber unterschiedlich streng bewertet wird, entscheidet ein einfaches Prinzip: Die strengste Anforderung gewinnt. Kein Aushandeln, kein Mittelwert, keine Ausnahme je nach Marktchance. Das Prinzip ist unbequem in der Entwicklung — und genau deshalb wertvoll im Nachweis.

Ein Katalog, der überall trägt

Am Ende dieser Konsolidierung steht ein einziger Katalog von Sicherheitszielen — formuliert auf Systemebene, gültig über alle Einsatzdomänen. Auf Prinzip-Ebene lauten die Ziele für die primären Bewegungsfunktionen so, wie man es erwarten würde, und genau das ist ihre Stärke: Verhindere unbeabsichtigte Lenkbewegungen. Verhindere den Verlust der Bremsfunktion. Verhindere ungewollten Vortrieb. Für diese Ziele gilt die höchste Einstufung der Leitnorm — ASIL D. Dazu kommen Ziele für flankierende Funktionen, vom Absichern des Stillstands bis zur Signalisierung, jeweils mit der Einstufung, die die strengste betroffene Normenwelt verlangt.

Entscheidend ist, was dieser Katalog nicht ist: kein nachträgliches Sammelwerk aus Einzelprojekten, sondern das Fundament, das vor der Architektur stand. Jede Design-Entscheidung der Plattform — Redundanzen, Diagnosen, Degradationslogik — lässt sich auf ein Ziel in diesem Katalog zurückführen. Diese Rückverfolgbarkeit ist unspektakulär, bis eine Genehmigungsbehörde oder ein Assessor danach fragt. Dann ist sie alles.

Was OEMs, Integratoren und Betreiber jetzt klären sollten

• Auf welcher HARA basiert der ASIL-Claim eines Lieferanten — und decken deren Betriebssituationen die eigenen Einsatzszenarien tatsächlich ab?
• Sind die Sicherheitsziele nur für die Straße formuliert — oder tragen sie auch im Feld, auf der Baustelle und in der Lagergasse?
• Sind die Annahmen dokumentiert, insbesondere zur Kontrollierbarkeit durch einen Fahrer — und gelten sie im fahrerlosen Betrieb noch?
• Wie wird bei unterschiedlich strengen Bewertungen desselben Ziels entschieden — gewinnt die strengste Anforderung oder die günstigste?
• Wird der Zielkatalog nachgeführt, wenn eine neue Einsatzdomäne oder ein neues Einsatzland hinzukommt — und wer verantwortet das?

Wer diese Fragen erst beantwortet, wenn das Lastenheft längst geschrieben ist, verhandelt Sicherheit gegen Termindruck — und verliert dabei fast immer beides. Arnold NextG hat den konsolidierten Zielkatalog deshalb an den Anfang der Plattformentwicklung gestellt. Er ersetzt nicht die anwendungsspezifische Analyse im Kundenprojekt — aber er sorgt dafür, dass diese Analyse auf einem Fundament aufsetzt, das die strengste Anforderung bereits kennt, statt sie später nachrüsten zu müssen.

Fazit

Fünf Normenwelten, eine Bewertungslogik, ein Prinzip: Die Konsolidierung der Sicherheitsziele ist der Punkt, an dem aus einer Normenstrategie ein belastbares Fundament wird. Die strengste Anforderung als Maßstab kostet in der Entwicklung Disziplin — und zahlt sie im Nachweis, in der Skalierung und in jeder neuen Einsatzdomäne zurück.

Im dritten Teil dieser Serie zeigen wir, wie aus dem Zielkatalog Architektur wird: warum der sichere Zustand bei Safety-by-Wire® Weiterfahren heißt — und was durchgängige Redundanz wirklich bedeutet.