Umsetzung der Dekompositionsregeln

i-Q-Mitarbeiter Ingenieur telefoniert © i-Q Schacht & Kollegen Qualitätskonstruktion GmbH

Wir als ISO26262-Fachleute sollen eigentlich wissen, dass ein ASIL B(D) nicht identisch ist mit einem ASIL B. Aber die Fragen aller Fragen zu diesem Themenbereich sind einfach:

• Wann kann ich einen ASIL B(D) tatsächlich wie einen ASIL B behandeln? 
• Wann muss ich vielleicht bei einem ASIL B(D) die Vorgehensweisen von ASIL C anwenden? 
• Und wann muss ich auch tatsächlich sogar bei einem ASIL B(D) die kompletten Anforderungen zu ASIL D erfüllen?

Und genau auf diese Anforderungen und Hinweise haben wir die Norm mal sehr intensiv angesehen. Unser Ergebnis sieht dabei im Groben wie folgt aus:

Bei sehr vielen Fällen (wir haben jetzt nicht exakt durchgezählt) kann ein ASIL B(D) tatsächlich wie ein ASIL B behandelt werden. Und damit führt diese Erkenntnis dazu, dass wir Vorgehensweisen vereinfachen können bzw. nicht alle Methoden des ursprünglichen Levels anwenden müssen.

ABER: Es gibt auch Bereiche, in denen die Norm keine eindeutige Aussage liefert, aber wir der Meinung sind, dass gewisse Rahmenbedingungen einfach erfüllt werden müssen.

Beispiel: Der OEM dekomponiert seinen ASIL D (auf Fahrzeug-Ebene) auf zwei Steuergeräte (von unterschiedlichen Lieferanten) jeweils auf ASIL B(D). Das bedeutet, dass der OEM zum Beispiel eine FTA auf der System-Ebene erstellen muss! Aber dazu ist er definitiv nicht in der Lage, wenn er die entsprechenden Informationen bezüglich FTAs für die beiden Steuergeräte nicht bekommt! Daraus ergibt sich die logische Schlussfolgerung, dass auch die Lieferanten jeweils für ihr ASIL B(D) System eine FTA erstellen müssen, entgegen der normativen Anforderung.

Einen kleinen Auszug unserer Vorstellungen zeigt die folgende Abbildung. Für detailliertere Informationen sprechen Sie uns einfach an.

Warum weisen wir dem Bereich "QM" ein Symbol zu?

Damit wollen wir aufzeigen, wie die Methoden - die in den Tabellen der ISO 26262 erwähnt werden - im Vergleich zu den ASIL-Einstufungen auf der QM-Ebene zur Anwendung kommen sollten. Der Grad unserer Empfehlung orientiert sich an den Vorgaben der ASIL-Einstufungen aus der aktuellen Norm.

Für jede Methode hängt der Grad der Empfehlung, die entsprechende Methode zu verwenden, vom ASIL 
ab und ist wie folgt kategorisiert:

• "++" bedeutet, dass die Methode für das identifizierte ASIL sehr empfohlen wird;
• "+" bedeutet, dass die Methode für das identifizierte ASIL empfohlen wird; und
• "o" bedeutet, dass für die Methode keine Empfehlung für oder gegen ihre Anwendung für das identifizierte ASIL vorliegt. 

Dem QM wurde nun - von den Entwicklern dieser Tabelle - auch ein Grad der Empfehlung (nachfolgend Wert genannt) nach folgender Logik zugewiesen:

1. Wenn der Wert von ASIL A höher als der Wert von ASIL B ist, dann übernimmt QM den Wert von ASIL A.
2. Wenn der Wert von ASIL B höher als der Wert von ASIL A ist, dann übernimmt QM den Wert von ASIL A.
3. Wenn alle ASILs den gleichen Wert haben, dann übernimmt QM diesen Wert.
4. Wenn nur die Werte von ASIL A & ASIL B gleich sind, dann übernimmt QM den Wert von ASIL A vermindert um 1.
5. Wenn eine dieser QM-Zuweisungen inhaltlich nicht sinnvoll erscheint, wird eine Ausnahme festgelegt und erläutert.

