5.1 verlässlichkeitsmodellierung wintersemester 2018/2019 ... · not use radio comms 9 phone comms...
TRANSCRIPT
Verlässliche SystemeWintersemester 2018/2019
Verlässliche Systeme
5. KapitelQualitative Analyse
Christine JakobsProfessur Betriebssysteme
Verlässliche Systeme – Qualitative Analyse5.1 Verlässlichkeitsmodellierung
5.1 Verlässlichkeitsmodellierung
I Verlässlichkeit ist eine Sammelbegriff für eine Menge nicht-funktionellerAnforderungen
I Fragen an geplantes / existierendes SystemI Wann wird es ausfallen?I Wie oft wird es ausfallen?I Gibt es Schwachstellen in der Architektur?I Was passiert in einer Fehlersituation?
I Reale System sind bei Weitem zu komplex, um direkte Antworten auf diese Fragenzu ermöglichen
I Erstellung eines Modells zur Reduktion von InformationenI Ein Modell ist immer „von etwas“ und „für etwas“
WS 2018/19 · C. Jakobs 2 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.1 Verlässlichkeitsmodellierung
Verlässlichkeitsmodellierung
WS 2018/19 · C. Jakobs 3 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.1 Verlässlichkeitsmodellierung
Verlässlichkeitsmodellierung (Forts.)
I Modellierung ist grundsätzlich der Prozess der InformationsreduktionI I0: Externer allmächtiger Beobachter (theoretisches Konzept)I I1: Menge aller Informationen, die man theoretisch sammeln kannI I2: Messung und Untersuchung führt zu verfügbaren InformationenI I3: Explizite Reduktion der Menge der genutzten InformationenI M : Kreative Abbildung in ein Modell
R
�TT`2?2MbB#H2BM7Q`K�iBQM
UI1V
�HHBM7Q`K�iBQM
UI0V
�p�BH�#H2BM7Q`K�iBQM
UI2V
lb2/BM7Q`K�iBQM
UI3VJQ/2HUMV
fB fKJ�TTBM;
WS 2018/19 · C. Jakobs 4 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.1 Verlässlichkeitsmodellierung
Verlässlichkeitsmodellierung (Forts.)
I Modelle können als visuelle Beschreibunghilfreich sein
I Modellparameter: Offene Fragen an dasSystemI „*“ -Kardinalität in UML ModellenI Übergangswahrscheinlichkeiten in
ZustandsmodellenI Kann festgelegt oder später eingegrenzt
werden (Implementierung, Simulation,Experiment)
I Modellanalyse: Generierung einesRückschlusses aus der Beschreibung
I Verlässlichkeitsanalyse: Rückschlusshinsichtlich Verlässlichkeitsaspekten
WS 2018/19 · C. Jakobs 5 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.1 Verlässlichkeitsmodellierung
Analyse
I Induktive AnalyseI Ausgehend von Spezialfall („temperaturbedingter Bitflip im Speicher“))I Ziel ist eine allgemeine Lösung („Systemzuverlässigkeit in 2 Jahren ist 0.87“)
I Deduktive AnalyseI Ausgangspunkt ist Ausfall („Flugzeugabsturz, 200 Tote“)I Von da aus rückwärts nach Ursache suchen („eingefrorener
Geschwindigkeitssensor?“)I Qualitative Analyse
I Untersuchung struktureller Eigenschaften, ignorieren von ModellparameternI Quantitative Analyse
I Numerische Werte an Modellparameter zuweisen, Berechnung von Resultaten
WS 2018/19 · C. Jakobs 6 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.2 Qualitative Verlässlichkeitsanalyse
5.2 Qualitative Verlässlichkeitsanalyse
I Qualitative Modellierung von VerlässlichkeitI Fokus auf strukturellen Abhängigkeiten und BeziehungenI Approximieren oder ignorieren von numerischen Modellparametern
I Bevorzugter Ansatz in der IndustrieI Keine Notwendigkeit für Vertrauen in WahrscheinlichkeitenI Anwendung in frühen EntwurfsphasenI Modellerstellung passt ganz natürlich in den strukturierten
Entwicklungsprozess(Anforderungen á Entwurf á Implementation á Test á . . . )
I Von Standards zu Sicherheitszertifizierung erfordert
WS 2018/19 · C. Jakobs 7 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.2 Qualitative Verlässlichkeitsanalyse
Root Cause Analysis (RCA)
I Sammelbegriff für Ansätzeder deduktiven Analyse
I Frage: Was kann/hat einenAusfall verursacht?I Ebene für Ebene
zurückziehenI Systematisch als
Untersuchungdurchgeführt
I Hilft eine plausibleTimeline der Ereignissefestzulegen
R
BM�+iBp27�mHi
BMi2`M�H7�mHi
�+iBp�iBQM
2ti2`M�H7�mHi
2``Q` 7�BHm`2Q`B;BM
2ti2`M�H7�mHi2``Q`
T`QT�;�iBQM7�BHm`2 Q`B;BM
bvbi2K7�BHm`2
2ti2`M�H BMi2`7�+2
BMi2`M�H BMi2`7�+2
WS 2018/19 · C. Jakobs 8 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.2 Qualitative Verlässlichkeitsanalyse
Root Cause Analysis (RCA) (Forts.)
I Interativer ProzessI Kann reaktiv oder pro-aktiv durchgeführt werden
I Findet in verschiedenen Bereichen Anwendung, unterschiedliche Definitionen undVerständnisseI Unfallanalyse in sicherheitskritischen Systemen, z.B. LuftfahrtindustrieI Qualitätskontrolle in industrieller FertigungI Ausfallanalyse für Hardwarekomponenten
I Typischerweise wird angenommen, dass man etwas reparieren kann (defekterProzess, veränderbare Ursache)
I Diskussion von Beispielen: Fishbone, WBG, FMEA, HAZOPS
WS 2018/19 · C. Jakobs 9 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.3 Hazard & Operability Studies (HAZOPS)
5.3 Hazard & Operability Studies (HAZOPS)
I Prozess zur Identifikation potentieller Gefahren & Bedienproblemen, die vonAbweichungen von der Designabsicht herrührenI Unterscheidung zwischen Abweichung (Ausfall) und Ursache (Fault)I Durchführung beabsichtigt Funktionalität auf sicherste und effektivste ArtI Initial für Untersuchungen in der chemischen Industrie entwickelt, mittlerweile
in Erdöl-, Nahrungs- und WasserindustrieI Ausdehnung auf komplexe (Software) Systeme
I Qualitative TechnikI Nimm Beschreibung eines Prozesses und stelle systematisch jeden Teil in
FrageI Beurteilung möglicher Abweichungen und deren KonsequenzenI Basiert auf Leitworten und multi-disziplinären Meetings
WS 2018/19 · C. Jakobs 10 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.3 Hazard & Operability Studies (HAZOPS)
Hazard & Operability Studies (HAZOPS)I Zuerst Systementitäten und deren Attribute identifizieren (z.B.
Zustandsdiagramme)I Nutze Schlüsselworte, um Aufmerksamkeit zu bündeln
I Primäre Schlüsselworte - Aufmerksamkeit auf bestimmte Aspekte derEntwurfsintention / Prozessbedingungen / untersuchten ParameterI Beispiele für Kraftwerke:
flow, pressure, react, corrode, temperature, level, mix, absorb, erode, . . .isolate, vent, inspect, start-up, shutdown, purge, maintain, . . .
I Beispiele für Java-Sprachdefinitionsanalyse:Type default value, type value range, name scope, class modifier, classname, field modifier, field type, method modifier, method name, formalparameter, . . .
I Sekundäre Schlüsselworte - Suggeriert mögliche Abweichungen des Systemsvon der Entwurfsabsicht, wenn mit primärem Schlüsselwort kombiniertI Standardisierte Liste, nicht alle Kombinationen sind angemessen
WS 2018/19 · C. Jakobs 11 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.3 Hazard & Operability Studies (HAZOPS)
Kraftwerksbeispiel - Sekundäre SchlüsselworteWord Meaning
No The design intent does not occur (e.g. Flow/No), or the operational aspect is not achievable (Isolate/No)
Less A quantitative decrease in the design intent occurs (e.g. Pressure/Less)
More A quantitative increase in the design intent occurs (e.g. Temperature/More)
Reverse The opposite of the design intent occurs (e.g. Flow/Reverse)
Also The design intent is completely fulfilled, but in addition some other related activity occurs (e.g. Flow/Also indicating contamination in a product stream)
Other The activity occurs, but not in the way intended (e.g. Flow/Other could indicate a leak or product flowing where it should not)
Fluctuation The design intention is achieved only part of the time (e.g. an air-lock in a pipeline might result in Flow/Fluctuation)
EarlyUsually used when studying sequential operations, this would indicate that a step is started at the wrong time or done out of sequence
Late
WS 2018/19 · C. Jakobs 12 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.3 Hazard & Operability Studies (HAZOPS)
Kraftwerksbeispiel - Kombinationen
WS 2018/19 · C. Jakobs 13 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.3 Hazard & Operability Studies (HAZOPS)
Java-Beispiel - Sekundäre SchlüsselworteWord Meaning
No No part of the intention is achieved. No use of syntactic components
More A quantitative increase, the data value is too high (within or out of bounds)
Less A quantitative decrease, the data value is too low (within or out of bounds)
As Well As Specific design intent is achieved but with additional results
Part Of Only some of the intention is achieved, incomplete
Reverse Reverse flow - flow of information in wrong direction, iteration count modified in wrong direction, logical negation of condition
Other Than A result other than the original intention is achieved, complete but incorrect
Narrowing Scope or accessibility is narrower than intended.
Widening Scope or accessibility is enlarged
Equivalent The same design intent is achieved in a different way (without any side effect)
WS 2018/19 · C. Jakobs 14 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.3 Hazard & Operability Studies (HAZOPS)
HAZOPS-Verfahren
WS 2018/19 · C. Jakobs 15 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.3 Hazard & Operability Studies (HAZOPS)
HAZOPS-Dokumentation
I Systematische Anwendung aller relevanten Kombinationen von Schlüsselwortenauf den Entwurf
I Pro Kombination, ein EintragI Abweichung (Schlüsselwortkombination)I Ursache (potentielle Ursache für die Abweichung)I Konsequenz (der Abweichung und der Ursache)
I Sollte nicht für Schutzmechanismen oder -designinstrumenteverantwortlich gemacht werden, da zu diesem Zeitpunkt nicht alleAusführungsbedingungen klar sind
I Sicherungen (verhindern die Ursache oder schützen das System gegen sie )I Kann Hardware, Software oder Prozeduren sein
I Aktionen (entweder Ursache entfernen oder Konsequenzen abschwächen)
WS 2018/19 · C. Jakobs 16 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.3 Hazard & Operability Studies (HAZOPS)
HAZOPS für Java-Sprachspezifikation
WS 2018/19 · C. Jakobs 17 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.4 Why-Because-Graph
5.4 Why-Because-Graph
I In den 90ern von Peter B. Ladkin entwickeltI Hauptsächliche für Unfallanalyse in Luftfahrtindustrie entwickeltI Explizite Einschränkung auf Zustände, Ereignisse und deren KausalbeziehungI Definition einer graphischen Notation und entsprechender formaler SemantikI Schritt 1: Aufzeigen kausaler Beziehungen im Fehlerraum
I Jeder Knoten ist ein KausalfaktorI Jede Kante ist eine Ursache-und-Effekt-BeziehungI Resultierender Graph ist eine gerichteter azyklischer why-because-graph
(WBG)
WS 2018/19 · C. Jakobs 18 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.4 Why-Because-Graph
Why-Because-Graph
0Indian Pacific
delayed at end ofblock
7Indian Pacific does
not use radiocomms
9Phone comms
failure
10Required
communicationsprocedures
16Phone comms
time-consuming
1Interurban train
collides with IndianPacific at end of
block
11Interurban train
proceeds into block
12Interurban train failsto halt upon driver
sighting IndianPacific
2Interurban train
driver proceeded atup to 50 kph,
omitting to exerciseextreme caution
3Interurban train
driver believed thatblock clear
5Rule 245 did not
guide operations asintended
4Signaller issues
permission to enterblock
6Signal failure
8Lack of train
indicator board
13Signaller believes
block clear
15Phone technology
unreliable
14Signaller fails to
determine locationof previous train to
have passedsignal, the Indian
Pacific
17Inappropriate phone
technology
Fig. 3. The Glenbrook WB-Graph with all Specific Causes (WBG-SC)
4
WS 2018/19 · C. Jakobs 19 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.4 Why-Because-Graph
Why-Because-Graph (Forts.)
I Schritt 2: Analysiere Abhängigkeiten zwischen Faktoren mit ModallogikI Basiert auf der Idee des kontrafaktischen Konditionals
I „Wenn die Software die Eingabe E bekommen würde, dann würde sieabstürzen.“
I Es wird angenommen, dass das „Wenn“ nicht eintrittI Wenn es passiert, dann tritt unter Garantie das „Dann“ ein
I Test mit kontraktischem Test (Dawid Lewis 1975, philosophical logician)I Wenn die Ursache nicht existiert, hätte der Effekt dann eintreten können?I Naheliegendste Weltannahme: Nur „Wenn“-Bedingung ändert sich und nichts
sonstI Wenn der Effekt nicht eintritt, dann ist die Ursache ein necessary causal
factor (NCF)I Wenn alle WBG-Knoten NCSs sind, dann sind alle Blätter notwendige Root Causes
WS 2018/19 · C. Jakobs 20 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
5.5 Failure Mode and Effect Analysis (FMEA)
I Methode der Qualitätssicherung in frühen EntwurfsphasenI In den späten 1940ern für militärische Anwendungen eingeführt (MIL-P-1629)
I Später auch für Raumfahrt, Fahrzeugindustrie, Halbleiterverarbeitung,Softwareentwicklung, Gesundheitswesen, . . .
I Hauptziel ist Identifikation und Prävention von kritischen AusfällenI Von bereichsübergreifendem Team von Experten ausgeführtI Wichtigster Schritt in vielen Zuverlässigkeitsprogrammen
I Six Sigma certification, reliability-centered maintenance (RCM)I Automotive industry (ISO16949, SAE J1739)I Medizingeräte
WS 2018/19 · C. Jakobs 21 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Failure Mode and Effect Analysis (FMEA)
I Hauptannahme: System kann in Ausfallmodi ausgeführt werdenI Beispiel: elektrischer Kurzschluss, Korrosion, Deformation
I Identifizierung relevanter Ausfallmodikandidaten aufgrund vergangener ErfahrungI Analyse der Effekte
I Was passiert mit der Funktionalität, die der Nutzer sieht?I Beispiele: Verminderte Leistung, Geräusche, Verletzung
I Priorisierung der Fehlermodi hinsichtlich ihrer KonsequenzenI Wie häufig treten sie auf?I Wie einfach kann man sie finden?
WS 2018/19 · C. Jakobs 22 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA Worksheet
WS 2018/19 · C. Jakobs 23 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA Worksheet (Forts.)Item Function Potential
Failure Mode
Potential Effect(s) of
Failure
Severity (S)
Potential Cause of Failure
Current Prevention Controls
Probability of Occurrence
(O)
Current Detection Controls
Probability of
Detection (D)
RPN = S*O*D
Criticality = S*O
Recommended Action
I Definition von Einträgen hängt von FMEA-Granularität abI Ausgangspunkt ist System FMEA - nur ein EintragI Funktionen müssen eine gegebenen Standardleistung oder Anforderung habenI Fokus auf ernste Effekte (System / Endnutzerkonsequenzen) eines AusfallsI Schwere ermöglicht Einordnung der Effekte, typischerweise basierend auf
Firmenstandards
WS 2018/19 · C. Jakobs 24 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Starter Questions for Functions [Carlson]
Item Function Potential Failure Mode
Potential Effect(s) of
Failure
Severity (S)
Potential Cause of Failure
Current Prevention Controls
Probability of Occurrence
(O)
Current Detection Controls
Probability of
Detection (D)
RPN = S*O*D
Criticality = S*O
Recommended Action
I „Was sind die primären Zwecke eines Gegenstands?“I „Was soll ein Gegenstand leisten? Was muss er tun?“I „Was ist die Standardleistung?“I „Welche Funktionen treten an Schnittstellen?“I „Welche sicherheitsrelevanten Funktionen sind wichtig für diesen Gegenstand?“
WS 2018/19 · C. Jakobs 25 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Starter Questions for Failure Modes [Carlson]Item Function Potential
Failure Mode
Potential Effect(s) of
Failure
Severity (S)
Potential Cause of Failure
Current Prevention Controls
Probability of Occurrence
(O)
Current Detection Controls
Probability of
Detection (D)
RPN = S*O*D
Criticality = S*O
Recommended Action
I „Wie kann ein Gegenstand bei der Ausübung einer Funktion fehlschlagen?“I „Wie könnte der Gegenstand eine unbeabsichtigte Funktion ausführen?“I „Was kann bei den Schnittstellen schiefgehen?“I „Was ist in der Vergangenheit schiefgegangen?“I „Wie könnte der Gegenstand missbraucht werden?“I „Was sind die Bedenken der Teammitglieder hinsichtlich dieses Gegenstandes?“
WS 2018/19 · C. Jakobs 26 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Starter Questions for Effects [Carlson]
Item Function Potential Failure Mode
Potential Effect(s) of
Failure
Severity (S)
Potential Cause of Failure
Current Prevention Controls
Probability of Occurrence
(O)
Current Detection Controls
Probability of
Detection (D)
RPN = S*O*D
Criticality = S*O
Recommended Action
I „Was ist die Folge eines Ausfalls?“I „Wie wird die Erfahrung des Nutzers aussehen?“I „Wird der Ausfall potentiellen Schaden für den Nutzer verursachen?“I „Wird der Ausfall potentielle Verstöße von Bestimmungen nachsichziehen?“I „Was würde ein Ausfall für benachbarte Teile und Subsysteme bedeuten?“
WS 2018/19 · C. Jakobs 27 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Example: Severity Ranking in Automotive IndustryEffect Severity of effect on product Rank
System fails to meet safety / regulatory
requirements
Failure mode affects safe operation or rules, without warning 10
Failure mode affects safe operation or rules, with warning 9
Loss or degradation of primary function
Loss of primary function 8
Degradation of primary function 7
Loss or degradation of secondary function
Loss of secondary function 6
Degradation of secondary function 5
Annoyance
Appearance or audible noise, noticed by >75% of customers 4
Appearance or audible noise, noticed by 50% of customers 3
Appearance or audible noise, noticed by <25% of customers 2
No effect No discernible effect 1
WS 2018/19 · C. Jakobs 28 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Example: NASA Spacecraft Severity Ranking
I Kategorie 1, Catastrophic - Ausfälle, die zu ernsten Verletzungen oder Verlust vonMenschenleben oder Schaden an Trägerrakete usw. führen können.
I Kategorie 1R, Catastrophic - Ausfälle von identischer oder äquivalenterredundanter Hardware, die zu Kategorie-1-Effekten führen können.
I Kategorie 2, Critical - Ausfälle, die zum Verlust/Nichterreichen eines oder mehrererMissionsziele, nach Definition des GSFC Projektbüros, führen können.
I Kategorie 2R, Critical - Ausfälle von identischer oder äquivalenter redundanterHardware, die zu Kategorie-2-Effekten führen können.
I Kategorie 3, Significant - Ausfälle, die zu einer Verschlechterung hinsichtlich derMissionsziele beitragen können.
I Kategorie 4, Minor - Ausfälle, die zu unwichtigem oder keinem Verlust hinsichtlichder Missionsziele führen können.
WS 2018/19 · C. Jakobs 29 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA WorksheetItem Function Potential
Failure Mode
Potential Effect(s) of
Failure
Severity (S)
Potential Cause of Failure
Current Prevention Controls
Probability of Occurrence
(O)
Current Detection Controls
Probability of
Detection (D)
RPN = S*O*D
Criticality = S*O
Recommended Action
I Cause ist die spezifische Ursache eines Ausfalls („why?“, „due to“)I Wenn die Ursache vorliegt, so tritt der entsprechende Ausfall einI In Wartungsanalyse, die Ursache ist ein ,maintenance-actionable’ itemI Ausfallmechanismus != cause
I Occurrence drückt die Wahrscheinlichkeit von Ursache + Ausfall ausI Relative Bedeutung, die Aussage „passiert nie“ muss OK sein
WS 2018/19 · C. Jakobs 30 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Starter Questions for Causes [Carlson]
Item Function Potential Failure Mode
Potential Effect(s) of
Failure
Severity (S)
Potential Cause of Failure
Current Prevention Controls
Probability of Occurrence
(O)
Current Detection Controls
Probability of
Detection (D)
RPN = S*O*D
Criticality = S*O
Recommended Action
I „Wie kann ein Ausfall eintreten? Was ist die Mechanik des Ausfalls?“I „Welche Umstände können den Gegenstande dazu veranlassen nicht die gewollte
Funktion auszuführen?“I „Gibt es mögliche Systeminteraktionen, Verschlechterungen,
Betriebskonfigurationen, Nutzerverhalten oder Montageprobleme, die den Ausfallverursachen können?“
WS 2018/19 · C. Jakobs 31 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Example: Occurrence Ranking in Automotive IndustryMode Likelihood Associated Cause Rank
Very high New technology / design with no history >= 1 in 10 10
High
Failure is inevitable with new design 1 in 20 9
Failure is likely with new design 1 in 50 8
Failure is uncertain with new design 1 in 100 7
Moderate
Frequent failures expected due to knowledge from similar designs / experiment 1 in 500 6
Occasional failures expected due to knowledge from similar designs / experiment 1 in 2000 5
Isolated failures expected due to knowledge from similar designs / experiment 1 in 10.000 4
Low
Only isolated failures expected due to knowledge from similar designs / experiment 1 in 100.000 3
No failures expected due to knowledge from similar designs / experiment 1 in 1.000.000 2
Very low Failure is eliminated through preventive control Failure eliminated 1
WS 2018/19 · C. Jakobs 32 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA WorksheetItem Function Potential
Failure Mode
Potential Effect(s) of
Failure
Severity (S)
Potential Cause of Failure
Current Prevention Controls
Probability of Occurrence
(O)
Current Detection Controls
Probability of
Detection (D)
RPN = S*O*D
Criticality = S*O
Recommended Action
I High severity muss immer beachtet werden, unabhängig von occurence-RangI Prevention controls sind beabsichtigt (!), um die Wahrscheinlichkeit des Auftretens
zu verringernI Man sollte nur Dinge beachten, die schon geplant oder vor Ort sind - keine
,want-to’-Gegenstände oder FunktionenI Detection controls beschreiben, wie der Ausfall oder die Ursache erkannt werden
I Beispiel: in DFMEA, testen ist detection controlI Controls beeinflussen die Schwere eines Ausfalls nicht
WS 2018/19 · C. Jakobs 33 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Example: Detection Ranking in Automotive IndustryOpportunity for Detection Detection by Design Control Rank
No No current design control 10
Not likely to detect Controls have weak capabilities 9
Prior to launch
Pass / fail testing after design freeze 8
Test to failure testing after design freeze 7
Degradation testing after design freeze 6
Prior to design freeze
Pass / fail testing before design freeze 5
Test to failure testing before design freeze 4
Degradation testing before design freeze 3
From design controls Strong control capabilities 2
No applicable Failure mode cannot occur since it is prevented 1
WS 2018/19 · C. Jakobs 34 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Risk Priority Number
I Numerische Einstufung des Risiko jedes potentiellen AusfallsI Hitzige Debatte in der Community über saubere Verwendung dieser Werte
I Wichtig: Immer Schwere ausschlaggebend, unabhängig von RPN
I Niedrige RPN kann verwendet werden, um Kandidaten für Kosteneinsparungen zuidentifizieren
I Hoher Risikofaktor sollte immer zu mehreren vorgeschlagenen Aktionen führenI Zustimmung des Managements ist ein strategischer VorteilI Wenn ,review’ Teil der Aktion ist, ist sicherzustellen, dass es ein follow-up gibt
WS 2018/19 · C. Jakobs 35 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Risk Priority Number - Limitations
I Subjektivität: Hilft in der Priorisierung vorgeschlagener Aktionen, keinRisikovergleich über FMEAs hinweg nützlich
I Fehlende Information zu Detektion: Manche Firmen geben nur RPN=SxO herausI Löcher in der Skala: Obwohl RPN eine Ganzzahlskala ist, ist sie nicht proportional
oder kontinuierlichI Doppelte RPN-Zahlen: Ausfälle mit weitreichend unterschiedlicher Schwere
können die gleiche Wichtigkeit bekommenI RPN Schwellwerte: Management liebt RPN-Schwellwerte, führt zu ,numbers game’
I Teams setzen Werte herab, um exzessive Konsequenzen zu umgehenI Wichtigster Aspekt erfolgreicher FMEA ist ein ehrliches Team
WS 2018/19 · C. Jakobs 36 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Starter Questions for Recommended Actions [Carlson]Item Function Potential
Failure Mode
Potential Effect(s) of
Failure
Severity (S)
Potential Cause of Failure
Current Prevention Controls
Probability of Occurrence
(O)
Current Detection Controls
Probability of
Detection (D)
RPN = S*O*D
Criticality = S*O
Recommended Action
I „Was kann getan werden, um die Schwere durch Designanpassung zu reduzieren?“I „Wenn das Produkt ausfällt, wie kann der Nutzer vor potentiellem Schaden oder
Verletzung geschützt werden?“I „Wie kann das derzeitige Design robuster gemacht werden?“I „Welche Tests oder Evaluationstechniken müssen hinzugefügt oder geändert
werden, um die Erkennungsfähigkeit zu verbessern?“I „Wenn die vorgeschlagenen Aktionen implementiert sind, wird das ausreichen, um
alle Risiken mit hoher Schwere und hoher RPN anzusprechen?“
WS 2018/19 · C. Jakobs 37 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA Steps [asq.org]1. Identifiziere FMEA-Bereich im funktionsübergreifenden Team (design, quality,
testing, support, . . . )2. Identifiziere Funktionen im untersuchten Bereich (Verb + Substantiv)3. Aus Funktion alle Arten, wie ein Ausfall zustande kommen kann, identifizieren -
potential failure modes4. Identifiziere hinsichtlich der Ausfälle Konsequenzen / Effekte - für das System
selbst, verbundene Systeme, Produkt, Service, Kunde oder Bestimmungen5. Führe hinsichtlich der Effekte eine Schwereeinschätzung (S) durch - von unwichtig
bis katastrophal; nur höchstrangige Effekte in späterer Analyse hinzunehmen6. Identifiziere hinsichtlich der Ausfälle Ur-Ursachen, mit probability of occurrence
(O) einstufen7. Liste Tests / Prozeduren (process control), die vorhanden sind, um den Ursachen
zu verhindern8. Bestimme hinsichtlich der Kontrollen eine Detektionseinstufung (D) - von sicherer
Erkennung bis keine Erkennung, basierend auf Level der vorliegendenProzesskontrolle
9. Risk priority number (RPN) = S x O x D, Criticality (CRIT) = S x OWS 2018/19 · C. Jakobs 38 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Example: System FMEA of ATM [asq.org]
WS 2018/19 · C. Jakobs 39 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Example: Design FMEA for disk brake [asq.org]
ItemPotential Failure Mode
Potential Cause of Failure Current Prevention Controls
Current Detection Controls
Recommended Action
Disk Brake
System
Vehicle does not
stop
Mechanical linkage break due to corrosion
Designed per material standard
MS-845Environmental
stress test 03-9963Change material to
stainless steel
Master cylinder vacuum lock
Carry-over design with same duty
cycle requirements
Pressure variability testing on system
levelNone
Loss of hydraulic fluid due to back off of
connector
Designed per torque
requirements - 3993
Vibration step-stress test 18-1950
Modify connector from crimp style to
quick connect.
Loss of hydraulic fluid due to hydraulic lines
crimped or compressed
Designed per material standard
MS-1178DOE tube resiliency
test
Modify design from MS-1178 to MS-2025 to
increase strength.
WS 2018/19 · C. Jakobs 40 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA-Ziele in der Praxis
I Identifiziere und verhindere SicherheitsbedrohungenI Minimiere Verlust der Leistung des ProduktesI Verbessere Test- und VerifikationspläneI Verbessere ProzesskontrollpläneI Änderungen im Produktdesign oder Herstellungsprozess prüfenI Identifiziere wichtige Produkt- oder ProzesscharakteristikaI Entwickle präventive Wartungspläne für Maschinen und AusrüstungI Entwickle Onlinediagnosetechniken
WS 2018/19 · C. Jakobs 41 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA-Typen
I SFMEA (S: System)I Verbesserung des Gesamtsystemdesigns, um Komplettausfälle zu verhindernI Analyse der höchstmöglichen AbstraktionsebeneI Ziel sind systemrelevante Defizite, wie Sicherheit oder UntersystemI Fokus auf Funktionen und Beziehungen, die im System einzigartig sindI Beachtung menschlicher Interaktion und Dienstbereitstellung
I DFMEA (D: Design)I Fokus auf Ausfälle, die durch Designdefizite in Subsystemen verursacht
werdenI Fokus auf Teile, die man vor der Massenproduktion prototypisch testen kann
WS 2018/19 · C. Jakobs 42 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA-Typen (Forts.)
I PFMEA (P: Process)I Analyse des Herstellungs- und ZusammensetzungsprozessesI Beeinflusst Maschinendesign, Auswahl der Werkzeuge und KomponententeileI Erstellt um sicher, mit minimaler downtime, Ausschuss oder Nachbesserung
zu entwickelnI Beinhaltet Auslieferung, eingehende Teile, Transport des Materials, Lagerung,
Förderbänder, Werkzeugwartung und BeschriftungI Typischerweise wird ein abgeschlossenes Produktdesign angenommen
I Designfehler und deren Ursachen (inkorrekte Materialspezifikation) sollten nichtmit Prozessfehlern und deren Ursachen (inkorrekte Materialien verwendet)vermischt werden.
WS 2018/19 · C. Jakobs 43 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA-Typen (Forts.)Andere, weniger populäre VariantenI Concept FMEA: Kurzversion von FMEA, um zwischen Systemdesignalternativen zu
wählen; Resultat: priorisierte Liste mit BedenkenI Reliability-Centered Maintenance (RCM): Analytischer Prozess, um Anforderungen
an präventive Wartung zu identifizierenI FMEA auf Herstellungs- und Einsatzequipment ist Hauptpunkt
I Software FMEA: Bestimmung, ob Software Fehlertolerant hinsichtlichHardwarefehlern ist; Identifikation fehlender Anforderungen
I Hazard Analysis: Identifikation sicherheitsrelevanter Risiken in derSystemlebensdauer
I Human Factors FMEA: Aufmerksamkeit auf Interkation zwischen Nutzern(Menschen) und Ausrüstung
I Service FMEA: Fokus auf Installation oder Bereitstellung von Ausrüstung währenddes Einsatzes
WS 2018/19 · C. Jakobs 44 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA-Typen (Forts.)
I Business Process FMEA: Minimiere Ineffizienzen durch Verbesserung vonWorkflow, Organisationsmanagement und EntscheidungsfindungI Ähnlich zu PFMEA, aber Schritte des Geschäftsprozesses ersetzen
HerstellungsschritteI Failure Mode, Mechanisms, and Effects Analysis (FMMEA): Erweitert FMEA durch
Identifikation hoch priorisierter AusfallmechanismenI Bestimmung operationaler Belastungen und Umgebungsparameter
I Failure Mode, Effects, and Diagnosis Analysis (FMEDA): FMEA-Erweiterung, ummehr Details über Effekt von Ausfällen abzuleitenI Generiert Ausfallraten für sicherheitsrelevante EffektkategorienI Verwendet, um Onlinediagnosetechniken für IEC61509-Compliance zu
entwickeln
WS 2018/19 · C. Jakobs 45 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Example: NASA Spacecraft FMEA Rules
I Nur ein Ausfall existiert gleichzeitig.I Alle Eingaben (einschließlich Softwarekommandos) in einen analysierten
Gegenstand sind vorhanden und auf Nominalwert .I Alle Verbrauchsmaterialien sind in ausreichender Menge vorhanden.I Nennleistung ist verfügbar.I Alle Missionsphasen werden in der Analyse beachtet; Missionsphasen, die
nachweislich nicht eintreten, können ausgelassen werden.I Connector-Ausfälle sind auf Connector-Trennung begrenzt.I Schwerpunkt wird auf Identifikation von Einzelausfällen gelegt, die den Verlust von
zwei oder mehr redundanten Pfaden bedingen.
WS 2018/19 · C. Jakobs 46 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Example: NASA Spacecraft FMEA Rules (Forts.)
WS 2018/19 · C. Jakobs 47 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Software FMEA
I FMEA auf funktionellem, detailliertem (logischen) Entwurfs- oder CodeniveauI Unterstützt durch DatenflussdiagrammeI Typische Ziele
I Identifizierung fehlender SoftwareanforderungenI Analyse von AusgabevariablenI Analyse von Systemantwort als Reaktion auf unterschiedliche
UmgebungseingabenI Analyse der Schnittstellen, zusätzlich zu FunktionenI Identifizierung der Softwareantwort auf Hardwareanomalien
I Since software is a logical construct, hazards must be identified first [Goddard]
WS 2018/19 · C. Jakobs 48 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Software FMEA - Failure Definition [Raheja]
I Versagen beim zuverlässigen Ausführen einer FunktionI Versagen eine Funktion sicher auszuführenI Versagen eine Funktion auszuführen, wenn sie (nicht) benötigt wirdI Funktionen ausführen, die nicht in der Spezifikation stehenI Versagen einen Task zum rechten Zeitpunkt zu stoppenI Verlust von Eingabe oder AusgabeI Verfälschte Leistung wegen AusführungsumgebungI Ausfall wegen inkorrekter AnfrageI Unvollständige AusführungI Unfähigkeit kritische Unterbrechungen auszuführen
WS 2018/19 · C. Jakobs 49 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Software FMEA - Cause Definition [Raheja]Es ist nützlich Ursachentypen zu definieren
I Physische HardwareeffekteI Coding- oder LogikfehlerI Eingabe- / AusgabefehlerI DatenbearbeitungI VariablendefinitionenI Schnittstellenfehler
I Lücken in der SpezifikationI Unzureichender oder verfälschter
SpeicherI AusführungsumgebungI Unzutreffende Eingabe, z.B. von
SensorenI Defekte Hardware / Stromausfall /
lockere Drähte oder KabelI Kommunikationsausfälle
á Immernoch Forschungsgebiet
Beispiel: Orthogonal Defect Classification (ODC)
WS 2018/19 · C. Jakobs 50 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Most Common FMEA Mistakes [Carlson]I Machne FMEAs raten zu keinerlei AktionI Manche FMEAs raten hauptsächlich zum Testen, andere zu ineffektiven AktionenI Manche FMEAs versagen dabei auf Ausfälle mit hohem Risiko einzugehenI Manche FMEA-Teams beinhalten keine Repräsentanten der Test- und
AnalyseabteilungI Manche Firmen konzentrieren sich nur auf Teil- oder Subsystemausfälle und
vernachlässigen die SchnittstellenI Versagen beim Zusammenbringen von FMEA und FeldinformationenI „Missing the forrest for the trees“ -
Zu viele Details machen es schwer Bereiche mit hohem Risiko zu identifizierenI Späte FMEAs sind weniger effektivI Teilnahme an Team-Meetings und richtige Auswahl der Leute ist zentralI FMEA selbst muss als Prozedur evaluiert werde; es gibt viele Wege es falsch zu
machen
WS 2018/19 · C. Jakobs 51 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
FMEA Success Factors [Carlson]I Verhindern der ,lost in space’-Problematik
I Klare Definition des Bereichs eines FMEA-ProjektsI In Grenzfällen Teamzustimmung einholenI Relevante Informationen und Dokumente vor einem Meeting sammeln
I Experten für jeweiligen Bereich suchen, typischerweise eine Gruppe von 4 bis 8Personen
I Ein Teilnehmer muss als FMEA-Moderator auftreten - Brainstormingleitung,Ermutigung, Diskussionsführung, Entscheidungsfindung, Konflikt- undZeitmanagement
I Vergangene FMEAs und Feldinformationen müssen wiederverwendet werden, umZeit zu sparen
I Ziel ist es das Systemdesign zu verbessern, nicht es zu verstehenI Ursachen bis zu den Ur-Ursachen zurükverfolgen (z.B. durch FTA), nicht KontrollenI Abstimmungen vermeiden, Konsens bevorzugen
WS 2018/19 · C. Jakobs 52 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Failure Mode Effects and Criticality Analysis (FMECA)
I Ähnlich zu FMEA, aber auf anderer Größenordnung, einschließlich KritikalitätI Standards: MIL-STD 1629A and SAE ARP5580, originally developed by NASA
I Qualitative FMECAI Grad der Schwere potentieller Effekte
(catastrophic, critical, marginal, minor)I Grad der Wahrscheinlichkeit des
Eintretens (frequent, reasonably probable,occasional, remote, extremely unlikely)
I Ausfälle vergleichen durch criticalitymatrix
I Quantitative FMECAI Serie von Berechnungen, um Gegenstände
und Ausfälle einzuordnen
WS 2018/19 · C. Jakobs 53 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Qualitative FMECA Example [Carlson]
Items FunctionsFailures
and Causes
Local Failure Effects
Next Higher Level
Effects
End Effects
Severity Class
Failure Detection Method
Compen-sation
Bicycle Brake Pad
Primary means of friction
between the brake
caliper against the
wheel
Excessive wear of
pad due to wrong
material
No controlled friction to the wheel
Wheel does not
slow down when
break lever pulled
Bicycle does not
stop, causing accident
Catas-trophic
Brake testing
procedure #1234
Select new material
with better durability
Pad material cracks
(cured too hot)
Erratic friction against wheel
Wheel motion chugs during
maneuver
Bicycle operator
dissatisfiedMarginal
No detection,
only by owner
Revise curing
procedure
WS 2018/19 · C. Jakobs 54 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Quantitative FMECA
I Berechnung der erwarteten Ausfälle für jeden Gegenstand (ausVerlässlichkeitsdaten)
I Identifizierung des Grades der Unverlässlichkeit für potentielle AusfälleI Prozentwert aller Ausfälle für einen Gegenstand, die vom untersuchten Ausfall
abhängenI Kann aus Verlässlichkeitsvorhersagedaten (siehe letzte Einheit) abgeleitet
werdenI Einordnung der Wahrscheinlichkeit eines Verlusts hinsichtlich der Ausfälle
I Wahrscheinlichkeit, dass der Ausfall zum Systemversagen führtI Mode criticality [item, failure mode] = Erwartete Ausfälle x Ausfälle x
Wahrscheinlichkeit des VerlustsI Item criticality [item] = Sum (mode criticalities)I Ausgabe: Critical item list, single failure points list, failure mode list
WS 2018/19 · C. Jakobs 55 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Quantitative FMECA Example [Carlson]
Items Operating Time (h)
Expected Failures Functions
Failures and
CausesRatio of
UnreliabilityProbability
of LossMode
CriticalityItem
Criticality
Bicycle Brake Pad 5475 0,548
Primary means of friction
between the brake
caliper and the wheel
Excessive wear of
pad due to wrong
material
0,85 0,75 0,349
0,361Pad
material cracks
(cured too hot)
0,15 0,15 0,012
WS 2018/19 · C. Jakobs 56 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Literature
b [Car12] Carl Carlson. Effective FMEAs: Achieving safe, reliable, and economicalproducts and processes using failure mode and effects analysis. Bd. 1.John Wiley & Sons, 2012
b [God00] P. L. Goddard. „Software FMEA techniques“. In: Annual Reliability andMaintainability Symposium. 2000 Proceedings. International Symposiumon Product Quality and Integrity (Cat. No.00CH37055). Jan. 2000,S. 118–123
b [KCM99] Sunwoo Kim, John Clark und John McDermid. „The rigorous generationof Java mutation operators using HAZOP“. In: Informe técnico, TheUniversity of York (1999)
b [McD+95] J. A. McDermid u. a. „Experience with the application of HAZOP tocomputer-based systems“. In: COMPASS ’95 Proceedings of the TenthAnnual Conference on Computer Assurance Systems Integrity, SoftwareSafety and Process Security’. Juni 1995, S. 37–48
WS 2018/19 · C. Jakobs 57 / 58 osg.informatik.tu-chemnitz.de
Verlässliche Systeme – Qualitative Analyse5.5 Failure Mode and Effect Analysis (FMEA)
Literature (Forts.)
b [Kim14] H. H. Kim. „SW FMEA for ISO-26262 Software Development“. In: 201421st Asia-Pacific Software Engineering Conference. Bd. 2. Dez. 2014,S. 19–22
b [Rah05] Dev Raheja. „Software FMEA: A Missing Link in Design for Robustness“.In: SAE Technical Paper. SAE International, Apr. 2005
b [SCP04] Thitima Srivatanakul, John A Clark und Fiona Polack. „Effective securityrequirements analysis: Hazop and use cases“. In: InternationalConference on Information Security. Springer. 2004, S. 416–427
b [Qur07] Zahid H Qureshi. „A review of accident modelling approaches forcomplex socio-technical systems“. In: Proceedings of the twelfthAustralian workshop on Safety critical systems and software andsafety-related programmable systems-Volume 86. Australian ComputerSociety, Inc. 2007, S. 47–59
WS 2018/19 · C. Jakobs 58 / 58 osg.informatik.tu-chemnitz.de