ISO 26262 · IEC 61508 · Bestätigungsmaßnahmen
Sicherheitskonzepte kommen fast nie vor der Architektur. Sie kommen danach – und müssen zu etwas passen, das bereits existiert.
Diese Situation kennen wir von innen: eine ASIL-Dekomposition, die eine Architektur überstehen muss, die nie dafür entworfen wurde; eine Zulieferkomponente, deren Safety Manual eine andere Frage beantwortet; ein Termin, der davon ausging, der Safety Case sei ein Dokument und keine Argumentation. Das ist der Normalfall. Es ist auch der teure Fall – und darum geht es im Folgenden.
Unsere Haltung
Sicherheit lässt sich nicht nachrüsten
Sicherheit ist eine Eigenschaft des Systems, nicht der Dokumente darüber. Man kann sie am Ende weder hineinprüfen noch hineinschreiben.
Freedom from Interference ist eine Eigenschaft der Architektur. Wenn die Architektur keine Trennung bietet, schafft auch die beste Dokumentation keine – der Safety Case beschreibt dann schlicht ein System, das es nicht gibt. Mit der Traceability verhält es sich genauso: Sie ist günstig, wenn Anforderungen von vornherein nachverfolgbar geschrieben wurden, und ruinös, wenn sie achtzehn Monate später aus Commit-Nachrichten rekonstruiert werden muss. Eine Teststrategie, die gemeinsam mit den Anforderungen entstanden ist, erzeugt Nachweise nebenbei. Eine nach der Integration erfundene erzeugt eine Excel-Tabelle.
Das Muster, das wir auf beiden Seiten des Tisches immer wieder gesehen haben: Teams, die einfach gut entwickeln, bestehen Safety-Reviews fast nebenbei. Ihre Architektur ist modular, weil sich damit leichter arbeiten ließ. Sie wissen, was in einem Build steckt, weil sie es brauchten. Die Safety-Artefakte beschreiben das, was sie tatsächlich getan haben. Teams mit schwachem Engineering versuchen, denselben Abstand mit Dokumenten zu schließen – und jedes Dokument ist ein Versprechen, das später jemand einlösen muss.
Deshalb geben wir manchmal eine Antwort, nach der niemand gefragt hat. Wenn Sie uns für ein Sicherheitskonzept holen und das eigentliche Problem im darunterliegenden Engineering liegt, sagen wir das – früh, und bevor Sie ein Konzept bezahlt haben, das nicht tragen kann. Das ist ein größeres Gespräch als das, mit dem Sie begonnen haben, und es ist billiger als die Alternative. Eine Gefährdung, die in der Konzeptphase gefunden wird, kostet einen Nachmittag Diskussion. Dieselbe Gefährdung in der Validierung kostet eine Neuentwicklung.
Die Prozessseite derselben Argumentation: Automotive SPICE →
Bestätigungsmaßnahmen
Die Arbeit, für die es jemanden von außen braucht
ISO 26262 verlangt Bestätigungsmaßnahmen mit einem Unabhängigkeitsgrad, der mit dem ASIL steigt. Eine externe Praxis erfüllt das strukturell: keine Berichtslinie ins Projekt, kein gemeinsames Budget und kein Karrieregrund, ein Finding weicher zu formulieren.
Confirmation Reviews
Ebene Arbeitsprodukt
Review von Safety-Plan, HARA, Sicherheitskonzepten und Safety Case auf Normkonformität – so berichtet, dass das Team damit arbeiten kann und es nicht nur ablegt.
Safety Audit
Ebene Prozess
Ob der Safety-Prozess im Projekt tatsächlich umgesetzt wurde – und nicht nur im Handbuch beschrieben ist. Meist der Punkt, an dem der Abstand zwischen beidem sichtbar wird.
Safety Assessment
Ebene Item
Die Beurteilung, ob das Item funktionale Sicherheit erreicht – die Argumentation als Ganzes, keine Checkliste gegen Klauseln. Mit einer Empfehlung, die Sie gegenüber dem Kunden vertreten können.
Was wir nicht tun: zertifizieren
Ein Zertifikat auszustellen setzt die Akkreditierung bei einer staatlichen Stelle voraus, die eine Ein-Personen-Praxis sinnvollerweise nicht hält. Also behaupten wir es auch nicht. Was wir tun: Sie so weit bringen, dass eine Zertifizierungsstelle nichts Überraschendes findet – und Ihnen früh und deutlich sagen, welche Ihrer Fragen wirklich eine solche Stelle braucht und welche nicht. Nach unserer Erfahrung braucht sie einiges davon nicht.
Die Argumentation aufbauen
Bevor irgendjemand etwas bestätigt
Der größte Teil der Arbeit liegt weit vor einer Bestätigungsmaßnahme. Ein Safety Case ist eine Argumentation – und Argumentationen baut man leichter auf, als man sie repariert.
Safety-Plan und -Konzept
HARA, funktionales und technisches Sicherheitskonzept, eine ASIL-Dekomposition, die die Architektur auch tragen kann – und ein Plan, der zum Projekt passt statt zur Norm.
Arbeitsprodukte, die tragen
Anforderungen, Architektur, Verifikation und die Traceability dazwischen – im Engineering entstanden, nicht hinterher für den Reviewer rekonstruiert.
Lieferanten und SEooC
DIA, Assumptions of Use, Qualifizierung von Softwarekomponenten – die Stellen, an denen eine Sicherheitsargumentation am häufigsten auf etwas ruht, das niemand geprüft hat.
Über Straßenfahrzeuge hinaus
IEC 61508 für industrielle E/E-Systeme
ISO 26262 ist eine branchenspezifische Ableitung der IEC 61508, und Teams, die zwischen beiden wechseln, nehmen oft Gewohnheiten mit, die dort nicht mehr gelten. Wir arbeiten in beiden Welten: SIL-Bestimmung, Sicherheitslebenszyklus, Lieferantenqualifizierung und der Safety Case für industrielle elektrische und elektronische Systeme – auch für Organisationen, deren Automotive-Prozesse jetzt eine nicht-automobile Produktlinie mitbedienen müssen.
Wo Safety auf Security trifft: Safety & Security Co-Engineering →