Zusammenfassung:

QM erhält stets den Wert von ASIL A.
Ausnahme: Die Werte von ASIL A und ASIL B sind gleich, jedoch ungleich der Werte von ASIL C und/oder ASIL D, dann übernimmt QM den Wert von ASIL A vermindert um 1

Und hier eine mathematisch angehauchte Version der QM-Zuweisungen:

1. Wenn ASIL A > ASIL B → QM = ASIL A    
2. Wenn ASIL B > ASIL A → QM = ASIL A    
3. Wenn ASIL A = ASIL B = ASIL C = ASIL D → QM = ASIL A    
4. Wenn ASIL A = ASIL B ≠ ASIL C und/oder ASIL D → QM = ASIL A - 1    
5. Wenn 1. bis 4. unlogisch → Ausnahme, siehe Erläuterungen

Zusammenfassung:

QM = ASIL A, außer wenn ASIL A = ASIL B ≠ ASIL C und/oder ASIL D, dann QM = ASIL A - 1

Im Folgenden finden Sie entsprechende Ausnahmen mit Begründungen, wann und warum in der Spalte QM ein anderer Wert gewählt wurde, als in unserer eigenen QM-Zuweisung festgelegt:

Part 5, Tabelle 3 - Hardware design verification, Eintrag 1a - Hardware design walkthrough: Das Walkthrough ist die einfachste Version des Reviews. Daher sollte man (wenn ein Review durchgeführt wird) dieses nach der Methodik des Walkthroughs durchführen. Aus diesem Grund weisen wir in der Spalte QM den Wert "++" zu, statt "+".

Part 6, Tabelle 2 - Notations for software architectural design, Eintrag 1b - Notations for software architectural design: Weil für ASIL A und ASIL B die Methoden sehr empfohlen werden, für ASIL C und ASIL D aber "nur" empfohlen werden, weisen wir in der Spalte QM den Wert "++" zu. (umgekehrte Logik wie oben beschrieben, aber in diesem Fall hoffentlich auch nachvollziehbar)

Part 6, Tabelle 2 - Notations for software architectural design, Eintrag 1d - Notations for software architectural design: Obwohl alle Einträge ein "+" haben, sind wir der Meinung, dass eine formale Notation für den Bereich QM nicht angemessen ist. Aus diesem Grund weisen wir in der Spalte QM den Wert "o" zu, statt "+".

Part 6, Tabelle 5 - Notations for software unit design, Eintrag 1d - Formal notations: Obwohl alle Einträge ein "+" haben, sind wir der Meinung, dass eine formale Notation für den Bereich QM nicht angemessen ist. Aus diesem Grund weisen wir in der Spalte QM den Wert "o" zu, statt "+".

Nachdem nun die QM-Zuweisungen für den Grad der Anforderungen und Empfehlungen feststehen (weiße Spalten in unserer Methoden-Tabelle mit Dekomposition), gehen wir zur Dekomposition der Safety-Requirements (farbige Spalten). 

Erläuterungen zu unserer Methoden-Tabellen mit Dekomposition

In der 1. farbigen Kopfzeile unserer Methoden-Tabellen mit Dekomposition steht ein Requirement (Req.X) mit seinem ursprünglichen Sicherheitsziel (z.B. ASIL A bis ASIL D) für ein Element E (→Elmt.E), dass je nach seiner Kritikalität einen passenden farblichen Hintergrund hat.

In der 2. farbigen Kopfzeilen unserer Tabellen sind die dekomponierten Sicherheitsziele zu sehen und ob ihr Element ein Sicherheitsmechanismus (S) oder eine Funktion (F) haben sollte. Auch hier zeigt die farbliche Abstufung die Kritikalität der dekomponierten Safety Anforderungen. Je dunkler der Farbton desto höher die Kritikalität. 

Beispiel: Ein ASIL D kann z.B. in ein ASIL D(D) - Element mit Sicherheitsmechanismus - und QM (D) - Element mit Funktionalität - dekomponiert werden. Das bedeutet, dass:

