DGQ-Regionalkreis Karlsruhe - Pforzheim - Gaggenau, 07.02.2011
FUNKTIONALE SICHERHEIT NACH ISO/DIS 26262
Dr.-Ing. Alexander Schloske
Abteilungsleiter Produkt- und Qualitätsmanagement
© Fraunhofer
Telefon: +49(0)711/9 70-1890Fax: +49(0)711/9 70-1002
E-Mail: [email protected]
Internet: www.ipa.fraunhofer.de
1427/08
Dortmund
Darmstadt
Dresden
Bremen
Hannover
Berlin
Rostock
VorstellungDie Fraunhofer-Gesellschaft
© Fraunhofer
Karlsruhe
Saarbrücken
MünchenStuttgart
Freiburg
57 Institute an rund 40 Standorten
17.000 Mitarbeiter1,6 Mrd. € Budget
Institutsleitung: Prof. Dr.-Ing. Engelbert WestkämperProf. Dr.-Ing. Alexander Verl
Unternehmensorganisation Oberflächentechnik
LackiertechnikDipl.-Ing. Dieter Ondratschek
Digitale FabrikDr.-Ing. Carmen Constantinescu
Automatisierung
Orthopädie und Bewegungssysteme
RobotersystemeDipl.-Ing. Martin Hägele M.S.
Produkt- und QualitätsmanagementProzessengineering
VorstellungDas Fraunhofer-Institut für Produktionstechnik und Automatisierung (IPA), Stuttgart
© Fraunhofer
Fabrikplanung und ProduktionsoptimierungDipl.-Ing. Michael Lickefett
Unternehmenslogistik und Auftragsmanagement
Dipl. oec. soc. Anja Schatz
Orthopädie und BewegungssystemeDr. med. Urs Schneider
Reinst- und MikroproduktionDr.-Ing. Dipl.-Phys. Udo Gommel
Technische InformationsverarbeitungDipl.-Inf. Markus Hüttel
SchichttechnikDr.-Ing. Martin Metzner
Pigmente und LackeDr.-Ing. Michael Hilt
Anwendungszentrum Rostock
Fraunhofer Research Austria
Projektgruppe Bayreuth
Produkt- und QualitätsmanagementDr.-Ing. Alexander Schloske
RefabrikationProf. Dr.-Ing. Rolf Steinhilper
Produktions- und Prozessautomatisierung
Dr.-Ing. Jan Stallkamp
PrüfsystemeDipl.-Ing. Joachim Montnacher
Prozessengineering funktionaler Materialien
Dipl.-Ing. (FH) Ivica Kolaric, MBA
Projektgruppe Zilina
VorstellungVernetzung von Wissenschaft und Praxis
© Fraunhofer
Lehre Forschung Entwicklung Realisierung Anwendung
Thematische Ausrichtung
� Entwicklung von Life-Cycle-Konzepten und Life-Cycle-Methoden zur Optimierung von Produkten und Prozessen
Optimierungsziele
� Qualität, Kosten, Umwelt / Energie, Zeit
VorstellungDie Abteilung Produkt- und Qualitätsmanagement
© Fraunhofer
� Qualität, Kosten, Umwelt / Energie, Zeit
Themenschwerpunkte
� Produktentwicklung
� Prozessoptimierung
� Risikomanagement
� Green Manufacturing
Highlight-Themen Absicherung einer Sicherheitslogik im automotive Umfeld
Aufgabenstellung:
� Absicherung einer Sicherheitslogik für ein innovatives System in der Automobilindustrie
� Sicherstellung der „Funktionalen Sicherheit“ nach IEC 61508 und ISO/CD 26262
Projektvorgehensweise:
1965
© Fraunhofer
Projektvorgehensweise:
� Durchführung von Gefahren- und System-Risikoanalysen
� Definition von Softwarerequirements für die Steuerung
� Erarbeitung von Testplänen und Testszenarien
Projektkenndaten:
� Projektlaufzeit: ca. 12 MonateFahrzeug zufällig gewählt !
20xx?
Bildquelle: http://www.automobilrevue.de/detroit2002.htm
Funktionale SicherheitBeispiele zur Funktionalen Sicherheit
Beispiele aus der Realität:
� Renault ruft 2010 weltweit 695.000 Scénic zurück
� Bei diesem Modell kann es laut Renault zu einem unbe-absichtigten Anziehen der automatischen Parkbremse während der Fahrt kommen.Quelle: www.welt.de
© Fraunhofer
� Toyota ruft 2010 373.000 Autos zurück
� Rückrufaktion auf Grund der Möglichkeit, dass während derFahrt das Lenkradschloss selbsttätig einrastet. Damit ist das Lenken des Fahrzeugs nicht mehr möglich. Quelle: http://www.auto-motor-und-sport.de/
Quelle: www.motor-talk.de/
Funktionale SicherheitBeispiele zur „Funktionalen Sicherheit“
Beispiele aus der Realität:
� „Volvo-City- Safety“ versagt 2010 bei Pressevorführung
� Das City-Safety-System soll Hindernisse wie Gegenstände aufder Straße oder Fußgänger erkennen und automatisch das Auto abbremsen, um einen Zusammenstoß zu verhindern.
� Wie der Autohersteller später angab, war eine nicht
© Fraunhofer
� Wie der Autohersteller später angab, war eine nicht funktionierende Batterie schuld am Ausfall des Systems.Quelle: www.auto.de
Vortragsinhalte
� Aufbau und Anwendung der ISO 26262
� Grundlegende Begriffe und Verfahren
� Gefahren- und Risikoanalyse
� Risikographen zur ASIL-Klassifizierung
� Failure Modes und Hardware Metriken
© Fraunhofer
� Failure Modes und Hardware Metriken
© Fraunhofer
ENTWICKLUNG UND NORMENZUR FUNKTIONALEN SICHERHEIT
Funktionale SicherheitUrsprung der Funktionalen Sicherheit
Chemieunfall in Seveso, Italien 1976: Hochgiftiges Dioxin mit katastrophalen Folgen für Menschen, Tierwelt und Natur ausgetreten
� Unkontrollierte Reaktion führte zur Überhitzung
� Automatische Kühlsysteme und Warnanlagen
© Fraunhofer
� Automatische Kühlsysteme und Warnanlagen waren nicht vorhanden
Unglück löste Normungsbestrebungen für funktionale Sicherheit aus:
� IEC 61508 (allgemein) – 1998/2000
� ISO 26262 (automotive) – 05/2011 (geplant)
Funktionale SicherheitNormenlandschaft
elektrische, elektronische und programmierbare elektronische Geräte
IEC 61508derzeitig:
© Fraunhofer
…Kernkraftwerke MaschinenMedizingeräte
AutomotivePersonenkraftwagen (PKW bis 3,5t)
Bahnsektor
DIN IEC 61513 DIN IEC 60601 DIN EN 501xx
ISO/DIS 26262 (Erscheinung Mitte 2011)(Draft International Standard)
DIN EC 62061
Prozessindustrie
DIN IEC 61511
künftig:
(weitere)
…
(weitere)
Funktionale SicherheitScope der ISO/DIS 26262
� Geltungsbereich der ISO/DIS 26262
� PKW bis 3,5 Tonnen
� Elektrische und elektronische Systeme (E/E-Systeme)
� PKWs, die in Serie produziert werden
© Fraunhofer
� Nicht gültig (weiterhin Geltungsbereich der IEC 61508)
� Sonderfahrzeuge (Fahrzeuge für Personen mit Behinderungen)
� LKW, Pick-ups, Kleintransporter, Motorräder, …
� Programmierbare elektronische Systeme (PE-Systeme)
© Fraunhofer
DEFINITION UND ZIELSETZUNGDER FUNKTIONALEN SICHERHEIT
Funktionale SicherheitDefinition
� Funktionale Sicherheit ist die Fähigkeit eines elektrischen oder elektronischen Systems (E/E-System), beim Auftreten
� systematischer Ausfälle (z.B. fehlerhafte Systemauslegung)
� zufälliger Ausfälle (z.B. Alterung von Bauteilen)
mit gefahrbringender Wirkung, einen sicheren Zustand einzunehmen
© Fraunhofer
mit gefahrbringender Wirkung, einen sicheren Zustand einzunehmen bzw. im sicheren Zustand zu bleiben.
Funktionale SicherheitBegriffe der funktionalen Sicherheit
� Sicherheitsfunktion bzw. Funktionale Sicherheitsanforderung
Funktion eines sicherheitsbezogenen Systems, um im Gefahrfall einen Zustand mit tolerierbarem Restrisiko einzunehmen / aufrecht zu erhalten
� Sicherheitsintegrität
Wahrscheinlichkeit, dass ein sicherheitsbezogenes System die geforderten
© Fraunhofer
Wahrscheinlichkeit, dass ein sicherheitsbezogenes System die geforderten Sicherheitsfunktionen unter allen festgelegten Bedingungen innerhalb eines festgelegten Zeitraums anforderungsgemäß ausführt
� Sicherheits-Integritätslevel (A)SIL
vier diskrete Stufen zur Festlegung von Anforderungen für die Sicher-heitsintegrität der Sicherheitsfunktionen
� SIL1 bis SIL4 bei IEC 61508
� ASIL A bis ASIL D bei ISO/DIS 26262
Funktionalen SicherheitGrundprinzip „Risikominderung“
© Fraunhofer
Funktionalen SicherheitAnforderungen der Norm(en)
Die Normen (z.B. ISO/DIS 26262) zur Funktionalen Sicherheit fordern
� Maßnahmen zum Management der funktionalen Sicherheit
� Maßnahmen gegen systematische Ausfälle
� Maßnahmen gegen zufällige Hardwareausfälle
� Maßnahmen zur Beurteilung der funktionalen Sicherheit
© Fraunhofer
� Maßnahmen zur Beurteilung der funktionalen Sicherheit
Funktionale SicherheitErfüllung der Anforderungen
AnforderungenIEC 61508 / ISO DIS 26262
AnforderungenCMMI / SPICE
Risikoanalyse Architektur CMMI / SPICE
© Fraunhofer
Risikoanalyse
Funktionale Sicherheits-
anforderungen
Architektur
Integrität(SIL / ASIL)
CMMI / SPICE
Projektmanagement,Konfigurations-management,,...
Management des Sicherheitslebenszyklus
Quelle: nach Löw, Pabst, Petry (2010)
© Fraunhofer
AUFBAU UND INHALTE DER ISO/DIS 26262
Funktionale SicherheitAufbau der ISO/DIS 26262
1. Glossar
2. Management der funktionalen Sicherheit
3. Konzeptphase
4. Produktentwicklung: Systemebene
5. Produktentwicklung: Hardwareebene
© Fraunhofer
5. Produktentwicklung: Hardwareebene
6. Produktentwicklung: Softwareebene
7. Produktion und Betrieb
8. Unterstützende Prozesse
9. ASIL- und sicherheitsorientierte Analysen
10.Orientierungshilfen
Quelle: ISO/DIS 26262
(insgesamt 381 Seiten)
Funktionale SicherheitAufbau der Einzelnormen der ISO/DIS 26262-#
1. Scope
2. Normative reference
3. Terms, definitions, abbreviated terms
4. Requirements for compliance
5. Content
© Fraunhofer
5. Content- Objectivess- General- Inputs for this clause- Requirements and recommendations- Work products
6. Annex (informative)
7. Bibliography
Quelle: ISO/DIS 26262
Funktionale SicherheitAnforderungen an compliance (Kapitel 4 in ISO 26262-#)
� 4.1 Allgemeine Anforderungen
� Geplante Anpassungen
� Begründungen bei Abweichungen
� 4.2 Interpretation der Tabellen
� ++ Methode für ASIL stark empfohlen
© Fraunhofer
� ++ Methode für ASIL stark empfohlen
� + Methode für ASIL empfohlen
� 0 Keine Aussage (für / wider) zur Methode
� 4.3 ASIL-abhängige Anforderungen und Empfehlungen
� ASIL Anwendung
� (ASIL) Empfehlung
Quelle: ISO/DIS 26262-2
Funktionale SicherheitLebenszyklusmodell der ISO/DIS 26262
© Fraunhofer
Quelle: ISO/DIS 26262
Funktionale SicherheitLebenszyklusmodell der ISO/DIS 26262 (vereinfacht)
1. Vocabulary
2. Management of functional safety
3. Concept 7. Production
4. Product developmentsystem level
© Fraunhofer
Quelle: ISO/DIS 26262
3. Conceptphase
7. Productionand operation5. Product
developmenthardware
level
6. Productdevelopment
softwarelevel
8. Supporting processes
9. ASIL-oriented and safety-oriented analyses
10. Guideline on ISO 26262 (informative)
Funktionale SicherheitManagement der Funktionalen Sicherheit (Safety plan)
Der Safety-Plan enthält die zur Sicherstellung der Funktionalen Sicherheit erforderliche Aufbau- und Ablaufplanung (Phasen, Meilensteine, Verant-wortlichkeiten, Dokumente) hinsichtlich:
� Strategien und Aktivitäten
� Schnittstellenabstimmung mit Lieferanten
© Fraunhofer
� Unterstützende Prozesse
� Gefahren- und Risikoanalyse
� Entwicklung und Umsetzung der Sicherheitsanforderungen
� Sicherheitsanalysen
� Verifikation und Validation
� Dokumentation der durchgeführten Maßnahmen
� Unabhängigkeit der Bestätigung der durchgeführten Maßnahmen
Funktionale SicherheitSicherheits-Lebenszyklus (safety lifecycle)
Item definition3-5
Initiation of thesafety lifecycle3-6
Hazard analysisand risk assessment3-7
Functional safetyconcept3-8
Conce
pt phase
Pro
duct developm
ent
© Fraunhofer
ProductdevelopmentSystem level
4
Release for production4-11
Production7-5
Operation, service anddecommissioning7-6
Hardwarelevel
5
Softwarelevel
6
Operationplanning7-6
Productionplanning7-5
Other technologies
Controllability
Externalmeasures
Back to appropiatelifecycle phase
Pro
duct developm
ent
After SOP
Quelle: ISO/DIS 26262-2
Product development at system level
Funktionale SicherheitAnforderungen der ISO 26262-4Produktentwicklung auf Systemebene
Initiation of productdevelopment on system level4-5
Spezification of thetechnical safety requirements4-6
System design4-7
4
© Fraunhofer
Item integration and testing4-8
Safety validation4-9
Functional safety assessment4-10
Product developmentat Hardware level
5 Product developmentat Software level
6
Release for production4-11
Quelle: ISO/DIS 26262-4
Product development at hardware level
Funktionale SicherheitAnforderungen der ISO 26262-5Produktentwicklung auf Hardwareebene
Initiation of productdevelopment at hardware level5-5
Specification ofhardware safety requirements5-6
5
System design4-7
© Fraunhofer
Hardware design5-7
Hardware integrationand testing5-10
Quelle: ISO/DIS 26262-5
Hardware architectural metric5-8
Evaluation of violation of safetygoal due to random HW failures5-9
Production and operation5-7
Qualification ofhardware components8-13
Item integration and testing4-8
Funktionale SicherheitISO 26262-5, Annex CZufällige Hardwarefehler
� Single point fault (SPF)Abweichung, die durch keinen Sicherheitsmechanismus abge-deckt ist und sofort zur Verletzung eines Sicherheitsziels führt
� Residual fault (RF)Teil einer Abweichung, der nicht durch einen Sicherheits-mechanismus abgedeckt wird und welcher zur Verletzung eines Sicherheitsziels führt
© Fraunhofer
eines Sicherheitsziels führt
� Multiple point fault (MPF)Abweichung unter mehreren unabhängigen Abweichungen, welcher in Kombination zu einem Mehrfachfehler führt
� Perceived (MPF P)bemerkt
� Detected (MPF D)entdeckt
� Latent (MPF L)schlafend
Quelle: ISO/DIS 26262-5
Funktionale Sicherheit Fault-Metriken und gefahrbringende AusfälleISO 26262-5, Annex E und G, Zielwerte
PFH = λ + λ + λ
ASIL SPFM LFM
A - -
B ≥ 90% ≥ 60%
C ≥ 97% ≥ 80%
D ≥ 99% ≥ 90%
© Fraunhofer
PFH = λSPF
+ λRF+ λ
LMPF
PFH: Probability of dangerous failure per hour
LFM: Latent Faults Metric
SPFM: Single Point Faults Metric
MPF: Multiple Point Fault
S: Safe
D ≥ 99% ≥ 90%
ASIL PFH
A < 10-6
B < 10-7
C < 10-7
D < 10-8
Funktionale SicherheitISO 26262-5, Annex D (informative)Ermittlung von Diagnosedeckungsgraden (DC)
Ermittlung und Realisierung der Diagnosedeckungsgrade kann auf Basis von Empfehlungen der ISO/DIS 26262-5, Annex D (Tabelle 1-12 und Erläuterung D 2.1-D 2.11) erfolgen (z.B. ROM und Block replication)
© Fraunhofer
Quelle: ISO/DIS 26262-5
Funktionale SicherheitErmittlung der Fehlermodi und Fehlerraten von Systemelementen
Ermittlung der Fehlermodi und FIT-Werte von Systemelementen:
� Literatur zur Zuverlässigkeit (z.B. Birolini)
� Firmennormen (z.B. SN 29500)
� Zuverlässigkeitshandbücher
© Fraunhofer
� Zuverlässigkeitshandbücher (z.B. MIL-Handbook 217)
� Datenblätter
� Felderfahrungswerte
Funktionale SicherheitErmittlung der Fehlermodi und Fehlerraten von Systemelementen
© Fraunhofer
Quellen:SN 29500-4 (2004)
Birolini (2007)
Fehlermodi für Widerstände aus Birolini:Open = 40%Drift = 60%
Funktionale SicherheitErmittlung der Fehlerraten komplexer Systemelemente
Verfahren zur Aufteilung von FIT-Werten bei komplexen Bauteilen:
� 50/50-Aufteilung
� Aufteilung auf Funktionsgruppen
� Aufteilung nach Chipflächen
© Fraunhofer
� Aufteilung nach Chipflächen
� Aufteilung nach Empfehlungen (z.B. Birolini, SN 29500)
Bildquelle: www.kurz-elektronik.de
Funktionale SicherheitAnforderungen der ISO 26262-6Produktentwicklung auf Softwareebene
System design4-7
Specification ofsoftware safety requirements6-6
Design phase verification
Item integration and testing4-8
Verification ofsoftware safety requirements6-11
Software testing
Test phase verification
Itemtesting
Test phase verification
© Fraunhofer
Quelle: ISO/DIS 26262-6
Software architectural design6-7
Software unit design and implementation6-8
Design phase verification
Design phase verification
Software integrationand testing6-10
Software unit testing6-9
Software testing
Test phase verification
Software testing
Test phase verification
verification
© Fraunhofer
METHODEN ZUR ANALYSE MECHATRONISCHER SYSTEME
Methoden zur Analyse mechatronischer Systeme
Methoden zur SIL-Klassifizierung
� Gefahren- und Risikoanalyse
� Risikograph
Methoden zur Analyse systematischer Fehler
© Fraunhofer
Methoden zur Analyse systematischer Fehler
� Fehlermöglichkeits- und Einflussanalyse (FMEA)
� Fehlerbasierte System-Reaktionsanalyse (FSR)
Methoden zur Analyse zufälliger Fehler
� Fehlermöglichkeits-, Einfluss- und Diagnoseanalyse (FMEDA)
Gefahren- und Risikoanalyse
Zielsetzung:
� Systematische Ermittlung potentieller Gefahren-und Risiken des Systems
Methodisches Vorgehen:
� Definition der Hauptfunktionen des Systems
© Fraunhofer
� Definition der Hauptfunktionen des Systems
� Ermittlung der potentiellen Fehlfunktionen
� Ermittlung der Gefahren und Risiken
Nutzen/Anmerkung:
� Frühzeitige Durchführung
� Betrachtung unabhängig vom Sicherheits-konzept (Grundlage für Sicherheitskonzept)
� Voraussetzung zur (A)SIL-Einstufung
Risikograph zur ASIL-Klassifizierung nach ISO/DIS 26262
C0 C1 C2 C3
S0 E0 – E4 QM QM QM QM
S1
E0 QM QM QM QM
E1 QM QM QM QM
E2 QM QM QM QM
E3 QM QM QM A
E4 QM QM A B
S2
E0 QM QM QM QM
E1 QM QM QM QM
E2 QM QM QM A
Zielsetzung:
� Systematische Ermittlung des ASIL-Levels auf Basis der Gefahren- und Risikoanalyse
Methodisches Vorgehen:
� Bestimmung des ASIL-Levels anhand
ControllabilityControllabilityControllabilityControllability CCCCExposureExposureExposureExposure EEEE
Severity S
Severity S
Severity S
Severity S
© Fraunhofer
E3 QM QM A B
E4 QM A B C
S3
E0 QM QM QM QM
E1 QM QM QM A
E2 QM QM A B
E3 QM A B C
E4 QM B C D
� Bestimmung des ASIL-Levels anhand
� der Schwere (Severity)
� der Häufigkeit des Ausgesetztseins (Exposure)
� der Beherrschbarkeit (Controllability)
Nutzen/Anmerkung:
� Systematisches und nachvollziehbares Vorgehen
Severity S
Severity S
Severity S
Severity S
[nach ISO DIS 26262]
Gefahren- und Riskoanalyse Risikograph zur ASIL-Klassifizierung nach ISO/DIS 26262
Schwere (Severity)S0: keine VerletzungsgefahrS1: geringe und mäßige VerletzungenS2: ernste und möglicherweise tödliche VerletzungenS3: schwere und wahrscheinlich tödliche Verletzungen
Häufigkeit des Ausgesetztseins (Exposure)E1: selten: Situation tritt für die meisten Fahrer seltener
als einmal pro Jahr aufE2: gelegentlich: Situation tritt für die meisten Fahrer
Controllability CControllability CControllability CControllability CExposure EExposure EExposure EExposure E
C0 C1 C2 C3
S0 E0 – E4 QM QM QM QM
S1
E0 QM QM QM QM
E1 QM QM QM QM
E2 QM QM QM QM
E3 QM QM QM A
© Fraunhofer
E2: gelegentlich: Situation tritt für die meisten Fahrer wenige Male pro Jahr auf
E3: ziemlich oft: Situation tritt für Durchschnittsfahrer einmal im Monat oder öfter auf
E4: oft: Situation die bei nahezu jeder Fahrt auftritt
Beherrschbarkeit (Controllability)C1: einfach beherrschbar: mehr als 99% der Fahrer oder der
anderen Verkehrsteilnehmer können den Schaden üblicherweise abwenden
C2: durchschnittlich beherrschbar : mehr als 90% der Fahrer oder der anderen Verkehrsteilnehmer können den Schaden üblicherweise abwenden
C3: schwierig oder gar nicht beherrschbar :weniger als 90% der Fahrer oder der anderen Verkehrs-teilnehmer können den Schaden üblicherweise abwenden
Severity S
Severity S
Severity S
Severity S
[nach ISO/DIS 26262]
E3 QM QM QM A
E4 QM QM A B
S2
E0 QM QM QM QM
E1 QM QM QM QM
E2 QM QM QM A
E3 QM QM A B
E4 QM A B C
S3
E0 QM QM QM QM
E1 QM QM QM A
E2 QM QM A B
E3 QM A B C
E4 QM B C D
Fehlermöglichkeits- und Einflussanalyse (FMEA)
Zielsetzung:
� Systematische Ermittlung potentieller Fehl-funktionen für die Komponenten des Systems
Methode nach VDA 4 Kapitel 3 (2006):
1: Strukturanalyse (Strukturbaum)
1.
2.
© Fraunhofer
1: Strukturanalyse (Strukturbaum)2: Funktionsanalyse (Funktionsnetze)3: Fehleranalyse (Fehlernetze)4: Maßnahmenanalyse und Bewertung5: Optimierung (falls notwendig)
Nutzen/Anmerkung:
� Detaillierte Übersicht über Fehlfunktionen
� Maßnahmenplan für sichere Systemauslegung
� Präzise Benennung der Fehlfunktionen
3.
4.
5.
Mögliche Systemstruktur eines mechatronischen Systems
© Fraunhofer
Mögliche Maßnahmenstruktur eines mechatronischen Systems
Maßnahmen zur Vermeidungin der Entwicklung
Maßnahmen zur Entdeckungin der Entwicklung
Software-Requirements zur Überführung in sicheren Zustand
© Fraunhofer
Überführung in sicheren Zustand
Maßnahmen zum Test der korrekten Software-Funktion
Maßnahmen zur Entdeckungim Gesamtsystem
Maßnahmen zur Entdeckungim Service
Maßnahmen zur Entdeckungim Betrieb
Analyse und Bewertung von Fehlfunktionen, Fehlererkennungen und Fehlerreaktionen im Betrieb
© Fraunhofer
Quelle: Workshop B, XVI.-APIS-Benutzertreffen (2010)
Analyse und Bewertung von Fehlfunktionen, Fehlererkennungen und Fehlerreaktionen im Betrieb
© Fraunhofer
Quelle: Workshop B, XVI.-APIS-Benutzertreffen (2010)
Analyse und Bewertung von Fehlfunktionen, Fehlererkennungen und Fehlerreaktionen im Betrieb
Häufigkeit A
© Fraunhofer
2. Fehler-reaktion
1. Fehler-erkennung
Schadensausmaß B
A=1
Fehlerbasierte System-Reaktionsanalyse (FSR)
Zielsetzung:
� Analyse der Diagnose- und Absicherungs-maßnahmen auf systematische Fehler
Methode:
� Übernahme der Fehlfunktionen aus der System-
© Fraunhofer
� Übernahme der Fehlfunktionen aus der System-FMEA für alle beteiligten Komponenten
� Bewertung der Entdeckbarkeit von Ausfallarten unter Berücksichtigung von nutzerbedingten Interaktionen und Systemzuständen
Nutzen/Anmerkung:
� Hinweise auf „schlafende Fehler“ im System
� Kompakte Darstellung komplexer Systeme
Failure Modes, Effects and Diagnostic Analysis (FMEDA)
Zielsetzung:
� Analyse der Fehlermodi der an der Sicherheits-funktion beteiligten Komponenten
Methode:
� Auflistung aller Fehlerarten der an der Sicher-FMEDA
Komponenten derSicherheitsfunktion
© Fraunhofer
� Auflistung aller Fehlerarten der an der Sicher-heitsfunktion beteiligten Komponenten
� Bewertung der Abweichungen/Ausfälle
� Ermittlung der Fehlerraten
Nutzen/Anmerkung:
� Tabellarisches Verfahren zur Vorbereitung der Berechnung der FuSi-Parameter (z.B. PFH, Fault-Metriken)
FMEDA
© Fraunhofer
AUSLEGUNG / ABSICHERUNGMECHATRONISCHER SYSTEME
Auslegung und Absicherung von mechatronischen Systemen
Konzept
AnalyseSystem-FMEA
Gesamtsystemkonzept
Systemkonzept Diagnosekonzept
(System + Diagnose)
© Fraunhofer
Test Betrieb
AnalyseGefahren- und Risikoanalyse,SIL-Einstufung
System-FMEA- Systemkonzept- Diagnosekonzept
FME(D)A / IEC-Par.
FehlerbasierteSystem-Reaktions-
analyse (FSR)
Ergänzende Informationen- Betrieb- Service
Testplan für Gesamtsystem- Hardware (Zuverlässigkeit)- Software (korrekte Funktion)- Betrieb (sichere Information)
SIL-KlassifizierungSicherheitsfunktion
RisikographIEC 61508
ISO DIS 26262
Unterstützung der Analysen zur Funktionalen SicherheitG-u. R.-Analyse
+ SIL-Klassen
> Ist )
- Fault-Metrik-Bereiche- PFH-Bereiche
Vorgabe-Werte f(HWFT)
Entwicklung des Sicherheitskonzeptes
© Fraunhofer
FMEDAund
Berechnungs-verfahren
System-FMEA
K-FMEA
FSR- System- Diagnose
+ SIL-Parameter
Verg
leich ( Vorg
abe <-> Ist )
Systemkonzept (HWFT)
Testplan
Wartungsplan
Diagnosekonzept
Betriebsanleitung
Entwicklung des Zuverlässigkeitskonzeptes
Ist-Werte- DC- PFH- Fault-Metrik
Testplan
Diagnosekonzept
APIS IQ-RM-X 6.0
Zusammenhang zwischen den eingesetzten Methoden
Systemarchitekturund Funktions-
block-Diagramm
Bauteil-informationen(z.B. SN 29500)
Failure ModesFIT-Werte
Komponenten Funktionen
FehlerbasierteSystemreaktions-
Analyse (FSR)
Komplexe Fehlerfälle
DCSoftware-Konzepte und Algorithmen
© Fraunhofer
FMEA
EinfacheFehlerfälle
SIL 2
FMEDA undBerechnungs-
verfahren
FuSi-Parameter:Fault-Metrikenund PFH-Werte
DCSoftware-Konzepte und Algorithmen
© Fraunhofer
ERLÄUTERUNG ANHAND EINES BEISPIELSYSTEMS
Beispielsystem (Fahrzeug zufällig gewählt)
© Fraunhofer
1965 20xx ?
Quelle: http://www.automobilrevue.de/detroit2002.htmQuelle: http://www.imcdb.org
Gefahren- und Risikoanalyse
Hauptfehlfunktion Hauptfunktion
© Fraunhofer
Möglicher Risikograph gemäß ISO DIS 26262
C0 C1 C2 C3
S0 E0 – E4 QM QM QM QM
S1
E0 QM QM QM QM
E1 QM QM QM QM
E2 QM QM QM QM
E3 QM QM QM A
E4 QM QM A B
S2
E0 QM QM QM QM
E1 QM QM QM QM
E2 QM QM QM A
E3 QM QM A B
Fehlfunktionen und Auswirkungen aus der
Gefahren- und Risikoanalyse
FahrzeugGeöffnete Fahr-zeugtüre verletzt Passanten am
PortaltüreFondtürelässt sich bei v > 4 km/h von
© Fraunhofer
E3 QM QM A B
E4 QM A B C
S3
E0 QM QM QM QM
E1 QM QM QM A
E2 QM QM A B
E3 QM A B C
E4 QM B C D
Passanten am Straßenrand
v > 4 km/h von innen öffnen
Severity – S:S2: Schwere Verletzungen, lebensbedrohlich, Überleben wahrscheinlich
Exposure – E:E4: hohes bzw. ständiges Auftreten
Controllability – C:C2: durchschnittlich kontrollierbar: mehr als 90% der Fahrer bzw. Verkehrsteilnehmer können den Schaden üblicherweise abwenden
ASIL BPFH < 10-7
Gefahren- und Risikoanalyse
© Fraunhofer
© Fraunhofer
ANALYSE SYSTEMATISCHER FEHLER
Mögliche Systemstruktur einer „Portaltüre“
Diagnosesystem (Sensorik)
© Fraunhofer
Systemkomponente (Aktorik)
Informationsschnittstelle (Input)
Mögliches Funktionsnetz einer „Portaltüre“
Funktion an System-komponente (Aktorik)
© Fraunhofer
Funktion am Diagnosesystem (Sensorik)
Funktion an der Informations-schnittstelle (Input)
Hauptfunktion des Systems
Mögliches Fehlernetz einer „Portaltüre“
Fehlfunktion an System-komponente(Aktorik)
© Fraunhofer
Fehlfunktion an der Informations-schnittstelle (Input)
ASIL B bzw. SIL2Fehlfunktion des System
Fehlfunktion am Diagnosesystem (Sensorik)
Mögliches Fehlernetz einer „Portaltüre“
© Fraunhofer
Fehlfunktion an der Informations-schnittstelle (Input)
ASIL B bzw. SIL2Fehlfunktion des System
Mögliches Formblatt einer „Portaltüre“
© Fraunhofer
Sichere Verriegelung bei Fehlfunktion an der Informations-schnittstelle (Input) und sichere Infor-mation des Fahrers.
Mögliches Formblatt einer „Portaltüre“
© Fraunhofer
Überprüfung auf der Test Bench, ob die Software beim Auftreten der Fehlfunktion korrekt reagiert.
Mögliches Fehlernetz einer „Portaltüre “
© Fraunhofer
ASIL B bzw. SIL2Fehlfunktion des System
Fehlfunktion am Diagnosesystem (Sensorik)
Mögliches Formblatt einer „Portaltüre “
Keine Erkennung der Fehlfunktion
© Fraunhofer
der Fehlfunktion an der Sensorikim Betrieb und keine Informationdes Fahrers
Mögliche FSR eines Diagnosesystems der „Portaltüre“
© Fraunhofer
Mögliches Formblatt einer „Portaltüre “
© Fraunhofer
Sichere Fehler-erkennung an der Sensorik bei Zündung an und Information des Fahrers
Keine Erkennung der Fehlfunktion an der Sensorikim Betrieb und keine Informationdes Fahrers
Mögliche FSR eines Diagnosesystems der „Portaltüre“
© Fraunhofer
Mögliches Formblatt einer „Portaltüre “
© Fraunhofer
Sichere Fehler-erkennung an der Sensorik im Betrieb und Information des Fahrers
Mögliche FSR eines Diagnosesystems der „Portaltüre“
© Fraunhofer
Mögliches Formblatt einer „Portaltüre “
Nachweis
© Fraunhofer
Nachweis erbracht!Sichere Fehler-erkennung an der Sensorik im Betrieb und Information des Fahrers
Fehlererkennung / Fehlerreaktion im System „Portaltüre“
© Fraunhofer
2. Fehlerreaktion 1. Fehlererkennung
© Fraunhofer
ANALYSE ZUFÄLLIGER FEHLER
FuSi-Kennwerte anhand von Fehlernetzen und Ausfall-raten bis auf die Ebene der elektr(on)ischen Bauteile
FIT = Failure in TimeAusfallrate technischer Komponenten (Anzahl der Bauteile, welche in 109 Stunden ausfallen).
1 FIT = 1 Ausfall in ca. 114.000 Jahren
λ_open = 0,05 FITλ_short = 0,02 FITλ_drift = 0,03 FIT
Portaltüre
© Fraunhofer
FuSi-Kennwerte
Fault-Klassifizierung
Fault
Ist die Komponente an einer sicher-heitsbezogenen
Funktion beteiligt?
Unberück-sichtigterSafe Fault
Kann der Defekt in Abwesen-heit von Sicherheits-mechanismen das Sicherheitsziel verletzen?
Ist ein Sicher-heitsmechanismusimplementiert, der eine Verletzung des Sicherheitsziels verhindert?
Kann der Defekt mit einem
weiteren unabhäng-igen Defekt in einer anderen Komponente zu einer Verletzung des Sicherheitsziels
führen?
Gibt es Sicherheits-mechanismen, die andere Fehler der
gleichen Komponente abfangen?
Safe Fault
Single Point Fault
N
N
N
J
N
N
J
J
© Fraunhofer
verhindert?
Residual Fault
Wird der Defekt entdeckt?
Multiple Point Fault
DetectedMultiple
Point Fault
Wird der Defekt vom Fahrer wahrgenommen?
Latent Multiple
Point Fault
PerceivedMultiple
Point Fault
NN
J
J
J
J
Potentielle Fehlfunktionen der Komponenten FMEDA
Detected Latent Preceived
Spannungsversorgung µC 100,00 40,00 0,00 16,04 43,80 0,08 0,08
Quarz 5,00 0,00 0,00 4,46 0,50 0,02 0,02
Relais 300,00 224,78 0,30 0,00 74,18 0,37 0,37
Taster 40,00 19,80 0,40 0,00 0,00 9,90 9,90
HW-Watchdog 10,00 0,00 0,00 0,00 0,10 9,85 0,05
µC 25,00 12,50 12,38 0,00 0,00 0,06 0,06
µC-ROM 25,00 0,00 0,00 0,00 24,75 0,25 0,00
Multiple Point Fault
Systemkomponenten
FIT
(10-9
)
DC 1
(%)
Safe
Fault
Single Point
Fault
Residual
Fault
DC 2
(%)
© Fraunhofer
µC-ROM 25,00 0,00 0,00 0,00 24,75 0,25 0,00
µC-RAM 25,00 12,50 0,00 0,00 12,38 0,12 0,00
µC-I/O 25,00 12,50 12,38 0,00 0,00 0,06 0,06
µC-Watchdog 25,00 0,00 0,00 0,00 0,00 25,00 0,00
Summe 580,00 322,08 25,45 20,49 155,70 45,73 10,55
Gefahrbringende Ausfälle/Stunde 91,67
Single Point Fault Metric 92,1%
Latent Fault Metric 91,4%
< 10-7
(erfüllt)
≥ 90% (erfüllt)
≥ 60% (erfüllt)
© Fraunhofer
FAZIT
Fazit
Bewertung
Funktionale Sicherheit stellt eine neue Herausforderung an das technische Risikomanagement dar (von Industrie geschätzter Mehraufwand 10-20%)
Voraussetzungen zur Sicherstellung der funktionalen Sicherheit sind
© Fraunhofer
Voraussetzungen zur Sicherstellung der funktionalen Sicherheit sind
� Funktionierende Managementsysteme (z.B. TS 16949, SPICE, CMMI)
� Organisatorische Erweiterungen für das Safety Management entsprechend den Anforderungen der IEC 61508 bzw. ISO/DIS 26262
� Detaillierte und präzise Systemanalysen durch den OEM sowie effektives Schnittstellenmanagement/Kommunikation mit den Lieferanten
� Integrierte Anwendung vorhandener technischer Risikoanalysen
� Kritische Betrachtung der Risiken unabhängig von Zahlenwerten
Funktionale SicherheitLiteraturempfehlung
© Fraunhofer
Vielen Dank für IhreAufmerksamkeit !
Vielen Dank für IhreAufmerksamkeit !
No risk – no fun !
© Fraunhofer
Bildquelle: http://www.extr3m3.de/