Funktionale Sicherheit
ISO 26262 in Serienprojekten
Fortsetzung des Artikels von Teil 2
Verification-Driven Design mit ISO 26262
ISO 26262 und ASPICE versuchen die Qualität durch Umsetzung systematischer (Sicherheitsmanagement)-Prozesse zu erhöhen. Abhängig vom Druck der Fahrzeughersteller scheint ASPICE Prozesskonformität derzeit wichtiger zu sein als ISO 26262 technische Kompetenz und Tiefe. Dies führt zu Entscheidungen der Projektleitung, vermehrt Ressourcen und Zeit für Reviews und formelle Anforderungsverfolgung freizugeben, was zu Lasten effektiverer analytische Nachweismethoden, wie FTA (Fault Tree Analysis), FMEA (Failure Mode and Effect Analysis), FMEDA (Failure Mode, Effect and Diagnostic Analysis), SW-Kritikalitätsanalyse oder SW-HAZAN (Hazard Analysis) gehen kann. Reviews sind passive Verifikationsmaßnahmen, d.h. der Reviewer „verdaut“ in der Regel die vorgestellten Arbeitsprodukte. Dies birgt – wie bei jeder Verdauung – die Gefahr, bei zu schwerer Mahlzeit das Gehirn zu verlangsamen, was bei aktuellen Entwicklungsdokumenten leicht der Fall sein kann. Dies gilt auch für Checklisten unterstützte Inspektionen.
Jobangebote+ passend zum Thema
Bei aktiven Sicherheitsverifikationen wie FTA und FMEA analysieren die Verifikations- und Design-Teams aktiv die Arbeitsprodukte durch Analysetechniken und Pass/Fail-Kriterien – unabhängig vom jeweiligen Designdokument. Solche Verifikationsaktivitäten sind am effektivsten, wenn sie bereits in einer Phase des Projektes durchgeführt werden, die noch nicht so stark vom SOP-Druck (Start of Production) betroffen ist. Einige Fahrzeughersteller fordern diese technisch tiefgehenden Analyseschritte in ihren Integrationsmeilensteinen. Exida empfiehlt, die Vorteile solcher frühzeitigen aktiven Sicherheitsverifikationen gegenüber passiven Reviews gut zu nutzen.
Eine Verifikationstechnik, die von Entwicklungsingenieuren nach kurzer Eingewöhnungszeit gerne angenommen wird, ist die qualitative und quantitative Fehlerbaumanalyse (FTA). Die grafische Darstellung der Fehlerbäume gibt Entwicklungsingenieuren einen sehr viel übersichtlicheren Einstieg in die Systemarchitektur und das Sicherheitskonzept, als es durch riesige FMEA-/FMEDA-Tabellen erreicht wird. Die Ingenieure sind in der Lage, die Sicherheit ihres Designs schon lange vor einer formalen FMEA und FMEDA zu beurteilen und einfach gegenüber den Sicherheitsingenieuren der Kunden zu demonstrieren und zu diskutieren. Die FTA-Workshops für das zu entwickelnde Produkt bringen auch einen viel höheren Erkenntnisgewinn bzgl. zufälliger und systematischer Fehler als allgemeine Trainings.
Ziel muss es sein bereits mit einem sicherheitstechnisch soliden Designentwurf in den formalisierten ISO 26262 Lebenszyklus zu starten. Das Verification-driven Design führt dazu eine informelle „Feasibility Study“ mit qualitativen und semi-quantitativen Fehleranalysen (vorzugsweise FTA und DFA/CCA (Dependent Failure Analysis/Common Cause Analysis)) vor den formellen Nachweisschritten und Dokumentationsaktivitäten des ISO-26262-Lebenszyklus ein. Die Fehleranalysen dienen dazu, alle notwendigen Sicherheitsmechanismen zu ermitteln und als Designanforderungen festzuschreiben, um die Anforderungen an das Fehlerverhalten zu erfüllen. Dazu wird das Anforderungsengineering in mehrere Schritte aufgeteilt, die von Ingenieuren mit unterschiedlichem Erfahrungshintergrund durchgeführt werden können.
Schritt 1: Definition eindeutiger Produktanforderungen
Heute ist es üblich, dass die Fahrzeughersteller dem Zulieferer Lastenhefte mit 3500 bis über 5000 Anforderungen übergeben. Diese Menge an Anforderungen muss beim Hersteller in für die einzelnen Teams beherrschbare Pakete aufgeteilt werden. Parallel dazu werten Sicherheits- und Qualitätsingenieure die im Kundenlastenheft referenzierten Standards bezüglich zusätzlicher produkt- oder qualifizierungsrelevanter Anforderungen aus. Bei Re-Use-Projekten müssen die Kundenanforderungen von den einzelnen Entwicklungsteams mit den vorhandenen Produktlösungen verglichen und die geänderten bzw. neuen Anforderungen hervorgehoben werden (Bild 2).
Schritt 2 + 3: Definition eindeutiger Produktanforderungen
Im nächsten Schritt erstellt der Konzeptingenieur einen ersten Entwurf des Technischen Sicherheitskonzepts, das die entscheidenden bzw. schwierigsten Produktanforderungen umsetzt. Auch wenn dieser Schritt nicht allen formalen Vorgaben genügt, so ist es doch von großer Bedeutung, dass die umgesetzten und die nicht umgesetzten Anforderungen eindeutig gekennzeichnet sind. Dieser Entwurf des Technische Sicherheitskonzepts wird dann im dritten Schritt den vorläufigen Sicherheitsanalysen (FTA und DFA) unterzogen (Bild 3).
Dabei ist es von großer Bedeutung, dass ein Katalog anzunehmender Fehlerarten existiert. Andernfalls sind diese Analysen zu sehr von Wissen und Erfahrung der Teilnehmer abhängig, und man läuft Gefahr, kein objektives Kriterium für die Vollständigkeit bzw. das Ende der Analysen definieren zu können. Hierbei sind die Fehlerannahmen in ISO 26262-5 Annex D.1 und in ISO 26262-9 ausgezeichnete, aber nicht ausreichende Startpunkte.
Bild 4 zeigt das stark vereinfachte Beispiel einer FTA und einen Teil der zugehörigen DFA einer Energieversorgung. Die FTA ist sehr hilfreich, die Beziehungen zwischen den Teilsystemen zu erkennen, und schafft damit die Grundlage für die zugehörige DFA. Alle UND-Gatter der FTA sind bezüglich der statistischen Unabhängigkeit seiner Eingangsereignisse in der DFA zu untersuchen. Dies ist in der ISO 26262 besonders wichtig, da die Norm keine statistische Modellierung der Wahrscheinlichkeit des gemeinsamen Ausfalls definiert. Damit steht und fällt die Berechnung der gefährlichen Ausfallraten und der SPFM (Single Point Failure Metric) mit der Gründlichkeit der Fehlerannahmen zur DFA und deren Durchführung.
- ISO 26262 in Serienprojekten
- OEM-Anforderungen an Zulieferer in Re-Use-Projekten
- Verification-Driven Design mit ISO 26262
- ISO 26262 in der Zukunft
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
Distribution
Rutronik gründet Automotive Business Unit
Call for Papers - Jetzt Vortrag einreichen
Forum Funktionale Sicherheit 2015
Interview Prof. Dr. Thomas Klindt
»Normenkonformität bedeutet nicht Rechtskonformität!«
PES
Funktionale Sicherheit in verteilten Embedded-Systemen
VDE – Teil 2
Modelle der funktionalen Sicherheit