• ASIL D ausreicht, um Elemente zu entwickeln, die einen Sicherheitsmechanismus enthalten um die vorgesehene Funktionalität zu erfüllen
• das Qualitätsmanagement-System ausreicht, um Elemente zu entwickeln, die die vorgesehene Funktionalität der zugeordneten Safety-Anforderung umsetzen

Übrigens: Das komplette Zerlegungsschemata der Dekomposition kann aus der ISO 26262:2018, 9-5.4.9 entnommen oder durch eine einfache mathematische Formel ermittelt werden, die auf unserer Webseite FuSi - Dekomposition / Grundlagen erklärt wird.

Da ein ASIL D in 2 x ASIL B(D) dekomponiert werden kann, müsste in der 2. Kopfzeile unserer Tabelle korrekterweise die Spalte B(D) 2 mal existieren. Aber der Inhalt dieser weiteren Spalte wäre identisch mit der bereits bestehenden - würde den Nutzen der Tabelle also nicht verbessern. Somit stellen wir in unserer Tabelle nur 1 mal die Spalte B(D) dar. Gleiches gilt für die Spalte A(B) bei der Dekomposition eines ASIL B.

In der 3. Zeile (grau) wird der Teil der Norm benannt, in der die darunter stehenden Methoden-Tabellen zu finden sind.

In der 4. farbigen Zeile steht in fetten Großbuchstaben der Level des Sicherheitsziels nach der Dekomposition. Jede Dekomposition bringt entweder ein ASIL- und ein QM-Requirement oder 2 ASIL-Requirements hervor. Es kann auch so dekomponiert werden, dass es zu einer höheren ASIL-Anforderung kommt (ISO 26266:2018, 9-5.4.9). Diesen Fall berücksichtigt unsere Tabelle jedoch nicht, da wir die mögliche Logik dahinter bis heute nicht verstanden haben.

Ab Zeile 5 zeigen die Zellen (auf der farbigen Seite der Tabellen) den Grad der Empfehlung der entsprechenden Methode – und zwar stets nach der Dekomposition. Entweder richtet er sich nach dem Grad der Empfehlung des Ursprungs-ASILs oder nach dem des dekomponierten ASILs bzw. des QMs.

Dekomposition: Was ist zu beachten?

• Die ursprüngliche Sicherheitsanforderung wird in einzelne Sicherheitsanforderungen zerlegt. 
• Diese einzelnen Sicherheitsanforderungen müssen durch unabhängige Elemente (Elmt.E.1 und Elmt.E.2) umgesetzt werden (independence of elements).
• Nach der Dekomposition ist die hinreichende Unabhängigkeit der Elemente nachzuweisen durch die Analyse der abhängigen Ausfälle:
  • entweder es gibt keine plausible Ursache, die zur Verletzung einer ursprünglichen Sicherheitsanforderung führen kann
  • oder jede identifizierte Ursache wird durch eine angemessene Sicherheitsmaßnahme gemäß des ASIL der ursprünglichen Sicherheitsanforderung beherrscht
• Nach der Dekomposition muss eines der Elemente den Sicherheitsmechanismus / die Sicherheitsfunktion erhalten (Elmt.E.1 = S) und das andere Element die ursprüngliche Funktionalität umsetzen (ELMT.E.2 = F), also die Nutzfunktion übernehmen.
• ASIL-Zuweisung:
  • Entweder das Requirement der Sicherheitsfunktion erhält den höheren ASIL und das Requirement der Nutzfunktion erhält den niedrigeren ASIL oder QM
  • Oder beide Requirements erhalten den gleichen ASI 
• Die Realisierung der Nutzfunktion ist oft aufwendiger als die Realisierung der meist einfacheren Sicherheitsfunktion. 
  • Beispiel Nutzfunktion vs. Sicherheitsfunktion:
    • Vor der Dekomposition: ASIL C für ein Requirement an die komplexe Software einer Motorsteuerung mit 200.200 Zeilen C-Codes
    • Dekomposition: ASIL C wird dekomponiert in QM(C) und ASIL C(C)
    • Nach der Dekomposition: QM(C) wird dem Requirement für die komplexe Software einer Motorsteuerung mit 200.000 Zeilen C-Codes (Nutzfunktion) zugewiesen und ASIL C(C) wird dem Requirement für die Überwachungsfunktion mit 200 Zeilen C-Codes (Sicherheitsfunktion) zugewiesen.
