5.1 Verlässlichkeitsmodellierung Wintersemester 2018/2019 ... · not use radio comms 9 Phone comms...

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ä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;


osg.informatik.tu-chemnitz.de




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



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


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



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







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


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



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



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







Kraftwerksbeispiel - Kombinationen



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)



HAZOPS-Verfahren



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)







HAZOPS für Java-Sprachspezifikation


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)



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



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






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



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?



FMEA Worksheet



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







Starter Questions for Functions [Carlson]

Item Function Potential Failure Mode


Failure

Severity (S)




(O)


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?“



Starter Questions for Failure Modes [Carlson]Item Function Potential

Failure Mode


Failure

Severity (S)




(O)


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?“



Starter Questions for Effects [Carlson]



Failure

Severity (S)




(O)


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?“



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







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.



FMEA WorksheetItem Function Potential

Failure Mode


Failure

Severity (S)




(O)


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



Starter Questions for Causes [Carlson]



Failure

Severity (S)




(O)


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?“



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







FMEA WorksheetItem Function Potential

Failure Mode


Failure

Severity (S)




(O)


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



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



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



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







Starter Questions for Recommended Actions [Carlson]Item Function Potential

Failure Mode


Failure

Severity (S)




(O)


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?“



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


Example: System FMEA of ATM [asq.org]



Example: Design FMEA for disk brake [asq.org]

ItemPotential Failure Mode

Potential Cause of Failure Current Prevention 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.







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



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



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.



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







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



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.



Example: NASA Spacecraft FMEA Rules (Forts.)



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]







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



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)



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



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







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



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



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



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







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



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




5.1 Verlässlichkeitsmodellierung Wintersemester 2018/2019 ... · not use radio comms 9 Phone comms...

Documents

Transcript of 5.1 Verlässlichkeitsmodellierung Wintersemester 2018/2019 ... · not use radio comms 9 Phone comms...