ASIL-DEKOMPOSITION MIT BEISPIELEN ERKLAERT

ASIL-Dekomposition wird gerne missverstanden. Sie ist kein Rabatt auf Safety-Arbeit und kein Trick, um ein ASIL-D-Ziel billig zu machen. Richtig eingesetzt hilft sie Teams, ein hohes Sicherheitsziel über mehrere unabhängige Sicherheitsmaßnahmen zu erreichen.

Hand aufs Herz: Wenn die Dekomposition nur im Spreadsheet steht, aber nicht in Requirements, Architektur, Reviews und Evidence sichtbar bleibt, ist sie im Audit schwer zu verteidigen.

Was ASIL-Dekomposition leisten soll

Ein Safety Goal mit hohem ASIL kann unter bestimmten Bedingungen in mehrere Anforderungen mit niedrigeren ASIL-Anteilen zerlegt werden. Das funktioniert nur, wenn die Maßnahmen wirklich unabhängig sind und die Sicherheitsargumentation klar zeigt, warum ein gemeinsamer Fehler nicht beide Pfade aushebelt.

Ein einfaches Beispiel

Angenommen, ein Safety Goal verlangt, unbeabsichtigte Beschleunigung zu verhindern. Eine Architektur könnte zwei unabhängige Schutzpfade nutzen: einen Plausibilitaetscheck im Steuergeraet und eine getrennte Überwachung, die bei Abweichung in einen sicheren Zustand führt. Die Dekomposition ist nur belastbar, wenn beide Pfade nicht dieselbe Fehlerursache teilen.

Wo Teams stolpern

Typische Fehler sind zu frühe Dekomposition, fehlende Common-Cause-Betrachtung, unklare Allocation und Requirements, die zwar getrennt aussehen, aber im selben Softwarepfad oder Sensorannahmen hängen. Im Projektalltag fällt das oft erst spät auf.

Aegis SafeForge hilft, Dekompositionsentscheidungen mit Safety Goals, Requirements, Review-Status und Evidence verbunden zu halten. KI kann beim Formulieren der Rationale helfen; die Freigabe bleibt eine Engineering-Entscheidung.