• Ausnahmen: Nach der Dekomposition gilt trotzdem die Anforderung des Ursprungs-ASILs in folgenden Fällen:
  • Integrationsaktivitäten der dekomponierten Elemente und die nachfolgenden Aktivitäten, einschließlich Verifizierungs- und Bestätigungs-Maßnahmen (Verification und Confirmation Measures) (ISO 26262, 5-10.4.2 + 9-5.4.12) und für die
  • Anforderungen an die Bewertung der Hardware-Architekturmetriken als auch die Bewertung von Sicherheitszielverletzungen aufgrund von zufälligen Hardwareausfällen gemäß ISO 26262-5 (ISO 26262:2018, 9-5.4.5 + 9-5.4.11)

Wann muss ich vielleicht bei einem ASIL B(D) die Vorgehensweisen von ASIL C anwenden? 

Diese Vorgehensweise wurde in der 1. Ausgabe der Norm von 2011 beschrieben. In der aktuell gültigen Version von 2018 wird diese Vorgehensweise nicht mehr erwähnt.

Und wann muss ich auch tatsächlich sogar bei einem ASIL B(D) die kompletten Anforderungen zu ASIL D erfüllen?

Die ASIL-Anforderungen an die ursprüngliche ASIL-Zuweisung bleiben bei der Zerlegung unverändert, bei:

• Integrationsaktivitäten der dekomponierten Elemente
• Aktivitäten nach den Integrationsaktivitäten
• Verifizierungs- und Bestätigungs-Maßnahmen (Verification und Confirmation Measures)
• Requierments an die Bewertung der Hardware-Architekturmetriken
• Requierments an die Bewertung von Sicherheitszielverletzungen aufgrund von zufälligen Hardwareausfällen gemäß ISO 26262-5

Gründe für verschiedene Dekompositionsstrategien:

ASIL B(D) und ASIL B(D): Diese Dekomposition kann gewählt werden, wenn zwei Elemente mit mittlerer Kritikalität ausreichend voneinander unabhängig sind. Dadurch kann Redundanz geschaffen werden, so dass die Sicherheitsziele erreicht werden können.

ASIL A(D) und ASIL C(D): Diese Option kann sinnvoll sein, wenn ein Element weniger kritisch ist (ASIL A), während das andere Element eine höhere Kritikalität (ASIL C) aufweist. Dies kann nützlich sein, um Kosten für weniger kritische Komponenten zu senken.

ASIL D(D) und QM(D): Hier wird ein Element als "Quality Managed" (QM) betrachtet, was bedeutet, dass es keinen speziellen ASIL hat, während das andere Element eine hohe Kritikalität (ASIL D) beibehält. Diese Strategie könnte angewendet werden, wenn die Funktionalität sehr umfangreich gegenüber der sicherheitskritischen Überwachung ist oder wenn ein Teil der Software relativ häufige Änderungen des Quellcodes erwarten lässt.

Welche Dekompositions-Strategie ist am besten geeignet und kosteneffektiv?

Durch eine sorgfältige Analyse kann eine fundierte Entscheidung getroffen werden, welche Dekompositionsstrategie am besten geeignet und kosteneffektiv ist. Die folgenden Punkte können bei einer Abwägung nützlich sein:

• Risiken und Sicherheitsanforderungen der einzelnen Komponenten analysieren
• Kostenabschätzung für die Entwicklung, Implementierung und Validierung der verschiedenen Dekompositionsoptionen
• Wirtschaftlichkeitsanalyse durchführen, um die Gesamtkosten der verschiedenen Optionen zu vergleichen. Direkte als auch indirekte Kosten sind zu berücksichtigen
• Überprüfung der technischen Machbarkeit und die Auswirkungen auf die Systemarchitektur
• Ermittlung der langfristigen Auswirkungen auf Wartung, Upgrades und eventuelle Rückrufe