Zuverlässigkeit und Sicherheit von Automatisierungssystemen

Zuverlässigkeit und Sicherheit von Automatisierungssystemen
Universität Stuttgart
Institut für Automatisierungs- und Softwaretechnik
Prof. Dr.-Ing. Dr. h. c. P. Göhner
Zuverlässigkeit und Sicherheit
von Automatisierungssystemen
Sommersemester 2015
Dr. N. Jazdi
www.ias.uni-stuttgart.de/zsa
[email protected]
© 2015 IAS, Universität Stuttgart
1
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Ansprechpartner für die Vorlesung
Bei organisatorischen Fragen zur Vorlesung oder bei Problemen mit dem
Ablauf
der
Vorlesung
„Zuverlässigkeit
und
Sicherheit
von
Automatisierungssystemen“ wenden Sie sich bitte an:
Dr.-Ing. Nasser Jazdi
Zimmer: 2.139 (Pfaffenwaldring 47, 2. Stock am IAS)
Tel.:
0711- 685-67303
E-Mail: [email protected]
© 2015 IAS, Universität Stuttgart
2
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Unterlagen
 Skript „Zuverlässigkeit und Sicherheit von Automatisierungssystemen“
• Blaue Texte zum Mitschreiben (im Skript nicht enthalten)
• Live-Mitschriebe (leere Folien im Skript für Mitschrieb vorgesehen)
• Fragen am Ende jedes Unterkapitels – Antworten zum Mitschreiben
 Vorlesungsportal im Internet: www.ias.uni-stuttgart.de/zsa
• Aktuelle Informationen zur Vorlesung
• Vollständige Vorlesungsunterlagen
• Lecturnity-Aufzeichnungen im Internet und als Podcast
 Vorlesungen
© 2015 IAS, Universität Stuttgart
3
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Literatur
Bertsche, Bernd; Göhner, Peter; Jensen, Uwe; Schinköthe, Wolfgang;
Wunderlich, Hans-Joachim:
Zuverlässigkeit mechatronischer Systeme, Grundlagen und Bewertungen in
frühen Entwicklungsphasen, Springer-Verlag Berlin – Heidelberg, 2009
© 2015 IAS, Universität Stuttgart
4
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Vorlesungstermine
Nr.
Termin
Thema der Vorlesung
01
16.04.2015
Einführung in die Zuverlässigkeit und Sicherheit
02
23.04.2015
Begriffe und Normen
03
30.04.2015
Wahrscheinlichkeit und Lebensdauerverteilungen
04
07.05.2015
Verfügbarkeit und Zuverlässigkeitsberechnung
05
21.05.2015
Einführung in die Fehlerbaumanalyse
06
11.06.2015
Durchführung der Fehlerbaumanalyse
07
18.06.2015
Einführung in die Fehlermöglichkeits- und Einfluss-Analyse
08
25.06.2015
Durchführung der Fehlermöglichkeits- und Einfluss-Analyse
09
02.07.2015
Einführung in die Softwarezuverlässigkeit
10
09.07.2015
Modelle der Softwarezuverlässigkeit
11
16.07.2015
Zuverlässigkeits- und Sicherheitstechnik
12
23.07.2015
Übung / Prüfungsbesprechung
© 2015 IAS, Universität Stuttgart
5
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Ziele der Vorlesung
 Grundlagen der Zuverlässigkeit und Sicherheit verstehen
• Kennenlernen der wichtigen Begriffe, Kenngrößen und Normen
• Verstehen der Notwendigkeit von Zuverlässigkeits- und Sicherheitstechnik
 Zuverlässigkeitsmaßnahmen kennen und anwenden können
• Methoden der Zuverlässigkeitsberechnung
• Modelle der Zuverlässigkeitsanalyse
 Sicherheitskriterien berücksichtigen und handhaben
• Strategien zum Entwurf sicherer Systeme
• Bewertung von Risiko- und Gefährdungssituationen
© 2015 IAS, Universität Stuttgart
6
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Bezug zu anderen Vorlesungen der Fakultät:
Vertiefung einzelner
Themen in
Komplexitätstheorie
Zuverlässigkeit und Sicherheit von
Automatisierungssystemen
Grundkenntnisse aus
Automatisierungstechnik I
Höhere
Mathematik
Automatisierungstechnik II
© 2015 IAS, Universität Stuttgart
Grundlagen der
Softwarezuverlässigkeit
Hardware Based
Fault Tolerance
Networks and
Processes
Embedded
Systems
Engineering
7
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Gliederung
§ 1 Einführung, Begriffe und Normen
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
§ 3 Fehlerbaumanalyse (FTA)
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
§ 5 Softwarezuverlässigkeit
§ 6 Zuverlässigkeits- und Sicherheitstechnik
§ 7 Übungsaufgaben
© 2015 IAS, Universität Stuttgart
8
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 1 Einführung , Begriffe und Normen
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
1.2 Definition von Zuverlässigkeit und Sicherheit
1.3 Wichtige Begriffe und Bedeutungen
1.4 Normen
© 2015 IAS, Universität Stuttgart
9
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
ZSA
Wenn Systeme versagen…
 Beispiel 1: Bosch und Siemens Hausgeräte (BSH) in 2013
• Rückruf von über 5 Millionen Geschirrspülmaschinen weltweit
• Brandgefahr durch einen Fehler in einem elektr. Bauteil des Bedienfelds
• Kunden erhalten kostenfreie Reparatur oder reduziertes Neugerät
• Kosten für das Unternehmen ca. 700Mio Euro
 Beispiel 2: Toyota von 2010 bis 2013
• Rückruf von über 22 Millionen Fahrzeugen in den USA
• Ursachen u.a. klemmende Gaspedale, explodierende Airbags,…
• Kosten der Rückrufaktionen für das Unternehmen nicht bekannt
• Dazu aber mehrere Straf- bzw. Entschädigungs-Zahlungen an USKunden von insgesamt 2,6Mrd Dollar
© 2015 IAS, Universität Stuttgart
10
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
ZSA
Aktuelle Trends
1960
Quelle: www.autozeitung.de, 2014
2014
Quelle: www.autotribute.com, 2014
 Systeme werden immer komplexer
 Menschen werden immer mehr von Systemen abhängig
 Fehler in Systemen haben Ausfälle oder Unfälle mit beträchtlichen
Auswirkungen zur Folge:
• Beschädigung von Güter
• Verletzung und Tod von Menschen
© 2015 IAS, Universität Stuttgart
11
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
ZSA
Fazit
 Systeme müssen Zuverlässigkeit und Sicherheit gewährleisten
 Methoden der Zuverlässigkeits- und Sicherheitstechnik müssen
beherrscht werden
 Nur dadurch kann weiterer Fortschritt gewährleistet werden
 Beispiel: Mercedes DICE (Dynamic & Intuitive Control Experience)
Quelle: www.daimler.com, 2014
© 2015 IAS, Universität Stuttgart
12
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
ZSA
Historie (1940er – 1980er)
 Bis 1940
• Festlegung von produktspezifischen Qualitäts-Merkmalen
• Einführung von Qualitäts-Prüfungen
 1940 – 1960 (mit wachsender Zahl von Systemen)
• Systematische Erfassung und Analyse von Ausfällen
• Einführung statistischer Qualitätskontrollen
• Zuverlässigkeitsuntersuchungen bereits während der Entwicklung
 1960 – 1980 (mit wachsender Komplexität der Systeme)
• Methoden zur Schätzung und zum Nachweis von Ausfallzeiten
• Festlegung von Zuverlässigkeitszielen bereits während der Analyse
• Zunehmende Bedeutung der Softwarezuverlässigkeit
© 2015 IAS, Universität Stuttgart
13
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
ZSA
Historie (1980er – heute)
 1980 – 1990
• Detailliertere Untersuchung der Software-Zuverlässigkeit
• Notwendigkeit automatisierter Tests bzw. Selbsttests von Systemen
• Steigende Bedeutung der Produkthaftung
 1990 bis heute
• Gegenseitiger Austausch auf nationaler und internationaler Ebene
• Erarbeitung einheitlicher Richtlinien (nicht produktspezifisch!)
• Qualitätsmerkmale als Grundsätze bzw. Ziele der Entwicklung
• Einbeziehung von Kunden und Lieferanten
© 2015 IAS, Universität Stuttgart
14
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
ZSA
Bedeutung im Entwicklungsprozess
 Kundenzufriedenheit ist elementarer Aspekt
 Komplexer werdende Systeme sind teurer als ihre Vorgänger
 Erwartungen der Kunden an Zuverlässigkeit und Sicherheit der
Systeme steigen mit dem Preis
 Aspekte der Zuverlässigkeit und Sicherheit müssen im
Entwicklungsprozess bereits in frühen Phasen berücksichtigt und
besonders beachtet werden
Entwurf nach
Sicherheits-Kriterien
Entwurf nach
ZuverlässigkeitsKriterien
Entwurf nach
Kostenkriterien
Stopp des Entwurfsprozess wenn Kriterien nicht erfüllbar
© 2015 IAS, Universität Stuttgart
15
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
ZSA
Zuverlässigkeitsmanagement
 Organisation der Zuverlässigkeitsarbeit im Unternehmen (nach VDI 4003)
 Gesamtheit von Planung, Durchführung und Kontrolle der Zuverlässigkeit
 Dazu gehören die Ziele:
• Nachweis einer definierten Ausfallwahrscheinlichkeit eines Produkts
bzw. Systems
• Optimierung der Verfügbarkeit über den geplanten Lebenszyklus
• Verbesserungen durch Vergleiche mit alternativen Systementwürfen
• Identifikation kritischer Komponenten oder Teilsysteme
• Gewinnung von Planungswerten
• Definition allgemeingültiger Zuverlässigkeitsziele
• Aufbau einer Wissensbasis
© 2015 IAS, Universität Stuttgart
16
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
ZSA
Beispiel Daimler AG: „Sieben kategorische Imperative“
 Die Zuverlässigkeit elektronischer Systeme muss mindestens genauso groß
sein wie die vergleichbarer mechanischer Systeme!
 Wir brauchen Standards!
 Softwarefehler sind kein Zufall!
 Software-Entwicklungs-Tools dürfen nicht schnellere Fortschritte machen als
Software-Validierungs-Tools!
 Zertifizierung und Systemintegration sind Domänen der Erstausrüster (OEM)!
 Keine Hardware-Fehler!
 Keine Funktionen, die dem Kunden keinen Nutzen bieten!
© 2015 IAS, Universität Stuttgart
17
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 1 Einführung , Begriffe und Normen
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
1.2 Definition von Zuverlässigkeit und Sicherheit
1.3 Wichtige Begriffe und Bedeutungen
1.4 Normen
© 2015 IAS, Universität Stuttgart
18
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Zuverlässigkeit
 Wahrscheinlichkeit, dass ein System
1. innerhalb eines bestimmten Zeitintervalls,
2. unter den zulässigen Betriebsbedingungen,
die geforderte, spezifizierte Funktion erfüllt.
 Maßnahmen der Zuverlässigkeitstechnik richten sich gegen das Auftreten
von Fehlern und Ausfällen
 Grund für Maßnahmen ist die Wirtschaftlichkeit
 Nachweisverfahren: Zuverlässigkeitsanalyse
 Ziel ist die Erfüllung der Garantiezeiten
 Zuverlässigkeit ist elementarer Teil der Qualität (Qualitätsmanagement)
© 2015 IAS, Universität Stuttgart
19
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Einflussfaktoren auf die Zuverlässigkeit
Verringerte Entwicklungskosten
Höhere Komplexität
Größere Funktionalität
Kürzere Entwicklungszeiten
Zuverlässigkeit
Minimierung von Fehlerkosten
Gestiegene Kundenanforderungen
Steigende Produkthaftung
© 2015 IAS, Universität Stuttgart
20
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Zuverlässigkeitsanalyse
 Ziele:
• Prognose der zu erwartenden Zuverlässigkeit
• Erkennung und Beseitigung von Schwachstellen
• Durchführung von Vergleichsstudien
 Anforderungen an die Durchführung:
• Erfahrenes Bearbeitungsteam
• Systematische Planung aller erforderlichen Arbeitsschritte
• Geeignete Zuverlässigkeitsdatenbasis
• Geeignete Software
© 2015 IAS, Universität Stuttgart
21
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Quantitative Modelle der Zuverlässigkeitsanalyse
 Probabilistische Zuverlässigkeitsprognose
 Berechnung einer vorausgesagten und erwarteten Zuverlässigkeit
 Analyse der Ausfallrate
 Beispiel:
• Fehlerbaumanalyse FTA (vgl. Kap 3)
• Lebensdauerverteilungen (vgl. Kap 2)
• Boole-Modell (vgl. Kap 2)
• Markov-Modell
© 2015 IAS, Universität Stuttgart
22
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Markov-Modell (1/2)
 Benannt nach russischem Mathematiker A. A. Markov
 Stochastisches Modell, bei dem ein System über unbeobachtete
Zustände modelliert wird
Quelle: de.wikipedia.org, 2014
 Übergange zwischen den Zuständen und das Verweilen in einem Zustand
werden mit Wahrscheinlichkeiten versehen
 Beispiel: Beschreibung des Systemverhaltens über ein Zustandsdiagramm
mit den zwei Zuständen 1 (System ist in Ordnung) und 2 (System ist
ausgefallen)
W12
Wahrscheinlichkeit
W11 = 0,6
1
2
Wahrscheinlichkeit
W22 = 0,3
W21
© 2015 IAS, Universität Stuttgart
23
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Markov-Modell (2/2)
 Ablauf:
System
Definition von Zuständen und Übergängen
Zusammenstellung und Beschreibung der statistischen
Eingangsdaten durch Differentialgleichungen (DGL)
Numerische Auswertung der DGL
Zuverlässigkeitskenngrößen
© 2015 IAS, Universität Stuttgart
24
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Qualitative Modelle der Zuverlässigkeitsanalyse
 Systematische Untersuchung der Auswirkungen von Fehlern oder
Ausfällen
 Aufdeckung von Schwachstellen in Systemen
 Analyse der Ausfallart
 Beispiele:
 Fehlerbaumanalyse FTA (vgl. Kap 3)
 Fehlermöglichkeits- und Einfluss-Analyse FMEA (vgl. Kap 4)
 Checklisten (vgl. Kap 4)
 ABC-Analyse
© 2015 IAS, Universität Stuttgart
25
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
ABC-Analyse (1/2)
 Beschreibung von H. Ford Dickie (Manager bei General Electric) in 1951
 Ziel ist nach einer Zustandsbeschreibung die Trennung des „Wesentlichen“
vom „Unwesentlichen“ und dadurch die Steigerung der Wirtschaftlichkeit
 Basiert auf:
 Pareto Prinzip (nach Vilfredo Pareto, 1896)
 80% der Ergebnisse eines Projekts in 20% der Zeit
 20% der Ergebnisse eines Projekts in 80% der Zeit
 Lorenz-Kurve (nach Max Otto Lorenz, 1905)
 Statistische Verteilungskurve
 Berücksichtigt das Ausmaß bzw. den Grad der Ungleichverteilung
einer Größe zu einer anderen Größe
© 2015 IAS, Universität Stuttgart
26
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
ABC-Analyse (2/2)
 Vorhandene Daten werden in drei Relevanz-Klassen eingeteilt und nach
Größe und Wichtigkeit geordnet und visualisiert
 Beispiel Beanspruchung eines Bauteils:
AB C
• A (risikoreich) mit Wertanteil 5%
 Beanspruchung z.B. statische Belastungen
 Ausfallverhalten über Berechnung bestimmbar
20%
80%
• B (teil risikoreich) mit Wertanteil 15%
 Beanspruchung z.B. Verschleiß
 Ausfallverhalten über Schätzung oder Experimente bestimmbar
• C (risikoneutral) mit Wertanteil 80%
 Beanspruchung z.B. stochastische Stöße
 Ausfallverhalten kaum bzw. nicht bestimmbar
© 2015 IAS, Universität Stuttgart
27
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Induktive Zuverlässigkeitsanalyse
 Es wird ein Schluss vom Einzelnen auf die Allgemeinheit gezogen
 Ziel ist die Ableitung von allgemeinen Regeln oder Zusammenhängen
 Vereinfachter Gedankengang:
Mein Smartphone
benötigt Strom
Mein Smartphone ist ein
elektrisches Gerät
Alle elektrischen
Geräte benötigen
Strom
In der Zuverlässigkeitstechnik:
 Vorwärts gerichtete Verfolgung von Ereignissen, die zu Unfällen führen
können
 Frage: „Was sind die Folgen für das Gesamtsystem, wenn das
Einzelereignis X eintritt“?
© 2015 IAS, Universität Stuttgart
28
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Deduktive Zuverlässigkeitsanalyse
 Es wird ein Schluss von der Allgemeinheit auf das Einzelne gezogen
 Ziel ist die Schlussfolgerung logischer Konsequenzen
 Vereinfachter Gedankengang:
Elektrische Geräte
benötigen Strom
Mein Smartphone ist ein
elektrisches Gerät
Auch mein
Smartphone benötigt
Strom
In der Zuverlässigkeitstechnik:
 Rückwärts gerichtete Herleitung von möglichen Ausfällen oder
Fehlerquellen, die zu Unfällen führen können
 Frage: „Welche Einzelereignisse oder Kombinationen von
Einzelereignissen können zu einem unerwünschten Zustand führen?“
© 2015 IAS, Universität Stuttgart
29
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Zuverlässigkeitsanalyse in Entwicklungsprozess
 Vereinfacht dargestellt am Beispiel des V-Modells:
Lastenheft
Abnahme
Test
Pflichtenheft
Systemtest
Modellbildung
© 2015 IAS, Universität Stuttgart
30
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Sicherheit
 Sachlage, dass von einem System
1. innerhalb vorgegebenen Grenzen und
2. für eine bestimmte Zeitdauer
keine Gefahr ausgeht oder keine Gefährdung eintritt.
 Maßnahmen der Sicherheitstechnik richten sich gegen gefährliche
Auswirkungen von Fehlern und Ausfällen
 Grund für Maßnahmen ist die Genehmigung durch eine Zulassungsbehörde
 Nachweisverfahren: Sicherheitsnachweis über Gefahrenanalyse
 Ziel ist das Verhindern einer Gefahr
 Sicher sein bedeutet frei sein von Gefährdungen
© 2015 IAS, Universität Stuttgart
31
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Sicherheit = Safety
Umwelt
 Verhindern von Gefahren, die vom System auf die
Umwelt oder den Mensch ausgehen
System
 Gefahr wirkt von Innen nach Außen
 Ziel: Erfüllung von (rechtlichen) Sicherheitsstandards
 Sicherheitsmanagement während der Entwicklung (nach ISO 26262):
• Sicherheitsplan (safety plan)
 Planung von Entwicklungsaktivitäten und Analysemethoden
 Ableitung von Verifikationsmaßnahmen
• Sicherheitsnachweis (safety case)
 Ergebnisse der Aktivitäten und Maßnahmen
 Nachweis, dass die sicherheitskritischen Anforderungen
vollständig erfüllt werden
© 2015 IAS, Universität Stuttgart
32
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Sicherheit = Security
Umwelt
 Verhindern von Gefahren, die vom Menschen oder der
Umwelt auf das System einwirken
System
 Gefahr wirkt von Außen nach Innen
 Beinhaltet Außenzugriffe (Hackerangriffe, Viren,…), die das System so
beeinflussen können, dass es gefährlich werden kann
 Ziel: Schutz vor Bedrohungen und Vermeidung wirtschaftlicher Schäden
 Informationstechnik beinhaltet die Schutzziele:
• Vertraulichkeit (confidentiality): Zugriff nur für autorisierte Benutzer
• Integrität (integrity): Verhinderung unbemerkter Veränderungen
• Verfügbarkeit (availability): Verhinderung von Systemausfällen
• Authenzität (authenticity): Echtheit und Überprüfbarkeit von Daten
© 2015 IAS, Universität Stuttgart
33
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Risikobetrachtung
Grenzrisiko
Risiko vertretbar gering
(kleiner als Grenzrisiko)
Grundrisiko
(ohne Maßnahmen)
Risiko nicht vertretbar
(größer als Grenzrisiko)
Gefahr
Sicherheit
Restrisiko
Mindestens
erforderliche
Risikoreduzierung
tatsächliche
Risikoreduzierung
© 2015 IAS, Universität Stuttgart
34
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Sicherheitsnachweis
Beschreibung des Automatisierungssystems
Beschreibung der Umgebung und Einflüsse
Gefahrenanalyse
(Identifikation von Gefährdungen)
Risikobewertung
(Bewertung der Auswirkungen von Gefährdungen)
© 2015 IAS, Universität Stuttgart
35
1.2 Definition von Zuverlässigkeit und Sicherheit
ZSA
Frage zu Kapitel 1.2
Welchen Aussagen stimmen Sie zu?
□
□
□
□
Eine Anlage mit einer hohen Sicherheit zeichnet sich
grundsätzlich auch durch eine hohe Zuverlässigkeit aus.
Grund für Zuverlässigkeitsmaßnahmen von Systemen ist die
Wirtschaftlichkeit.
Absolute Sicherheit ohne jegliches Risiko gibt es in der Technik
nicht.
Die Berechnung der Zuverlässigkeit ist das Ziel einer
qualitativen Analyse.
© 2015 IAS, Universität Stuttgart
36
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 1 Einführung , Begriffe und Normen
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
1.2 Definition von Zuverlässigkeit und Sicherheit
1.3 Wichtige Begriffe und Bedeutungen
1.4 Normen
© 2015 IAS, Universität Stuttgart
37
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Begriff: RAMS(S)-Management nach DIN EN 50126
 Prozess bzw. Methodik zur Verhinderung von Fehlern bereits in der
Planungsphase
 Dient zur Systemspezifikation von sicherheitskritischen Systemen
 RAMS(S)-Prozess ist erst abgeschlossen, wenn System bzw. Produkt
außer Betrieb genommen und entsorgt worden ist
 Beinhaltet:
• Reliability (Zuverlässigkeit)
• Availability (Verfügbarkeit)
• Maintainability (Instandhaltbarkeit, Dauer von Reparaturen)
• Safety (Sicherheit, Gefährdungsfreiheit des Gerätes nach außen)
• Security (Sicherheit, Schutz gegen unberechtigten Zugriff)
© 2015 IAS, Universität Stuttgart
38
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Begriff: Fehler
 Fehler
• Nichterfüllung mindestens einer vorgegebenen Forderung
• Fehler entstehen durch Mensch, Material, Milieu (Umgebung), Methode,…
 Im engl. klare Unterscheidung (nach ISO 26262):
• fault: „Eine abnormale Bedingung, die ein Element scheitern lassen kann.“
• error: „Abweichung zwischen dem berechneten und dem spezifizierten Wert.“
System
© 2015 IAS, Universität Stuttgart
39
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Arten von Fehlern (1/2)
 Physikalische Fehler
• Meist stochastischen Ursprungs
• Ursachen sind physikalische oder chemische Ausfallmechanismen
oder Effekte (z.B. elektromagnetische Störungen)
• Charakterisiert durch konstante Ausfallraten:
 Inhärente Fehler
• Fehler, die schon vor Beginn des Betriebs vorhanden sind
• Oft systematische Fehler, die nicht immer offensichtlich sind:
 Pflichtenheftfehler
 Software-Entwurfsfehler
 Verdrahtungsfehler
© 2015 IAS, Universität Stuttgart
40
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Arten von Fehlern (2/2)
 Nicht inhärente Fehler
• Fehler, die erst nach der Inbetriebnahme begangen werden
• Oft kaum abzusehen bzw. zu verhindern:
 Bedienfehler
 Fehler bei Wartung und Pflege
 Absichtliche Fehler (Sabotage oder Vandalismus)
© 2015 IAS, Universität Stuttgart
41
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Fehlertypen / Fehlerübergänge
 Statischer Fehler
• Übergang in Fehlerzustand statisch, d.h., Komponente wird abrupt
defekt und bleibt defekt bis zur Reparatur
• Dient als Annahme für einfache Zuverlässigkeitsmodelle
 Drift-Fehler
• Langsamer Übergang der Systemmerkmale in einen Fehlerzustand
• Meist bei analogen, weniger bei digitalen Bauteilen
 Transienter Fehler
• Kurze Wirkungsdauer bedingt durch externe Einstreuung (z.B. EMV)
• Oft vernachlässigbar wenn Wirkungsdauer sehr gering
 Intermittierender Fehler
• Häufig auftretender transienter Fehler mit nachfolgender Ruhepause
• Oft durch Betrieb der Hardware an Belastungsgrenze
© 2015 IAS, Universität Stuttgart
42
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Umgang mit Fehlern - Maßnahmen zur….
 Fehlerprävention (fault prevention)
• Um das Auftreten von Fehlern von vornherein zu vermeiden.
 Fehlertoleranz (fault tolerance)
• Um auch mit begrenzter Anzahl von fehlerhaften Komponenten noch
die geforderte Funktion erfüllen zu können.
 Fehlerbehebung (fault removal)
• Um die Anzahl oder Auswirkungen von Fehlern zu vermindern.
 Fehlervorhersage (fault forecasting)
• Um die zukünftige Zahl von Fehlern und deren Konsequenzen
abschätzen zu können.
© 2015 IAS, Universität Stuttgart
43
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Begriff: Ausfall
 Ausfall (failure)
• Aussetzen der Ausführung einer festgelegten Aufgabe
• Übergang vom funktionsfähigen in den fehlerhaften Zustand
 Unterscheidung:
• hard failure:
Sofortiger Übergang zum völligen Versagen des Systems
• soft failure:
Übergang hin zu einer unzulässigen Abweichung (Drift)
System
© 2015 IAS, Universität Stuttgart
44
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Begriffe: Sicherer Zustand und Rückfallebene
 Sicherer Zustand
• Zustand, in dem trotz gewisser, zugelassener Ausfälle keine Gefahr
mehr vom bzw. auf das System ausgehen kann
• Beispiel: Haltezustand von Zügen
 Rückfallebene
• Sekundärsystem, das bei Ausfall des primären Systems einen Schutz
gegenüber einer Gefährdung bietet und den Totalausfall des Systems
verhindert
• Meist Aufrechterhaltung einer reduzierten Betriebsqualität
© 2015 IAS, Universität Stuttgart
45
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Übergange in einen sicheren Zustand
 fail-operational
• Grundfunktionalität wird solange aufrechterhalten, bis es möglich ist, einen
sicheren Zustand zu erreichen (auch über längere Dauer hinweg)
• System beinhaltet redundante Strukturen um den Betrieb weiterzuführen
 fail-safe
• Unmittelbarer Übergang in einen sicheren Zustand
• System bleibt bis zur Reparatur im sicheren Zustand
 fail-silent
• Sofortiges Stillhalten oder Abschalten von Teilsystemen oder Komponenten
nach Detektion einer Abweichung vom vorgegebenen Betrieb
• Ziel ist es, die Beeinflussung anderer Teilsystemen zu verhindern
© 2015 IAS, Universität Stuttgart
46
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Begriffe: Verfügbarkeit und Verlässlichkeit
 Verfügbarkeit
• Wahrscheinlichkeit, ein reparierbares System zu einem vorgegebenen
Zeitpunkt im funktionsfähigen Zustand anzutreffen
• Wesentliche Kennzahl eines Systems
 Verlässlichkeit
• Eigenschaft eines Systems die es erlaubt, volles Vertrauen in die
bereitgestellte Funktionalität zu setzen
• Überbegriff für Qualitätskriterien eines Systems
© 2015 IAS, Universität Stuttgart
47
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Übersicht Begriffe der Zuverlässigkeits-/Sicherheitstechnik
Begriff
Definition
Fehler1
(Error)
Abweichung zwischen einem berechneten Wert und dem wahren, spezifizierten
oder theoretisch richtigem Wert aufgrund eines Fehlers2 oder einer Störung1.
Fehler2
(Defect)
Nichterfüllung der Anforderungsspezifikation, Unkorrektheit.
Fehler3
(Fault)
Abweichung der tatsächlichen Ausführung von der für die Erfüllung der
Anforderungsspezifikation erforderlichen konstruktiven und fertigungstechnischen
Ausführung des Systems.
Fehler4
(Mistake)
Menschliche Handlung mit unerwünschtem Ergebnis, ein Irrtum oder Schnitzer.
Gefahr
Sachlage, bei der das Risiko größer als das Grenzrisiko ist, wobei unter
Grenzrisiko das größte noch vertretbare Risiko verstanden wird.
Korrektheit
Erfüllung der Anforderungsspezifikation. Übereinstimmung zwischen realisierter
und spezifizierter Funktion.
Risiko
Möglichkeit, Schaden zu erleiden.
Risiko = Schadensausmaß ∗ Wahrscheinlichkeit des Schadeneintritts
© 2015 IAS, Universität Stuttgart
48
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Übersicht Begriffe der Zuverlässigkeits-/Sicherheitstechnik
Begriff
Definition
Schaden
Nachteil durch Verletzung von Rechtsgütern aufgrund eines bestimmten
technischen Vorgangs oder Zustandes.
Schutz
Verringerung des Risikos durch Maßnahmen, die entweder die Eintrittshäufigkeit
oder das Ausmaß des Schadens oder beide einschränken.
Sicherheit
Sachlage, bei der das Risiko kleiner als das Grenzrisiko ist.
Störung1
(Interference)
Vorübergehende Beeinträchtigung einer Funktion.
Störung2
(Deficiency)
Fehlende, fehlerhafte oder unvollständige Erfüllung einer geforderten Funktion.
Validation
Nachweis, dass ein System seinen Erfordernissen genügt.
Verifikation
Nachweis, dass eine Betrachtungseinheit die Anforderungsspezifikation
vollständig erfüllt.
Versagen
Verhalten eines Systems, das nicht der Anforderungsspezifikation entspricht.
Robustheit
Fähigkeit einer Betrachtungseinheit, auch bei Verletzung der spezifizierten
Randbedingungen vereinbarte Funktionen zu erfüllen.
© 2015 IAS, Universität Stuttgart
49
1.3 Wichtige Begriffe und Bedeutungen
ZSA
Frage zu Kapitel 1.3
Welchen Aussagen stimmen Sie zu?
□ Ein Fehler ist ein Zustand.
□ Ein Fehler hat immer einen Ausfall zur Folge.
□ Verifikation ist der Nachweis, dass ein System den Erfordernissen genügt.
□ Verfügbarkeit steht für Sicherheit + Zuverlässigkeit + Verlässlichkeit.
© 2015 IAS, Universität Stuttgart
50
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 1 Einführung , Begriffe und Normen
1.1 Einführung in die Zuverlässigkeits- und Sicherheitstechnik
1.2 Definition von Zuverlässigkeit und Sicherheit
1.3 Wichtige Begriffe und Bedeutungen
1.4 Normen
© 2015 IAS, Universität Stuttgart
51
1.4 Normen
ZSA
Allgemeines zu Normen
 Norm: Regel, Maßstab, Richtung,…
 Normung: Formulierung, Veröffentlichung und Anwendung von Regeln,
Leitlinien und Merkmalen durch eine anerkannte Organisation
 Nationale Normung:
• Deutsches Institut für Normung (DIN)
• Verein Deutscher Ingenieure (VDI)
 EU-Normung:
• Europäisches Komitee für Normung (CEN)
• Europäisches Komitee für elektrotechnische Normung (CENLEC)
 Internationale Normung:
• Internationale Organisation für Normung (ISO)
• Institut of Electrical and Electronics Engineers (IEEE)
© 2015 IAS, Universität Stuttgart
52
1.4 Normen
ZSA
Nationale Normungsarbeit nach DIN
 Historie
• 1917 Gründung „Normenausschuss der deutschen Industrie“
• 1926 Umbenennung zu „Deutscher Normenausschuss“ und Gründung
von zusätzlichen Arbeitsbereichen für Krankenhäuser, Bürowesen etc.
• 1975 Zusammenfassung aller Arbeitsbereiche zum „Deutschen Institut
für Normung“ (DIN) und Gründung von Normenausschüsse, z.B.:
 Normenausschuss Automobiltechnik (NAAutomobil)
 Normenstelle Elektrotechnik (NE)
 DIN hat ca.1800 Mitglieder aus Unternehmen, Behörden oder Wissenschaft
 Aufgabe ist die Erarbeitung von Normen innerhalb “interessierter Kreise“, die
sich aus Vertretern der verschiedenen Normenausschüsse bilden
 Jeder kann einen Antrag auf Normung stellen
© 2015 IAS, Universität Stuttgart
53
1.4 Normen
ZSA
Umgang mit Normen
 Normen sind kein Gesetz, d.h., deren Einhaltung ist nicht verbindlich!
 Normen repräsentieren den zu diesem Zeitpunkt aktuellen Stand der Technik
 Stand der Technik entspricht dem, was heute technisch machbar ist und
tatsächlich mindestens einmal realisiert wurde
 Für neue sicherheitskritische Systeme:
Achtung:
 Im Produkthaftungsfall (nicht Schäden am Produkt, sondern Schäden durch
das Produkt) ist nicht der Stand der Technik, sondern der Stand von
Wissenschaft und Technik nachzuweisen
 Stand von Wissenschaft und Technik entspricht dem, was heute
erkenntnistheoretisch erreichbar ist (höchstes Niveau)
 Für neue sicherheitskritische Systeme:
© 2015 IAS, Universität Stuttgart
54
1.4 Normen
ZSA
Chancen und Vorteile von Normen für ein Unternehmen
 Kostensenkungen in Entwicklung und Produktion
• Massenproduktion
• Globaler Einkauf
• Verminderte Anpassungskosten
• Verkürzung der Entwicklungszeiten
 Wettbewerbsvorteile gegenüber Konkurrenten
• Wissens- und Zeitvorteile
• Imagesteigerung
• Zugang zu neuen Märkten
 Klar definierte Schnittstellen sowohl intern als auch zu Kunden und Zulieferern
 Verbesserung der Kundenkontakte und Anreize für neue Kunden
© 2015 IAS, Universität Stuttgart
55
1.4 Normen
ZSA
Sicherheitsgrundnorm DIN EN 61508
 Funktionale Sicherheit sicherheitsbezogener elektrischer / elektronischer /
programmierbar elektronischer Systeme
 Aufbau (Stand: 02/2011):
• Teil 0: Funktionale Sicherheit
• Teil 1: Allgemeine Anforderungen
• Teil 2: Anforderungen an sicherheitsbezogene elektrische, elektronischer
und programmierbar elektronischer Systeme
• Teil 3: Anforderungen an Software
• Teil 4: Begriffe und Abkürzungen
• Teil 5: Beispiele zur Ermittlung der Stufe der Sicherheitsintegrität (SIL)
• Teil 6: Anwendungsrichtlinie für IEC 61508-2 und IEC 61508-3
• Teil 7: Überblick über Verfahren und Maßnahmen
© 2015 IAS, Universität Stuttgart
56
1.4 Normen
ZSA
Ausschnitt DIN EN 61508 (1/3)
© 2015 IAS, Universität Stuttgart
57
1.4 Normen
ZSA
Ausschnitt
DIN EN 61508 (2/3)
© 2015 IAS, Universität Stuttgart
58
1.4 Normen
ZSA
Ausschnitt DIN EN 61508 (3/3)
© 2015 IAS, Universität Stuttgart
59
1.4 Normen
ZSA
Beispiel: ISO 26262 (abgeleitet aus DIN EN 61508)
 Sicherheitsnorm zur funktionalen Sicherheit von Kraftfahrzeugen
 Inkrafttreten November 2011 (aktuell Überarbeitung zu Version 2 in 2017/18)
 Im Beuth-Verlag erschienen, Kosten gesamt: 1.262,70 Euro
 Umfang ca. 400 Seiten in 10 Teilen auf engl. Sprache:
• Teil 1: Vokabular
• Teil 2: Management der funktionalen Sicherheit
 Projektübergreifendes Sicherheitsmanagement
 Sicherheitsmanagement während der Entwicklung
 Aktivitäten nach Produktfreigabe
© 2015 IAS, Universität Stuttgart
60
1.4 Normen
ZSA
Beispiel: ISO 26262 (abgeleitet aus DIN EN 61508)
• Teil 3: Konzeptphase
 Definition des Systems
 Identifikation und Analyse von Gefährdungen
 Risikoabschätzung
• Teil 4: Produktentwicklung auf Systemebene
• Teil 5: Produktentwicklung auf Hardwareebene
• Teil 6: Produktentwicklung auf Softwareebene
© 2015 IAS, Universität Stuttgart
61
1.4 Normen
ZSA
Beispiel: ISO 26262 (abgeleitet aus DIN EN 61508)
• Teil 7: Anforderungen an Produktion, Betrieb und Außerbetriebnahme
 Installation und Stilllegung
 Wartung, Pflege und Reparatur
• Teil 8: Unterstützende Prozesse
 Konfigurations- und Änderungsmanagement
 Verifikation und Dokumentation
• Teil 9: SIL- und sicherheitsorientierte Analysen
 Unterteilung in Sicherheitsanforderungsstufen (SIL)
 Möglichkeiten zur Reduzierung von Gefahrensituationen
• Teil 10: Guideline
 Anwendungsbeispiele
 Weiterführende Informationen (Erläuterungen)
© 2015 IAS, Universität Stuttgart
62
1.4 Normen
ZSA
Weitere Beispiele abgeleiteter Normen:
DIN EN 61511
Funktionale Sicherheit – Sicherheitstechnische Systeme für Prozessindustrie
Stand: 2005-05
DIN EN ISO 13849
Sicherheit von Maschinen – Sicherheitsbezogene Teile von Steuerungen
Stand: 2008-12
Teil 1: Allgemeine Gestaltungsgrundsätze
Teil 2: Validierung
DIN EN ISO 50129
Bahnanwendungen – Telekommunikationstechnik, Signaltechnik und
Datenverarbeitungssysteme – Sicherheitsrelevante elektronische Systeme für
Signaltechnik
Stand: 2003-12
© 2015 IAS, Universität Stuttgart
63
1.4 Normen
ZSA
Weitere Beispiele abgeleiteter Normen:
VDI/VDE 3542
Sicherheitstechnische Begriffe für Automatisierungssysteme
Stand: 2000-10
Teil 1: Qualitative Begriffe
Teil 2: Quantitative Begriffe und Definitionen
Teil 3: Anwendungshinweise und Beispiele
Teil 4: Zuverlässigkeit und Sicherheit komplexer Systeme (Begriffe)
DIN 40041
Zuverlässigkeit; Begriffe
Stand: 1990-12
© 2015 IAS, Universität Stuttgart
64
1.4 Normen
ZSA
Frage zu Kapitel 1.2
Was ist der Kerninhalt der Norm ISO 26262?
Was ist der grundsätzliche Unterschied zwischen den Normen DIN EN 61508
und der Norm DIN EN 62061?
© 2015 IAS, Universität Stuttgart
65
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Gliederung
§ 1 Einführung, Begriffe und Normen
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
§ 3 Fehlerbaumanalyse (FTA)
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
§ 5 Softwarezuverlässigkeit
§ 6 Zuverlässigkeits- und Sicherheitstechnik
§ 7 Übungsaufgaben
© 2015 IAS, Universität Stuttgart
66
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
2.2 Lebensdauerverteilungen
2.3 Verfügbarkeit von Systemen
2.4 Zuverlässigkeitsblockdiagramm
© 2015 IAS, Universität Stuttgart
67
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Einführung - Wahrscheinlichkeit zufälliger Ereignisse
 Wahrscheinlichkeitsrechnung beschreibt ein Zufallsexperiment, das unter
bestimmten Randbedingungen durchgeführt wird und dessen Ergebnis über ein
Ereignis E charakterisiert wird
 Beispiele für zufällige Ereignisse:
• Werfen eines Würfels
• Verhalten einer Komponenten innerhalb/außerhalb eines definierten Bereichs
• Zustand eines Systems (funktionsfähig/nicht funktionsfähig)
 Wahrscheinlichkeit P(E) für die ein Ereignis E auftritt:
𝐏 𝐄 =
𝐀𝐧𝐳𝐚𝐡𝐥 𝐝𝐞𝐫 𝐳𝐮 𝐄 𝐠𝐞𝐡ö𝐫𝐞𝐧𝐝𝐞𝐧 𝐄𝐫𝐠𝐞𝐛𝐧𝐢𝐬𝐬𝐞
𝐀𝐧𝐳𝐚𝐡𝐥 𝐚𝐥𝐥𝐞𝐫 𝐄𝐫𝐠𝐞𝐛𝐧𝐢𝐬𝐬𝐞
© 2015 IAS, Universität Stuttgart
68
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Kombination von Ereignissen – Boolesche Modellbildung
 Ereignisse können miteinander verknüpft werden, um so zu neuen Ereignissen
zu führen
 Verknüpfung erfolgt über logische Gatter, die als elementare Bausteine einer
Schaltung logische Operationen durchführen
 Eine logische Operation ist eine boolesche Funktion über die Menge M = {0,1}
und kann mithilfe von Wertetabellen definiert werden
 Ein Logikgatter repräsentiert dabei eine Funktion:
𝒙𝟏
ƒ
𝐲
𝒙𝟐
© 2015 IAS, Universität Stuttgart
69
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Grundgatter der Boolschen Modellbildung (1/3)
 Normung nach IEC 60617 – „Graphische Symbole für Schaltpläne“
Schaltzeichen (IEC 60617)
Negation (NOT)
𝒙𝟏
1
𝒚
𝒙𝟏
𝒚
1
0
0
1
𝒙𝟏 𝒙𝟐
Disjunktion (OR)
𝒙𝟏
Wertetabelle
≥1
𝒙𝟐
© 2015 IAS, Universität Stuttgart
𝒚
Funktion
𝐲 = ¬𝐱 𝟏
𝐲 = 𝐱𝟏
𝒚
0
0
0
0
1
1
1
0
1
1
1
1
𝐲 = (𝐱 𝟏 ∨ 𝐱 𝟐 )
70
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Grundgatter der Boolschen Modellbildung (2/3)
Schaltzeichen (IEC 60617)
Konjunktion (AND)
Wertetabelle
𝒙𝟏 𝒙𝟐
𝒙𝟏
&
𝒚
𝒙𝟐
Antivalenz (XOR)
𝒙𝟏
=1
𝒙𝟐
© 2015 IAS, Universität Stuttgart
𝒚
Funktion
𝒚
0
0
0
0
1
0
1
0
0
1
1
1
𝒙𝟏 𝒙𝟐
𝒚
0
0
0
0
1
1
1
0
1
1
1
0
𝐲 = 𝐱𝟏 ∧ 𝐱𝟐
𝐲 = 𝐱𝟏 ∗ 𝐱𝟐
𝐲 = 𝐱 𝟏 ⨁𝐱 𝟐
71
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Grundgatter der Boolschen Modellbildung (3/3)
Schaltzeichen (IEC 60617)
NAND
Wertetabelle
𝒙𝟏 𝒙𝟐
𝒙𝟏
&
𝒚
𝒙𝟐
NOR
𝒙𝟏
≥𝟏
𝒙𝟐
© 2015 IAS, Universität Stuttgart
𝒚
Funktion
𝒚
0
0
1
0
1
1
1
0
1
1
1
0
𝒙𝟏 𝒙𝟐
𝒚
0
0
1
0
1
0
1
0
0
1
1
0
𝐲 = 𝐱𝟏 ∧ 𝐱𝟐
𝐲 = 𝐱𝟏 ∗ 𝐱𝟐
𝐲 = 𝐱𝟏 ∨ 𝐱𝟐
72
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Boolesche Modellbildung – Axiome der Booleschen Algebra
 Kommutativgesetz:
𝐱𝟏 ∧ 𝐱𝟐 = 𝐱𝟐 ∧ 𝐱𝟏
𝐱𝟏 ∨ 𝐱𝟐 = 𝐱𝟐 ∨ 𝐱𝟏
 Assoziativgesetz:
𝐱𝟏 ∧ 𝐱𝟐 ∧ 𝐱𝟑 = 𝐱𝟏 ∧ 𝐱𝟐 ∧ 𝐱𝟑
𝐱𝟏 ∨ 𝐱𝟐 ∨ 𝐱𝟑 = 𝐱𝟏 ∨ 𝐱𝟐 ∨ 𝐱𝟑
 Distributivgesetz:
𝐱𝟏 ∨ 𝐱𝟐 ∧ 𝐱𝟑 = 𝐱𝟏 ∨ 𝐱𝟐 ∧ 𝐱𝟏 ∨ 𝐱𝟑
𝐱𝟏 ∧ 𝐱𝟐 ∨ 𝐱𝟑 = 𝐱𝟏 ∧ 𝐱𝟐 ∨ 𝐱𝟏 ∧ 𝐱𝟑
 Idempotenzgesetz:
𝐱∧𝐱 =𝐱
𝐱∨𝐱 =𝐱
 De Morgansches Gesetz:
𝐱𝟏 ∨ 𝐱𝟐 = 𝐱𝟏 ∧ 𝐱𝟐
𝐱𝟏 ∧ 𝐱𝟐 = 𝐱𝟏 ∨ 𝐱𝟐
 Weiter gilt:
© 2015 IAS, Universität Stuttgart
𝐱∨𝟎 =𝐱
𝐱∨𝟏 =𝟏
𝐱∨𝐱 =𝟏
𝐱∧𝟏 =𝐱
𝐱∧𝟎 =𝟎
𝐱∧𝐱 =𝟎
73
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Zuverlässigkeit als Wahrscheinlichkeit
 Quantitative Methoden sind eng mit Begriffen und Verfahren der Statistik und
Wahrscheinlichkeit verknüpft
 Ausfallzeiten von Bauteilen sind gewisser Stochastik und Streuung
unterworfen
 Einflussnahme auf die Ursachen der Streuung sind begrenzt
 Ein Ausfall lässt sich daher nicht über rein deterministische Verfahren
bestimmen
 Kenntnis der Wahrscheinlichkeitsrechnung notwendig, u.a.:
• Ausfallrate
• Ausfalldichte
• Ausfallwahrscheinlichkeit
• Überlebenswahrscheinlichkeit / Zuverlässigkeit
© 2015 IAS, Universität Stuttgart
74
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Zustand eines technischen Systems
 Zustand des Systems zum Zeitpunkt t:
UP = 1
DOWN = 0
t
(t = 0)
(t = T)
 Lebensdauer T eines technischen Systems ist die Zeitspanne für t ≥ 0, von der
(ersten) Inbetriebnahme bei t = 0 bis hin zum Ausfall des Systems bei t = T
𝐗 𝐭 =
© 2015 IAS, Universität Stuttgart
𝟏,
𝟎,
𝐭<𝐓
𝐭≥𝐓
75
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Ausfallwahrscheinlichkeit F(t)
 Lebensdauer T ist eine reelle Zufallsgröße mit einer gewissen
Verteilungsfunktion
 Verteilungsfunktion heißt Ausfallwahrscheinlichkeit F(t) und stellt die
Wahrscheinlichkeit P so dar, dass die Zufallsgröße T kleiner oder gleich
eines vorgegebenen Wertes t ist (probability of failure) :
𝐅 𝐭 = 𝐏(𝐓 ≤ 𝐭)
 F(t) ist die Wahrscheinlichkeit für das Eintreten eines Systemausfalls im
Intervall [0,t] mit:
© 2015 IAS, Universität Stuttgart
76
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Ausfalldichte f(t)
 Häufigkeit der Ausfälle, d.h., die zeitliche Ableitung der Ausfallwahrscheinlichkeit
wird als Ausfalldichte f(t) bezeichnet (failure density) :
𝐟 𝐭 =
𝐝𝐅(𝐭)
𝐝𝐭
 Für die Ausfalldichte gilt:
𝐟 𝐭 𝐢𝐬𝐭
© 2015 IAS, Universität Stuttgart
= 𝟎,
≥ 𝟎,
𝐭<𝟎
𝐭≥𝟎
77
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Überlebenswahrscheinlichkeit / Zuverlässigkeit R(t)
 Zuverlässigkeit R(t) stellt die Wahrscheinlichkeit P so dar, dass die Zufallsgröße
T größer eines vorgegebenen Wertes t ist (reliability):
𝐑 𝐭 = 𝐏(𝐓 > 𝐭)
 R(t) ist die Wahrscheinlichkeit für keinen Systemausfall im Intervall [0,t], d.h.,
die Zuverlässigkeit ist das Gegenereignis zur Ausfallwahrscheinlichkeit mit:
𝐑 𝐭=𝟎 =𝟏
𝐑 𝐭→∞ =𝟎
© 2015 IAS, Universität Stuttgart
78
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Ausfallrate λ(t)
 Ausfallrate λ(t) ist die Ausfallneigung eines Systems in Abhängigkeit der Zeit
 Kenngröße, die die Wahrscheinlichkeit eines Systemausfalls bezogen auf die
gesamte Lebensdauer T darstellt (failure rate):
ᵧ
Ausfallrate (t)
Frühausfälle
(Bereich 1)
Zufallsausfälle
(Bereich 2)
z.B. Montage-, Fertigungs-, z.B. verursacht durch BedienungsWerkstoff- und eklatante
oder Wartungsfehler,
Konstruktionsfehler
Schmutzpartikel
Verschleiß- &
Ermüdungsfehler
(Bereich 3)
z.B. Dauerbruch,
Alterung, Grübchen
Lebensdauer t
© 2015 IAS, Universität Stuttgart
79
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Ausfallraten von Komponenten (1/2)
 Unternehmen und Forschungsinstitute veröffentlichen Datenbanken oder
(Online-) Handbücher zur Bestimmung der Ausfallraten von Komponenten:
• Siemens (SN29500)
• Union Technique de l‘Electricite (RDF 2000)
• Reliability Information Center (EPRD-97)
 Beispiel: EPRD-97
Quelle: www.theriac.org
© 2015 IAS, Universität Stuttgart
80
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Ausfallraten von Komponenten (2/2)
 Bei den in Dokumenten genannten Werte handelt es sich um bekannte,
konstante Ausfallraten für Komponenten, die mit Qualitäts- und Einsatzfaktoren
modifiziert werden um Unsicherheiten zu berücksichtigen
 Die Angaben sind daher in der Regel (erheblich) größer als im konkreten
Einsatz und variieren für bestimmte Komponenten je nach Herausgeber
deutlich
 Relativ gesicherte Angaben für eine bestimmte Komponente können direkt den
„Reliability Reports“ der Hersteller entnommen werden
 In 1970er und 1980er versuchte die Projekt-Gruppe EuReDatA (European
Reliability Data Banks Association), den Austausch und die Zusammenfassung
von Datenbeständen zwischen Unternehmen, Behörden und Hochschulen zu
fördern
© 2015 IAS, Universität Stuttgart
81
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Typische Ausfallratenbereiche
(nach A.E. Green und A.J. Bourne : „Reliability Technologie“)
10-9
10-8
10-7
10-6
10-5
10-4
10-3
10-2
10-1
100
λ
Halbleiter
mech. Bauteile
elektr. Bauteile
Stromschalter
Transformatoren
Transistoren
Große elektr. Systeme ohne Redundanz
Große elektr. Systeme mit Redundanz
Große elektr. Systeme mit Redundanz und Diversität
© 2015 IAS, Universität Stuttgart
82
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
ZSA
Frage zu Kapitel 2.1
Welchen Aussagen stimmen Sie zu?
□
□
□
□
Die Zuverlässigkeit eines Bauteils weist direkt bei Inbetriebnahme
eine Wahrscheinlichkeit von 100% auf.
Mit steigender Ausfallwahrscheinlichkeit sinkt die Zuverlässigkeit.
In frühen Stadien eines Produkts ist mit einer hohen Ausfallrate zu
rechnen.
Ausfälle lassen sich über rein deterministische Verfahren
berechnen.
© 2015 IAS, Universität Stuttgart
83
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
2.2 Lebensdauerverteilungen
2.3 Verfügbarkeit von Systemen
2.4 Zuverlässigkeitsblockdiagramm
© 2015 IAS, Universität Stuttgart
84
2.2 Lebensdauerverteilungen
ZSA
Einführung
 Lebensdauer ist die Zeit, in der eine Einheit betriebsbereit ist
 Lebensdauer selbst besitzt eine Lebensdauerverteilung, die als quantitative
Methode zur Prognose der Zuverlässigkeit verwendet wird
 Kontinuierliche Lebensdauerverteilungen:
• Exponentialverteilung
• Weibullverteilung
• Erlang-Verteilung
 Diskrete Lebensdauerverteilungen:
• Binomialverteilung
• Poisson-Verteilung
© 2015 IAS, Universität Stuttgart
85
2.2 Lebensdauerverteilungen
ZSA
Exponentialverteilung – Allgemeines
 Moderne Wahrscheinlichkeitsrechnung wurde 1933 von
dem russischen Mathematiker Andrei Kolmogorow
(1903 - 1987) in seinem Buch „Grundbegriffe der
Quelle: www.heise.de, 2014
Wahrscheinlichkeitsrechnung“ beschrieben
 1920-1925 Studium am chemisch technischen Institut der staatlichen
Lomonossow-Universität Moskau
 1929 Promotion, 1931 Professur auf dem Gebiet der Wahrscheinlichkeit
 1933 Direktor des mathematischen Instituts
 Exponentialverteilung beschreibt eine stetige Wahrscheinlichkeitsverteilung
über die Menge der positiven reellen Zahlen.
 Lebensdauer von elektrischen Bauteilen und Systemen mit sehr geringer
Alterung bzw. Verschleiß
© 2015 IAS, Universität Stuttgart
86
2.2 Lebensdauerverteilungen
ZSA
Exponentialverteilung – Gleichungen
 Annahme einer konstanten Ausfallrate, d.h., die Restlebensdauer hängt nicht
von der bisherigen Lebensdauer ab
 Es gilt für t ≥ 0:
• Ausfallrate:
𝛌 𝐭 = 𝛌𝟎 = 𝐜𝐨𝐧𝐬𝐭.
• Ausfalldichte:
𝐟 𝐭 = 𝛌𝟎 ∗ 𝐞−𝛌𝟎 𝐭
• Ausfallwahrscheinlichkeit:
𝐅 𝐭 = 𝟏 − 𝐞−𝛌𝟎𝐭
• Zuverlässigkeit:
𝐑 𝐭 = 𝐞−𝛌𝟎𝐭
© 2015 IAS, Universität Stuttgart
87
2.2 Lebensdauerverteilungen
ZSA
Exponentialverteilung – Simulation
Dichteverteilung
 Ausfalldichte:
Zeit [Jahre]
Zuverlässigkeit
Ausfallwahrscheinlichkeit
 Zuverlässigkeit und Ausfallwahrscheinlichkeit:
Zeit [Jahre]
© 2015 IAS, Universität Stuttgart
Zeit [Jahre]
88
2.2 Lebensdauerverteilungen
ZSA
Exponentialverteilung - Rechenbeispiel
Die Lebensdauer eines Bauteils sei exponentiell-verteilt mit λ0 = 0,5*10-5 h-1.
a) Wie groß ist die Wahrscheinlichkeit, dass das Bauteil innerhalb eines Jahres
ausfällt?
𝐏 𝐓 < 𝟏𝐚 = 𝐅 𝟏𝐚 = 𝐅 𝟖. 𝟕𝟔𝟎𝐡 = 𝟏 − 𝐞−𝟎,𝟓 ∗𝟏𝟎
−𝟓 𝒉−𝟏 ∗ 𝟖.𝟕𝟔𝟎𝐡
= 𝟎, 𝟎𝟒𝟐𝟖 ≈ 𝟒, 𝟑%
b) Wie große ist die Wahrscheinlichkeit, dass das Bauteil zwischen dem 5. und
10. Jahr ausfällt?
𝐏 𝟓𝐚 ≤ 𝐓 ≤ 𝟏𝟎𝐚 = 𝐅 𝟏𝟎𝐚 − 𝐅 𝟓𝐚 = 𝟎, 𝟑𝟓𝟓 − 𝟎, 𝟏𝟗𝟕 = 𝟎, 𝟏𝟓𝟖 ≈ 𝟏𝟓, 𝟖%
© 2015 IAS, Universität Stuttgart
89
2.2 Lebensdauerverteilungen
ZSA
Weibullverteilung - Allgemeines
 Benannt nach Waloddi Weibull (1887 – 1979)
 Schwedischer Mathematiker und Ingenieur
 1932 Promotion an der Universität Uppsala
Quelle: www.weibullnews.com, 2014
 1941 Professur für technische Physik an der königlichen technischen
Hochschule Stockholm
 Verfasste diverse Abhandlungen über die Materialfestigkeit, Materialermüdung
und das Bruchverhalten von Festkörpern
 Veröffentlichung der Weibull-Verteilung in 1951:
• Beschreibung von Lebensdauerverteilungen mit monoton fallender,
konstanter und monoton wachsender Ausfallrate möglich
• Findet Einsatz bei lebensdauerbeeinflussenden Lastmerkmalen wie
Spannung oder Kraft, sowie bei dynamischen Festigkeitsversuchen
© 2015 IAS, Universität Stuttgart
90
2.2 Lebensdauerverteilungen
ZSA
Weibullverteilung – Beschreibung
 Charakterisierung über Parameter:
• Ausfallsteilheit bzw. Formparameter b
 Frühausfälle (1) mit b < 1
 Zufallsausfälle (2) mit b = 1
 Verschließ-/Ermüdungs-Fehler (3) mit b > 1
• Charakteristische Lebensdauer bzw. Lageparameter T
 Praxis typ. Zeitspanne, in der 63% aller Komponenten (Einheiten
eines Systems, Bauteile einer Serienproduktion,…) ausfallen
 Beispiel für Komponenten mit typischem
• Frühausfall-Verhalten:
• Verschleiß-/Ermüdungs-Fehler-Verhalten:
© 2015 IAS, Universität Stuttgart
91
2.2 Lebensdauerverteilungen
ZSA
Weibullverteilung – Gleichungen
 Es gilt für t ≥ 0:
𝐛−𝟏
• Ausfallrate:
𝐛
𝐭
𝛌 𝐭 = ∗
𝐓 𝐓
𝐛−𝟏
• Ausfalldichte:
𝐛
𝐭
𝐟 𝐭 = ∗
𝐓 𝐓
• Ausfallwahrscheinlichkeit:
• Zuverlässigkeit:
© 2015 IAS, Universität Stuttgart
𝐅 𝐭 =𝟏−𝐞
𝐑 𝐭 =𝐞
∗𝐞
𝐭 𝐛
−
𝐓
𝐭 𝐛
− 𝐓
𝐭 𝐛
− 𝐓
92
2.2 Lebensdauerverteilungen
ZSA
Weibullverteilung - Simulation
Zuverlässigkeit
Ausfallwahrscheinlichkeit
 Variation der charakteristischen Lebensdauer T:
Zeit [Jahre]
Zeit [Jahre]
Zuverlässigkeit
Ausfallwahrscheinlichkeit
 Variation der Ausfallsteilheit b:
Zeit [Jahre]
© 2015 IAS, Universität Stuttgart
Zeit [Jahre]
93
2.2 Lebensdauerverteilungen
ZSA
Weibullverteilung - Rechenbeispiel
Ein System sei weibull-verteilt mit dem Formparameter b = 2.
Welche charakteristische Lebensdauer T liegt vor, wenn das System im ersten
Jahr eine Zuverlässigkeit von 95% aufweist?
𝐑 𝟖. 𝟕𝟔𝟎𝐡 = 𝐞
𝟖. 𝟕𝟔𝟎𝐡
𝐓
𝐓=
© 2015 IAS, Universität Stuttgart
𝟖.𝟕𝟔𝟎𝐡 𝟐
−
𝐓
= 𝟎, 𝟗𝟓
𝟐
= −𝐥𝐧(𝟎, 𝟗𝟓)
𝟖. 𝟕𝟔𝟎𝐡
−𝐥𝐧(𝟎, 𝟗𝟓)
≈ 𝟑𝟖. 𝟔𝟕𝟗𝐡
94
2.2 Lebensdauerverteilungen
ZSA
Erlang-Verteilung - Allgemeines
 Entwickelt von Agner Krarup Erlang (1878 – 1929)
 Dänischer Mathematiker und Ingenieur
 1896 – 1901 Studium an der Universität Kopenhagen
Quelle: de.wikipedia.org, 2014
 Nach verschiedenen Lehrtätigkeiten ab 1908 Entwicklungsingenieur bei der
Kopenhagener Telefongesellschaft
 Veröffentlichung der Erlang-Verteilung in 1917 zur Beschreibung der
statistischen Modellierung von Intervall-Längen zwischen Telefonanrufen
 Einsatz der Erlang-Verteilung:
• Vorwiegend im Zusammenhang mit der Warteschlangen- bzw.
Bedienungs-Theorie und Schalt-Redundanzen
• Hier: Betrachtung von n-Stufen mit derselben konstanten Ausfallrate λ0
© 2015 IAS, Universität Stuttgart
95
2.2 Lebensdauerverteilungen
ZSA
Erlang-Verteilung - Gleichungen
 Es gilt für t ≥ 0:
• Ausfallrate:
𝛌 𝐭 ≝ 𝛌𝟎
• Ausfalldichte:
(𝛌𝟎 ∗ 𝐭)𝐧−𝟏
𝐟 𝐭 = 𝛌𝟎 ∗
∗ 𝐞−𝛌𝟎 𝐭
𝐧−𝟏 !
𝐧−𝟏
• Ausfallwahrscheinlichkeit:
𝐅 𝐭 =𝟏−
𝐞−𝛌𝟎𝐭
∗
𝐢=𝟎
𝐧−𝟏
• Zuverlässigkeit:
𝐑 𝐭 =
𝐞−𝛌𝟎𝐭
∗
𝐢=𝟎
© 2015 IAS, Universität Stuttgart
𝛌𝟎 ∗ 𝐭
𝐢!
𝛌𝟎 ∗ 𝐭
𝐢!
𝐢
𝐢
96
2.2 Lebensdauerverteilungen
ZSA
Erlang-Verteilung – Simulation
Zuverlässigkeit
Ausfallwahrscheinlichkeit
 Betrachtung von verschiedenen n-Stufen von Schaltredundanzen
Zeit [Jahre]
© 2015 IAS, Universität Stuttgart
Zeit [Jahre]
97
2.2 Lebensdauerverteilungen
ZSA
Erlang-Verteilung - Rechenbeispiel
Zur Sicherstellung der Stromversorgung einer Anlage werden zwei gleiche
Generatoren als Standby-System mit einer Ausfallrate von λ0 = 10-4 h-1 eingesetzt.
Die Generatoren werden alle 14 Tage gewartet. Welche Zuverlässigkeit liegt
innerhalb der Wartungsintervalle vor?
𝐧−𝟏
𝐑 𝐭 = 𝐞−𝛌𝟎𝐭 ∗
𝐢=𝟎
𝟐−𝟏
𝐑 𝐭 = 𝐞−𝛌𝟎𝐭 ∗
𝐢=𝟎
=𝐞
𝛌𝟎 ∗ 𝐭
𝐢!
𝛌𝟎 ∗ 𝐭 𝐢
𝛌𝟎 ∗ 𝐭
= 𝐞−𝛌𝟎𝐭 ∗ 𝟏 +
𝐢!
𝟏!
−𝟏𝟎−𝟒 𝐡−𝟏 𝟑𝟑𝟔𝐡
© 2015 IAS, Universität Stuttgart
𝐢
𝟏𝟎−𝟒 𝐡−𝟏 ∗ 𝟑𝟑𝟔𝐡
∗ 𝟏+
= 𝟎, 𝟗𝟗𝟗𝟒 = 𝟗𝟗, 𝟗𝟒%
𝟏!
98
2.2 Lebensdauerverteilungen
ZSA
Binomialverteilung - Allgemeines
 Erste Diskussion der Verteilung von Blaise Pascal (1623 – 1662)
 Französischer Mathematiker, Physiker und Philosoph
 1654 „Geburtsstunde der Wahrscheinlichkeitsrechnung“
Quelle: de.wikipedia.org, 2014
• Untersuchung der Gewinnchancen bei Würfelspielen
• Veröffentlichung einer Abhandlung mit Beschreibung der
Binomialkoeffizienten
 Vollständige Beschreibung von Jakob I. Bernoulli (1655 – 1705)
 Schweizer Mathematiker und Physiker
 Baute seine Abhandlungen auf den Diskussionen Pascals auf
Quelle: de.wikipedia.org, 2014
 Behandelte Prozesse, mit denen die Anzahl für Erfolge bei einer Serie
von gleichen Versuchen beschrieben werden konnten
© 2015 IAS, Universität Stuttgart
99
2.2 Lebensdauerverteilungen
ZSA
Binomialverteilung - Beschreibung
 Diskrete Lebensdauerverteilung, die bei einem Experiment mit der
Erfolgswahrscheinlichkeit bzw. dem Merkmal p und der Anzahl bzw. Serie von
gleichartigen und unabhängigen Versuchen n beschreibt, mit welcher
Wahrscheinlichkeit genau k Erfolge erzielt werden können
 Es gilt für eine Zufallsvariable X und n ≥ k mit n, k ≥ 0:
• Verteilungsdichte:
• Binomialkoeffizient:
© 2015 IAS, Universität Stuttgart
𝐧
𝑷(𝑿 = 𝐤) =
∗ 𝐩𝐤 ∗ 𝟏 − 𝐩
𝐤
𝐧−𝐤
𝐧
𝐧!
=
𝐤
𝐤! ∗ 𝐧 − 𝐤 !
100
2.2 Lebensdauerverteilungen
ZSA
Binomialverteilung – Simulation
 Verteilungsdichte ordnet den natürlichen Zahlen k bestimmte
Wahrscheinlichkeitswerte zu
 Simulation der Wahrscheinlichkeitsverteilung bei n = 100 Versuchen und
Wahrscheinlichkeit
veränderlicher Erfolgswahrscheinlichkeit p
k
© 2015 IAS, Universität Stuttgart
101
2.2 Lebensdauerverteilungen
ZSA
Binomialverteilung – Zuverlässigkeitsberechnung
 Einsatz zur Berechnung der Zuverlässigkeit von „mvn–Systemen“
 Redundante Systeme (Majoritätsredundanz), bei denen m von n
Komponenten funktionieren müssen (z.B. 2 von 3)
1
2
3
Mehrheitsentscheider
(„2 von 3“)
Schalter
 Voraussetzung ist, dass dabei alle Komponenten dieselbe Ausfallrate
besitzen und somit identische Zuverlässigkeitswerte p aufweisen
 Es gilt:
𝐧
𝐑 𝐦𝐯𝐧 =
𝐤=𝐦
© 2015 IAS, Universität Stuttgart
𝐧
∗ 𝐩𝐤 ∗ 𝟏 − 𝐩
𝐤
𝐧−𝐤
102
2.2 Lebensdauerverteilungen
ZSA
Poisson-Verteilung - Allgemeines
 Benannt nach Siméon Denis Poisson (1781 – 1840)
 Französischer Mathematiker und Physiker
Quelle: de.wikipedia.org, 2014
 1798 – 1800 Studium der Mathematik an der Ecole Polytechnique in Paris
 1802 stellvertretender Professor von Joseph Fourier
 1806 Übernahme dessen Lehrstuhl für Analysis und Mechanik
 1837 Veröffentlichung erster Gedankengänge zur Poisson-Verteilung (im
Rahmen der Wahrscheinlichkeitsbetrachtung von Urteilen in Straf- und
Zivil-Sachen):
• Basiert auf der Binomialverteilung und stellt deren Grenzverteilung dar
• Verteilung für einen großen Stichprobenumfang bzw. Zahl der
Versuche n  ∞ und kleine Merkmalswerte bzw. Abnahme der
Wahrscheinlichkeit p  0
© 2015 IAS, Universität Stuttgart
103
2.2 Lebensdauerverteilungen
ZSA
Poisson-Verteilung - Beschreibung
 Die Forderung liegt vor, dass das Produkt aus n und p weder Null noch
Unendlich wird und gegen einen endlichen Grenzwert µ konvergiert,
gemäß:
 Es gilt für eine Zufallsgröße X im Raum der natürlichen Zahlen k und dem
Parameter µ > 0:
• Verteilungsdichte:
𝛍𝐤
𝐏 𝐗 = 𝐤 = 𝐏𝛍 (𝐤) =
∗ 𝐞−𝛍
𝐤!
 Einsatz im Rahmen statistischer Prüfplanung von Ausfällen in der Produktion
oder der Modellierung von Störfällen komplexer Industrieanlagen
 Experimente, bei denen ein Ereignis selten eintritt, dieses jedoch ein großes
Risiko mit sich bringen kann
© 2015 IAS, Universität Stuttgart
104
2.2 Lebensdauerverteilungen
ZSA
Poisson-Verteilung – Simulation
 Poisson-Verteilung wird vollständig über den Parameter µ beschrieben
Wahrscheinlichkeit
 Simulation der Wahrscheinlichkeitsverteilung bei veränderlichem Parameter µ
k
© 2015 IAS, Universität Stuttgart
105
2.2 Lebensdauerverteilungen
ZSA
Poisson-Verteilung - Rechenbeispiel
Ein Hersteller produziert Bauteile mit einem durchschnittlichen Ausschuss
von 1%. Wie groß ist die Wahrscheinlichkeit, dass bei einer
Qualitätskontrolle von 10 Bauteilen genau 2 defekt sind?
𝛍 = 𝐧 ∗ 𝐩 = 𝟏𝟎 ∗ 𝟎, 𝟎𝟏 = 𝟎, 𝟏
𝟎, 𝟏𝟐
𝐏 𝐗 = 𝟐 = 𝐏𝟎,𝟏 (𝟐) =
∗ 𝐞−𝟎,𝟏 ≈ 𝟎, 𝟎𝟎𝟒𝟓 = 𝟎, 𝟒𝟓%
𝟐!
© 2015 IAS, Universität Stuttgart
106
2.2 Lebensdauerverteilungen
ZSA
Frage zu Kapitel 2.2
Ein Sensors soll bei einer Betriebszeit von 10.000h eine exponentiell-verteilte
Ausfallwahrscheinlichkeit von 8% nicht überschreiten. Welche dabei als konstant
annehmbare Ausfallrate sollte der Sensor maximal haben?
© 2015 IAS, Universität Stuttgart
107
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
2.2 Lebensdauerverteilungen
2.3 Verfügbarkeit von Systemen
2.4 Zuverlässigkeitsblockdiagramm
© 2015 IAS, Universität Stuttgart
108
2.3 Verfügbarkeit von Systemen
ZSA
Verfügbarkeit
 Wahrscheinlichkeit, ein reparierbares System zu einem vorgegebenen
Zeitpunkt in einem funktionsfähigem Zustand anzutreffen
 Zeitlicher Anteil der Benutzbarkeit eines Systems
• Wert 1: System ist funktionsfähig
• Wert 0: System ist nicht funktionsfähig
1


0
© 2015 IAS, Universität Stuttgart
109
2.3 Verfügbarkeit von Systemen
ZSA
Ableitung des Erwartungswerts
 Der Erwartungswert ist der geometrische Mittelwert einer Zufallsgröße
 In der Zuverlässigkeitstechnik ist der Erwartungswert der Zeitpunkt, bei dem
durchschnittlich ein Ausfall auftritt:
„The expectation of the time to failure“ (IEC 60050)
 Der Erwartungswert der Zuverlässigkeit wird als MTTF (Mean Time To Failure)
bezeichnet:
∞
𝐌𝐓𝐓𝐅 = 𝐄 𝐭 =
∞
𝐭 ∗ 𝐟 𝐭 𝐝𝐭 =
𝟎
𝐑 𝐭 𝐝𝐭
𝟎
 Unter der Annahme einer konstanten Ausfallrate gilt:
© 2015 IAS, Universität Stuttgart
110
2.3 Verfügbarkeit von Systemen
ZSA
Kenngrößen der Verfügbarkeit
MTBF
Zustand
MTTF
UP = 1
MTTR
DOWN = 0
Inbetriebnahme
Zeit t
Ausfall 1
 MTTF (Mean Time To Failure):
(„Durchschnittliche Zeit bis zum Ausfall“)
 MTTR (Mean Time To Repair):
(„Durchschnittliche Reparaturzeit“)
 MTBF (Mean Time Between Failure):
Ausfall 2
𝟏
𝐌𝐓𝐓𝐅 =
𝛌
𝟏
𝐌𝐓𝐓𝐑 =
𝛍
𝐌𝐓𝐁𝐅 = 𝐌𝐓𝐓𝐑 + 𝐌𝐓𝐓𝐅
(„Mittlere Betriebsdauer zwischen zwei Ausfällen“)
© 2015 IAS, Universität Stuttgart
111
2.3 Verfügbarkeit von Systemen
ZSA
Berechnung der Verfügbarkeit
1

 Berechnung der Verfügbarkeit über:

0
𝐌𝐓𝐓𝐅
𝐌𝐓𝐓𝐅
𝛍
𝐕=
=
=
𝐌𝐓𝐁𝐅 𝐌𝐓𝐓𝐅 + 𝐌𝐓𝐓𝐑
𝛍+ 𝛌
 Ziel ist das erreichen einer hohen Verfügbarkeit:
Verfügbarkeit
Ausfallzeit / Jahr
𝐌𝐓𝐓𝐑
≪𝟏 →𝐕 ≅𝟏
𝐌𝐓𝐓𝐅
Systemtyp
90,0%
ca. 880h
Unmanaged
99,0%
ca. 88h
Managed
(Standard für Systeme)
99,9%
ca. 9h
Well-Managed
99,99%
ca. 53min
Fault-Tolerant
99,999%
ca. 5min
Highly Available
99,9999%
ca. 32s
Very Highly Available
99,99999%
ca. 3s
Ultra Highly Available
(nur für Mikro-Bauteile, keine Systeme)
© 2015 IAS, Universität Stuttgart
112
2.3 Verfügbarkeit von Systemen
ZSA
Hochverfügbarkeit (high availability)
 Definition nach IEEE:
“High Availability (HA for short) refers to the availability of resources in a
computer system, in the wake of component failures in the system.”
 System ist hochverfügbar, wenn es auch im Fehlerfall weiter verfügbar ist und
ohne unmittelbaren menschlichen Eingriff weiter genutzt werden kann
 Erreichbar durch:
• Hohe Verfügbarkeit durch hohe Zuverlässigkeit:
 Hoch zuverlässige Komponenten
 Redundante Strukturen
• Hohe Verfügbarkeit durch kurze Reparaturzeiten:
 Kurze Fehlerdiagnosezeit durch Selbstdiagnose-Software
 Modulare Struktur zum einfachen Austausch von Komponenten
© 2015 IAS, Universität Stuttgart
113
2.3 Verfügbarkeit von Systemen
ZSA
Hochverfügbarkeit nach der Harvard Research Group (HRG)
 Einteilung der Hochverfügbarkeit in AEC-Stufen („Availability Environment
Classification“)
AEC
Erklärung
0
Funktion kann unterbrochen werden, Datenintegrität ist nicht essentiell.
1
Funktion kann unterbrochen werden, Datenintegrität muss jedoch gewährleistet sein.
2
Funktion darf nur innerhalb festgelegter Zeiten oder zur Hauptbetriebszeit minimal
unterbrochen werden.
3
Funktion muss innerhalb festgelegter Zeiten oder während der Hauptbetriebszeit
ununterbrochen aufrechterhalten werden.
4
Funktion muss ununterbrochen aufrechterhalten werden, 24/7-Betrieb muss
gewährleistet sein.
5
Funktion muss unter allen Umständen verfügbar sein.
 Probleme beim Erreichen einer hohen Verfügbarkeit:
© 2015 IAS, Universität Stuttgart
114
2.3 Verfügbarkeit von Systemen
ZSA
Frage zu Kapitel 2.3
Welche Verfügbarkeit weist eine Anlagensteuerung mit einer Ausfallrate von
λ0 = 6,5 ·10 -4 h-1 auf, wenn die durchschnittliche Reparaturzeit 20 h beträgt?
© 2015 IAS, Universität Stuttgart
115
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
2.1 Grundlagen der Wahrscheinlichkeitsrechnung
2.2 Lebensdauerverteilungen
2.3 Verfügbarkeit von Systemen
2.4 Zuverlässigkeitsblockdiagramm
© 2015 IAS, Universität Stuttgart
116
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Zuverlässigkeitsblockdiagramm
 Betrachtung eines aus mehreren Komponenten aufgebauten Gesamtsystems
 Zuverlässigkeitsblockdiagramm stellt dar, unter welcher Bedingung das
Gesamtsystem funktionsfähig ist
 Gesamtsystem ist funktionsfähig, wenn das Blockdiagramm auf mindestens
einem Pfad durchlaufen werden kann, auf welchem kein Modul ausgefallen ist
 Block ist eine Komponente bzw. eine bereits zusammengefasste Einheit von
Komponenten
Sensor
© 2015 IAS, Universität Stuttgart
Verstärker
μC
117
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Serienanordnung
A
B
 System ist funktionsfähig, wenn alle Module funktionsfähig sind
 Sobald mindestens ein Modul ausfällt, ist das System ausgefallen
 Es gilt:
• Boolesche Funktion:
𝐲 = (𝐱 𝐀 ∧ 𝐱 𝐁 )
𝐧
• Ausfallrate und MTTF:
𝛌𝐬 𝐭 =
𝛌𝐢
𝐢=𝟏
𝐌𝐓𝐓𝐅𝐬 =
• Zuverlässigkeit:
𝟏
=
𝛌𝐬 (𝐭)
𝟏
𝐧
𝐢=𝟏 𝛌𝐢
𝐧
𝐑 𝐢 (𝐭) = 𝐑 𝟏 𝐭 ∗ 𝐑 𝟐 𝐭 ∗ ⋯ ∗ 𝐑 𝐧 𝐭 = 𝐞−𝛌𝟏 ∗𝐭 ∗ 𝐞−𝛌𝟐∗𝐭 ∗ ⋯ ∗ 𝐞−𝛌𝐧∗𝐭
𝐑𝐬 𝐭 =
𝐢=𝟏
© 2015 IAS, Universität Stuttgart
118
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Serienanordnung mit 2 identischen Komponenten
2
1
 Für identische Ausfallraten mit λ(t) = const. = λ1 = λ2 = λ0 gilt:
𝟐
• Ausfallrate und MTTF:
𝛌𝐬 𝐭 =
𝛌𝐢 = 𝛌𝟏 + 𝛌𝟐 ≝ 𝛌𝟎 + 𝛌 𝟎 = 𝟐 ∗ 𝛌𝟎
𝐢=𝟏
𝐌𝐓𝐓𝐅𝐬 =
𝟏
𝟐
𝐢=𝟏 𝛌𝐢
=
𝟏
𝟏
𝟏
≝
=
𝛌𝟏 + 𝛌𝟐 𝛌𝟎 + 𝛌𝟎 𝟐 ∗ 𝛌𝟎
• Zuverlässigkeit:
𝟐
𝐑 𝐢 (𝐭) = 𝐑 𝟏 𝐭 ∗ 𝐑 𝟐 𝐭 ≝ 𝐑 𝟎 𝐭 ∗ 𝐑 𝟎 𝐭 = (𝐑 𝟎 (𝐭))𝟐
𝐑𝐬 𝐭 =
𝐢=𝟏
© 2015 IAS, Universität Stuttgart
119
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Serienanordnung mit 3 identischen Komponenten
1
2
3
 Für identische Ausfallraten mit λ(t) = const. = λ1 = λ2 = λ3 = λ0 gilt:
𝟑
• Ausfallrate und MTTF:
𝛌𝐬 𝐭 =
𝛌𝐢 ≝ 𝟑 ∗ 𝛌𝟎
𝐢=𝟏
𝐌𝐓𝐓𝐅𝐬 =
𝟏
𝟑
𝐢=𝟏 𝛌𝐢
≝
𝟏
𝟑 ∗ 𝛌𝟎
• Zuverlässigkeit:
𝟑
𝐑 𝐢 (𝐭) ≝ (𝐑 𝟎 (𝐭))𝟑
𝐑𝐬 𝐭 =
𝐢=𝟏
© 2015 IAS, Universität Stuttgart
120
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Parallelanordnung (Redundanz)
A
B
 System ist funktionsfähig, wenn mindestens ein Modul funktionsfähig ist
 Sobald alle Module ausgefallen sind, ist das System ausgefallen
 Es gilt:
• Boolesche Funktion:
• MTTF:
𝐲 = (𝐱 𝐀 ∨ 𝐱 𝐁 )
∞
𝐌𝐓𝐓𝐅𝐩 =
𝐑 𝐩 𝐭 𝐝𝐭
𝟎
𝐧
• Zuverlässigkeit:
𝐑𝐩 𝐭 = 𝟏 −
[𝟏 − 𝐑 𝐢 𝐭 ]
𝐢=𝟏
© 2015 IAS, Universität Stuttgart
121
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Parallelanordnung mit 2 identischen Komponenten
1
 Für identische Ausfallraten mit λ(t) = λ1 = λ2 = λ0 gilt:
• Zuverlässigkeit:
2
𝟐
[𝟏 − 𝐑 𝐢 𝐭 ] ≝ 𝟏 − (𝟏 − 𝐑 𝟎 𝐭 )𝟐 = 𝟐𝐑 𝟎 𝐭 − 𝐑 𝟎 𝐭
𝐑𝐩 𝐭 = 𝟏 −
𝟐
𝐢=𝟏
• MTTF:
∞
𝐌𝐓𝐓𝐅𝐩 =
∞
𝐑 𝐩 𝐭 𝐝𝐭 =
𝟎
𝟎
𝟐
𝐌𝐓𝐓𝐅𝐩 = 𝐌𝐓𝐓𝐅𝟎
𝐢=𝟎
𝟐
𝟏
𝟏
(𝟐𝐑 𝟎 − 𝐑 𝟎 ) 𝐝𝐭 =
−
=
∗
𝛌𝟎 𝟐𝛌𝟎 𝛌𝟎
𝟐
𝟏
𝟏 𝟑
𝟐−
=
∗
𝟐
𝛌𝟎 𝟐
𝟏
𝟏
𝟏 𝟑
= 𝐌𝐓𝐓𝐅𝟎 ∗ 𝟏 +
=
∗
𝐢
𝟐
𝛌𝟎 𝟐
© 2015 IAS, Universität Stuttgart
122
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Parallelanordnung mit 3 identischen Komponenten
1
 Für identische Ausfallraten mit λ(t) = λ1 = λ2 = λ3 = λ0 gilt:
2
• Zuverlässigkeit:
3
𝟑
[𝟏 − 𝐑 𝐢 𝐭 ] ≝ 𝟏 − (𝟏 − 𝐑 𝟎 𝐭 )𝟑 = 𝟑𝐑 𝟎 𝐭 − 𝟑𝐑 𝟎 𝐭
𝐑𝐩 𝐭 = 𝟏 −
𝟐
+ 𝐑𝟎 𝐭
𝟑
𝐢=𝟏
• MTTF:
∞
𝐌𝐓𝐓𝐅𝐩 =
∞
(𝟑𝐑 𝟎 −𝟑𝐑 𝟎 𝟐 +𝐑 𝟎 𝟑 ) 𝐝𝐭 =
𝐑 𝐩 𝐭 𝐝𝐭 =
𝟎
𝟎
𝟑
𝐌𝐓𝐓𝐅𝐩 = 𝐌𝐓𝐓𝐅𝟎
𝐢=𝟎
𝟑
𝟑
𝟏
𝟏 𝟏𝟏
−
+
=
∗
𝛌𝟎 𝟐𝛌𝟎 𝟑𝛌𝟎 𝛌𝟎 𝟔
𝟏
𝟏 𝟏
𝟏 𝟏𝟏
= 𝐌𝐓𝐓𝐅𝟎 ∗ 𝟏 + +
=
∗
𝐢
𝟐 𝟑
𝛌𝟎 𝟔
© 2015 IAS, Universität Stuttgart
123
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Komplexe Zuverlässigkeitsblockschaltbilder
 Reduzierung über Serien- und Parallelanordnungen:
6
7
2
4
1
8
3
5
9
67
2
2
4
1
467
1
35
89
© 2015 IAS, Universität Stuttgart
3589
124
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Separation bei Brückenelementen
 Bei Brückenelementen ist eine allgemeine Reduktion auf Serien- bzw.
Parallelanordnungen nicht möglich, daher Durchführung einer Separation
über Methode der relevanten Systemkomponenten:
x1
x3
x5
Modul 5 ist
ständig funktionsfähig
x1
x3
x2
x4
Modul 5 ist
ständig ausgefallen
x1
𝐱𝟓
𝐱𝟓
x2
x3
x4
© 2015 IAS, Universität Stuttgart
x2
x4
125
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Methode der relevanten Systemkomponenten (1/2)
 Betrachtung des Falls „R5 ist ständig funktionsfähig“:
x1
x3
yup
x5
x2
x4
• Boolesche Funktion:
𝐲𝐮𝐩 = 𝐱 𝟓 ∧ [(𝐱 𝟏 ∧ 𝐱 𝟑 ) ∨ (𝐱 𝟏 ∧ 𝐱 𝟒 ) ∨ (𝐱 𝟐 ∧ 𝐱 𝟑 ) ∨ (𝐱 𝟐 ∧ 𝐱 𝟒 )]
• Umformung
 Distributivgesetz:
𝐲𝐮𝐩 = 𝐱 𝟓 ∧ [(𝐱 𝟏 ∧ 𝐱 𝟑 ∨ 𝐱 𝟒 ) ∨ (𝐱 𝟐 ∧ (𝐱 𝟑 ∨ 𝐱 𝟒 ))]
 Kommutativgesetz: 𝐲𝐮𝐩 = 𝐱 𝟓 ∧ [( 𝐱 𝟑 ∨ 𝐱 𝟒 ∧ 𝐱 𝟏 ) ∨ ((𝐱 𝟑 ∨ 𝐱 𝟒 ) ∧ 𝐱 𝟐 )]
 Distributivgesetz:
𝐲𝐮𝐩 = 𝐱 𝟓 ∧ [ 𝐱 𝟑 ∨ 𝐱 𝟒 ∧ (𝐱 𝟏 ∨ 𝐱 𝟐 )]
• Zuverlässigkeit:
𝐑 𝐮𝐩 = 𝐑 𝟓 ∗
𝟏 − 𝟏 − 𝐑𝟑 ∗ 𝟏 − 𝐑𝟒
© 2015 IAS, Universität Stuttgart
∗ 𝟏 − 𝟏 − 𝐑𝟏 ∗ 𝟏 − 𝐑𝟐
126
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Methode der relevanten Systemkomponenten (2/2)
 Betrachtung des Falls „R5 ist ständig ausgefallen“:
x1
x3
ydown
𝐱𝟓
x2
x4
• Boolesche Funktion:
𝐲𝐝𝐨𝐰𝐧 = 𝐱 𝟓 ∧ [(𝐱 𝟏 ∧ 𝐱 𝟑 ) ∨ (𝐱 𝟐 ∧ 𝐱 𝟒 )]
• Zuverlässigkeit
𝐑 𝐝𝐨𝐰𝐧 = 𝟏 − 𝐑 𝟓 ∗
𝟏 − 𝟏 − 𝐑𝟏𝐑𝟑 ∗ 𝟏 − 𝐑𝟐𝐑𝟒
 Berechnung der Systemzuverlässigkeit des Brückenelements über die
Addition der Teilwahrscheinlichkeiten
 Möglich, da Ereignisse voneinander unabhängig sind (vgl. dazu Satz der
totalen Wahrscheinlichkeit)
 Es gilt also für ein Brückenelement:
© 2015 IAS, Universität Stuttgart
127
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Obere Grenze der Zuverlässigkeit
 Bei komplexen Systemen kann die obere Grenze bzw. die maximale
Zuverlässigkeit schnell abgeschätzt werden:
8
7
2
1
4
3
5
9
6
 Abschätzung max. Zuverlässigkeit des Systems:
© 2015 IAS, Universität Stuttgart
128
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Zuverlässigkeitsanalyse über Blockdiagramme (1/2)
 Am Beispiel eines Steuergeräts:
𝛌𝐒𝐞𝐧𝐬𝐨𝐫 = 𝟐 ∗ 𝟏𝟎−𝟔 𝐡−𝟏
𝛌𝐕𝐞𝐫𝐬𝐭. = 𝟏 ∗ 𝟏𝟎−𝟗 𝐡−𝟏
𝛌𝛍𝐂 = 𝟎, 𝟓 ∗ 𝟏𝟎−𝟔 𝐡−𝟏
Sensor
Verstärker
𝐑 𝐒𝐞𝐧𝐬𝐨𝐫 (𝟖𝟕. 𝟔𝟎𝟎𝐡) = 𝐞−(𝟐∗𝟏𝟎
𝐑 𝐕𝐞𝐫𝐬𝐭. (𝟖𝟕. 𝟔𝟎𝟎𝐡) = 𝐞−(𝟏∗𝟏𝟎
𝐑 𝛍𝐂 (𝟖𝟕. 𝟔𝟎𝟎𝐡) = 𝐞−(𝟎,𝟓∗𝟏𝟎
© 2015 IAS, Universität Stuttgart
𝐭 = 𝟏𝟎𝐚 = 𝟖𝟕. 𝟔𝟎𝟎 𝐡
μC
−𝟔 𝐡−𝟏 ∗𝟖𝟕𝟔𝟎𝟎𝐡)
−𝟗 𝐡−𝟏 ∗𝟖𝟕𝟔𝟎𝟎𝐡)
−𝟔 𝐡−𝟏 ∗𝟖𝟕𝟔𝟎𝟎𝐡)
= 𝟎, 𝟖𝟑𝟗
= 𝟎, 𝟗𝟗𝟗
= 𝟎, 𝟗𝟓𝟕
129
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Zuverlässigkeitsanalyse über Blockdiagramme (2/2)
 Maßnahme: Redundanz zur Erhöhung der Zuverlässigkeit
Sensor
Verstärker
μC
Sensor
𝐩
𝐑 𝐒𝐞𝐧𝐬𝐨𝐫 𝐭 = 𝟐𝐑 𝐒𝐞𝐧𝐬𝐨𝐫 𝐭 − 𝐑 𝐒𝐞𝐧𝐬𝐨𝐫 𝐭
𝟐
= 𝟐 ∗ 𝟎, 𝟖𝟑𝟗 − 𝟎, 𝟖𝟑𝟗
𝟐
= 𝟎, 𝟗𝟕4
 Zuverlässigkeit des Steuergeräts mit Redundanz:
𝐩
𝐑 𝐠𝐞𝐬,𝐧𝐞𝐮 𝐭 = 𝐑 𝐒𝐞𝐧𝐬𝐨𝐫 𝐭 ∗ 𝐑 𝐕𝐞𝐫𝐬𝐭. 𝐭 ∗ 𝐑 𝛍𝐂 𝐭 = 𝟎, 𝟗𝟕𝟒 ∗ 𝟎, 𝟗𝟗𝟗 ∗ 𝟎, 𝟗𝟓𝟕 = 𝟎, 𝟗𝟑𝟏
 Vgl. Zuverlässigkeit des Steuergeräts ohne Redundanz:
𝐑 𝐠𝐞𝐬,𝐚𝐥𝐭 𝐭 = 𝐑 𝐒𝐞𝐧𝐬𝐨𝐫 (𝐭) ∗ 𝐑 𝐕𝐞𝐫𝐬𝐭. 𝐭 ∗ 𝐑 𝛍𝐂 𝐭 = 𝟎, 𝟖𝟑𝟗 ∗ 𝟎, 𝟗𝟗𝟗 ∗ 𝟎, 𝟗𝟓𝟕 = 𝟎, 𝟖02
© 2015 IAS, Universität Stuttgart
130
2.4 Zuverlässigkeitsblockdiagramm
ZSA
Frage zu Kapitel 2.4
Um eine höhere Zuverlässigkeit zu erreichen, soll die Sensoreinheit eines
Steuergeräts aus 3 identischen, parallel geschalteten Sensoren aufgebaut
werden. Es soll dabei im Durchschnitt höchstens alle 20 Jahre zu einem Ausfall
kommen.
Können dazu Sensoren eingesetzt werden, die eine Ausfallrate von
λ0 = 9,3 * 10-6 h-1 aufweisen?
© 2015 IAS, Universität Stuttgart
131
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Gliederung
§ 1 Einführung, Begriffe und Normen
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
§ 3 Fehlerbaumanalyse (FTA)
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
§ 5 Softwarezuverlässigkeit
§ 6 Zuverlässigkeits- und Sicherheitstechnik
§ 7 Übungsaufgaben
© 2015 IAS, Universität Stuttgart
132
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 3 Fehlerbaumanalyse (FTA)
3.1 Grundlagen der FTA
3.2 Qualitative FTA
3.3 Quantitative FTA
3.4 FTA in der Softwareentwicklung
© 2015 IAS, Universität Stuttgart
133
3.1 Grundlagen der FTA
ZSA
Einführung in die FTA
 Fehlerbaumanalyse (FTA) ist eine Methode, die einen graphischen
Zusammenhang zwischen einem Top-Ereignis (Systemausfall,
Gefährdung,…) und den Ursachen, die zu diesem Top-Ereignis führen,
darstellt
 Deduktives Verfahren, d.h., ausgehend von dem unerwünschten TopEreignis werden die möglichen Ursachen gesucht
 Ursachen können dabei entweder alleine oder in Kombination mit anderen
Ursachen auftreten und zu einem definierten Fehler führen
© 2015 IAS, Universität Stuttgart
134
3.1 Grundlagen der FTA
ZSA
Historie (1960er – 1980er)
 1960er:
• Entwicklung FTA von
H.A. Watson bei Bell
Laboratories in New
Jersey (USA)
• Einsatz in der Luft und
Raumfahrt u.a. für
Quelle: en.wikipedia.org, 2014
Flugzeuge von Boeing
 1970er und 1980er
• Planung von Kernkraftwerken führte zur internationalen Verbreitung
• Entstehung Auswerte-Algorithmen und unterstützender Software
© 2015 IAS, Universität Stuttgart
135
3.1 Grundlagen der FTA
ZSA
Historie (1990er – heute)
 1990er
• Einsatz in der
Automobilindustrie
• Software-Tools zur
Konstruktion und
Auswertung der FTA
Quelle: www.openfta.com, 2014
 Heute
• Anwendung in nahezu allen Bereichen
• Verbreitung der FTA in der SW-Entwicklung
• Normung nach DIN 25424-1/-2 (1981/1990) und DIN EN 61025 (2007)
© 2015 IAS, Universität Stuttgart
136
3.1 Grundlagen der FTA
ZSA
Ziele der FTA
 System auf Komponentenbasis wirklichkeitsnah zu modellieren und
auszuwerten:
• Ausfallarten und Ausfallursachen zu detektieren
• Funktionale Zusammenhänge der Ausfälle herzustellen
• Auswirkungen von Ausfällen auf das System zu beschreiben
 Die FTA wird eingesetzt zur:
• Präventiven Qualitätssicherung
• Systemanalyse
• Problemlösung bei neu auftretenden Fehlern
 Analyse der Zuverlässigkeit über qualitativen oder quantitativen Ansatz:
• Qualitativ:
• Quantitativ:
© 2015 IAS, Universität Stuttgart
137
3.1 Grundlagen der FTA
ZSA
Struktur eines Fehlerbaums (Top-Down)
 Graphische Darstellung über mehrere Systemebenen, die durch logische
Verknüpfungen miteinander verbunden sind:
Systemausfall
Ausfall Teilsystem
Mikrocontroller (µC) liefert keine Daten
Ausfall Baugruppe
bzw. Ausfallebene
HW der µC-Einheit defekt
Ausfall Bauteil
Ausfallart
Bauteilmerkmal bzw.
Entwicklungsfehler
© 2015 IAS, Universität Stuttgart
Steuergerät funktioniert nicht
Bauteil µC defekt
Kurzschluss durch Feuchtigkeitseintritt
Konstruktionsfehler
138
3.1 Grundlagen der FTA
ZSA
Gängige Symbole des Fehlerbaums (1/2)
 Konstruktion des Fehlerbaums nach DIN 25424-1 genormten Symbolen
 Unterscheidung in Ereignis-, Verknüpfungs- und Tranfersymbole
 Ereignissymbole:
Symbol
Bezeichnung
Erklärung
Ereignis
Fehlereignis, das aus der Interaktion
mehrerer Ereignisse durch logische
Verknüpfung resultiert.
Primäres Ereignis
Feinste Auflösung des Fehlerbaums, z.B.,
der Ausfall einer Komponente.
Wird nicht weiter untergliedert.
Unentwickeltes Ereignis
Sonderfall, ein Ereignis über das keine
weiteren Details bekannt sind.
Keine weitere Untergliederung möglich.
Auslösendes Ereignis
Keine eigenständige Fehlerquelle, tritt als
Rahmenbedingung im Betrieb auf.
Kombination mit weiteren Ereignissen nötig.
© 2015 IAS, Universität Stuttgart
139
3.1 Grundlagen der FTA
ZSA
Gängige Symbole des Fehlerbaums (2/2)
 Verknüpfungssymbole:
Symbol
Bezeichnung
Erklärung
&
UND-Verknüpfung
Ausgangsereignis tritt genau dann ein, wenn
alle Eingangsereignisse wahr sind.
≥1
ODER-Verknüpfung
Ausgangsereignis tritt genau dann ein, wenn
mindestens ein Eingangsereignis wahr ist.
 Tranfersymbole:
Symbol
x
x
Bezeichnung
Erklärung
Transfer-IN
Input, Ereigniseingang einer Verbindung zu
einem anderen Fehlerbaum.
Transfer-OUT
Ereignis-Output, der an einen anderen Baum
den Input liefert.
An Position des Top-Ereignisses.
© 2015 IAS, Universität Stuttgart
140
3.1 Grundlagen der FTA
ZSA
Beispiel Fehlerbaum - Ausfall Steuergerät
V-1
V-2
I/O-1
I/O-2
Steuergerät
funktioniert nicht
Systemausfall
≥1
Ausfall Teilsystem
© 2015 IAS, Universität Stuttgart
Defekt auf Platine
Defekt des Interface
1
≥1
Interface Anschluss
V1+2 defekt
Interface Anschluss
I/O 1+2 defekt
…
…
141
3.1 Grundlagen der FTA
ZSA
Beispiel Fehlerbaum - Ausfall Steuergerät
1
Defekt auf Platine
≥1
Ausfall Baugruppe
Sensor
defekt
Mikrocontroller
defekt
Verstärker
defekt
…
≥1
…
Ausfallebene
© 2015 IAS, Universität Stuttgart
Defekt
auf HW-Ebene
Fehler
auf SW-Ebene
2
…
142
3.1 Grundlagen der FTA
ZSA
Beispiel Fehlerbaum - Ausfall Steuergerät
2
Defekt auf
HW-Ebene
≥1
Ausfall Bauteil
Ausfallart
Bauteilmerkmal bzw.
Entwicklungsfehler
Bauteildefekt durch
Kurzschluss
Bauteildefekt durch
Alterung/Verschleiß
≥1
…
Überspannung
Feuchtigkeit
Staub
…
≥1
…
Fehler
Konstruktion
© 2015 IAS, Universität Stuttgart
Material
143
3.1 Grundlagen der FTA
ZSA
Fragen zu Kapitel 3.1
Welchen Aussagen stimmen Sie zu?
□ Bei der FTA handelt es sich um ein deduktives Verfahren.
□ Das Vorgehen der FTA entspricht einer Bottom-Up-Analyse.
□ Ein primäres Ereignis kann mehrere Fehlerursachen haben.
□ Das Ergebnis einer FTA kann immer über Zahlenwerte beschrieben werden.
© 2015 IAS, Universität Stuttgart
144
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 3 Fehlerbaumanalyse (FTA)
3.1 Grundlagen der FTA
3.2 Qualitative FTA
3.3 Quantitative FTA
3.4 FTA in der Softwareentwicklung
© 2015 IAS, Universität Stuttgart
145
3.2 Qualitative FTA
ZSA
Qualitative FTA – Anwendung (1/2)
 Ziele:
• Identifikation sämtlicher Ausfallarten und Ausfallursachen
• Festhalten aller kritischer Ereignisse und Ereigniskombinationen
• Lokalisierung von Schwachstellen
• Erstellung objektiver Beurteilungskriterien
• Dokumentation
© 2015 IAS, Universität Stuttgart
146
3.2 Qualitative FTA
ZSA
Qualitative FTA – Anwendung (2/2)
 Gliederung:
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
!
No data available
© 2015 IAS, Universität Stuttgart
µC
Sensor
defekt
Steuergerät
funktioniert nicht
Steuergerät
funktioniert nicht
≥1
≥1
Mikrocontroller
defekt
Verstärker
defekt
Sensor
defekt
Mikrocontroller
defekt
!
Verstärker
defekt
147
3.2 Qualitative FTA
1. Analyse des Systems (1/2)
ZSA
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Mit dem Ziel:
• Wirkungsweise des Systems deutlich zu machen
• Wechselwirkung über Schnittstellen mit der Umwelt zu ermitteln
• Abhängigkeiten innerhalb des Systems zu ermitteln
 Wirkungsweise des Systems über Zusammenhang zwischen Anforderungen
und Funktionen bestimmen:
• Darlegen der Anforderungen (Funktion, Leistung, Qualität,…)
• Aufzeigen der Funktionalität und Zuordnung einzelner Funktionen zu
Komponenten
• Durchgängigkeit zwischen Anforderungen, Funktionen und Komponente
herstellen
© 2015 IAS, Universität Stuttgart
148
3.2 Qualitative FTA
1. Analyse des Systems (2/2)
ZSA
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Berücksichtigung der Umgebung
• Identifikation relevanter Umgebungseinflüsse (Temperatur, Feuchtigkeit,
Vibration,...)
• Eigenschaften der Systemelemente bestimmen (chemisch und physikalisch),
die von der Umgebung beeinflusst werden können
 Verhaltensabhängigkeiten untersuchen
• Zusammenwirken von Systemkomponenten
• Reaktion auf Einflüsse der Umgebung und auf Ausfälle externer/interner, mit
der System in Verbindung stehender, Komponenten
© 2015 IAS, Universität Stuttgart
149
3.2 Qualitative FTA
2. Unerwünschte Ereignisse definieren
ZSA
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Vorgehen nach zwei mögliche Ansätze
• Präventiver Ansatz:
„Unerwünschten Ereignisse werden von der möglichen Nichterfüllung von
Funktionen und Anforderungen abgeleitet.“
• Korrektiver Ansatz:
„Unerwünschte Ereignisse werden direkt von aufgetretenen Ausfällen
bzw. Fehlfunktionen abgeleitet.“
© 2015 IAS, Universität Stuttgart
150
3.2 Qualitative FTA
3. Ausfallarten bestimmen
ZSA
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Unterschiedliche Arten von Ausfällen haben unterschiedliche Auswirkungen auf
das Top-Event
 Betrachtung verschiedener Arten von Komponentenausfällen:
• Primärer Ausfall
 Komponentenausfall durch Schwächen bzw. Fehler, die sich schon zu
Beginn im System befinden
 Ausfall bei zulässigen Einsatzbedingungen
• Sekundärer Ausfall
 Komponentenausfall, der durch die Umgebungsbedingungen oder
durch die Einsatzbedingungen eintritt
 Ausfall bei unzulässigen Einsatzbedingungen
© 2015 IAS, Universität Stuttgart
151
3.2 Qualitative FTA
3. Ausfallarten bestimmen
ZSA
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
• Kommandierter Ausfall
 Komponentenausfall einer eigentlich funktionsfähigen Komponente
durch eine Fehlbedienung oder Eingabe von falschen oder ungültigen
Werten (bei Software)
 Bedienung- und Wartungsfehler
 Absichtliche Fehler
© 2015 IAS, Universität Stuttgart
152
3.2 Qualitative FTA
ZSA
4. Fehlerbaum erstellen
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Allgemeines Vorgehensmuster:
Ermittlung des
Top-Ereignis
Ereignis auf Ausfall
einer Komponente
reduzierbar?
nein
Berücksichtigung
aller Einzelausfälle
der Komponenten
ja
Eintrag ausgefallene
Komponente in den
Fehlerbaum
Alle Ausfälle
berücksichtigt?
Ursachen ermitteln
nein
ja
Vollständiger
Fehlerbaum
© 2015 IAS, Universität Stuttgart
153
3.2 Qualitative FTA
ZSA
Common Mode Failure
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Ausfall mehrerer gleichartiger Komponenten, die zu einem Schadenereignis
führen
 Fehler, die nicht durch eine gemeinsame Ursache ausgelöst werden
Ausfall
Sensoreinheit
Hat der Ausfalle eines Sensors den
Ausfall eines anderen Sensors zur
Folge?
&
Ausfall Sensor 1
Ausfall Sensor 2
© 2015 IAS, Universität Stuttgart
154
3.2 Qualitative FTA
ZSA
Common Cause Failure
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Ausfall mehrerer Komponenten, deren Ursache ein einzelner Ausfall einer
anderen Komponente darstellt
 Ausfälle sind statistisch abhängig voneinander, da sich verschiedene Äste
des Fehlerbaums auf dieselbe ausgefallene Komponente beziehen
…
…
Ausfall
Sensor 1
Ausfall
Sensor 2
≥1
≥1
Bauteil 1
defekt
Versorgung
defekt
Bauteil 2
defekt
Versorgung
defekt
Handelt es sich um denselben
Spannungsversorgungsanschluss?
© 2015 IAS, Universität Stuttgart
155
3.2 Qualitative FTA
5. Qualitative Bewertung
ZSA
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Die Zuverlässigkeit bzw. das Risiko von Ausfällen wird über die graphische
Struktur (qualitativ) abgeschätzt
 Keine Eingangsdaten für den Fehlerbaum (Ausfallraten) notwendig
 Verfahren bzw. Fehlerbaum muss vollständig sein, damit eine qualitative
Bewertung zweckmäßig ist
 Vollständigkeit bedeutet, dass alle Ereignisse und Ereigniskombinationen in der
Fehlerbaumerstellung berücksichtig wurden
 Ansätze zu Bewertung:
• Kritischer Pfad
• Kritische Menge bzw. minimale Schnittmenge
© 2015 IAS, Universität Stuttgart
156
3.2 Qualitative FTA
ZSA
Kritischer Pfad
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Ast des Fehlerbaums, bei dem die Komponentenausfälle nicht durch
systemeigene Vermeidungs- bzw. Prüfmechanismen (Diagnose- und
Fehlererkennungsmaßnahmen) abgesichert sind oder werden können
 Erkenntnisse über Zusammenhänge von Ursache und Wirkung
 Ableitung von Näherungen über Risiken und Schwachstellen des Systems
Defekt auf
SW-Ebene
≥1
Fehler bei
Code-Ausführung
Laufzeitumgebung
fehlerhaft
≥1
&
Tatsächlicher
SW-Fehler liegt vor
Fälschlicherweise wird
ein Fehler gemeldet
© 2015 IAS, Universität Stuttgart
Zugriff auf Funktion
Funktion arbeitet anders
als erwartet
157
3.2 Qualitative FTA
ZSA
Kritische Menge – Schwächster Ast
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Die kritische Menge ist der Unterbaum eines Fehlerbaums, der die minimale
Kombination von Einzelelementen enthält, deren Ausfall zu einem
unerwünschten Ereignis führt
 Es ist somit eine Aussage über den schwächsten Ast des Fehlerbaums möglich
 Schwächster Ast ist die Kombination an Ereignissen, die am ehesten zu einem
Ausfall führt
Defekt auf
SW-Ebene
≥1
Laufzeitumgebung
fehlerhaft
Fehler bei
Code-Ausführung
&
≥1
Tatsächlicher
SW-Fehler liegt vor
.
.
.
© 2015 IAS, Universität Stuttgart
Fälschlicherweise wird
ein Fehler gemeldet
Zugriff auf Funktion
Funktion arbeitet
anders als erwartet
.
.
.
158
3.2 Qualitative FTA
ZSA
Kritische Menge – Stärkster Ast
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte Ereignisse
definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
Qualitative
Bewertung
 Ist für einen Unterbaum der schwächste Ast bestimmt worden, so ist es auch
möglich, den stärksten Ast des Unterbaums zu bestimmen
 Stärkster Ast ist die Kombination an Ereignissen, mit deren Auftreten am
ehesten nicht zu rechnen ist und somit ein Ausfall „unrealistischer“ ist
 D.h., ein Ausfall über den stärksten Ast wird am wenigsten erwartet
Defekt auf
SW-Ebene
≥1
Laufzeitumgebung
fehlerhaft
Fehler bei
Code-Ausführung
&
≥1
Tatsächlicher
SW-Fehler liegt vor
.
.
.
© 2015 IAS, Universität Stuttgart
Fälschlicherweise wird
ein Fehler gemeldet
Zugriff auf Funktion
Funktion arbeitet
anders als erwartet
.
.
.
159
3.2 Qualitative FTA
ZSA
Beurteilung der qualitativen FTA
 Vorteile:
•
Exakte Anpassung an den Untersuchungsgegenstand möglich
•
Tiefer Informationsgehalt der Auswertung
•
Ermöglicht die Aufdeckung noch unbekannter Ausfallursachen
 Nachteile:
• Aufwendige Auswertung der Ergebnisse
• Hohe fachliche Kenntnis der Themenfelder der jeweiligen Äste notwendig
• Relativ zeit- und kostenintensiv
© 2015 IAS, Universität Stuttgart
160
3.2 Qualitative FTA
ZSA
Fragen zu Kapitel 3.2
Welchen Aussagen stimmen Sie zu?
□ Der erste Schritt einer FTA ist die Erstellung eines Fehlerbaums.
□ Eine qualitative FTA findet Einsatz bei der Dokumentation.
□ Eine qualitative Auswertung hat einen tiefen Informationsgehalt.
□ Qualitative FTA ermöglicht die Vergleichbarkeit von Systemen.
© 2015 IAS, Universität Stuttgart
161
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 3 Fehlerbaumanalyse (FTA)
3.1 Grundlagen der FTA
3.2 Qualitative FTA
3.3 Quantitative FTA
3.4 FTA in der Softwareentwicklung
© 2015 IAS, Universität Stuttgart
162
3.3 Quantitative FTA
ZSA
Quantitative FTA – Anwendung (1/2)
 Ziele:
• Nachweis geforderter Zuverlässigkeitsanforderungen
• Berechnung von Zuverlässigkeitskenngrößen bzgl. konkreter
Zahlenwerte (Ausfall- und Überlebenswahrscheinlichkeit)
• Aufzeigen von Faktoren oder Komponenten, die die Zuverlässigkeit
besonders beeinflussen
© 2015 IAS, Universität Stuttgart
163
3.3 Quantitative FTA
ZSA
Quantitative FTA – Anwendung (2/2)
 Durchführung:
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
Steuergerät
funktioniert nicht
x1
µC
!
≥1
x2
No data available
Sensor
defekt
Mikrocontroller
defekt
x3
x5
Verstärker
defekt
x4
Ist
=/≈
Soll?
λ(t)
Zuverlässigkeitskenngrößen
der Komponenten benötigt!
© 2015 IAS, Universität Stuttgart
164
3.3 Quantitative FTA
5. Zuverlässigkeitskenngrößen
ZSA
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Zuverlässigkeitskenngrößen der Komponenten (Ausfallrate, Zuverlässigkeit):
• Bekannt durch Herstellerangaben
• Ermittelt über Labortests
• Geschätzt über Wahrscheinlichkeitsrechnung
 Bestimmung der Zuverlässigkeitskenngrößen für Basisereignisse
• Ausfallwahrscheinlichkeit über einen Zeitraum berechnen, d.h., die
Berechnung der zu erwarteten Eintrittshäufigkeit des Top-Events
• Nichtverfügbarkeit zu einem beliebigen Zeitpunkt berechnen
© 2015 IAS, Universität Stuttgart
165
3.3 Quantitative FTA
ZSA
Funktions- und Fehlerbaum
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Es gibt eine grundsätzliche Unterscheidung zwischen einer Funktionsbaum-
und einer Fehlerbaum-Betrachtung
 Es gilt für eine Funktionsbaum-Betrachtung, dass Ereignisse bzw. positive
Parameter verknüpft werden, zum Beispiel:
y
&
𝐲 = 𝐱𝟏 ∧ 𝐱𝟐
x2
x1
 Es gilt für eine Fehlerbaum-Betrachtung, dass Fehl-Ereignisse bzw. negative
Parameter verknüpft werden, zum Beispiel :
𝐲
≥1
x1
𝐲 = x1 ∨ x2
x2
© 2015 IAS, Universität Stuttgart
166
3.3 Quantitative FTA
ZSA
Gegenseitige Überführung (1/2)
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
𝐑 𝐠𝐞𝐬 (𝐭)
𝐅𝐠𝐞𝐬 (𝐭)
y
𝐲
&
≥1
𝐲 = 𝐱𝟏 ∧ 𝐱𝟐
x1
𝐑 𝟏 (𝐭)
x1
x2
𝐅𝟏 (𝐭)
𝐑 𝟐 (𝐭)
𝐲 = x1 ∨ x2
x2
𝐅𝟐 (𝐭)
𝐅𝐠𝐞𝐬 𝐭 = 𝟏 − 𝟏 − 𝐅𝟏 𝐭
𝟏 − 𝐑 𝐠𝐞𝐬 𝐭 = 𝟏 −
6. Schritt
Quantitative
Bewertung
𝟏 − 𝟏 − 𝐑𝟏 𝐭
∗ 𝟏 − 𝐅𝟐 (𝐭)
∗ 𝟏 − 𝟏 − 𝐑𝟐 𝐭
𝟏 − 𝐑 𝐠𝐞𝐬 𝐭 = 𝟏 − 𝐑 𝟏 𝐭 ∗ 𝐑 𝟐 𝐭
𝐑 𝐠𝐞𝐬 𝐭 = 𝐑 𝟏 𝐭 ∗ 𝐑 𝟐 (𝐭)
© 2015 IAS, Universität Stuttgart
𝐑 𝐠𝐞𝐬 𝐭 = 𝐑 𝟏 𝐭 ∗ 𝐑 𝟐 (𝐭)
167
3.3 Quantitative FTA
ZSA
Gegenseitige Überführung (2/2)
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Es sich lässt sich demnach folgender Zusammenhang ableiten:
Funktionsbaum
Fehlerbaum
y
𝐲
&
≥1
x1
x2
x1
x2
y
𝐲
≥1
&
x1
x2
© 2015 IAS, Universität Stuttgart
x1
Zuverlässigkeitsberechnung
x2
168
3.3 Quantitative FTA
ZSA
Berechnung am Fehlerbaum
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Die quantitative Zuverlässigkeitsuntersuchung bei Fehlerbäumen lässt sich
demnach zu folgendem Schema zusammenfassen:
• UND-Verknüpfungen
Rges1(t)
𝐧
&
FehlEreignis 1
R1(t)
FehlEreignis 2
𝐑 𝐠𝐞𝐬𝟏 𝐭 = 𝟏 −
…
R2(t)
[𝟏 − 𝐑 𝐢 𝐭 ]
𝐢=𝟏
FehlEreignis n
Rn(t)
• ODER-Verknüpfung
Rges2(t)
𝐧
≥1
FehlEreignis 1
FehlEreignis 2
R1(t)
R2(t)
…
© 2015 IAS, Universität Stuttgart
𝐑 𝐠𝐞𝐬𝟐 𝐭 =
FehlEreignis n
𝐑 𝐢 (𝐭)
𝐢=𝟏
Rn(t)
169
3.3 Quantitative FTA
ZSA
Zusammenfassen von Pfaden
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Um die Analyse größerer Fehlerbäume zu ermöglichen, werden die
Zuverlässigkeiten entlang einzelner Pfade nach Schema zusammengefasst
 Beispiel: 𝐭 = 𝟏𝟎𝐚 = 𝟖𝟕𝟔𝟎𝟎𝐡
.
.
.
𝛌𝟎 = 𝟎, 𝟓 ∗ 𝟏𝟎−𝟔 𝐡−𝟏
Bauteil erhält kein
Strom
&
Stromversorgung
am Bauteil defekt
Stromversorgung
am Interface defekt
𝐑 𝐒𝐕−𝐁 𝐭
&
Anschluss 1 defekt
𝐑𝟎 𝐭
© 2015 IAS, Universität Stuttgart
Anschluss 2 defekt
𝐑𝟎 𝐭
170
3.3 Quantitative FTA
6. Quantitative Bewertung
ZSA
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Bei der Durchführung einer quantitativen Bewertung gilt es, den Ist-Zustand
eines Gesamtsystem anhand von charakteristischen und eindeutigen
Zuverlässigkeitskenngrößen mit dem geplanten und vorher definierten SollZustand zu vergleichen
 Methoden dabei:
• Methode der minimalen Erfolgspfade
• Methode der minimalen Ausfallschnitte
© 2015 IAS, Universität Stuttgart
171
3.3 Quantitative FTA
ZSA
Minimale Erfolgspfade (1/2)
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Ein Pfad entspricht einer Menge an Komponenten, deren Funktionsfähigkeit
das Funktionieren des Gesamtsystems garantiert
 Pfade sind dabei minimale Pfade, d.h., ein Pfad darf keine weiteren (Unter-)
Pfade als Teilmenge enthalten
 Für jeden Pfad wird die Zuverlässigkeit anhand der darin enthaltenen
Komponenten berechnet, zum Beispiel:
x1
x5
 Pfade als solche stellen Serienanordnungen dar
𝐩𝟏 = (𝐱 𝟏 ∧ 𝐱 𝟑 )
𝐩𝟐 = (𝐱 𝟐 ∧ 𝐱 𝟒 )
x3
x2
x4
 Menge an Pfaden stellt Parallelanordnung dar
𝐩𝟏𝟐 = (𝐱 𝟏 ∧ 𝐱 𝟑 ) ∨ (𝐱 𝟐 ∧ 𝐱 𝟒 )
© 2015 IAS, Universität Stuttgart
172
3.3 Quantitative FTA
ZSA
Minimale Erfolgspfade (2/2)
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Beispiel:
• Pfad 1:
𝐩𝟏 = (𝐱 𝟏 ∧ 𝐱 𝟑 )
• Pfad 2:
𝐩𝟐 = (𝐱 𝟐 ∧ 𝐱 𝟒 )
• Pfad 3:
𝐩𝟑 = (𝐱 𝟏 ∧ 𝐱 𝟓 ∧ 𝐱 𝟒 )
• Pfad 4:
𝐩𝟒 = (𝐱 𝟐 ∧ 𝐱 𝟓 ∧ 𝐱 𝟑 )
x1
x3
x5
x2
x4
 Boolesche Verknüpfung der Pfade:
𝐩𝐠𝐞𝐬 = (𝐱 𝟏 ∧ 𝐱 𝟑 ) ∨ (𝐱 𝟐 ∧ 𝐱 𝟒 ) ∨ (𝐱 𝟏 ∧ 𝐱 𝟓 ∧ 𝐱 𝟒 ) ∨ (𝐱 𝟐 ∧ 𝐱 𝟓 ∧ 𝐱 𝟑 )
 Berechnung der Systemzuverlässigkeit (boolesche Modellbildung):
𝐑 𝐠𝐞𝐬 = 𝟏 −
𝟏 − 𝐑 𝟏 𝐑 𝟑 ∗ 𝟏 − 𝐑 𝟐 𝐑 𝟒 ∗ 𝟏 − 𝐑 𝟏 𝐑 𝟓 𝐑 𝟒 ∗ (𝟏 − 𝐑 𝟐 𝐑 𝟓 𝐑 𝟑 )
© 2015 IAS, Universität Stuttgart
173
3.3 Quantitative FTA
ZSA
Minimale Ausfallschnitte (1/2)
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Ein Schnitt ist der komplementäre Begriff zu einem Pfad, d.h., ein Schnitt ist
die Menge an Komponenten, deren Ausfall zum Ausfall des Gesamtsystems
führt
 Schnitte sind dabei minimale Schnitte, d.h., ein Schnitt darf keine weiteren
Schnitte als Teilmenge enthalten
 Für jeden Schnitt wird die Ausfallwahrscheinlichkeit anhand der darin
enthaltenen Komponenten berechnet, zum Beispiel:
x1
 Schnitte als solche stellen Serienanordnungen dar
𝐜𝟏 = 𝐱 𝟏 ∧ 𝐱 𝟐
𝐜𝟐 = 𝐱 𝟑 ∧ 𝐱 𝟒
x3
x5
x2
x4
 Menge an Schnitten stellt Parallelanordnung dar
𝐜𝟏𝟐 = 𝐱 𝟏 ∧ 𝐱 𝟐 ∨ 𝐱 𝟑 ∧ 𝐱 𝟒
© 2015 IAS, Universität Stuttgart
174
3.3 Quantitative FTA
ZSA
Minimale Ausfallschnitte (2/2)
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Beispiel:
x1
• Schnitt 1:
𝐜𝟏 = (𝐱 𝟏 ∧ 𝐱 𝟐 )
• Schnitt 2:
𝐜𝟐 = (𝐱 𝟑 ∧ 𝐱 𝟒 )
• Schnitt 3:
𝐜𝟑 = (𝐱 𝟏 ∧ 𝐱 𝟓 ∧ 𝐱 𝟒 )
• Schnitt 4:
𝐜𝟒 = (𝐱 𝟐 ∧ 𝐱 𝟓 ∧ 𝐱 𝟑 )
x3
x5
x2
x4
 Boolesche Verknüpfung der Pfade:
𝐟𝐠𝐞𝐬 = (𝐱 𝟏 ∧ 𝐱 𝟐 ) ∨ (𝐱 𝟑 ∧ 𝐱 𝟒 ) ∨ (𝐱 𝟏 ∧ 𝐱 𝟓 ∧ 𝐱 𝟒 ) ∨ (𝐱 𝟐 ∧ 𝐱 𝟓 ∧ 𝐱 𝟑 )
 Berechnung der Systemausfallwahrscheinlichkeit (Boolesche Modellbildung):
𝐅𝐠𝐞𝐬 = [ 𝟏 − 𝟏 − 𝐅𝟏 𝟏 − 𝐅𝟐
∗ 𝟏 − 𝟏 − 𝐅𝟑 𝟏 − 𝐅𝟒
… ∗ 𝟏 − 𝟏 − 𝐅𝟏 𝟏 − 𝐅𝟒 𝟏 − 𝐅𝟓
© 2015 IAS, Universität Stuttgart
∗ …
∗ 𝟏 − 𝟏 − 𝐅𝟐 𝟏 − 𝐅𝟑 𝟏 − 𝐅𝟓 ]
175
3.3 Quantitative FTA
ZSA
Ergebnisanalyse (1/2)
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Nach Berechnung der Zuverlässigkeit oder Systemausfallwahrscheinlichkeit
eines unerwünschten Ereignisses erfolgt die Beurteilung hinsichtlich:
• Mechanik
𝛌𝐠𝐞𝐬 = 𝛌𝐌𝐞𝐜𝐡. + 𝛌𝐄𝐥. + 𝛌𝐒𝐖.
• Elektronik
• Software bzw. Informationstechnik
Mechanik
ATSystem
Software
© 2015 IAS, Universität Stuttgart
Elektronik
176
3.3 Quantitative FTA
ZSA
Ergebnisanalyse (2/2)
1. Schritt
2. Schritt
3. Schritt
4. Schritt
5. Schritt
Analyse des
Systems
Unerwünschte
Ereignisse definieren
(Ausfallkriterien)
Ausfallarten der
Komponenten
bestimmen
Fehlerbaum
erstellen
ZuverlässigkeitsKenngrößen
bestimmen
6. Schritt
Quantitative
Bewertung
 Durchführung einer Sensitivitätsanalyse als Basis der Ergebnis-Beurteilung
durch Entscheidungsträger (Vorgesetzte bzw. Auftraggeber)
 Methode, wie empfindlich Kennzahlen auf eine Änderung der
Eingangsparameter reagieren:
Eintrittswahrscheinlichkeit
von λges
Nicht
akzeptabel
akzeptabel
Analyse verursachender Ereignisse
© 2015 IAS, Universität Stuttgart
177
3.3 Quantitative FTA
ZSA
Beurteilung der quantitativen Durchführung einer FTA
 Vorteile:
• Exakte Ergebnisse
• Große Objektivität und Vergleichbarkeit
• Relativ geringer Zeit- und Kostenaufwand
 Nachteile:
• Keine direkt ableitbaren Verbesserungsvorschläge
• Keine Flexibilität bei der Untersuchung
• Nicht alle Ausfallursachen erfassbar
© 2015 IAS, Universität Stuttgart
178
3.3 Quantitative FTA
ZSA
Fragen zu Kapitel 3.3
Welchen Aussagen stimmen Sie zu?
□ Eine quantitative Analyse zeigt stark zuverlässigkeitsbeeinflussende Teile auf.
□ Quantitativ lassen sich nicht alle Ausfallursachen berücksichtigen.
□ Funktionsbäume lassen sich mathematisch in Fehlerbäume überführen.
□ Die Ergebnisse einer quantitativen Bewertung sind eindeutig.
© 2015 IAS, Universität Stuttgart
179
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 3 Fehlerbaumanalyse (FTA)
3.1 Grundlagen der FTA
3.2 Qualitative FTA
3.3 Quantitative FTA
3.4 FTA in der Softwareentwicklung
© 2015 IAS, Universität Stuttgart
180
3.4 FTA in der Softwareentwicklung
ZSA
Software-FTA
 Anfangs Einsatz der FTA rein zur Bewertung von Anlagen, Schaltungen etc.
 Mit zunehmender Zahl informationstechnischer Systeme ging eine zunehmende
Verflechtung der FTA mit Software einher:
• Software-Tools
 Unterstützung der Auswertung von Fehlerbäumen
 Beherrschung komplexer Software-Systeme
• Entwurf von Software
 Minimierung des Ausfallrisikos durch Identifikation von fehleranfälligen
Modulen (high-risk modules)
 Kontrolle von Code-Segmenten
© 2015 IAS, Universität Stuttgart
181
3.4 FTA in der Softwareentwicklung
ZSA
Unterstützung bei der Auswertung
 Komplexe Fehlerbäume lassen sich nur unter Anwendung rechnergestützter
Methoden sinnvoll behandeln:
• Qualitativen Bewertung

Identifikation kritischer Pfade

Erkennen kritischer Mengen
• Quantitativen Bewertung
 Aufstellen von Pfaden und Schnitten
 Berechnung von Zuverlässigkeitskenngrößen
 Lange Rechenzeiten und große Speicherkapazitäten notwendig
 Sorgfältige Planung des Einsatz:
• Strukturierte Analyse des Systems
• Effiziente Aufstellung des Fehlerbaums
© 2015 IAS, Universität Stuttgart
182
3.4 FTA in der Softwareentwicklung
ZSA
Beherrschung komplexer Systeme
 Fehlerbäume sind häufig unübersichtlich und enthalten Redundanzen
 Auf Basis der Primär-Ereignisse und deren Kombination können Fehlerbäume
mathematisch als boolesche Funktionen beschrieben werden, die über Algorithmen
vereinfacht werden können (z.B. Verfahren nach Quine und McCluskey)
 Beispiel der Systematik in Form binärer Entscheidungsdiagramme:
1
2
x1
x3
0
0
False
„0“
True
„1“
x3
x3
0
1
0
x2
x2
x2
x2
3
x1
x3
x3
1
0
x1
x2
x3
f
0
0
0
0
0
0
1
0
0
1
0
0
0
1
1
1
1
0
0
0
1
0
1
1
1
1
0
0
1
1
1
1
1
© 2015 IAS, Universität Stuttgart
x3
x3
0
4
x3
x1
x2
x2
x3
x3
0
1
1
x1
x2
0
x3
1
183
3.4 FTA in der Softwareentwicklung
ZSA
Minimierung des Ausfallrisikos
 Minimierung des Ausfallrisikos von Software-Systemen erfolgt durch die
Identifikation von fehleranfälligen Modulen, sogenannten high-risk modules:
Fehler in Funktion
≥1
Fehler in
Unterfunktion A
Fehler in
Unterfunktion B
&
&
Fehler im Modul 1
Fehler im Modul 2
Fehler im Modul 2
Fehler im Modul 3
 Ableitung von Maßnahmen zur Absicherung der erkannten Module
 Im Anschluss ausführliche Tests und Re-Design des Systems (falls nötig)
© 2015 IAS, Universität Stuttgart
184
3.4 FTA in der Softwareentwicklung
ZSA
Kontrolle von Code-Segmenten
 Kontrolle einer kompletten Software kaum möglich, da Abhängigkeiten im Code
zu komplex sind um diese über einen Fehlerbaum darzustellen
 Daher ist nur die automatische oder manuelle Überführung von Modulen,
Funktionen oder Schleifen in Fehlerbäume sinnvoll
 Top-Ereignis wird durch einen unerwünschten Output dargestellt
 Schematisches Beispiel:
Fehler
IF-ELSE-Statement
≥1
Fehler durch ELSEEreignis bei einer
Bedingung „true“
Fehler durch IFEreignis bei einer
Bedingung „false“
&
&
Bedingung ist „true“
© 2015 IAS, Universität Stuttgart
Sprung in ELSEAbschnitt der
Schleife
Bedingung ist
„false“
Sprung in IFAbschnitt der
Schleife
185
3.4 FTA in der Softwareentwicklung
ZSA
Probleme bei der Software FTA
 Fehlerbaum gibt ein System nur zu einem festen Zeitpunkt wieder
• Aber die Reihenfolge und die zeitlichen Abstände des Auftretens von
Ereignissen ist entscheidend über einen Ausfall von Software!
• Abhilfe über mehrere Fehlerbäume, die einen dynamischen Ablauf
darstellen können
 Software-Systeme können verschiedene Zustände einnehmen, wobei erst der
weitere Verlauf oder der Kontext angibt, ob dieser Zustand zu einem Ausfall
führen kann
• Aber die FTA erlaubt nur die Zustände „funktionsfähig“ oder „defekt“!
• Abhilfe bei der quantitativen Durchführung über Wahrscheinlichkeitstheorie
auf Basis exakter statistischer Daten
© 2015 IAS, Universität Stuttgart
186
3.4 FTA in der Softwareentwicklung
ZSA
Aussichten
 System werden immer komplexer, sodass eine Auswertung „von Hand“ kaum
mehr möglich ist
• Rechnergestützte Methoden zur Behandlung von Fehlerbäumen
• Effektive Methoden notwendig, die analytischen und simulativen
Charakter aufweisen
• Kombination der FTA mit anderen Methoden
 Aussagen über Software auf Basis empirischer Daten kaum möglich
• Genauigkeit und Belastbarkeit der Ergebnisse können in jeder
Entwicklungsphase in Frage gestellt werden
• Erfahrungswerte müssen geschaffen werden
• Berechnungsverfahren müssen Erfahrungswerte berücksichtigen
© 2015 IAS, Universität Stuttgart
187
3.4 FTA in der Softwareentwicklung
ZSA
Fragen zu Kapitel 3.4
Welchen Aussagen stimmen Sie zu?
□ FTA ermöglicht die Identifikation von fehleranfälligen SW-Modulen.
□ Es ist sinnvoll, die FTA mit weitere Analysemethoden zu kombinieren.
□ Jede Software lässt sich in einen Fehlerbaum überführen.
□ Ein Fehlerbaum kann immer die Zustände einer Software wiederspiegeln.
© 2015 IAS, Universität Stuttgart
188
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Gliederung
§ 1 Einführung, Begriffe und Normen
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
§ 3 Fehlerbaumanalyse (FTA)
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
§ 5 Softwarezuverlässigkeit
§ 6 Zuverlässigkeits- und Sicherheitstechnik
§ 7 Übungsaufgaben
© 2015 IAS, Universität Stuttgart
189
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
4.1 Grundlagen der FMEA
4.2 Arten der FMEA
4.3 Einsatz von Werkzeugen
4.4 Durchführung der FMEA
4.5 FMEA-Formblatt
4.6 Software-FMEA (SFMEA)
© 2015 IAS, Universität Stuttgart
190
4.1 Grundlagen der FMEA
ZSA
Einführung in die FMEA
 Fehlermöglichkeits- und Einflussanalyse, kurz FMEA (Failure Mode and
Effects Analysis), ist die bekannteste Methode der Zuverlässigkeitsanalyse
 Qualitatives, induktives Verfahren zur Analyse von Ausfällen
 Es erfolgt die Ausfall- und Fehler-Betrachtung nach:
• Folge
• Art
• Ursache
 FMEA ist eine vorbeugende Maßnahme:
• zur Fehlerprävention
• zur Fehlerdetektion
© 2015 IAS, Universität Stuttgart
191
4.1 Grundlagen der FMEA
ZSA
Historie (1940er – 1960er)
 1949 Beschreibung als militärische Anweisung „MIL-P-1629 – Procedures
for Performing a Failure Mode, Effects and Criticality Analysis”
 1960er
• Planung von Kernkraftwerken
• Einsatz in der Luft- und Raumfahrt (z.B. Apollo Mission der NASA)
Quelle: en.wikipedia.org, 2014
© 2015 IAS, Universität Stuttgart
192
4.1 Grundlagen der FMEA
ZSA
Historie (1970er – heute)
 1970er – 1980er
• Einsatz in der Automobilindustrie
(Ford in USA)
• Normung nach DIN 25448 (1980)
Quelle: www.ceptara.com, 2014
 1990er – heute
• Einsatz in der Elektronik und Softwareentwicklung
• Stetige Weiterentwicklungen (System-FMEA, Software-FMEA,…)
• Normung nach DIN EN 60812 (2006)
© 2015 IAS, Universität Stuttgart
193
4.1 Grundlagen der FMEA
ZSA
Fehlerprävention
 Erkennen und Verhindern von Fehlern in frühen Stadien eines Produktzyklus
© 2015 IAS, Universität Stuttgart
194
4.1 Grundlagen der FMEA
ZSA
Fehlerdetektion
 Detektion möglicher Fehlerquellen, die zu Ausfällen führen können
 Alle Ursachen und resultierenden Folgen von Fehlern auf ein Produkt
bzw. System zu ermitteln, zu reduzieren oder gar zu vermeiden
 Fehlerfreie Gestaltung von Prozessen während der Entwicklung
 Schwachstellen von System, Produkten oder Prozesse identifizieren,
sodass eine konstruktive Überarbeitung erfolgen kann
© 2015 IAS, Universität Stuttgart
195
4.1 Grundlagen der FMEA
ZSA
Zeitpunkt des Einsatz
 „So früh wie möglich“:
• Direkt bei Lasten- oder Pflichtenhefterstellung
• In frühen Phasen des Produktentstehungsprozess (nach ersten Entwürfen)
 „Entwicklungsbegleitend“:
• Mit permanenter Anpassung und Aktualisierung
• Als dynamisches Dokument
© 2015 IAS, Universität Stuttgart
196
4.1 Grundlagen der FMEA
ZSA
Einflussfaktoren auf den Einsatz
 Äußere Einflussfaktoren:
• Gestiegene Kundenanforderungen (an Qualität, Funktionalität,
Benutzbarkeit,…)
• Druck der Kostenoptimierung durch Wettbewerb
• Gesetzliche Produkthaftung
 Innere Einflussfaktoren:
• Zeitpunkt der Durchführung
• Freiheitsgrade im Ablauf
• Erfahrung der FMEA-Teilnehmer
© 2015 IAS, Universität Stuttgart
197
4.1 Grundlagen der FMEA
ZSA
Ziele der FMEA
 Am System bzw. Produkt:
• Steigerung der Zuverlässigkeit
• Einhaltung der Garantiezeiten
• Funktionssicherheit
 In der Entwicklung und Produktion:
• Verbesserte Kommunikation zwischen den Beteiligten
• Effektivere Prozesse
• Reduzierung von Kosten
• Reibungslose Serienanläufe in der Fertigung
© 2015 IAS, Universität Stuttgart
198
4.1 Grundlagen der FMEA
ZSA
Vergleich FMEA vs. qualitative FTA
 FMEA und qualitative FTA sind grundlegend unterschiedliche Methoden
 Methoden schließen sich aber gegenseitig nicht aus, sondern ergänzen sich
 Es gilt:
FMEA
Qualitative FTA
Deduktive Methode:
Induktive Methode:
Ursache
Wirkung
Kombination von Fehlerursachen
und Fehlerfolgen über
Systemebenen hinweg.
© 2015 IAS, Universität Stuttgart
Ursache
Wirkung
Systematische Suche nach Fehlerursachen
über Ereignis-Verknüpfungen innerhalb von
Systemebenen
199
4.1 Grundlagen der FMEA
ZSA
Frage zu Kapitel 4.1
Welchen Aussagen stimmen Sie zu?
□
Der Durchführungszeitpunkt einer FMEA beeinflusst das Ergebnis.
□
Ein Ziel der FMEA ist die fehlerfreie Gestaltung von Prozessen.
□
Die FMEA ist eine induktive Zuverlässigkeitsmethode.
□
FMEA entspricht prinzipiell der qualitativen FTA.
© 2015 IAS, Universität Stuttgart
200
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
4.1 Grundlagen der FMEA
4.2 Arten der FMEA
4.3 Einsatz von Werkzeugen
4.4 Durchführung der FMEA
4.5 FMEA-Formblatt
4.6 Software-FMEA (SFMEA)
© 2015 IAS, Universität Stuttgart
201
4.2 Arten der FMEA
ZSA
Unterscheidung nach Arten
 Im Entwicklungsprozess wird nach drei FMEA-Arten unterschieden:
• System-FMEA
• Konstruktions-FMEA (auch als Design-FMEA bezeichnet)
• Produkt- und Prozess-FMEA
 Aufteilung in Arten notwendig, da:
• Oft funktionale Zusammenhänge zwischen Komponenten nicht korrekt
erfasst werden können
• Aufgrund steigender Komplexität keine Analyse des gesamten
Herstellungsprozess von der Planung bis hin zur Auslegung von
Systemen mehr möglich ist
© 2015 IAS, Universität Stuttgart
202
4.2 Arten der FMEA
ZSA
FMEA-Arten im Entwicklungsfeld
Varianten
viel
SystemFMEA
KonstruktionsFMEA
Produktund ProzessFMEA
wenig
ungenau
© 2015 IAS, Universität Stuttgart
genau
Konkretisierung der
Produktmerkmale
203
4.2 Arten der FMEA
ZSA
Begriffe System und Funktion
 „System“ ist ein technisches Gebilde (Maschine, Gerät, Anlage,…):
• Klar abgrenzbar von der Umgebung
• Untergliederung in Teilsysteme möglich
• Einteilung in Einheiten möglich (Baugruppen, Komponenten,…)
 „Funktion“ beschriebt den Zusammenhang zwischen dem Ein- und
Ausgangsgrößen von Systemen:
• Aufgabenbeschreibung
• Eindeutige Zuordnung möglich
Eingangsgrößen
System
Ausgangsgrößen
Funktion
© 2015 IAS, Universität Stuttgart
204
4.2 Arten der FMEA
ZSA
System-FMEA
 Ziel ist es, mögliche funktionale Fehler in einem frühen Stadium zu
identifizieren:
• Strukturierung des zu untersuchenden Systems in Einheiten
• Aufzeigen von funktionalen Zusammenhängen zwischen Einheiten
• Ableitung von Fehlfunktionen der Einheiten
• Logische Verknüpfung der Fehlfunktionen
• Abgleich des Ergebnis mit dem Pflichtenheft
 Bildet die Grundlage der Konstruktions-FMEA
 Wird von der Entwicklungsabteilung durchgeführt
© 2015 IAS, Universität Stuttgart
205
4.2 Arten der FMEA
ZSA
Konstruktions-FMEA
 Ziel ist der einwandfreie Entwurf eines Produkts bzw. Systems unter
Betrachtung der einzelnen Komponenten:
• Fertigungseignung in frühen Phase abschätzen
• Identifikation systematischer Fehler in der Konstruktion
• Vermeidung von Entwicklungsfehler
 Spezielle Unterteilung möglich in:
• Hardware-FMEA zur Analyse von Hardware und Elektronik
• Software-FMEA zur Analyse von Programmcode
 Bildet die Grundlage der Produkt- und Prozess-FMEA
 Wird von der Konstruktionsabteilung durchgeführt
© 2015 IAS, Universität Stuttgart
206
4.2 Arten der FMEA
ZSA
Produkt- und Prozess-FMEA
 Ziel ist die Elemination von identifizierten Fehlern am Produkt selbst und am
produzierenden Prozess
 Am Produkt:
• Betrachtet werden physikalische Ausfallarten (Bruch, Verschleiß,…)
• Betrachtung erfolgt über alle Systemhierarchien hinweg
 Am Prozess:
• Betrachtet werden Fehler im Produktionsprozess (Fertigung, Montage,
Logistik, Transport,…)
• Strukturierte Beschreibung nach den „5 M‘s“ (Mensch, Maschine,
Material, Methode, Milieu/Mitwelt)
 Wird von der Planung und Produktion durchgeführt
© 2015 IAS, Universität Stuttgart
207
4.2 Arten der FMEA
ZSA
Übersicht der FMEA-Arten
Art
Betrachtungsgegenstand
Eingangsgröße
Durchführender
Bereich/Abteilung
SystemFMEA
Systemebene bzw.
übergeordnetes
Produkt
Pflichtenheft und
Produktkonzept
Entwicklung
KonstruktionsFMEA
Bauteile bzw.
Komponenten
Konstruktionsunterlagen und
Ergebnis der SystemFMEA
Konstruktion
Produkt- und
Prozess-FMEA
Produkt und
Fertigungsschritte
Fertigungs- bzw.
Montageabläufe und
Ergebnis der
Konstruktions-FMEA
Planung und
Produktion
© 2015 IAS, Universität Stuttgart
208
4.2 Arten der FMEA
ZSA
Frage zu Kapitel 4.2
Welchen Aussagen stimmen Sie zu?
□
Eine System-FMEA ist die Grundlage für eine Konstruktions-FMEA.
□
Die System-FMEA schätzt die Fertigungseignung eines Produkts ab.
□
Die Produktion führt die Konstruktions-FMEA durch.
□
Produkt-FMEA befasst sich mit physikalischen Fehlern.
© 2015 IAS, Universität Stuttgart
209
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
4.1 Grundlagen der FMEA
4.2 Arten der FMEA
4.3 Einsatz von Werkzeugen
4.4 Durchführung der FMEA
4.5 FMEA-Formblatt
4.6 Software-FMEA (SFMEA)
© 2015 IAS, Universität Stuttgart
210
4.3 Einsatz von Werkzeugen
ZSA
Werkzeuge bei der Durchführung einer FMEA
 Bei der FMEA wird ein Betrachtungsgegenstand so lange unterteilt, bis er als
geschlossene Funktionseinheit betrachtet werden kann
 Sehr komplex bei größeren Systemen
 Einsatz von Werkzeugen notwendig, um Komplexität zu beherrschen
 Beispiele :
• Fehlerbaumanalyse (FTA)
• Fischgräten- bzw. Ursache-Wirkungs-Diagramm
• Fragenkatalog bzw. Checklisten
• Ereignisablaufanalyse (ETA)
• Matrix-Diagramm
• FMEA-Software
© 2015 IAS, Universität Stuttgart
211
4.3 Einsatz von Werkzeugen
Fehlerbaumanalyse (FTA)
 Grundlagen und Durchführung siehe Kap.3
 Anwendung erfolgt in Form der qualitativen FTA
 Ziel der FTA im Rahmen der FMEA ist es, nicht nur Ausfallarten bzw.
Ausfallursachen eines Systems zu detektieren, sondern speziell:
• Funktionale Zusammenhänge über Verknüpfungen herzustellen
• Auswirkungen auf das System beschreiben
• Systematische Strukturierung herzustellen
© 2015 IAS, Universität Stuttgart
ZSA
4.3 Einsatz von Werkzeugen
ZSA
Fischgräten- bzw. Ursache-Wirkungs-Diagramm
 Darstellung der Kausalität zwischen einem unerwünschten Ereignis
(Wirkung) und den Gründen, die zu diesem Ereignis führen (Ursachen)
Maschine
……
……
Mensch
……
……
Problem
Material
Mit-/Um-Welt
© 2015 IAS, Universität Stuttgart
Methode
213
4.3 Einsatz von Werkzeugen
ZSA
Ursache-Wirkungs-Diagramm - Einsatz und Bewertung
 Einsatzmöglichkeiten:
• Analyse von Fehler- und Ausfallursachen
• Prozesse zur Produktivitätssteigerung
• Problemen innerhalb bzw. zwischen Abteilungen
• Optimierung eines Systems
 Vorteile:
• Übersichtliche und interdisziplinare Darstellung
• Einfache Erlern- und Lehrbarkeit (geringer Zeit- und Kostenaufwand)
 Nachteile:
• Zu umfangreich bei komplexen Problemstellungen
• Wechselwirkungen oder Zeitabhängigkeiten nicht erfassbar
© 2015 IAS, Universität Stuttgart
214
4.3 Einsatz von Werkzeugen
ZSA
Ursache-Wirkungs-Diagramm - Anpassung an Software
 Adaption und Einsatz des Ursachen-Wirkungs-Diagramms für die FMEA
von Software-Systemen möglich
 Beispiel:
Funktionalität
Zuverlässigkeit
Richtigkeit
Reife
Benutzbarkeit
Erlernbarkeit
Qualität der
Software
Verbrauch
Effizienz
Anpassbarkeit
Übertragbarkeit
© 2015 IAS, Universität Stuttgart
Prüfbarkeit
Änderbarkeit
215
4.3 Einsatz von Werkzeugen
ZSA
(Prüf-)Fragenkatalog bzw. Checklisten
 Zusammenstellung von Fragen zur Analyse von Systemen, Prozessen und
Arbeitsmitteln
 Ermöglicht eine systematische Bewertung des Ist-Zustands
 Beispielhafter Auszug zu einem unerwünschten Ereignis „μC liefert keine
Daten“:
Ebene
Hardware
Software
Schnittstelle
Kriterium
Ergebnis
Anmerkung
Spannungsversorgung angeschlossen?
Ja/Nein
-
Pins korrekt beschaltet?
Ja/Nein
Abgleich mit Datenblatt
Lötstellen in Ordnung?
Ja/Nein
Prüfung: Bildverarbeitung
Schleifen korrekt verschachtelt?
Ja/Nein
Kontrollflussgraph
Register korrekt initialisiert?
Ja/Nein
Abgleich mit Datenblatt
Flags richtig gelöscht?
Ja/Nein
-
Abschlusswiderstände an Leitungen?
Ja/Nein
z.B. 120 Ohm bei CAN
© 2015 IAS, Universität Stuttgart
216
4.3 Einsatz von Werkzeugen
ZSA
Prüffragenkatalog - Einsatz und Bewertung
 Bestehende Fragenkataloge können von Gewerkschaften, Berufsverbänden
oder Industrieverbänden angefordert werden
 Einsatz vor der FMEA, da Aussagen über Komponenten ableitbar, die bei der
Durchführung genauer untersucht werden müssen
 Vorteil:
• Zielgerichtetes Vorgehen durch klare und nachvollziehbare Abläufe
• Hinweise auf realtypische, auch komplexe Mängel und Fehlerarten
• Arbeitshilfe zur Dokumentation und Qualitätssicherung
 Nachteil:
• Qualität hängt von der Erfahrung der Ersteller ab
• Keine Angaben über neu entstandene, nicht berücksichtigte oder noch
unbekannt Fehlerursachen möglich
© 2015 IAS, Universität Stuttgart
217
4.3 Einsatz von Werkzeugen
ZSA
Ausschnitt Prüffragenkatalog „Bildschirmarbeitsplätze“
Quelle: www.bghw.de, 2014
© 2015 IAS, Universität Stuttgart
218
4.3 Einsatz von Werkzeugen
ZSA
Ereignisablaufanalyse (ETA)
 Ereignisablaufanalyse (ETA, Event Tree Analysis) ist ein induktives Verfahren,
bei dem mögliche Folgen eines Fehlers bestimmt werden sollen
 Normung nach DIN 25419
 Vorgänge bzw. logische Zusammenhänge werden graphisch in verzweigten
Ereignisbäumen dargestellt (über Ja/Nein-Bedingung)
 Ereignisablaufanalyse gleicht auf ersten Blick der Fehlerbaumanalyse, aber:
• FTA: Ermittlung aller Ursachen, die zu einer bestimmten Gefährdung
führen können (deduktiv)
• ETA: Ermittlung aller Gefährdungen, die auf einen bestimmten Fehler
bzw. Störfall folgen können (induktiv)
© 2015 IAS, Universität Stuttgart
219
4.3 Einsatz von Werkzeugen
ZSA
ETA - Einsatz und Bewertung
 Sinnvoller Einsatz frühestens dann wenn alle Systemanforderungen bekannt,
sodass alle Verzweigungen berücksichtigt werden können
 Praxis häufig in Kombination mit FTA im Rahmen der probabilistischen
Sicherheitsanalyse PSA (vgl. Kap 6)
 Vorteil:
• Ermöglicht vollständige Sicherheitsbetrachtung nach einem einfachem
Schema (Ja oder Nein)
• Zuordnung von Wahrscheinlichkeiten zur quantitativen Auswertung
möglich
 Nachteil:
• Unübersichtliche Bäume bei komplexen Problemstellungen
• Erstellung und Auswertung daher oft nur über Computerprogramme
möglich
© 2015 IAS, Universität Stuttgart
220
4.3 Einsatz von Werkzeugen
ZSA
Beispiel einer ETA zu „μC liefert keine Daten“
μC liefert keine
Daten
Verzweigung
Ja
Komponente μC
funktionsfähig
0,2
Ja
Spannungsversorgung
defekt
Defekt auf
Hardware-Ebene
0,6
Bauteil μC
defekt
© 2015 IAS, Universität Stuttgart
Ereignis
0,8
Nein
Nein
Ja
Nein
0,4
Softwarefehler
221
4.3 Einsatz von Werkzeugen
ZSA
Matrix-Diagramme – Korrelation und Kausalität
 Graphische Darstellung von Korrelationen zwischen BetrachtungsGegenständen und/oder ihren spezifischen Eigenschaften
 Häufiger Irrtum:
Quelle: www.xkcd.com, 2014
• Korrelation ist eine Wechselbeziehung, d.h., dass sich beispielsweise
Merkmale, Funktionen oder Ereignisse ähnlich verhalten:
„Im Sommer wird mehr Eis gegessen und es gibt mehr Sonnenbrände.“
• Kausalität ist das Prinzip zwischen Ursache und Wirkung, d.h., es
gibt eine Richtung von Aktion zu Reaktion:
„Eis essen verursacht Sonnenbrand.“
© 2015 IAS, Universität Stuttgart
222
4.3 Einsatz von Werkzeugen
ZSA
Matrix-Diagramm – Einsatz und Bewertung
 Bei der FMEA erfolgt die Verbindung von Komponenten zu den einzelnen,
produktsicherheitsrelevanten Merkmalen und Sichtweisen auf das Produkt
(Problemursache, Verantwortlichkeiten, Ressourcen,…)
 Es erfolgt Überführung und Gewichtung in Tabellenform:
Komponenten
Merkmale
Gewichtung
 Vorteil:
• Klare Übersicht
• Besseres Verständnis
 Nachteil:
• Erfordert Erfahrung und Fachverständnis bei großen und komplexen
Systemen
© 2015 IAS, Universität Stuttgart
223
4.3 Einsatz von Werkzeugen
ZSA
Matrix-Diagramm – Vorgehensbeispiel der Tabellenform
 Merkmale in den Zeilen werden mit Faktoren (z.B. 1-3) gewichtet
 Zeilenwerte einer Komponente werden in der Spalte addiert
 Komponente mit dem höchsten Zahlenwerten birgt das größte Ausfallrisiko
 Komponente mit dem größten Risiko wird in der FMEA detaillierter untersucht
Bauteil / Systemelement
Kosten-Kriterien
Sensor
Verstärker
μC
Neuentwicklung
2
1
3
Produktänderung
2
1
3
Prozessänderungen
2
2
2
Summe
6
4
8
© 2015 IAS, Universität Stuttgart
224
4.3 Einsatz von Werkzeugen
ZSA
FMEA-Software
 Nutzen der EDV-Unterstützung:
• Einfache Erstellung, Pflege und Dokumentation
• Unterstützung des FMEA-Teams (besonders Moderator, vgl. Kap 4.4)
• Überwachung der Terminplanung und Verantwortlichkeiten
• Gute Darstellung der Schritte bzw. Ergebnisse während der
Durchführung
 Zusätzlicher Aufwand:
• Auswahl einer geeigneten Software gemäß den Anforderungen des
Unternehmens bzw. des FMEA-Teams
• Erlernen und Beherrschen des FMEA-Programms
© 2015 IAS, Universität Stuttgart
225
4.3 Einsatz von Werkzeugen
ZSA
Software Beispiel: IQ-FMEA
 „IQ-FMEA“ von APIS Informationstechnologien
Quelle: www.apis.de, 2014
Quelle: www.apis.de
Quelle: www.apis.de, 2014
© 2015 IAS, Universität Stuttgart
226
4.3 Einsatz von Werkzeugen
ZSA
Software Beispiel: PLATO SCIO FMEA
 „PLATO SCIO-FMEA“ von Plato GmbH
Quelle: www.plato.de, 2014
Quelle: www.plato.de, 2014
© 2015 IAS, Universität Stuttgart
227
4.3 Einsatz von Werkzeugen
ZSA
Frage zu Kapitel 4.3
Welchen Aussagen stimmen Sie zu?
□
FTA entspricht der Ermittlung aller Gefährdungen, die auf einen
bestimmten Fehler bzw. Störfall folgen können.
□
In Matrix-Diagrammen werden Kausalitäten von Komponenten
verglichen und bewertet.
□
□
Bei Fischgräten-Diagrammen können auch zeitbehaftetet Ausfallarten
korrekt dargestellt werden.
Checklisten garantieren eine qualitative Zuverlässigkeitsanalyse auch
von Entwicklern, die noch über keine große Erfahrung verfügen.
© 2015 IAS, Universität Stuttgart
228
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
4.1 Grundlagen der FMEA
4.2 Arten der FMEA
4.3 Einsatz von Werkzeugen
4.4 Durchführung der FMEA
4.5 Risikoprioritätszahl (RPZ)
4.6 FMEA-Formblatt
4.7 Software-FMEA (SFMEA)
© 2015 IAS, Universität Stuttgart
229
4.4 Durchführung der FMEA
ZSA
Teamorientierung
 FMEA ist immer teamorientiert
 Einzelnen Punkte werden von einem FMEA-Team diskutiert und erörtert
Verantwortlicher
Experten
(versch. Fachbereiche)
© 2015 IAS, Universität Stuttgart
Moderator
bzw.
Methodenspezialist
230
4.4 Durchführung der FMEA
ZSA
Beteiligte Fachbereiche
 Expertengruppe setzt sich aus Vertretern verschiedener Fachbereiche
zusammen:
Qualitätssicherung
Entwicklung
Vertrieb
Fertigung
ExpertenGruppe
Verwaltung
Projektplanung
Logistik
Erprobung/Test
 Moderator ist ein Methodenspezialist aus einem der Fachbereiche
 Moderator kann auch identisch mit dem Verantwortlichen sein
 Verantwortlicher ist der Initiator der FMEA, oftmals Gesamtprojektleiter
© 2015 IAS, Universität Stuttgart
231
4.4 Durchführung der FMEA
ZSA
Aufgabe des FMEA-Team (1/2)
 Problemlösung und Ideenfindung durch gegenseitige
Anregung auf möglichst intuitive Art
 Laute Techniken, z.B. Diskussion über Brainstorming:
• Nach Alex F. Osborn, Autor, USA 1939
Quelle: www.mindspower.com, 2014
• Gruppe von 5 – 7 Personen, je nach Problemstellung Experten/Laien
• Grundsätzliche Regeln:
 Freies Aufgreifen von Ideen, freies Assoziieren und Phantasieren
 Kommentare, Korrekturen und Kritik sind verboten
 Begrenzter Zeitrahmen von ca. 5 - 30 min
• Einfache und kostengünstige Methode
• Gruppendynamik /-synergie führt oftmals zu innovativen Lösungsansätzen
• Nachteilig ist die Abhängigkeit von den Teilnehmern, Gefahr des
Abschweifens und die Selektion geeigneter Ideen
© 2015 IAS, Universität Stuttgart
232
4.4 Durchführung der FMEA
ZSA
Aufgabe des FMEA-Team (2/2)
 Ruhige Techniken, z.B. Kreativitätstechnik Brainwriting über „6-3-5-Methode“:
• Nach Bernd Rohrbach, Unternehmensberater, Deutschland 1968
• Reihenweise werden Ideen nach dem Schema niedergeschrieben, dass
bereits notierte Ideen aufgegriffen und ergänzt werden:
6 Teilnehmer
3 Ideen pro Teilnehmer
3
2
2
1
1
5 Weitergaben
18
Ideen
6
6
15
12
9
3
3
5
4
4
5
• Viele Ideen in kurzer Zeit, die nicht „zerredet“ werden
• Jeder Teilnehmer ist gleichberechtigt
• Nachteilig ist, dass der starre Ablaufmechanismus die Kreativität stören
oder der Bearbeitungstakt für Teilnehmer zu langsam/schnell sein kann
© 2015 IAS, Universität Stuttgart
233
4.4 Durchführung der FMEA
ZSA
Grundsätzlicher Ablauf einer FMEA
System-FMEA
Konstruktions-FMEA
Produkt- & Prozess-FMEA
Strukturanalyse
Funktionsanalyse
Fehleranalyse
Maßnahmenanalyse
Optimierung
© 2015 IAS, Universität Stuttgart
234
4.4 Durchführung der FMEA
ZSA
Strukturanalyse
 Systemstruktur erstellen:
• Zu untersuchendes System wird von der Umgebung abgegrenzt und
Schnittstellen werden klar definiert
• System wird in immer weitere Systemelemente aufgeteilt, bis einzelne
Funktionsgruppe, Baugruppen oder Bauteile vorliegen
• Einzelne Systemelemente werden hierarchisch angeordnet
 Schema:
System
© 2015 IAS, Universität Stuttgart
System-Element 1
System-Element 2.1
System-Element 2
System-Element 2.2
System-Element 3
System-Element 2.3
235
4.4 Durchführung der FMEA
ZSA
Funktionsanalyse
 Auf Basis der Strukturanalyse werden den Systemelementen einzelne
Funktionen zugeordnet
 Vorgehen nach Top-Down-Methode:
• Ausgehend von den Top-Funktionen des Systems werden die
entsprechenden Funktionalitäten mit den Elementen verknüpft
• Kenntnis der Funktionsanforderung unverzichtbar (Lasten-/Pflichtenheft)
System-Element 2.1
System-Element 2
System
Top-Funktion 1
Top-Funktion 2
© 2015 IAS, Universität Stuttgart
Teil-SystemFunktion 2.1
Teil-SystemFunktion 2.2
Sub-SystemFunktion 2.1.1
Sub-SystemFunktion 2.1.2
236
4.4 Durchführung der FMEA
ZSA
Fehleranalyse
 Für jedes Systemelement wird eine Fehleranalyse durchgeführt, d.h., mögliche
Fehlfunktionen werden ermittelt
 Funktionsfehler können über die Negation der Funktionalität abgeleitet werden
 Entsprechend der Top-Down-Methode werden die Fehlfunktionen mit den
Funktionen verknüpft
System-Element 2.1
System-Element 2
System
Top-Funktion 1
Top-SystemFehler 1
Top-Funktion 2
Top-SystemFehler 2
© 2015 IAS, Universität Stuttgart
Teil-SystemFunktion 2.1
Teil-SystemFehler 2.1
Teil-SystemFunktion 2.2
Teil-SystemFehler 2.2
Sub-SystemFunktion 2.1.1
Sub-SystemFehler 2.1.1
Sub-SystemFunktion 2.1.2
Sub-SystemFehler 2.1.2
237
4.4 Durchführung der FMEA
ZSA
Maßnahmenanalyse
 Es wird nun der aktuelle Stand des Systems bewertet
 Dazu werden die Kombinationen aus Funktion und Fehler unter Einbeziehung
der bisherigen festgelegten Prüfmaßnahmen untersucht:
• Vermeidungsmaßnahmen zur Risikobeseitigung
• Entdeckungsmaßnahmen zur Risikominderung
 Das Ergebnis der Untersuchung wird über folgende Kriterien bewertet:
• Auftretenswahrscheinlichkeit der Fehler-Ursache
• Bedeutung der Fehler-Folge
• Entdeckungswahrscheinlichkeit der Fehler-Ursache
 Aus den Bewertungskriterien wird Risikoprioritätszahl berechnet (siehe Kap 4.5)
 Entsprechend der Risikoprioritätszahl erfolgt die Ableitung von weiteren
Maßnahmen zur Risikobeseitigung/-minderung
© 2015 IAS, Universität Stuttgart
238
4.4 Durchführung der FMEA
ZSA
Optimierung
 Optimierungen an den Systemelementen, über die zuvor abgeleiteten
zusätzlichen Maßnahmen, erfolgt je nach Priorität:
• Konzeptänderungen um Fehler-Ursachen auszuschließen
 Änderung der Konstruktion
 Umgestaltung von Prozessen
• Konzeptzuverlässigkeit erhöhen um Schwere der Fehler-Art zu reduzieren
 Redundanz
 Fehleranzeigen
• Wirksamere Entdeckungsmaßnahmen
 Größere Anzahl von Tests
 Reviews
 Abschließend wird der neue bzw. geänderte Stand des Systems bewertet
 Abschätzung des Systemzustands erfolgt ernuet über die Risikoprioritätszahl
© 2015 IAS, Universität Stuttgart
239
4.4 Durchführung der FMEA
ZSA
Frage zu Kapitel 4.4
Welchen Aussagen stimmen Sie zu?
□
Der FMEA-Prozess beginnt mit der Auflistung der Funktionalität.
□
Die „6-3-5-Methode“ beschreibt eine Diskussionsform zur Ideenfindung.
□
□
Zusätzliche Maßnahmen lassen sich unter anderem aus der
Entdeckungswahrscheinlichkeit von Fehlern ableiten.
Der Initiator einer FMEA kann auch die Moderation übernehmen.
© 2015 IAS, Universität Stuttgart
240
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
4.1 Grundlagen der FMEA
4.2 Arten der FMEA
4.3 Einsatz von Werkzeugen
4.4 Durchführung der FMEA
4.5 Risikoprioritätszahl (RPZ)
4.6 FMEA-Formblatt
4.7 Software-FMEA (SFMEA)
© 2015 IAS, Universität Stuttgart
241
4.5 Risikoprioritätszahl (RPZ)
ZSA
Risikoprioritätszahl (RPZ)
 Die Risikobeurteilung bei einer FMEA erfolgt im Rahmen der
Maßnahmenanalyse über die Risikoprioritätszahl (RPZ)
 Für jede Fehlerart eines Betrachtungsgegenstand wird die RPZ ermittelt
 RPZ berechnet sich über die Multiplikation von Einzelbewertungen:
• Auftretenswahrscheinlichkeit (A)
• Bedeutung bzw. Schwere einer Gefährdung, d.h., einer Fehler-Folge (B)
• Entdeckungswahrscheinlichkeit (E)
𝐑𝐏𝐙 = 𝐀 ∗ 𝐁 ∗ 𝐄
 Die Einzelbewertungen werden von der interdisziplinären Experten-
Gruppe gemäß genormten Tabellenvorlagen bestimmt
© 2015 IAS, Universität Stuttgart
242
4.5 Risikoprioritätszahl (RPZ)
ZSA
Begriff Auftretenswahrscheinlichkeit (A)
 Bewertung der Auftretenswahrscheinlichkeit (A) einer Fehler-Ursache erfolgt
unter Berücksichtigung der definierten Vermeidungsmaßnahmen
 Ist es nahezu sicher, dass eine Fehler-Ursache auftritt, dann entspricht das
einer Auftretenswahrscheinlichkeit von 10
 Ist es äußerst unwahrscheinlich, so entspricht das dem Wert 1
 Je detaillierter die Fehleranalyse durchgeführt wurde, desto differenzierter
kann die Bewertung erfolgen
 Es wird bei der Bewertung von Ursachen auf bekannte Erfahrungswerte
zurückgegriffen (Schadenstatistiken, Zuverlässigkeitsraten,…)
© 2015 IAS, Universität Stuttgart
243
4.5 Risikoprioritätszahl (RPZ)
ZSA
Berechnung der Auftretenswahrscheinlichkeit
A=(w·g)+f
w
Fehlerwahrscheinlichkeit
1
Fehlverhalten wird selten erwartet
2
Fehlverhalten wird mit mäßiger Häufigkeit erwartet
3
Fehlverhalten wird sehr häufig erwartet
g
Gefährdungsdisposition
1
Aufenthalt im Gefahrenbereich sehr selten
2
Nur zeitweiser Aufenthalt im Gefahrenbereich
3
Sehr langer oder ständiger Aufenthalt im Gefahrenbereich
f
Anfälligkeit der Gefährdung
0
Nicht anfällig (gute persönliche Schutzausrüstung)
1
Sehr anfällig (keine Schutzausrüstung)
© 2015 IAS, Universität Stuttgart
244
4.5 Risikoprioritätszahl (RPZ)
ZSA
Bewertungskriterien der Auftretenswahrscheinlichkeit
Häufigkeit
Bewertungspunkte
Hoch
Es ist nahezu sicher, dass Fehler in größerem Umfang auftreten
werden.
1/10
1/20
10
9
Mäßig
Mit früherem Fertigungsverfahren vergleichbar, das oft zu Fehlern
führte (Prozess wird beherrscht).
1/50
1/100
8
7
Gering
Mit früherem Fertigungsverfahren vergleichbar, das gelegentlich,
jedoch nicht in einem wesentlichen Umfang, Fehler aufweist
(Prozess wird beherrscht).
1/200
1/500
1/1000
6
5
4
1/2000
1/20 000
3
2
≈0
1
Allgemeine Bewertungskriterien
Sehr gering
Der Prozess wird statistisch beherrscht.
Unwahrscheinlich
Die Prozessfähigkeit ist sichergestellt.
© 2015 IAS, Universität Stuttgart
245
4.5 Risikoprioritätszahl (RPZ)
ZSA
Begriff Bedeutung der Fehler-Folge (B)
 Bedeutung der Fehler-Folge (B) bewertet die Folgen einer Fehler-Ursache auf
das System
 Unter Folgen sind konkrete Risiken und Gefährdungen zu verstehen
 Bewertung erfolgt stets aus der Sicht des Nutzers bzw. Endverbrauchers
 Wert 10 steht für eine sehr hohe, 1 für eine sehr geringe Gefährdung
 Gleiche Fehler-Folgen müssen stets mit der gleichen Schwere bzw. dem
gleichen Zahlenwert bewertet werden
© 2015 IAS, Universität Stuttgart
246
4.5 Risikoprioritätszahl (RPZ)
ZSA
Berechnung der Bedeutung der Fehler-Folge
B=(v·d)+b
v
Verletzungsgrad
1
Leichte Verletzungen (Erste-Hilfe-Versorgung)
2
Mittelschwere Verletzungen (ambulante Behandlung notwendig)
3
Sehr schwere Verletzungen (stationäre Behandlung notwendig)
d
Schadensdauer
1
Keine Langzeitschäden oder Verletzungsfolgen
2
Noch tragbare Langzeitschäden
3
Schwere Langzeitschäden (Berufsunfähigkeit, Invalidität)
b
Rettungschancen und Schadensbegrenzung
0
Gute Rettungschancen, erfolgversprechende Schadensbegrenzung
1
Schlechte Voraussetzungen für Rettung und Schadensbegrenzung
© 2015 IAS, Universität Stuttgart
247
4.5 Risikoprioritätszahl (RPZ)
ZSA
Bewertungskriterien der Bedeutung der Fehler-Folge
Allgemeine Bewertungskriterien
Bewertungspunkte
Es tritt ein äußerst schwerwiegender Fehler auf, der darüber hinaus die Sicherheit
und / oder die Einhaltung gesetzlicher Vorschriften beeinträchtigt.
10
9
Es tritt ein schwerer Fehler auf, der eine Verärgerung beim Kunden auslöst
(Fehlfunktionen). Sicherheitsaspekte oder gesetzliche Vorschriften werden
hierdurch nicht berührt bzw. treffen hier nicht zu.
8
7
Es tritt ein mittelschwerer Fehler auf, der beim Kunden Unzufriedenheit auslöst.
Der Kunde fühlt sich dadurch belästigt oder gestört.
Der Kunde wird diese Beeinträchtigungen bemerken bzw. wahrnehmen.
(„Lautsprecher brummt“ oder „Pedalkräfte zu hoch“)
6
5
4
Der Fehler ist unbedeutend und der Kunde wird nur geringfügig belästigt. Der
Kunde wird nur geringe Beeinträchtigungen am Untersuchungsgegenstand
bemerken.
3
2
Es ist unwahrscheinlich, dass der Fehler wahrnehmbare Auswirkungen auf das
Verhalten des Untersuchungsgegenstandes haben könnte.
Der Kunde wird den Fehler wahrscheinlich nicht bemerken.
© 2015 IAS, Universität Stuttgart
1
248
4.5 Risikoprioritätszahl (RPZ)
ZSA
Begriff der Entdeckungswahrscheinlichkeit (E)
 Bewertung der Entdeckungswahrscheinlichkeit (E) einer Fehler-Ursache
erfolgt unter Berücksichtigung der definierten Entdeckungsmaßnahmen
 Es werden auch Entdeckungsmaßnahmen berücksichtigt, die lediglich die
Fehler-Folge an sich erkennen und somit nur indirekt auf die Fehler-Ursache
geschlossen werden kann
 Bewertung von 10 wird vergeben, wenn keine Entdeckungsmaßnahmen
definiert wurden und ein Fehler sicher nicht gefunden werden kann
 Wert 1, wenn ein Fehler mit einer sehr hohen Wahrscheinlichkeit gefunden
werden kann
© 2015 IAS, Universität Stuttgart
249
4.5 Risikoprioritätszahl (RPZ)
ZSA
Berechnung der Entdeckungswahrscheinlichkeit E
E=(q·k)+r
q
Qualifikation der gefährdeten Person
1
Fachmann
2
unterwiesene Person
3
Laie, nicht unterwiesene Person
k
Komplexität der Gefährdungssituation
1
Geringe Komplexität, Situation gut durchschaubar
2
Mittlere Komplexität, Situation noch durchschaubar
3
Hohe Komplexität, Situation kaum durchschaubar
r
Reaktions-, Eingreif-, Ausweichmöglichkeit
0
Gute Reaktionsmöglichkeiten
1
Schlechte Reaktionsmöglichkeiten
© 2015 IAS, Universität Stuttgart
250
4.5 Risikoprioritätszahl (RPZ)
ZSA
Bewertungskriterien der Entdeckungswahrscheinlichkeit
Allgemeine Bewertungskriterien
Häufigkeit
Bewertungspunkte
Unwahrscheinlich
Das Merkmal wird nicht geprüft bzw. kann nicht geprüft werden.
Verdeckter Fehler, der in der Fertigung oder Montage nicht entdeckt
wird.
<90 %
10
Sehr gering
Schwerer zu erkennendes Fehlermerkmal. Erkennung durch
visuelle oder manuelle 100%-Prüfung möglich.
>90 %
9
Gering
Leicht zu erkennendes, messbares Fehlermerkmal.
Erkennung durch 100%-Prüfung möglich (automatisiert).
>98 %
6-8
Mäßig
Es handelt sich um ein augenscheinliches Fehlermerkmal.
Erkennung durch 100%-Prüfung möglich (automatisiert).
>99,7 %
2-5
Hoch
Funktioneller Fehler, der bei den nachfolgenden Arbeitsschritten
bemerkt wird.
>99,99 %
1
© 2015 IAS, Universität Stuttgart
251
4.5 Risikoprioritätszahl (RPZ)
ZSA
Analyse der Risikoprioritätszahl
 Je nachdem, welcher Wert sich für die RPZ ergibt, sind bestimmte weitere
Maßnahmen sinnvoll:
RPZ
Einstufung
Bemerkung/Maßnahmen
Akzeptables Restrisiko
Keine Maßnahme erforderlich.
Geringes Restrisiko
Zusätzlicher Warnhinweis erforderlich.
(Maschine bzw. Benutzerhandbuch)
125 < RPZ < 250
Erhöhtes Restrisiko
Ergänzende, zusätzliche Schutzmaßnahmen
erforderlich.
(trennende und nicht trennende
Schutzeinrichtungen notwendig)
250 < RPZ < 1000
Inakzeptables Restrisiko
Konstruktive Maßnahmen unbedingt
erforderlich.
1 < RPZ < 100
100 < RPZ < 125
© 2015 IAS, Universität Stuttgart
252
4.5 Risikoprioritätszahl (RPZ)
ZSA
Frage zu Kapitel 4.5
Welchen Aussagen stimmen Sie zu?
□
Die RPZ ist das Produkt aus Auftretenswahrscheinlichkeit, Bedeutung
einer Gefährdung und Erfindungsreichtum von Maßnahmen.
□
Wird ein Fehler gefunden, so ist die Entdeckungswahrscheinlichkeit 10.
□
RPZ-Werte ab 250 sind für ein System inakzeptabel.
□
Akzeptable Risiken erfordern einen Warnhinweis im Benutzerhandbuch.
© 2015 IAS, Universität Stuttgart
253
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
4.1 Grundlagen der FMEA
4.2 Arten der FMEA
4.3 Einsatz von Werkzeugen
4.4 Durchführung der FMEA
4.5 Risikoprioritätszahl (RPZ)
4.6 FMEA-Formblatt
4.7 Software-FMEA (SFMEA)
© 2015 IAS, Universität Stuttgart
254
4.6 FMEA-Formblatt
ZSA
Grundlegendes Schema eines FMEA-Formblatts
 Durchführung und Ergebnis einer FMEA werden in einem Formblatt dargestellt
 Formblättere können einen unterschiedlichen Aufbau oder verschiedene
Bezeichnungen haben, jedoch ist die Struktur immer über folgenden 4 Bereiche
gegeben:
1
Stammdaten
2
Betrachtungsgegenstand
© 2015 IAS, Universität Stuttgart
3
Risiko-Analyse
und Bewertung
4
Maßnahmen der
Risikominderung
255
4.6 FMEA-Formblatt
ZSA
Stammdaten
1
Stammdaten
 Im Kopf des FMEA-Formblatts oder auf dem Deckblatt
2
Betrachtungsgegenstand
3
Risiko-Analyse
und Bewertung
4
Maßnahmen
der Risikominderung
 Beinhaltet z.B.:
• Daten des Unternehmens
• Bearbeiter bzw. FMEA-Team
• Kenndaten des Projekts
• Kenndaten des Systemelements (System-Nr.)
 Es muss klar ersichtlich sein:
• Um welches Projekt es sich handelt
• Welches Systemelement betrachtet wird
• Welche Fehler-Folge untersucht wird
© 2015 IAS, Universität Stuttgart
256
4.6 FMEA-Formblatt
ZSA
Betrachtungsgegenstand
1
Stammdaten
 Enthält:
•
2
Betrachtungsgegenstand
3
Risiko-Analyse
und Bewertung
4
Maßnahmen
der Risikominderung
Zu untersuchendes Systemelement
 Baugruppe
 Bauteil
 Prozessschritt
• Zugehörige Funktionalität
• Fehlerbeschreibung
 Fehler-Art
 Fehler-Ursache
 Daten werden entsprechend den Erfordernissen (Top-, Teil- oder SubSystem) eingetragen
© 2015 IAS, Universität Stuttgart
257
4.6 FMEA-Formblatt
ZSA
Risiko-Analyse und Bewertung
1
Stammdaten
2
 Enthält die bestehenden Prüfmaßnahmen:
Betrachtungsgegenstand
3
Risiko-Analyse
und Bewertung
4
Maßnahmen
der Risikominderung
• Vermeidungsmaßnahmen
• Erkennungsmaßnahmen
 Bestimmung bzw. Berechnung der Risikoprioritätszahl (gemäß Kap 4.5):
• Auftretenswahrscheinlichkeit einer Fehler-Ursache unter Berücksichtigung
der Vermeidungsmaßnahmen
• Bedeutung der Fehler-Folge für das Gesamtsystem
• Entdeckungswahrscheinlichkeit unter Berücksichtigung aller wirksamen
Erkennungsmaßnahmen
© 2015 IAS, Universität Stuttgart
258
4.6 FMEA-Formblatt
ZSA
Maßnahmen der Risikominderung
1
Stammdaten
2
 Enthält die, entsprechend der Risikoprioritätszahl, neuen
Betrachtungsgegenstand
3
Risiko-Analyse
und Bewertung
4
Maßnahmen
der Risikominderung
abgeleiteten Maßnahmen zur Fehlerbehandlung
 Verantwortlichkeit bei der Durchführung der Maßnahmen
 Wurden die Maßnahmen durchgeführt, so erfolgt die erneute Bestimmung und
Dokumentation der Risikoprioritätszahl im FMEA-Formblatt
 Es wird dadurch ermittelt, ob die getätigten Verbesserungen ausreichend
waren, um das Risiko auf einen vertretbaren Rahmen zu mindern oder ob
nochmals weitere Optimierungen notwendig sind
© 2015 IAS, Universität Stuttgart
259
4.6 FMEA-Formblatt
ZSA
Auszug FMEA-Formblatt
Stammdaten
Betrachtungsgegenstand
Maßnahmen der Risikominderung
Risiko-Analyse
und Bewertung
© 2015 IAS, Universität Stuttgart
260
4.6 FMEA-Formblatt
ZSA
Frage zu Kapitel 4.6
Welchen Aussagen stimmen Sie zu?
□
Stammdaten sind Teil des FMEA-Formblatts.
□
Betrachtungsgegenstand ist Teil des FMEA-Formblatts.
□
Instrumente bzw. Werkzeuge der Risiko-Analyse sind Teil des FMEAFormblatts.
□
Maßnahmen der Risikominderung sind Teil des FMEA-Formblatts.
© 2015 IAS, Universität Stuttgart
261
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
4.1 Grundlagen der FMEA
4.2 Arten der FMEA
4.3 Einsatz von Werkzeugen
4.4 Durchführung der FMEA
4.5 Risikoprioritätszahl (RPZ)
4.6 FMEA-Formblatt
4.7 Software-FMEA (SFMEA)
© 2015 IAS, Universität Stuttgart
262
4.7 Software-FMEA (SFMEA)
ZSA
FMEA in der Softwareentwicklung
 FMEA für Software-Systeme muss an die speziellen Anforderungen von
Software angepasst werden (vgl. Kap 5):
• Software unterliegt nicht dem Verschließ
• Software beinhaltet direkt bei Inbetriebnahme Fehler
• usw.
 Entscheidend ist die Tatsache, dass Software keine spezifischen, bekannten
und eindeutigen Ausfallwahrscheinlichkeiten aufweist
 Eine Bewertung über Wahrscheinlichkeiten fällt somit weg
 Man spricht daher im Zusammenhang mit der Software-FMEA (SFMEA) von
einer „Analyse von Möglichkeiten“
© 2015 IAS, Universität Stuttgart
263
4.7 Software-FMEA (SFMEA)
ZSA
Vorgehen
 Es fehlen (noch) allgemeingültige Standards bzw. Prozeduren zur
Durchführung einer SFMEA
 Es wird sich daher auf den bekannten Ablauf bezogen:
1. Strukturanalyse
2. Funktionsanalyse
3. Fehleranalyse
4. Risikobewertung
5. Optimierung
 Hier erfolgt eine Betrachtung der Schritte 1 - 3, da sich das Kapitel 5
ausführlich mit der Bewertung von Softwarezuverlässigkeit und Maßnahmen
zur Steigerung dieser beschäftigt
© 2015 IAS, Universität Stuttgart
264
4.7 Software-FMEA (SFMEA)
ZSA
Strukturanalyse
 Strukturanalyse entspricht prinzipiell der Analyse des Programmablaufs
 Programmablauf wird dem im Entwurf definierten Flussdiagramm entnommen
 Sollte das Flussdiagramm nicht aktuell sein oder fehlen, so kann ein
Kontrollflussgraph zu einem Software-Segment erstellt werden
 Beispiel:
int a = 0;
(1)
1
if (x>0 && y>0)
{
a = 10;
}
(2)
2
(3)
3
else if (x>10 && y<10)
{
a = 20;
}
(4)
4
(5)
5
else
{
a = 30;
6
(6)
}
return a;
© 2015 IAS, Universität Stuttgart
(7)
7
265
4.7 Software-FMEA (SFMEA)
ZSA
Funktionsanalyse
 Die exakte Funktionalität des Systems zu verstehen ist der wichtigste, aber
auch komplexeste Schritt
 Anforderungen an das Software-System müssen mit dem zu analysierenden
Code abgeglichen werden
• Überführung von menschlicher Sprache in maschinelle Sprache (Code)
ist immer kritisch
• Fehler bei diesem Schritt führen zu unbrauchbaren Ergebnissen der
SFMEA
 Weitere Aspekt ist der Durchführungszeitpunkt:
• In frühen Phasen liegen oft nur Teile der Gesamtsoftware vor
• Betrachtung des Gesamtsystems ist nicht möglich
© 2015 IAS, Universität Stuttgart
266
4.7 Software-FMEA (SFMEA)
ZSA
Fehleranalyse (1/2)
 Ansatz der Fehleranalyse ist die Annahme, dass jede Funktion in einen
Fehlerzustand geraten kann:
• Variable wird falsch zugewiesen
• Eingabewert ist falsch
• Ungewollter Aufruf eines Moduls
 Es müssen daher alle möglichen Fehler-Ursachen betrachtet werden:
• Algorithmen-Fehler (Formeln, Modelle,…)
• Bedatungs-Fehler (Festwerte von Konstanten, Grenzwerte von Variablen)
• Programmierfehler (Semantik)
• Methodenfehler (Programmiersprache)
• Designfehler
© 2015 IAS, Universität Stuttgart
267
4.7 Software-FMEA (SFMEA)
ZSA
Fehleranalyse (2/2)
 Um wirklich alle Fehler-Ursachen betrachten zu können, müssen sämtliche
Pfade des Kontrollflussgraphen berücksichtigt werden:
• Sehr zeitaufwendig und unübersichtlich
• Gefahr Pfade zu „übersehen“ (unbewusst/bewusst)
 Automatisierte Unterstützung notwendig zur:
• Generierung der großen Menge an Daten
• Verarbeitung der Datenmenge
 Notwendig, da nur bei Berücksichtigung aller Fehler-Ursachen und –Zustände
eine Ableitung von effektiven Gegenmaßnahmen möglich ist
© 2015 IAS, Universität Stuttgart
268
4.7 Software-FMEA (SFMEA)
ZSA
Frage zu Kapitel 4.7
Welchen Aussagen stimmen Sie zu?
□
□
□
□
Die Überführung von menschlicher in maschinelle Sprache ist
immer ein kritischer Vorgang.
Bei der SFMEA muss nicht jede Zeile-Code analysiert werden,
bereits eine Betrachtung der einzelnen Module ist aussagekräftig.
SFMEA wird besonders bei sicherheitskritischen Systemen eingesetzt,
da der Code vollständig geprüft wird.
SFMEA erlaubt eine klare Bestimmung der Ausfallwahrscheinlichkeit
eines Moduls.
© 2015 IAS, Universität Stuttgart
269
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Gliederung
§ 1 Einführung, Begriffe und Normen
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
§ 3 Fehlerbaumanalyse (FTA)
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
§ 5 Softwarezuverlässigkeit
§ 6 Zuverlässigkeits- und Sicherheitstechnik
§ 7 Übungsaufgaben
© 2015 IAS, Universität Stuttgart
270
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 5 Softwarezuverlässigkeit
5.1 Grundlagen der Softwarezuverlässigkeit
5.2 Maßnahmen gegen Softwarefehler
5.3 Modelle der Softwarezuverlässigkeit
5.4 Komponentenansatz
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
© 2015 IAS, Universität Stuttgart
271
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Softwarekrise – Damals!
 Mitte der 1960er überstiegen Softwarekosten erstmals die Hardwarekosten
 Entwicklungs- und Zuverlässigkeitsmethoden waren nicht an die Komplexität
und Anforderungen von Software angepasst:
•
Termine konnten nicht gehalten werden
•
Zeitdruck und, in Folge davon, die Zahl der Softwarefehler erhöhten sich
•
Gesamtkosten überstiegen Planung um ein Vielfaches
 Folge war, dass die ersten großen Software-Projekte scheiterten
 Daher Einführung des Begriffs Software-Engineering und Definition von
Entwicklungsvorgehen (NATO-Tagung 1968) mit der Erkenntnis:
„[…]when we had a few weak computers, programming became a mild
problem, and now we have gigantic computers, programming has
become an equally gigantic problem.”
(Edsger Dijkstra (1930-2002), niederländischer Informatiker, Wegbereiter der strukturierten Programmierung)
© 2015 IAS, Universität Stuttgart
272
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Softwarekrise – Heute?!
 Einsatz, Variation und Komplexität von Software wächst rasant
 Softwaregesteuerte Produkte übernehmen immer wichtigere und kritischere
Aufgaben in unserem Alltag
 Aber noch viele offene Punkte und Fragen:
• Führt der weiterhin steigende Entwicklungs- und Kostendruck auch zu einer
immer weiter steigenden Zahl von Fehlern?
• Kann die Qualitätssicherung mit dem Tempo der Entwicklung Schritt
halten?
• Was sind die Folgen von unzureichender Zuverlässigkeit oder möglicher
Sicherheitslücken?
 Softwarekrise ist weiterhin ein ungelöstes Problem der Informationstechnik!
© 2015 IAS, Universität Stuttgart
273
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Aspekte von Software (1/2)
 Software zur Realisation komplexer Funktionen nimmt eine immer wichtigere
Rolle ein
 Jede Software beinhaltet Fehler:
• Inhärente, systematische Fehler
 Spezifikationsfehler
 Entwurfsfehler
 Implementierungsfehler
 Dokumentationsfehler
• Verhalten abhängig vom Betriebsprofil (Umgebung,…)
© 2015 IAS, Universität Stuttgart
274
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Aspekte von Software (2/2)
 Testverfahren zeigen die Anwesenheit von Fehlern
 Keine genauen, auf empirischen Untersuchungen beruhenden Daten und
Aussagen über die Ausfallrate λ von Software möglich
 Entwicklung zuverlässiger Software ist ein Drahtseilakt
Anforderungen
© 2015 IAS, Universität Stuttgart
SW-Programm
275
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Hardware-Einheiten und Software-Einheiten
 Basis der Software-Zuverlässigkeitsarbeit ist das Verständnis der
Unterschiede zwischen Hardware- und Software-Einheiten:
Hardware-Einheiten
Software-Einheiten
Durchlaufen immer mehrere
Fertigungsphasen
Werden nach einmaliger
Implementierung einfach kopiert
Fehlerfrei bei Inbetriebnahme
Enthält Fehler bei Inbetriebnahme
Ausfall zu einem nicht
vorhersagbaren Zeitpunkt
Ausfall unter nicht
vorhersagbaren Mechanismen
Ausfall führt zum sofortigen
Versagen
Ausfall in Abhängigkeit
bestimmter Konstellationen
© 2015 IAS, Universität Stuttgart
276
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Fehlerursache von Hardware und Software
 Einordnung und Abgrenzung von Hardware- und Software-Fehlern:
NaturGesetze
Physikalische und
chemische Prozesse
(System und Umwelt)
Mensch
Bauelemente-Ausfall
Hardwarefehler
Störsignal
Softwarefehler
Ausgabefehler
Wartungs- oder
Bedienungsfehler
© 2015 IAS, Universität Stuttgart
277
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Beispiele für Softwarefehler
 Betrachtet wird ein simples C-Programm mit eingebauten Fehlern:
int a;
int c = 10;
int main()
{
if (a <= c)
{
printf("a ist c oder kleiner als c! \n");
return;
}
else if (a = b)
{
printf("a ist b! \n");
return;
}
else
(
printf("a ist weder b noch c, sowie größer als c! \n");
return;
)
}
© 2015 IAS, Universität Stuttgart
278
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Typische Softwarefehler (1/2)
 Datenreferenz
• Initialisierungsfehler
• Indizes außerhalb definierter Grenzen
 Datendeklaration
• Deklaration der Variablen fehlt
• Attribute wurden falsch verstanden
 Berechnung
• Verwendung inkorrekter Datentypen (Rundungsfehler, Überläufe,…)
• Falsch gesetzte Klammern
 Vergleich
• Inkorrekte Boolesche Ausdrücke
• Prioritäten der Vergleichsoperatoren wurden falsch verstanden
© 2015 IAS, Universität Stuttgart
279
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Typische Softwarefehler (2/2)
 Steuerfluss
• Falsche Schleifenendekriterien
• Struktur fehlerhaft (z.B. bei DO/END-Anweisung)
 Schnittstellen
• Verwechslung von Variablen und Konstanten
• Parameter oder Argumente nicht konsistent
 Ein-/Ausgabe
• Fehlerhafte Formate der Daten
• Unklarer Umgang mit Fehlern bei der Ein- und Ausgabe
 Sonstiges
• Funktionen wurden nicht realisiert
• Warnungen bei der Kompilierung wurden nicht beachtet
© 2015 IAS, Universität Stuttgart
280
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Betrachtung der Softwarezuverlässigkeit
 Eine hohe Zuverlässigkeit von Softwaresystemen wird durch Anwendung und
Zusammenspiel verschiedener Maßnahmen-Arten erreicht
 Es gilt:
SW-Zuverlässigkeit
Organisatorische
Maßnahmen
Konstruktive
Maßnahmen
Analytische
Maßnahmen
 Gegenseitige Beeinflussung, daher:
• Vorausschauendes Planen erspart Arbeit bei der Implementierung!
• Strukturierte Implementierung erspart Arbeit beim Testen!
© 2015 IAS, Universität Stuttgart
281
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Organisatorische Maßnahmen
SW-Zuverlässigkeit
Organisatorischen
Maßnahmen
Konstruktiven
Maßnahmen
Analytischen
Maßnahmen
 Organisatorische Maßnahmen zur Erhöhung der
Softwarezuverlässigkeit haben das Ziel, definierte
und kontrollierbare Prozesse zu gestalten
 Ausarbeitung und Einhaltung von Merkmalen ist Bestandteil der Maßnahmen
 Beispiele für organisatorische Maßnahmen:
• Entwicklung von Software nach Schema eines Vorgehensmodells
• Anwendung von Konfigurationsmanagement zur Steuerung und
Überwachung aller Änderungen und Aktivitäten
• Entwicklung nach allgemeingültigen Software-Qualitätsmerkmalen
(bereits in der Analyse- und Entwurfsphase)
© 2015 IAS, Universität Stuttgart
282
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Qualitätsmerkmale nach ISO/IEC 9126
 Zuverlässigkeit (reliability)
„Wird die geforderte Funktion fehlerfrei ausgeführt?“
 Benutzbarkeit (useability)
„Ist die Software verständlich und einfach bzw. intuitiv benutzbar?“
 Effizienz (efficiency)
„Wird der kleinste Bedarf an Rechenzeit, Speicher und Peripherie erreicht?“
 Änderbarkeit (changeability)
„Können Merkmale mit kleinstmöglichem Aufwand geändert werden?“
 Übertragbarkeit (portability)
„Ist die Software unabhängig vom Betriebssystem und der Hardware?“
 Funktionalität (functionality)
„Tut die Software was sie soll?“
© 2015 IAS, Universität Stuttgart
283
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Weitere Qualitätsmerkmale von Software
 Dokumentation (documentation)
„Liegen alle erforderlichen Dokumente vor und sind diese aktuell?“
 Integrität (integrity)
„Ist die Software sicher gegen eine unerlaubte Anwendung?“
 Konsistenz (consistency)
„Enthält die Software eindeutige Zuordnungen?“
 Robustheit (robustness)
„Ist die Software stabil bei Fehlbedienung oder Überlast?“
 Prüfbarkeit (testability)
„Kann die Software leicht beurteilt bzw. geprüft werden?“
 Vollständigkeit (completeness)
„Ist es nachgewiesen, dass die gesamte geforderte Funktionalität erfüllt ist?“
© 2015 IAS, Universität Stuttgart
284
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Konstruktive Maßnahmen
 Konstruktive Maßnahmen zur Erhöhung der
SW-Zuverlässigkeit
Organisatorischen
Maßnahmen
Konstruktiven
Maßnahmen
Analytischen
Maßnahmen
Softwarezuverlässigkeit haben das Ziel, eine
strukturierte Vorgehensweise in der Entwicklung zu
ermöglichen
 Konstruktive Maßnahmen dienen der Gestaltung der Zuverlässigkeit und
sollen präventiv die Entstehung von Fehlern vermeiden
 Einsatz von:
• Richtlinien und Prinzipien für den Entwicklungsprozess
• Methoden und Techniken zur Programmierung
• Einsatz von Prototypen
• Verwendung von Werkzeuge
© 2015 IAS, Universität Stuttgart
285
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Anwendung konstruktiver Techniken (1/2)
 Gegebene Anforderungen müssen genau überprüft werden, nach :
• Strukturiertheit
• Erkennbarkeit und Nachprüfbarkeit
• Vollständigkeit
• Widerspruchsfreiheit und
• Verständlichkeit
 Es müssen Absicherung eingeplant werden:
• gegen typische Programmierfehler
• jede Art der Fehlbedienung und
• mögliche äußere Störfaktoren
© 2015 IAS, Universität Stuttgart
286
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Anwendung konstruktiver Techniken (2/2)
 Bei der Implementierung ist zu beachten:
• Vorgehen nach Top-Down-Methode
• Verwendung höherer Programmiersprachen
• Strukturierung und Trennung von Funktionen (Modularität)
• Format der Daten
• Aspekte der Prüfbarkeit
• Klarer Programmierstil
• Geeignete Verwendung von Kommentaren
© 2015 IAS, Universität Stuttgart
287
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Analytische Maßnahmen
 Analytische Maßnahmen zur Erhöhung der
SW-Zuverlässigkeit
Organisatorischen
Maßnahmen
Konstruktiven
Maßnahmen
Analytischen
Maßnahmen
Softwarezuverlässigkeit haben das Ziel, möglichst
viele in der Software enthaltenen Fehler und
Mängel zu entdecken
 Es werden gezielt Informationen gesammelt, um den Zustand eines
Prüfobjekts zu bewerten
 Effektives und erfolgsversprechendes Prüfen ist schwierig, da bereits
einfache Programme eine große Anzahl zu beachtender Zustände aufweisen
 Daher sorgfältige Planung und Definition von:
• Aufgaben
• Zielen
• Strategien bei der Ausführung
© 2015 IAS, Universität Stuttgart
288
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Prüfgrundsätze
 Prüfung kann nur gegen Vorgaben erfolgen (Anforderungen, Vergleiche,…)
 Prüfung muss schon während des Entwurfs geplant werden
 Verwendung geeigneter Hilfsmittel (Debugger, Testgeneratoren,…)
 Prüfverfahren müssen reproduzierbare Ergebnisse liefern
 Ergebnisse müssen dokumentiert werden, wobei jeder Fehler ausreichend
protokolliert wird:
• Angabe der Prüfdauer bis zur Entdeckung
• Ursache, Art und Folge des Fehlers
• Aufwand der Fehlerbeseitigung
 Bei komplexen Softwaresysteme kann die Prüfung mit zugehöriger
Fehlerkorrektur über 50% des Entwicklungsaufwand beanspruchen
© 2015 IAS, Universität Stuttgart
289
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Konsequenzen der Maßnahmen für den Entwicklungsprozess
 Bei der Entwicklung von Software müssen Fehlfunktionen nicht nur erkannt
und korrigiert werden, sondern die Software selbst muss robust gegen das
Auftreten von Fehlfunktionen sein!
 Alle Entscheidungen und Änderungen am Entwurf müssen ausführlich
dokumentiert werden!
 Es müssen feste Verantwortlichkeiten vergeben werden!
 Prüfung von Software ist die einzige praktische Möglichkeit um Fehler zu
entdecken und somit die Zuverlässigkeit zu erhöhen!
 Es muss bei der Wiederverwendung von Software genau geprüft werden, ob
die Einsatz- bzw. Umgebungsbedingungen übereinstimmen!
© 2015 IAS, Universität Stuttgart
290
5.1 Grundlagen der Softwarezuverlässigkeit
ZSA
Frage zu Kapitel 5.1
Welchen Aussagen stimmen Sie zu?
□
Tests weisen die Fehlerfreiheit von Software nach.
□
Ein Softwarefehler führt nicht immer zum Ausfall eines Systems.
□
Menschliche Irrtümer sind der Grund für Fehler in Software.
□
Kommentare in Software haben keinen Einfluss auf deren Zuverlässigkeit.
© 2015 IAS, Universität Stuttgart
291
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 5 Softwarezuverlässigkeit
5.1 Grundlagen der Softwarezuverlässigkeit
5.2 Maßnahmen gegen Softwarefehler
5.3 Modelle der Softwarezuverlässigkeit
5.4 Komponentenansatz
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
© 2015 IAS, Universität Stuttgart
292
5.2 Maßnahmen gegen Softwarefehler
ZSA
Unterscheidung von Maßnahmen
 Maßnahmen, um die Entstehung von Softwarefehler über einen verbesserten
Entwicklungsprozess möglichst zu vermeiden
• Reviews
• Formale Anforderungsspezifikation
 Maßnahmen, um vor der Inbetriebnahme möglichst viele der enthaltenen
Softwarefehler über ein sicherheitsbezogenes Vorgehensmodell aufzudecken
• Testen
• Diversitäre Rückwärtsanalyse
 Maßnahmen, um gefährliche Auswirkungen von Softwarefehler während des
Betriebs zu verhindern
• Redundanz
• Software-Diversität
© 2015 IAS, Universität Stuttgart
293
5.2 Maßnahmen gegen Softwarefehler
ZSA
Review
 Review ist nach IEEE 729 ein mehr oder weniger formal geplanter und
strukturierter Prozess zur Analyse und Bewertung schriftlicher Dokumente
 Schema:
Moderator
Protokollant
Gutachter
Management
Leser
Autor
 Ziel:
• Feststellung von Mängeln, Fehlern und Unvollständigkeiten
 Fehler im Design
 Falsche Schnittstellenspezifikation
 Unzureichende Wartbarkeit
• Formale Planung und Strukturierung des Bewertungsprozess
• Formale Abnahme des Prüfobjekts
© 2015 IAS, Universität Stuttgart
294
5.2 Maßnahmen gegen Softwarefehler
ZSA
Allgemeine Review-Methoden
 Entwurfs- oder Programmreviews
• Aufdecken von Fehlern im Entwurf oder Programm
• Durchführung anhand von Checklisten
 Fortschrittsreview
• Bereitstellung von Informationen über den Fortschritt des Projekts für das
Management
• Betrifft vor allem Kosten und Termine
 Qualitätsreview
• Technische Analyse des Produkts (Komponenten und Dokumente)
• Aufdeckung von Fehlern und Inkonsistenzen zwischen der
Systemspezifikation, dem Entwurf, dem Programm und der Dokumentation
© 2015 IAS, Universität Stuttgart
295
5.2 Maßnahmen gegen Softwarefehler
ZSA
Review-Arten nach IEEE 1028
 Management-Review zur Bewertung des Projektstands durch das Management
 Technisches-Review zur Bewertung des Produkts durch Gutachter
 Walk-Through zur komprimierten Vorstellung des Produkts durch einen Autor
 Inspektion zur Betrachtung von Fehlern durch Gutachter
 Audit zum Nachweis von Konformität durch unabhängige Dritte (Leser und
Protokollant)
© 2015 IAS, Universität Stuttgart
296
5.2 Maßnahmen gegen Softwarefehler
ZSA
Formale Spezifikation von Anforderungen
 Formale Spezifikation ist die Beschreibung von Software bzw. eines
Programms mittels einer formalen Sprache
 Formale Sprache entspricht einer eindeutig definierten Notation über Zeichen,
Wörter, Symbole oder Phrasen
 Ziel ist die präzise Beschreibung der zu lösenden Aufgabe bzw. des zu
analysierenden Systems
 Es erfolgt der Einsatz von Werkzeugen zur Überprüfung der Regeleinhaltung
der formalen Sprache
 Ermöglicht die Prüfung des Softwaresystems gegen die Anforderungen, d.h.,
gegen die Systembeschreibung im Lastenheft
© 2015 IAS, Universität Stuttgart
297
5.2 Maßnahmen gegen Softwarefehler
ZSA
Ablauf formale Anforderungsspezifikation
Systembeschreibung im
Lastenheft
sicherheitskritisch
(Sicherheits-)
Anforderungen
Verbal beschriebene
Anforderungen
Anforderungen
Nicht sicherheitskritisch
gegenseitige Verifikation
z.B. CTL,
Petri-Netze
Formale
Spezifikation
System
Spezifikation
keine Verifikation
Verifikation über Standards:
• Compiler
• Betriebssystem
• Entwicklungsumgebung
Software-System
© 2015 IAS, Universität Stuttgart
298
5.2 Maßnahmen gegen Softwarefehler
ZSA
Bewertung einer formalen Spezifikation
 Stärken:
• Immer eindeutig, da Bedeutung der Notation definiert
• Neutrale und widerspruchsfreie Lösung
• Erfüllung von Eigenschaften (Sicherheitsanforderungen) beweisbar
• Modelle sind simulierbar (z.B. Petri-Netze)
 Schwächen:
• Sehr aufwendige Durchführung
 Zerlegung des Systems
 Beschreibung von Ausnahmefällen
• Erstellung und Prüfung nur über ausgebildetes Fachpersonal
• Teilweise einseitige Ausrichtung, z.B. bezogen auf:
 Die Funktionalität (mathematische Notationen)
 Das Verhalten (Petri-Netze)
© 2015 IAS, Universität Stuttgart
299
5.2 Maßnahmen gegen Softwarefehler
ZSA
Prozess des Testens
 Testen ist ein Verfahren bzw. ein Versuch der Softwareprüfung mit dem Ziel,
ein Programm so auszuführen, dass Fehler gefunden werden
 Vorgehen:
Testvorbereitung (TV):
 Ermittlung von Testfällen
 Spezifikation
TV
Testmanagement (TM):
Testdurchführung(TD):
 Ausführung der Testfälle
 Protokollierung
TD
TM
 Planung des Testprozess
 Steuerung
 Kontrolle
Testnachbereitung (TN):
 Aufbereitung der Testergebnisse
 Bewertung
© 2015 IAS, Universität Stuttgart
TN
300
5.2 Maßnahmen gegen Softwarefehler
ZSA
Testplanung
 Testplanung ist die Grundlage der Qualitätssicherung und Voraussetzung für
die Überwachung und Steuerung der Testausführung
 Testplan beinhaltet Aufgaben, Ziele und Strategien der Testausführung:
Beschreibung Testobjekt
Testdokumentation
Art der Abnahme
Qualitätsanforderungen
Testplan
Testmethode
Testkriterien
Testwerkzeuge
Testpersonen
© 2015 IAS, Universität Stuttgart
301
5.2 Maßnahmen gegen Softwarefehler
ZSA
Hinweise zum Testen
 Ein modularer Aufbau des Testobjekts (mit definierten Schnittstellen)
erleichtert die Fehlerlokalisierung über:
• Programmablaufverfolgung
• Zustandsverfolgung
• Zustandsüberwachung
 Sorgfältige Durchführung der Fehlerkorrektur zur Vermeidung von:
• Neuen Fehlern
• Mehrfacher Wiederholung der Testfälle
 Beachtung bekannter, typischer Fehler z.B.:
• Endlosschleifen
• Falsche logische Operationen
• Sonderfälle
© 2015 IAS, Universität Stuttgart
302
5.2 Maßnahmen gegen Softwarefehler
ZSA
Diversitäre Rückwärtsanalyse
 Vom TÜV Rheinland, im Rahmen eines Projekts am experimentellen
Kernkraftwerk in Norwegen, entwickelte Methode zur Software-Verifikation
und zum Sicherheitsnachweis von Software-Systemen
 Prinzip:
• Objekt wird aus der Zielmaschine ausgelesen und an zwei Prüfgruppen
übergeben
• Prüfgruppen arbeiten in Folge ohne Kontakt untereinander
• Code wird rückübersetzt bis hin zu den spezifizierten Anforderungen
• Rückspezifikationen werden untereinander und mit den ursprünglichen
Anforderungen verglichen
• Bei Übereinstimmung gilt Softwaresystem als korrekt entwickelt und
erhält Sicherheitsnachweis
• Annahme: System ist frei von Fehlern nach dem Stand der Technik
© 2015 IAS, Universität Stuttgart
303
5.2 Maßnahmen gegen Softwarefehler
ZSA
Ablauf der diversitären Rückwärtsanalyse
Prüfer 1
Maschinencode
Rückübersetzen
(Objektcode des
Zielrechners)
Rekonstruktion des
Software-Entwurfs
Rekonstruktion der
Anforderungsspezifikation
Prüfer 2
Rückübersetzen
Rekonstruktion des
Software-Entwurfs
ursprüngliche
AnforderungsSpezifikation
Rekonstruktion der
Anforderungsspezifikation
Prüfer 3
rekonstruierte
AnforderungsSpezifikation
Vergleich der
Anforderungsspezifikationen
rekonstruierte
AnforderungsSpezifikation
Sicherheits
Zertifikat
© 2015 IAS, Universität Stuttgart
304
5.2 Maßnahmen gegen Softwarefehler
ZSA
Bewertung
 Vorteile:
• Leicht verständlich und direkt anwendbar
• Sehr wirkungsvoll, da alle Abweichungen aufgedeckt werden
 Nachteile:
• Großer Aufwand
• Keine Betrachtung möglicher Fehlerfälle während des Betriebs
 Verringerung des Aufwands durch Rechnerunterstützung:
• Im ersten Zweig erfolgt Überprüfung durch einen Prüfer bzw. Prüfgruppe
• Im zweiten Zweig wird ein speziell entwickeltes Werkzeugsystem zum
Rückübersetzung eingesetzt
• Prüfer bzw. Prüfgruppe vergleicht die automatisierten Ergebnisse mit den
Eigenen
© 2015 IAS, Universität Stuttgart
305
5.2 Maßnahmen gegen Softwarefehler
ZSA
Redundanz
 Redundanz bedeutet das Vorhandensein zusätzlicher, funktionsbereiter Mittel
 Methode, um gefährliche Auswirkungen verbleibender Restfehler während des
Betriebs zu verhindern
 Kategorisierung:
Räumliche bzw.
strukturelle Redundanz
Redundanz
Informations-Redundanz
Zeitliche Redundanz
© 2015 IAS, Universität Stuttgart
306
5.2 Maßnahmen gegen Softwarefehler
ZSA
Redundanz-Kategorien (1/2)
 Räumliche bzw. strukturelle Redundanz
• Wird häufig auch als Hardware-Redundanz bezeichnet
• Aber alle Techniken können auf Software übertragen und implementiert
werden
Redundanzform
Merkmale
Heiße Redundanz
Mehrere Systeme (mind. 3), die gleichzeitig die gleiche
Funktion ausführen.
Kalte Redundanz
Mehrere Systeme, die eine gleiche Funktion ausführen können.
Standbye-Redundanz
Zusätzliche Mittel im System, auf die im Fehlerfall
umgeschaltet wird (Komponenten, kein ganzes System).
N+1-Redundanz
N aktive Einheiten und 1 passive Einheit im System, die
im Fehlerfall eine aktive Einheit ersetzen kann
© 2015 IAS, Universität Stuttgart
307
5.2 Maßnahmen gegen Softwarefehler
ZSA
Redundanz-Kategorien (2/2)
 Informations-Redundanz
• Einsatz, um Fehler bei der Kommunikation zwischen Komponenten zu
vermeiden bzw. zu reduzieren oder Speicher gegen Fehler abzusichern
• Kodierungs-Techniken und –Verfahren
 Zeitliche Redundanz
• Anweisungsausführung erfolgt zu unterschiedlichen Zeiten
• Informationen der Ausführung werden mit einem Datum versehen
• Die mit dem jeweiligen Datum versehenen Informationen werden zeitlich
getrennt voneinander an die jeweiligen Komponenten übertragen
• Besonders geeignet, um intermittierende Fehler zu erkennen
© 2015 IAS, Universität Stuttgart
308
5.2 Maßnahmen gegen Softwarefehler
ZSA
Software-Diversität
 Zur Vermeidung der Kopie von Fehlern, wie bei redundanten Systemen, erfolgt
eine Realisierung von Gleichartigkeit über unterschiedliche Mittel:
• Unterschiedliche Algorithmen
• Unterschiedliche Programmiersprachen
• Unterschiedliche Automatisierungsgeräte/Steuerungen
• Unterschiedliche Entwicklungs-Teams
 Struktur:
Eingabedaten
Programm 1
Programm 2
…
Programm N
Ergebnisvergleich
Ergebnis
© 2015 IAS, Universität Stuttgart
309
5.2 Maßnahmen gegen Softwarefehler
ZSA
Probleme bei Software-Diversität
 Nachweis der Diversität grundsätzlich problematisch
 Zeitliche Koordinierung diversitärer Programme ist aufwendig und schwierig
 Diversitäre Programme verursachen hohe Kosten
• Entwicklung
• Nachweis
• Wartung und Pflege
 Diversität muss auch nach Änderungen gewährleistet bleiben
 Auswahl der Art (Algorithmus, Programmiersprache,…)
 Denkmuster von Menschen
© 2015 IAS, Universität Stuttgart
310
5.2 Maßnahmen gegen Softwarefehler
ZSA
Frage zu Kapitel 5.2
Welchen Aussagen stimmen Sie zu?
□
□
□
□
Die Überführung einer verbalen in eine formale Sprache ist immer ein
kritischer Schritt.
Ein Audit ist eine komprimierte Vorstellung eines Produkts.
Bei Standbye-Redundanzen erfolgt im Fehlerfall ein Umschalten auf
ein separates zweites System.
Software-Diversität zeichnet sich durch geringe Kosten aus.
© 2015 IAS, Universität Stuttgart
311
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 5 Softwarezuverlässigkeit
5.1 Grundlagen der Softwarezuverlässigkeit
5.2 Maßnahmen gegen Softwarefehler
5.3 Modelle der Softwarezuverlässigkeit
5.4 Komponentenansatz
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
© 2015 IAS, Universität Stuttgart
312
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Software-Zuverlässigkeitsmodelle
 Zuverlässigkeitsmodelle in der Softwaretechnik sind mathematische Modelle zur:
• Abschätzung der Zuverlässigkeit einer Software
• Berechnung von Fehlerraten
• Schätzung der Anzahl von Rest-Fehlern in einem Codeabschnitt
 Basis aller Modelle sind empirische Daten (z.B. gesammelte Daten von Tests)
 Erkenntnisse aus empirischen Daten werden als Empirie bezeichnet:
Theorie
Deduktion
Empirie
Empirie
© 2015 IAS, Universität Stuttgart
313
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Klassifizierung nach geschichtlich-zeitlichem Auftreten
1975 Musa-Modell
1993 SQMA (IAS)
vgl. Kap 5.5
1975 SchneidewindModell
1973 LittlewoodVerrall-Modell
1973 SchickWolverton-Modell
1972 JelinskiMoranda-Modell
1972
1991 ShoomanModell
2015
#Modelle > 200
1984 Dunn-Modell
1984 MusaOkumoto-Modell
1980
© 2015 IAS, Universität Stuttgart
1990
1999-2007
Cukic-Modell
2000
2015
Jahr
314
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Klassifizierung nach Entwurfsphasen
Anforderungen
Entwicklungsphasen
Entwurf
Implementierung
Test
Feldeinsatz
Frühzeitige Prognosemodelle
Architekturbasierte Modelle
Zuverlässigkeitswachstumsmodelle
Andere Modelle
© 2015 IAS, Universität Stuttgart
315
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Frühzeitige Prognosemodelle - Prinzip
 Aus den, je nach Modell benötigten, empirischen Daten von Software lässt
sich eine Prognose der Zuverlässigkeit ableiten
 Bereits in frühen Phasen ist eine Abschätzung der Zuverlässigkeit für eine
Software möglich
 Prinzip:
Konstanten aus
empirischen
Untersuchungen
Wahrscheinlichkeit, dass ein Fehler
zum Ausfall führt
α, β
Prognose
Anzahl Fehler = α + β * (LOC )
Anzahl
Quellcodezeilen
Prognostizierte
SW-Zuverlässigkeit
LOC
© 2015 IAS, Universität Stuttgart
316
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Frühzeitige Prognosemodelle - Bewertung
 Problematisch ist die Genauigkeit der Ergebnisse
 Es ist kaum vorhersehbar ob, wie viele und wie schwere Fehler in einer
Entwicklungsphase gemacht werden
 Typische Fehler im Umgang mit Prognosemodellen:
• Zeitlich jüngere Werte werden überbewertet
• Populäre bzw. viel diskutierte Werte werden überbewertet
• Es werden scheinbare Muster erkannt, die nicht nachweisbar sind
• Einfluss von Wunsch- und Angst-Vorstellungen
• Daten werden so ausgewählt oder interpretiert, wie es den eigenen
Erwartungen entspricht
„Predicition is very difficult, especially about the future!“
(Niels Bohr (1885-1962), dänischer Physiker, Nobelpreis 1922 für die Erforschung der Atomstruktur)
© 2015 IAS, Universität Stuttgart
317
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Architekturbasierte Modelle - Prinzip
 Abschätzung der Zuverlässigkeit eines Entwurfs oder einer Implementierung
auf Basis der jeweilig bekannten, empirischen Einzel-Zuverlässigkeiten und
Ausführungs-Häufigkeiten der beinhaltenden Module
 Prinzip:
Zuverlässigkeit der
Einzel-Module
Software-Architektur
R(t)
Modul A
RA(t)
AusführungsHäufigkeit
x
© 2015 IAS, Universität Stuttgart
Modul C
xA
RC(t)
xC
Schätzung
SW-Zuverlässigkeit
Modul B
RB(t)
xB
318
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Architekturbasierte Modelle - Bewertung
 Vorteile:
• Hohe Genauigkeit bei möglichst präzisen Eingabedaten
• Einfluss einzelner Module auf die Gesamtheit kann analysiert werden
 Nachteile:
• Zuverlässigkeitswerte der einzelnen Module sind häufig unbekannt
• Bestimmung der Ausführungs-Häufigkeit ist in frühen Phasen schwierig
© 2015 IAS, Universität Stuttgart
319
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Zuverlässigkeitswachstumsmodelle - Prinzip
 Schrittweise Schätzung der Zuverlässigkeit auf Basis der zu Beginn (unter
Annahme) getroffenen und der im Betrieb empirischen Versagenszeitpunkte
von Software
 Annahme, dass nach einem Versagenszeitpunkt der Fehler korrigiert wird und
bei der Korrektur keine neuen Fehler entstehen
 Prinzip:
Fehlerzeitpunkt
Fehlerzahl
Versagen
Schätzung
Fehlerkorrektur
Zuverlässigkeit
FehlerKorrekturen
SWZuverlässigkeit
Zeit
© 2015 IAS, Universität Stuttgart
Schätzung
SW-Zuverlässigkeit
Ziel-Zuverlässigkeit
Zeit
320
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Zuverlässigkeitswachstumsmodelle - Bewertung
 Vorteile:
• Hohe Genauigkeit bei präziser Auswertung der empirischen Daten
 In vorangegangen Tests
 Im laufenden Betrieb
• Nachvollziehbarer und verfolgbarer Entwicklungs- und
Fehlerkorrekturverlauf
 Nachteile:
• In frühen Phasen liegen nicht ausreichend empirische Daten vor
• Es werden oftmals Annahmen getroffen, die in der Praxis nicht zutreffen
(besonders in frühen Phasen)
• Einfache bzw. direkte Übertragung der Ergebnisse von früheren System
ist nicht möglich, da individuell entwickelte Software direkt vergleichbar
ist
© 2015 IAS, Universität Stuttgart
321
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Klassifizierung nach der Zeitabhängigkeit
 Bei zeitabhängigen Modellen haben die Daten und Testergebnisse einen
zeitlichen Bezug
 Prozesse der Fehlererkennung und -Korrektur zur Bestimmung der:
•
Anzahl der Fehler in einem Programm
•
Fehlerrate, d.h., der Anzahl der in einer Zeiteinheit aufgetretenen Fehler
in Abhängigkeit von der Gesamtfehlerzahl
•
Mittleren Zeit zwischen zwei erkannten Fehlern, wobei die Zeit nach
jeder Korrektur größer wird
 Beispiele:
• Shooman-Modell
• Jelinski-Moranda-Modell
• Schick-Wolverton-Modell
© 2015 IAS, Universität Stuttgart
322
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell - Prinzip
 Zeitabhängiges Modell zur Schätzung der:
• Anzahl von Fehlern, die sich zu Beginn im Programm befinden
• Anzahl der Restfehler, die sich weiterhin im Programm befinden
• Fehlerrate und Zuverlässigkeit der Software
 Programmcode wird über einen bestimmten Zeitraum (Intervall) in Betrieb
genommen und getestet
 In einem Testintervall wird eine bestimmte Fehlerzahl gefunden und korrigiert
 Es gilt dabei:
I
≙
Anzahl der Programmanweisungen
t
≙
Betriebszeit
τ
≙
Testzeit
H
≙
fehlerfreie Testzeit
© 2015 IAS, Universität Stuttgart
323
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell - Fehlerzahl und Zeitabhängigkeit (1/2)
 Für die Anzahl der Fehler gilt
E
≙
(Gesamt-) Anzahl der Fehler zu Beginn
ε
≙
Relative Fehlerzahl (Fehlerdichte), d.h.,Fehlerzahl auf I normiert
Ec , εc
≙
Anzahl der korrigierten Fehler, Anzahl auf I normiert
Er , εr
≙
Anzahl der Restfehler, Anzahl auf I normiert
 Summe E der korrigierten und restlichen Fehler wird als konstant angenommen:
𝐄 = 𝐄𝐜 𝛕 + 𝐄𝐫 𝛕 = 𝐜𝐨𝐧𝐬𝐭.
 Es gilt dabei für die auf die Anzahl der Programmanweisung bezogenen Fehler:
𝐞𝐜 𝛕 =
𝐞𝐫 𝛕 =
© 2015 IAS, Universität Stuttgart
𝐄𝐜 𝛕
𝐈
𝐄𝐫 𝛕
𝐄 − 𝐄𝐜 𝛕
=
𝐈
𝐈
324
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell - Fehlerzahl und Zeitabhängigkeit (2/2)
 Es werden mehrere Testintervalle betrachtet, z.B. τ1 und τ2:
Ec(τ1)
t
0
τ2
τ1
Ec(τ2)
 Es werden dabei folgende Annahmen getroffen:
• Es entstehen keine neuen Fehler bei der Korrektur
• Für die Zahl der korrigierten Fehler in den Intervallen mit τ1 < τ2 gilt:
𝐄𝐜 𝛕 𝟏 < 𝐄𝐜 𝛕 𝟐
© 2015 IAS, Universität Stuttgart
325
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell – Berechnung der Fehlerrate
 Spezifische Fehlerrate in den Test-Intervallen τ1 bzw. τ2:
𝐄𝐜 (𝛕𝟏 )
𝛌𝐒𝐖𝟏 (𝐭) =
𝐇𝟏
𝐄𝐜 (𝛕𝟐 )
𝛌𝐒𝐖𝟐 (𝐭) =
𝐇𝟐
 Fehlerrate wird innerhalb der Intervalle bis zur nächsten Korrektur als
konstant angenommen:
𝛌𝐒𝐖𝟏/𝟐 (𝐭) ≝ 𝛌𝐒𝐖𝟏/𝟐 = 𝐜𝐨𝐧𝐬𝐭.
 Änderung der Fehlerrate:
𝛌𝐒𝐖𝟏 − 𝛌𝐒𝐖𝟐 =
𝐜
𝐄 𝛕 − 𝐄𝐜 𝛕 𝟏
𝐈 𝐜 𝟐
 Änderung der Fehlerrate pro Fehlerkorrektur:
𝚫𝛌𝐒𝐖
© 2015 IAS, Universität Stuttgart
𝐜
=
𝐈
326
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell – Proportionalitätskonstante c
 Proportionalitätskonstante c ist ein fester Wert und ergibt sich aus
• Programmiererfahrung der Softwareentwickler
• Dauer des Projekts
• …
 Gegeben aus Erfahrungswerten oder wird berechnet über:
• Proportionalität der Fehlerrate zu der Anzahl der Fehler:
𝛌𝐒𝐖 = 𝐜 ∗
𝐄𝐫 (𝛕)
𝐄 − 𝐄𝐜 (𝛕)
= 𝐜∗
𝐈
𝐈
• Umformung führt zu:
𝐈 ∗ 𝛌𝐒𝐖
𝛌𝐒𝐖
𝛌𝐒𝐖𝟏
𝛌𝐒𝐖𝟐
𝐜=
=
≝
=
𝐄
𝐄
𝐄
𝐄 − 𝐄𝐜 (𝛕)
−
𝛆
(𝛕)
−
𝛆
𝛕
𝐜
𝐜 𝟏
𝐈
𝐈
𝐈 − 𝛆𝐜 (𝛕𝟐 )
© 2015 IAS, Universität Stuttgart
327
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell – Bestimmung der Modellparameter
 Berechnung der Gesamtzahl der im Programmcode enthaltenen Fehler:
𝛌𝐒𝐖𝟐
∗ 𝛆 𝛕 − 𝛆𝐜 (𝛕𝟐 )
𝛌𝐒𝐖𝟏 𝐜 𝟏
𝐄= 𝐈∗
𝛌𝐒𝐖𝟐
−𝟏
𝛌𝐒𝐖𝟏
 Berechnung der Überlebenswahrscheinlichkeit bzw. Zuverlässigkeit
𝐑 𝐒𝐖 𝐭 =
𝐞−𝛌𝐒𝐖∗𝐭
=𝐞
−𝐜∗
𝐄−𝐄𝐜 𝛕
∗𝐭
𝐈
 Berechnung der mittleren Betriebsdauer bis zum Ausfall (MTTF)
𝐌𝐓𝐓𝐅𝐒𝐖 =
© 2015 IAS, Universität Stuttgart
𝟏
=
𝛌𝐒𝐖
𝟏
𝐜∗
𝐄 − 𝐄𝐜 𝛕
𝐈
328
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell – Rechenbeispiel (1/4)
 Gegeben:
• I =1000 Anweisungen im Programm
• Testintervalle τ1 = 20 Tage und τ2 = 40 Tage
• 5 Stunden fehlerfreie Testzeit pro Tag
• Im ersten Testintervall werden 16, im zweiten 24 Fehler korrigiert
 Daraus folgt:
• Anzahl der normierten Fehler
𝐞𝐜 𝛕 𝟏 =
𝐄𝐜 𝛕𝟏
𝟏𝟔
=
= 𝟎, 𝟎𝟏𝟔
𝐈
𝟏𝟎𝟎𝟎
𝐞𝐜 𝛕 𝟐 =
𝐄𝐜 𝛕𝟐
𝟐𝟒
=
= 𝟎, 𝟎𝟐𝟒
𝐈
𝟏𝟎𝟎𝟎
© 2015 IAS, Universität Stuttgart
329
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell – Rechenbeispiel (2/4)
• Fehlerfreie Testzeiten
𝐇𝟏 = 𝟐𝟎𝐝 ∗ 𝟓𝐡 = 𝟏𝟎𝟎𝐡
𝐇𝟐 = 𝟒𝟎𝐝 ∗ 𝟓𝐡 = 𝟐𝟎𝟎𝐡
• Abschätzung der Fehlerraten
𝛌𝐒𝐖𝟏 𝐭 ≝ 𝛌𝐒𝐖𝟏
𝐄𝐜 (𝛕𝟏 )
𝟏𝟔
=
=
= 𝟎, 𝟏𝟔𝐡−𝟏
𝐇𝟏
𝟏𝟎𝟎𝐡
𝛌𝐒𝐖𝟐 𝐭 ≝ 𝛌𝐒𝐖𝟐 =
© 2015 IAS, Universität Stuttgart
𝐄𝐜 (𝛕𝟐 )
𝟐𝟒
=
= 𝟎, 𝟏𝟐𝐡−𝟏
𝐇𝟐
𝟐𝟎𝟎𝐡
330
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell – Rechenbeispiel (3/4)
 Bestimmung der Modellparameter:
• Gesamtzahl der Fehler
𝛌𝐒𝐖𝟐
∗ 𝛆 𝛕 − 𝛆𝐜 (𝛕𝟐 )
𝛌𝐒𝐖𝟏 𝐜 𝟏
𝐄 =𝐈∗
𝛌𝐒𝐖𝟐
−𝟏
𝛌𝐒𝐖𝟏
𝟎, 𝟏𝟐
𝟎, 𝟏𝟔 ∗ 𝟎, 𝟎𝟏𝟔 − 𝟎, 𝟎𝟐𝟒
= 𝟏𝟎𝟎𝟎 ∗
𝟎, 𝟏𝟐
𝟎, 𝟏𝟔 − 𝟏
= 𝟒𝟖
© 2015 IAS, Universität Stuttgart
331
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Shooman-Modell – Rechenbeispiel (4/4)
• Proportionalitätskonstante
𝐈 ∗ 𝛌𝐒𝐖𝟏
𝐈 ∗ 𝛌𝐒𝐖𝟐
𝐜=
=
𝐄 − 𝐄𝐜 (𝛕) 𝐄 − 𝐄𝐜 (𝛕)
=
𝟏𝟎𝟎𝟎 ∗ 𝟎, 𝟏𝟔 𝟏𝟎𝟎𝟎 ∗ 𝟎, 𝟏𝟐
=
=𝟓
𝟒𝟖 − 𝟏𝟔
𝟒𝟖 − 𝟐𝟒
• Änderung der Fehlerrate pro Fehlerkorrektur
𝚫𝛌𝐒𝐖
𝐜
𝟓
= =
= 𝟎, 𝟎𝟎𝟓
𝐈 𝟏𝟎𝟎𝟎
© 2015 IAS, Universität Stuttgart
332
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Jelinski-Moranda-Modell
 Zeitabhängiges Zuverlässigkeitswachstumsmodell
 Zeiträume der Zuverlässigkeitsschätzung im Bereich von Monaten
 Es gelten folgende Annahmen:
• Zu Beginn befinden sich eine Zahl von X Fehlern im Programm
• Tritt ein Fehler auf, so wird dieser, ohne die Entstehung neuer Fehler,
erfolgreich behoben
• Fehler sind voneinander und von der Vorgeschichte unabhängig
 Benötigte Daten:
• Anzahl der Fehler zu Beginn (Schätzung aus Erfahrungswerten)
• Zahl der Fehler bis zu einem Ausfall
• Zeit zwischen den Ausfällen (MTBF)
© 2015 IAS, Universität Stuttgart
333
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Schick-Wolverton-Modell
 Zeitabhängiges Modell zur Berechnung der Restfehlerzahl und der
Fehlererkennungsrate innerhalb definierter Zeitintervalle
 Es gelten folgende Annahmen:
• Fehlerentdeckungsrate ist proportional zu der Zahl der enthaltenen
Restfehler
• Anzahl der Restfehler nimmt exponentiell ab
• Fehler treten zufällig auf und sind voneinander unabhängig
• Alle Fehler sind zu jedem Zeitpunkt gleich gefährlich
• Fehlerentdeckungsrate ist in den vorgegebenen Zeitintervallen konstant
• Alle entdeckten Fehler werden behoben und es werden dabei keine
neuen Fehler gemacht
© 2015 IAS, Universität Stuttgart
334
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Klassifizierung nach der Zeitunabhängigkeit
 Bei zeitunabhängigen Modellen liegt kein zeitlicher Bezug der Daten und
Testergebnisse vor
 Kennzeichnend für zeitunabhängige Tests ist:
• Große Zahl an Testdurchführungen
• Alle Tests sind voneinander unabhängig
• Dauer der Testdurchführung hat keine Bedeutung
 Für die Testergebnisse gilt:
• Jeder Test ist eindeutig (in Ordnung / nicht in Ordnung)
• Ein erkannter Fehler wird nur einmal gezählt
 Beispiele:
• Mill-Modell
• Lipow-Modell
© 2015 IAS, Universität Stuttgart
335
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Mill-Modell - Fehlersaat-Verfahren
 Zeitunabhängiges Modell zur Abschätzung der Fehlerzahl
 Vorgehen:
• Künstliche Fehler werden in ein Programm einbaut
• Durchführung von Programmtests mit den eingebauten Fehlern
• Aus Testergebnisse erfolgt Ableitung der Zahl erkannter echter Fehler
• Rückführung auf die Zahl zu Beginn im Programm enthaltener Fehler
 Annahmen:
• Gleiche Erkennungswahrscheinlichkeit für jeden Fehler
• Anzahl der eingebauten Fehler (Schätzung aus Erfahrungswerten) ist
deutlich größer als Anzahl der echten Fehler
© 2015 IAS, Universität Stuttgart
336
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Mill-Modell - Rechenvorschrift
 Es gilt:
X
≙ Gesamtzahl der echten Fehler
Y
≙ Gesamtzahl der eingebauten Fehler
U
≙ Zahl der erkannten echten Fehler
V
≙ Zahl der erkannten eingebauten Fehler
 Mit dem Zusammenhang:
𝐗
𝐔
=
𝐘
𝐕
𝐔
𝐗=𝐘∗
𝐕
© 2015 IAS, Universität Stuttgart
337
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Lipow-Modell
 Zeitunabhängiges Zuverlässigkeitswachstumsmodell
 Vorgehen:
• Ein Testprogramm wird in N Stufen unterteilt
• Jede Stufe besitzt eine bestimmte Anzahl von Testversuchen
• Alle Tests einer Stufe beziehen sich auf ähnliche Elemente
• Testergebnisse sind entweder „erfolgreich“ oder „fehlgeschlagen“
• Ergebnisse einer Stufe werden verwendet, um das jeweilige Elemente zu
verbessern
• Kontinuierliche Verbesserung der Zuverlässigkeit
© 2015 IAS, Universität Stuttgart
338
5.3 Modelle der Softwarezuverlässigkeit
ZSA
Frage zu Kapitel 5.3
Welchen Aussagen stimmen Sie zu?
□
□
□
□
Basis aller SW-Zuverlässigkeitsmodelle sind empirische Daten.
Architekturbasierte Modelle ermöglichen eine relativ genaue
Abschätzung der Zuverlässigkeit bei Kenntnis der Eingabeparameter.
Bei frühzeitigen Prognosemodellen kann die frühe Interpretation der
Werte zu falschen Ergebnissen führen.
Zuverlässigkeitswachstumsmodelle profitieren davon, dass Werte
vorheriger Projekte direkt eingesetzt werden können.
© 2015 IAS, Universität Stuttgart
339
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 5 Softwarezuverlässigkeit
5.1 Grundlagen der Softwarezuverlässigkeit
5.2 Maßnahmen gegen Softwarefehler
5.3 Modelle der Softwarezuverlässigkeit
5.4 Komponentenansatz
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
© 2015 IAS, Universität Stuttgart
340
5.4 Komponentenansatz
ZSA
Probleme mit klassischen Zuverlässigkeitsmodelle
 Verfügbarkeit empirischer Daten
• In frühen Entwicklungsphasen sind oftmals keine empirischen Daten über
die zu entwickelnde Software verfügbar
• Notwendige Daten werden häufig gar nicht oder nicht systematisch erfasst
• Aufwand für den Aufbau von Datenbanken ist sehr hoch
 Anwendbarkeit der Modelle im Entwicklungsprozess
• Keine Modelle mit guter Genauigkeit für frühe Entwicklungsphasen
• Zuverlässigkeitsaussagen schwer interpretierbar
(z.B. 10-3 Versagensfälle / Anforderung)
Entwicklung eines Konzepts zur
frühzeitigen Zuverlässigkeitsanalyse!
© 2015 IAS, Universität Stuttgart
341
5.4 Komponentenansatz
ZSA
Zuverlässigkeitsanalyse von Hardware und Software
System
Vorgefertigte
HW-Komponenten
Hardware
 Generische Zuverlässigkeitsaussagen
aus früherem Einsatz
 Zuverlässigkeit der Hardware-
Komponenten
 Zuverlässigkeit des HardwareSystems
© 2015 IAS, Universität Stuttgart
Software
Individuell
entwickelte
Software
 Fehlende generischen
Zuverlässigkeitsaussagen
5.4 Komponentenansatz
ZSA
Komponentenentwicklung als Lösungsansatz
 Kleinstbausteine werden durch vorgefertigte Komponenten ersetzt, für die
bereits empirische Zuverlässigkeitsdaten vorliegen
 Anwendung bisher in der Hardware-Entwicklung, nun Übertrag des Prinzips
auf Software-Entwicklung
System
Komponente
© 2015 IAS, Universität Stuttgart
Komponente
Komponente
343
5.4 Komponentenansatz
ZSA
Übertragung des Komponentenansatz auf Software
System
Vorgefertigte
HW-Komponenten
Hardware
Software
Vorgefertigte
SW-Komponenten
Analogie
 Einsatz von Komponenten in beiden Systemen
 Erfassung und Auswertung empirischer Daten!
 Ergebnis: Abhängigkeit Einflussgrößen ↔ Zuverlässigkeit
 Generische Zuverlässigkeitsaussagen

 Zuverlässigkeit des Gesamtsystems (Hardware und Software)
© 2015 IAS, Universität Stuttgart
344
5.4 Komponentenansatz
ZSA
Erfassung und Auswertung empirischer Daten
 Ziel ist es, Erkenntnisse aus empirischen Daten früherer Test- oder
Betriebszeiten auf das aktuell zu untersuchende System übertragen zu können
 Es ist aber nicht möglich Daten direkt zu übertragen
 Daher keine Entwicklung eines allgemein gültigen Modells, sondern eines
Werkzeugs zur Bewertung von:
• Produkteigenschaften unter bestimmten Randbedingungen
• Parameter des Entwicklungsprozess
 Es gilt:
Systematische Erfassung
empirischer Daten
Zusammenhang
SW- und HWKomponenten
Zuverlässigkeit
einzelner
Komponente
RechnerUnterstützung
Software-System-Zuverlässigkeit
© 2015 IAS, Universität Stuttgart
345
5.4 Komponentenansatz
ZSA
Struktur einer Softwarekomponente
 SW-Komponente ist eine unveränderliche, geschlossene Einheit, die an die
jeweilige Umgebung angepasst werden muss
 Prinzip:
Anpassung an Umgebung
Innere Abläufe
 Komponenten sind über Schnittstellen miteinander verbunden
 Aktivierung einer Komponente über eine andere Komponente, den Benutzer
oder das Betriebssystem
Anpassung
Komponente A
© 2015 IAS, Universität Stuttgart
Anpassung
Komponente B
346
5.4 Komponentenansatz
ZSA
Spezifische Eigenschaften von Softwarekomponenten (1/3)
 Anpassbarkeit
• Eine SW-Komponenten muss durch geeignete Parametrierung und
Konfiguration an die Aufgabe im aktuellen System angepasst werden
• Dazu gehört auch das An- und Abschalten von Funktionen
 Funktionale Geschlossenheit
• Funktionalität innerhalb der Komponente ist logisch zusammenhängend
• Nach außen ist Funktionalität nur über die Schnittstellen sichtbar
 Unveränderbarkeit durch Dritte
• SW-Komponenten werden in verschiedenen Systemen eingesetzt
• Quellcode kann dabei vom Einsetzenden nicht verändert werden
© 2015 IAS, Universität Stuttgart
347
5.4 Komponentenansatz
ZSA
Spezifische Eigenschaften von Softwarekomponenten (2/3)
 Verknüpfbarkeit
• SW-Komponenten werden über Schnittstellen miteinander verknüpft,
um geforderte Systemfunktionen zu erbringen
• Klare Unterscheidung notwendig, ob:

Dienst erfragt oder angeboten wird
 Ereignis gemeldet oder entgegengenommen wird
 Strukturelle Unabhängigkeit
• SW-Komponenten können die Dienste anderer Komponenten erfordern
• Dabei wird nur die jeweilige Funktionalität benötigt, nicht eine andere
Komponenten als solche
• SW-Komponenten sind somit strukturell voneinander abhängig
© 2015 IAS, Universität Stuttgart
348
5.4 Komponentenansatz
ZSA
Spezifische Eigenschaften von Softwarekomponenten (3/3)
 Nebenläufigkeit
• SW-Komponente muss in der Lage sein, parallel mit anderen
Komponenten ausgeführt zu werden
 Einmaligkeit
• SW-Komponente ist nur einmal in einem System vorhanden, kann aber
mehrerer Zustände annehmen
• D.h., sie kann eine Funktionalität in einem System in verschiedenen
Zusammenhängen bereitstellen
 Offenheit
• Spezifikation Komponenten muss gut dokumentiert und zugänglich sein
 Funktionalität
 Schnittstellenbeschreibung
© 2015 IAS, Universität Stuttgart
349
5.4 Komponentenansatz
ZSA
Einsatz von Komponenten
 Wesentliche Eigenschaft einer SW-Komponenten ist die unveränderte
mehrfache Verwendung
 Versagen einer Komponente ist auf Fehler zurückzuführen, die von der
jeweiligen Umgebung unterschiedlich häufig aktiviert werden
 Fehler sind dabei auf Einflussfaktoren der Umgebung zurückzuführen, da die
Komponente funktional geschlossen und unveränderbar ist
 Nur über die Parametrierung bzw. Anpassung an die Umgebung kann auf die
Fehler Einfluss genommen werden
 Abhängigkeit zwischen Komponente und Umgebung muss bekannt sein
 Daher Beschreibung bekannter Abhängigkeiten in Komponenten-Bibliotheken
© 2015 IAS, Universität Stuttgart
350
5.4 Komponentenansatz
ZSA
Identifikation relevanter Einflussfaktoren
System
Hardware
 Auf Hardware-Komponenten:
• Physikalische Umgebung
 Temperatur,
Software
 Auf Software-Komponenten:
• Konfiguration bzw.
Parametrierung
 Feuchtigkeit,
 Eingaben Entwickler
 Vibration
 Parameterschätzverfahren
• Benutzung
• Zeitliche Aktivierung
 Lastprofil
 Externe zeitliche Aktivierung
 Beanspruchungen
 Andere Komponente über
• Wechselwirkungen
© 2015 IAS, Universität Stuttgart
Verknüpfung
351
5.4 Komponentenansatz
ZSA
Zuverlässigkeitsanalyse beim Systementwurf
Hardware
KomponentenBibliothek
Bauteil, Beschaltung
HW
HW
HW
Konfiguration,
Parametrierung, Verknüpfung
Auswahl
HW
Software
SW
SW
Komponentenzuverlässigkeit
• Aktuelle Einflussgrößen
bestimmen
• Generische Aussagen
übertragen
© 2015 IAS, Universität Stuttgart
HW
SW
Zuverlässigkeit des
aktuellen System
Systemzuverlässigkeit
• Architektur analysieren
• Einzelne Zuverlässigkeiten
kombinieren
352
5.4 Komponentenansatz
ZSA
Zuverlässigkeitsanalyse beim Test und Betrieb des Systems
Hardware
KomponentenBibliothek
Bauteil, Beschaltung
HW
HW
HW
SW
Mehrfacher Einsatz in
verschiedenen Systemen
Software
Empirische
Daten
Generische Aussagen
zur Zuverlässigkeit
Generische Zuverlässigkeitsaussagen
• Empirische Daten auswerten
• Abhängigkeit von Einflussgrößen
zur Zuverlässigkeit beschreiben
© 2015 IAS, Universität Stuttgart
353
5.4 Komponentenansatz
ZSA
Frage zu Kapitel 5.4
Welchen Aussagen stimmen Sie zu?
□
□
□
□
Empirische Daten früherer Software-Systeme dürfen nicht direkt
wiederverwendet werden.
Eine Komponente darf nicht funktional geschlossen sein.
Komponenten müssen immer über Parameter an ihre Umgebung
angepasst werden.
Eine spezifische Eigenschaft von SW-Komponenten ist es, dass diese
nur einmalig im System vorhanden ist.
© 2015 IAS, Universität Stuttgart
354
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 5 Softwarezuverlässigkeit
5.1 Grundlagen der Softwarezuverlässigkeit
5.2 Maßnahmen gegen Softwarefehler
5.3 Modelle der Softwarezuverlässigkeit
5.4 Komponentenansatz
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
© 2015 IAS, Universität Stuttgart
355
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
Einführung in SQMA
ZSA
“If you can not measure it, you can not manage it?”
 SQMA (Situationsbasierte Qualitative
Modellbildung und Analyse) ist eine am IAS
entwickelte Methode zum Entwurf komplexer
Systeme
• in frühen Entwicklungsphasen.
• trotz unvollständigen bzw. ungewissen
Informationen.
 Komponentenbasierter Ansatz zur:
• Systemmodellierung
• Analyse des Systems
© 2015 IAS, Universität Stuttgart
356
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
ZSA
Konzept der Modellbildung mit SQMA
 Ansatz besteht aus mehreren sequentiell durchzuführenden Schritten:
1. Zerlegung des Gesamtsystems in Komponenten
2. Beschreibung der Komponenten mit qualitativen Ausdrücken
3. Modellierung des Verhaltens auf Komponentenebene
4. Komposition der Komponenten zum Gesamtsystem
5. Analyse des Gesamtsystems zur Ermittlung von Gefahren
© 2015 IAS, Universität Stuttgart
357
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
ZSA
Modellierung einzelner Komponenten – Intervall-Variablen
 Komponente wird aus ihrer Umgebung herausgelöst
 Es entstehen Schnittstellen zur Umgebung, an denen Größen bzw.
Nachrichten auftreten:
Nachricht 1
Nachricht 2
1
2
SW-Komponente
3
4
Nachricht 3
Nachricht 4
 Nachrichten werden über qualitative Variablen beschrieben
 Variablen umfassen einen bestimmten Werteraum, der in unterschiedliche, für
die Komponente typische Intervalle unterteilt wird
 Beispielsweise gilt für Nachrichten ein Intervall [X1,X2], wobei
• [0,0] den Fall beschreibt, dass eine Nachricht noch nicht eingetroffen ist
• [1,1] den Fall beschreibt, dass eine Nachricht bereits eingetroffen ist
© 2015 IAS, Universität Stuttgart
358
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
ZSA
Modellierung einzelner Komponenten - Zustandsgraph
 Verhalten der Komponente wird in einem Zustandsgraph beschrieben:
• Tritt Nachricht 1 auf, so erfolgt direkt der Übergang in Zustand B und
senden der Nachricht 2
• Tritt Nachricht 4 auf, so erfolgt direkt der Übergang in Zustand A und
Senden der Nachricht 3
Nachricht 2
Nachricht 1
Nachricht 4
A
B
Nachricht 3
© 2015 IAS, Universität Stuttgart
359
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
ZSA
Modellierung einzelner Komponenten - Situationstabelle
 Abhängigkeiten und Zusammenhänge der über Intervall-Variablen beschriebenen
Größen bzw. Nachrichten werden mit Situationsregeln modelliert
 Es werden dadurch alle möglichen Kombinationen bzw. Situationen ermittelt
 Beispielhaft ein Ausschnitt aus der Situationstabelle:
Nr.
Nachricht 1 Nachricht 2
Nachricht 3
Nachricht 4
Zustand
1
[0;0]
[0;0]
[0;0]
[0;0]
A
2
[1;1]
[0;0]
[0;0]
[0;0]
B
3
[1;1]
[1;1]
[0;0]
[0;0]
B
4
[1;1]
[1;1]
[1;1]
[0;0]
A
5
[1;1]
[1;1]
[1;1]
[1;1]
A
usw.
© 2015 IAS, Universität Stuttgart
360
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
ZSA
Modellierung einzelner Komponenten - Transitionsmatrix
 Das dynamisches Verhalten der Komponente wird über Transitionsregeln
beschrieben
 Es wird festgehalten, von welchen Situationen in welche Situationen
übergegangen werden kann
 Es werden somit die Situationsregelübergange dargestellt werden
 Beispielhaft ein Ausschnitt aus der Transitionsmatrix:
Nr.
1
2
1
X
X
X
2
4
X
X
4
X
5
X
X
3
5
3
X
X
usw.
© 2015 IAS, Universität Stuttgart
361
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
ZSA
Von den Komponenten zum System (1/2)
 Im nächsten Schritt erfolgt die Verknüpfung der modellierten Komponenten
zum Gesamtsystem
 In (Netz-)listen werden dazu die Verbindungen und Kommunikationen der
Komponenten untereinander festgelegt
 Verbindung entspricht sozusagen einem Nachrichtenkanal, der einen
Sender mit einen Empfänger verbindet
 Es entsteht somit eine Art Ablaufdiagramm bzw. Schaltplan, wodurch die
Wechselwirkungen zwischen den Komponenten beschrieben werden
können
 Durch die Modellierung zugehöriger Messwerte und Stellgrößen erfolgt die
Einbindung des technischen Prozess in das Ablaufdiagramm
© 2015 IAS, Universität Stuttgart
362
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
ZSA
Von den Komponenten zum System (2/2)
 Die Situationstabellen, die für die einzelnen Komponenten aufgestellt
wurden, lassen sich nun reduzieren und der Situationsraum des Systems
ableiten
 Der reduzierte Situationsraum enthält nun die Menge an tatsächlich
möglichen Systemsituationen
 Beispielhaft zur Reduzierung auf den Situationsraum:
Nr.
Nachricht 1 Nachricht 2
Nachricht 3
Nachricht 4
Zustand
1
[0;0]
[0;0]
[0;0]
[0;0]
A
2
[1;1]
[0;0]
[0;0]
[0;0]
B
3
[1;1]
[1;1]
[0;0]
[0;0]
B
4
[1;1]
[1;1]
[1;1]
[0;0]
A
5
[1;1]
[1;1]
[1;1]
[1;1]
A
Nicht möglich, da
Nachricht 3 nur
gesendet
wird, wenn
Nachricht 4
angekommen ist!
usw.
© 2015 IAS, Universität Stuttgart
363
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
ZSA
Analyse und Auswertung
 Systemsituationen werden als Szenarien interpretiert, die einzelne
Systemzustände beschreiben
 Systemzustände und Übergang in die Zustände können dabei möglichen
Gefahrensituationen zugeordnet werden
 Bei komplexen Systemen erfolgt ein rechnerbasiertes Aufspüren von
gefährlichen Systemzuständen bzw. Vorgängen
 Einheitliche Betrachtung des Systems durch Analyse des
Zusammenwirkens von Software, dem technischen Prozess und dem
Menschen bzw. Benutzer
qualitatives
Prozeßmodell
qualitatives
Softwaremodell
© 2015 IAS, Universität Stuttgart
qualitatives
Modell der
menschlichen
Bedieneingriffe
364
5.5 Situationsbasierte qualitative Modellbildung und Analyse (SQMA)
ZSA
Frage zu Kapitel 5.5
Welchen Aussagen stimmen Sie zu?
□
□
□
□
SQMA erlaubt die Beschreibung komplexer Systeme trotz
unvollständigen Informationen.
Um SQMA anzuwenden, müssen ausreichend empirische Daten
vorliegen.
Vor der Modellierung über SQMA müssen die SW-Komponenten zu
einem Gesamtsystem verknüpft werden.
SQMA ermöglicht die einheitliche Analyse des Mensch-, Prozess- und
Softwaremodels .
© 2015 IAS, Universität Stuttgart
365
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Gliederung
§ 1 Einführung, Begriffe und Normen
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
§ 3 Fehlerbaumanalyse (FTA)
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
§ 5 Softwarezuverlässigkeit
§ 6 Zuverlässigkeits- und Sicherheitstechnik
§ 7 Übungsaufgaben
© 2015 IAS, Universität Stuttgart
366
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 6 Zuverlässigkeits- und Sicherheitstechnik
6.1 Risiko, Gefährdung und Gefahr
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
6.3 Sicherheits- und Risikoanalysen
6.4 Ermittlung des Safety Integrity Levels (SIL)
© 2015 IAS, Universität Stuttgart
367
6.1 Risiko, Gefährdung und Gefahr
ZSA
Risiko, Gefährdung und Gefahr…
© 2015 IAS, Universität Stuttgart
368
6.1 Risiko, Gefährdung und Gefahr
ZSA
Allgemeine Definitionen (1/2)
 Begriffe für Risiko, Gefährdung und Gefahr sind in verschiedenen ISO-, ENund DIN-Normen definiert (z.B. DIN 31000), hier sollen nur die Erläuterungen
gebracht werden
 Risiko (risk)
• Die Möglichkeit, Schaden zu erleiden
• Produkt aus Schadenshäufigkeit und Schadensausmaß
• Risiko entspricht dem Schaden pro Zeiteinheit
• Unterteilung:
 Kollektives Risiko, bezogen auf Personengruppen
 Individuelles Risiko, bezogen auf einzelne Personen
• Sicherheit ist das Frei sein von nicht akzeptablen Risiken
© 2015 IAS, Universität Stuttgart
369
6.1 Risiko, Gefährdung und Gefahr
ZSA
Allgemeine Definitionen (2/2)
 Gefährdung (hazard)
• Eine potenzielle Gefahrenquelle
• Art der möglichen Auswirkungen einer Gefahr durch Angaben über
mögliche, nicht vertretbare Personen- und/oder Sachschäden
 Gefahr (danger)
• Die mögliche Schadwirkung der Gefahrenquelle oder der Zustand einer
Bedrohung durch eine Gefahrenquelle
• Zustand des Vorhandenseins von nicht vertretbaren Risiken
 Schaden (damage [obj.], harm [pers.])
• Die konkrete schädigende Auswirkung der Gefahrenquelle, als
Möglichkeit oder Wirklichkeit
• Jeder materielle oder immaterielle Nachteil, den eine Person oder Sache
durch ein Ereignis erleidet
© 2015 IAS, Universität Stuttgart
370
6.1 Risiko, Gefährdung und Gefahr
ZSA
Risikokriterium Schadenshäufigkeit
 Schadenshäufigkeit ist die Anzahl von Fehlereignissen innerhalb eines
Zeitraums, d.h., Anzahl der Gefahren, die im Lebenszyklus eines Produkts
eintreten
Kategorie
Definition
häufig
Eine ständige Gefahr, die allgegenwärtig eintreten kann.
wahrscheinlich
Es ist zu erwarten, dass eine Gefahr oft und mehrmals eintritt.
gelegentlich
Eine Gefahr kann mehrmals eintreten.
selten
Es sinnvoll, mit dem Eintreten einer Gefahr zu rechnen.
unwahrscheinlich
Es ist anzunehmen, dass eine Gefahr nur in Ausnahmesituationen eintritt.
unvorstellbar
Es darf angenommen werden, dass keine Gefahr eintritt.
© 2015 IAS, Universität Stuttgart
371
6.1 Risiko, Gefährdung und Gefahr
ZSA
Risikokriterium Schadensausmaß
 Schadensausmaß ist ein qualitatives Maß möglicher Konsequenzen
Kategorie
Konsequenzen für eine
Personen
Konsequenzen für eine
Betriebs- und Dienstleistung
katastrophal
Mehrere Unfalltote und/oder zahlreiche
Schwerverletzte und/oder schwere
Umweltschäden.
Verlust des gesamten Systems
bzw. der gesamten Funktionalität.
kritisch
Einzelne Unfalltote und/oder
Schwerverletzte und/oder nennenswerte
Umweltschäden.
Verlust eines bzw. mehrerer
wichtiger (Teil-) Systeme.
marginal
Kleinere Verletzungen und/oder
nennenswerte Bedrohung der Umwelt.
Schwere Beschädigung des
Systems.
unbedeutend
Mögliche, geringfügige Verletzungen.
Geringfügige Beschädigung des
Systems.
© 2015 IAS, Universität Stuttgart
372
6.1 Risiko, Gefährdung und Gefahr
ZSA
Risikostufen auf Basis der Risikokriterien
 Eine Bewertung des Risikos erfolgt vor und nach der Ausführung einer
Maßnahme zur Erhöhung der Sicherheit
 Es gilt das folgende Schema
Häufigkeit
Risikostufen
häufig
unerwünscht
intolerabel
intolerabel
intolerabel
wahrscheinlich
tolerabel
unerwünscht
intolerabel
intolerabel
gelegentlich
tolerabel
unerwünscht
unerwünscht
intolerabel
selten
vernachlässigbar
tolerabel
unerwünscht
unerwünscht
unwahrscheinlich
vernachlässigbar
vernachlässigbar
tolerabel
tolerabel
unvorstellbar
vernachlässigbar
vernachlässigbar
vernachlässigbar
vernachlässigbar
unbedeutend
marginal
kritisch
katastrophal
Schadensausmaß
© 2015 IAS, Universität Stuttgart
373
6.1 Risiko, Gefährdung und Gefahr
ZSA
Bewertung der Risikostufen
 Beurteilung, ob ein Risiko unter bestimmten Rahmenbedingungen akzeptabel
oder nicht akzeptabel ist und ob mögliche Restrisiken vertretbar sind
Kategorie
Kriterien für anzuwendende Maßnahmen
intolerabel
Ein Risiko muss unbedingt ausgeschlossen werden.
unerwünscht
Ein Risiko darf nur akzeptiert werden, wenn eine Risikominderung
praktisch nicht durchführbar ist und eine Zustimmung der für die
Sicherheit zuständigen Aufsichtsbehörde vorliegt.
tolerabel
Bei geeigneter Überwachung und mit Zustimmung einer
Aufsichtsbehörde kann das Risiko akzeptiert werden.
vernachlässigbar
Ohne weiter Zustimmung einer Aufsichtsbehörde darf das Risiko
akzeptiert werden.
© 2015 IAS, Universität Stuttgart
374
6.1 Risiko, Gefährdung und Gefahr
ZSA
Grenzrisiko und Risikoakzeptanz
 Grenzrisiko ist das größte noch vertretbare bzw. noch akzeptable Risiko
 Grenze für das noch akzeptable Risiko wird durch gesetzliche,
gesellschaftliche oder persönliche Regeln gesetzt:
• Aktuelle Statistiken als Basis für das Grenzrisiko
• Genormte Akzeptanzkriterien (z.B. in EN 50126)
 Das verbleibende Restrisiko ist das Risiko, das nicht durch Maßnahmen und
die Wirkung aller Sicherheitsfunktionen ausgeschlossen werden kann
 Restrisiko setzt sich aus einem bekannten bzw. abschätzbaren und einem
unbekannten Teil zusammen
© 2015 IAS, Universität Stuttgart
375
6.1 Risiko, Gefährdung und Gefahr
ZSA
Arten der Risikoakzeptanz
 Allgemeine Risikoakzeptanz
• Risiko, dass bei der richtigen Anwendung der nach dem Stand der
Technik notwendigen Maßnahmen nicht ausschließbar ist
• Neben der Technik an sich, sind Betriebsführung (Organisation,
Personal,…) und mögliche Externe Einflüsse am Gesamtrisiko beteiligt
 Individuelle Risikoakzeptanz
• Risiko, das man selbst bereit ist zu akzeptieren
• Zum Beispiel Rauchen, Motorrad fahren, Sport
© 2015 IAS, Universität Stuttgart
376
6.1 Risiko, Gefährdung und Gefahr
ZSA
Mortalität
 Begriff aus der Demographie für die Sterberate, d.h., es wird die Zahl der
Todesfälle bezogen auf die Anzahl der Individuen berechnet
 Darstellung der Mortalität erfolgt bezogen auf die Altersgruppen
 Beispiel Deutschland (als entwickeltes Industrieland):
Quelle: de.wikipedia.org
© 2015 IAS, Universität Stuttgart
377
6.1 Risiko, Gefährdung und Gefahr
ZSA
Lebens- und Sterberisiko
 Begriffe aus der Rechtsprechung, die mögliche Gefahren bzw. negative
Ereignisse beschreiben, die zum Nachteil oder Tod von Menschen führen
können
 Tod ergibt sich aus vielen verschiedenen Ursachen, wobei eine
Ursachengruppe der „Technologie“ zugeordnet wird
• Verkehr (PKW, Bahn,…)
• Arbeitsmaschinen
• Heimwerken
• Unterhaltung und Sport
 Jede Ursachengruppe hat einen bestimmten Prozentsatz von Toten/Jahr
 Entsprechend der Altersverteilung der Mortalität wird das Risiko bzw. der
jeweilige Prozentsatz als „Endogene Sterblichkeit/Mortalität R“ bezeichnet
© 2015 IAS, Universität Stuttgart
378
6.1 Risiko, Gefährdung und Gefahr
ZSA
Minimale Endogene Mortalität (MEM)
 MEM ist das Maß für das unvermeidliche und akzeptierte Risiko, dass
Personen durch den Einsatz einer Technologie zu Tode kommen
 Wird in der Norm EN 50126 konkret beschrieben und orientiert sich an der
Mortalität der Gruppe der 5- 15jährigen in einem entwickelten Industrieland:
Rm = 2 · 10-4 Todesfälle/(Person x Jahr)
 Es wird daraus die Regel abgeleitet, dass Gefahren, die sich durch ein neues
technologisches System (z.B.: Verkehr) ergeben, zu keiner nennenswerte
Erhöhung der minimalen endogenen Mortalität führen
 In der Praxis akzeptierte Werte sind dabei:
• Rx < 10-5 Todesfälle/(Person x Jahr)
• Rx < 10-4 Schwerverletzte/(Person x Jahr)
• Rx < 10-3 Leichtverletzte/(Person x Jahr)
© 2015 IAS, Universität Stuttgart
379
6.1 Risiko, Gefährdung und Gefahr
ZSA
Bewertung des Risikoakzeptanzkriterium MEM
 Vorteile des Ansatz:
• Garantiert feste Grenzwerte, unabhängig vom Nutzungsverhalten sowie
den individuellen Risiken eines Nutzers
• Ermöglicht den Vergleich verschiedener (Teil-)Systeme
• Erleichtert die Arbeit von Sicherheitsaufsichtsbehörden, indem
Entscheidungskriterien zur Freigabe eines Systems gegeben sind
• Festes Maß, das sich nicht an gesellschaftliche oder politische
Gegebenheiten anpassen lässt (Sensibilität aufgrund aktueller Unfälle)
 Nachteil des Ansatz:
• Verallgemeinerung, da das Systemverhalten im Betrieb nicht genauer
betrachtet wird (Nutzungsdauer, Bedienpersonal,…)
© 2015 IAS, Universität Stuttgart
380
6.1 Risiko, Gefährdung und Gefahr
ZSA
ALARP-Prinzip („As Low As Reasonably Practicable“)
 Prinzip der Risikoreduzierung, nach dem ein Risiko durch ein zusätzliches
System so niedrig wie vernünftigerweise praktikabel sein soll
 System muss unter dem möglichen Grad der Wirtschaftlichkeit sicher sein, die
Kosten für eine Risikominderung müssen auf wirtschaftlichen Basis beruhen
 Es gilt:
Unzulässiges Risiko
Risikominderung ungeachtet der Kosten
Tod / (Person x Jahr)
10-3 (Arbeit)
10-4 (Privat)
Risiko ist zulässig, wenn
ALARP
Bereich
1) Eine Risikominderung nicht möglich
2) Kosten der Risikominderung > Nutzen
10-6 (generell)
© 2015 IAS, Universität Stuttgart
Zulässiges Risiko
Risikominderung nicht notwendig
381
6.1 Risiko, Gefährdung und Gefahr
ZSA
GAMAB („Globalement Au Moins Aussi Bon“)
 Prinzip, das ein neues System mindestens so sicher bzw. risikoarm sein
muss, wie ein bereits existierendes, vergleichbares System
 Mindestanforderung an ein neues System ist der derzeitige Sicherheitsstandard
 Technischer Fortschritt baut auf den Mindestanforderungen auf
 Vorgehen:
• Ableitung statistischer Daten aus bisher eingesetzten Systemen
• Charakterisierung des neuen Systems durch eine Reihe von Parametern
• Untersuchung der System-Parameter mit Hilfe der statistischen Daten der
bisher eingesetzten Systeme
• Geschätzten Daten des neuen Systems entsprechen oder übertreffen
Daten der bisherigen Systeme
© 2015 IAS, Universität Stuttgart
382
6.1 Risiko, Gefährdung und Gefahr
ZSA
Frage zu Kapitel 6.1
Welchen Aussagen stimmen Sie zu?
□
□
□
□
Ist ein Risiko tolerabel, so kann es bei geeigneter Überwachung und mit
Zustimmung einer Aufsichtsbehörde akzeptiert werden.
Das individuelle Risiko ist das Risiko, das man selbst bereit ist zu
akzeptieren.
Nach dem GAMAB Prinzip muss ein System so risikoarm sein, dass es
gerade noch praktikabel ist.
Ein System orientiert sich bei der Risikobewertung nach dem ALARPPrinzip an vergleichbaren Systemen.
© 2015 IAS, Universität Stuttgart
383
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 6 Zuverlässigkeits- und Sicherheitstechnik
6.1 Risiko, Gefährdung und Gefahr
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
6.3 Sicherheits- und Risikoanalysen
6.4 Ermittlung des Safety Integrity Levels (SIL)
© 2015 IAS, Universität Stuttgart
384
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Methoden und Techniken
 Erhöhung der Sicherheit um Gefährdungen auszuschließen
• Fehlerausschluss
• Fehlersicher (fail-safe)
• Fehlererkennung und Überführung zur sicheren Seite
 Erhöhung der Zuverlässigkeit um die Ausfallwahrscheinlichkeit zu reduzieren
• Bessere Komponenten
• Besser Systemstruktur
• Redundanzstrukturen
 Zuverlässigkeits- und Sicherheitstechnik ist die Kombination beider Methoden
und Techniken, wobei gilt:
© 2015 IAS, Universität Stuttgart
385
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Echte-Fail-Safe-Verfahren
 Konstruktiv festgelegte Ausfallrichtung durch die Ausnutzung von
physikalischen Effekten
 Sichere Ausfallrichtung durch Zusammenschaltung von Komponenten
 Keine Ausfall- oder Fehlererkennung wird verwendet
 Beispiel: Ruhestromprinzip bei Relaisschaltungen
• System wird auch in Ruhe mit ständigem, definierten Strom betrieben
• Aktion wird veranlasst, wenn Strom außerhalb eines Toleranzbereich ist
oder eine Unterbrechung des Stromfluss vorliegt
 Bei Software-Systemen nicht realisierbar, da auch unbekannte Fehler
sicherheitsgerichtet wirken müssten
© 2015 IAS, Universität Stuttgart
386
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Quasi-Fail-Safe-Verfahren
 Bei Erkennung eines Fehlers erfolgt die Einleitung von sicherheitsgerichteten
Maßnahmen (unterbrechungsfreie Stromversorgung)
 Verwendung einer Ausfall- oder Fehlererkennung
 Beispiel: Zweikanalige Signalverarbeitung
• Versorgung und Kommunikation über parallele Einheiten
• Systemfunktionalität gegeben trotz Ausfall einer Einheit
 Bei Software-Systemen erfolgt Ausfall- oder Fehlererkennung über:
• Programmablaufüberwachung
• Rechenzeit- bzw. Laufzeitüberwachung
• Plausibilitätsprüfungen
 Enge Verbindung bzw. Zusammenwirken von Hardware und Software
© 2015 IAS, Universität Stuttgart
387
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Allgemeine Beispiele von Strategien
 Hardware-Strategien
• Verbesserung von Material, Konstruktion und Herstellungsprozess
• Auswahl besserer Komponenten
• Redundanz
• Schutz gegen Umwelteinflüsse
 Software-Strategien
• Geeignete Methoden der Softwareentwicklung
• Geeignete Tools zur Softwareentwicklung
• Wiederverwendung von Software
• Selbstüberwachung
© 2015 IAS, Universität Stuttgart
388
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Perfektionsstrategie und Non-Perfektionsstrategie
 Strategien der Zuverlässigkeits- und Sicherheitstechnik lassen sich
grundsätzlich in zwei Klassen unterteilen:
Perfektionsstrategie
Non-Perfektionsstrategie
– Fehlervermeidung –
– Fehlertoleranz –
Ausschließen von Fehlern
vor der Inbetriebnahme
eines Systems
System kann die spezifizierte
Funktion nach der
Inbetriebnahme trotz
vorhandener Fehler erfüllen
Zeitpunkt der Inbetriebnahme
© 2015 IAS, Universität Stuttgart
389
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Perfektionsstrategie (1/2)
 Der Einsatz von Perfektionsstrategien richtet sich nach der Wirtschaftlichkeit
eines Produkts und ist abhängig von geltenden Normen bzw. Vorschriften
 Ziel ist das generelle Ausschließen von Fehlern über:
• Maßnahmen gegen Ausfälle aufgrund von bestimmten
Ausfallmechanismen
• Maßnahmen gegen Ausfälle aufgrund von Störeinflüssen
© 2015 IAS, Universität Stuttgart
390
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Perfektionsstrategie (2/2)
 Nach der Perfektionsstrategie gilt für den Entwicklungsprozess die Einhaltung
bzw. Durchführung von:
• Konstruktiven Maßnahmen
• Sorgfältiger Entwurf
• Erhöhte Anzahl von Tests
• Ausgereifte Verifikations- und Testmethoden
© 2015 IAS, Universität Stuttgart
391
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Non-Perfektionsstrategie (1/2)
 Verhinderung gefährlicher Auswirkungen von Fehlern und Ausfällen, die im
laufenden Betrieb auftreten können, durch Diagnose-, Erkennungs- und
Redundanzmaßnahmen
 Non-Perfektionsstrategie erfolgt immer nur ergänzend zur Perfektionsstrategie
 Grund dafür ist:
• Menschliche Bedienhandlungen sind im Fehler- bzw. Störungsfall immer
als kritisch anzusehen
• Reduzierung der Wahrscheinlichkeit von Mehrfachfehlern, die auch für die
Toleranzstrategien kritisch sind
© 2015 IAS, Universität Stuttgart
392
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Non-Perfektionsstrategie (2/2)
 Maßnahmen der Non-Perfektionsstrategie werden eingesetzt zur:
• Fehlerausgrenzung, d.h., eine fehlerhafte Komponente wird durch
eine fehlerfreie / funktionsfähige Komponente ersetzt.
• Fehlerbehebung, d.h., Rücksetzung auf einen gesicherten und bekannten
vorherigen, fehlerfreien Zustand
• Fehlermaskierung, d.h., Aufbau redundanter Strukturen, sodass ein
Mehrheitsentscheider definiert, welches Ereignis korrekt ist.
• Fehlerdetektion und -korrektur
© 2015 IAS, Universität Stuttgart
393
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Anwendungs-Beispiel: Ausfall eines Bauteils
 Betrachtung physikalischer Fehler, die zu dem Ausfall des Bauteils führen
 Maßnahmen der Perfektionsstrategie:
•
Maßnahmen gegen Ausfälle aufgrund von Ausfallmechanismen
 Überdimensionierung des Bauteils
 Verwendung eines hochwertigen, vorgealterten Bauteils
•
Maßnahmen gegen Ausfälle aufgrund von Störeinflüssen

Abschirmung

Räumliche Trennung von Energie- und Signalleitungen
 Maßnahmen der Non-Perfektionsstrategie:
• Redundante Struktur von Sensoren innerhalb einer Sensoreinheit
© 2015 IAS, Universität Stuttgart
394
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
ZSA
Frage zu Kapitel 6.2
Welchen Aussagen stimmen Sie zu?
□
Detaillierte Prüfung des Systems ist Teil der Perfektionsstrategie.
□
Redundanz ist Teil der Perfektionsstrategie.
□
Potentialtrennung ist Teil der Perfektionsstrategie.
□
Die Verwendung mechanischer Konstruktionen mit einer hohen Steifigkeit
ist Teil der Perfektionsstrategie.
© 2015 IAS, Universität Stuttgart
395
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 6 Zuverlässigkeits- und Sicherheitstechnik
6.1 Risiko, Gefährdung und Gefahr
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
6.3 Sicherheits- und Risikoanalysen
6.4 Ermittlung des Safety Integrity Levels (SIL)
© 2015 IAS, Universität Stuttgart
396
6.3 Sicherheits- und Risikoanalysen
ZSA
Risikoanalyse
 Risikoanalyse (risk assessment) ist ein Mittel zur Bewertung von Situationen,
Vorhaben, Systeme oder Ereignissen in allen möglichen Bereichen des
Lebens
 Primäres Ziel in der Sicherheits- und Zuverlässigkeitstechnik ist die
Vermeidung negativer Ereignisse durch Präventionsmaßnahmen, die aus
Methoden bzw. Verfahren der Risikobewertung abgeleitet werden
 Anwendungsgebiete von Risikoanalysen sind beispielsweise:
•
In der Entwicklung zur Identifikation von Risiken neuer Systeme
•
In der Politik zu Erhebung von Risikostatistiken
•
In Banken zur Bestimmung von risikobehafteten Kundensegmenten
 Hier betrachtete Risikoanalyse befassen sich mit der Sicherheit von Systeme:
• PSA/PRA
• PAAG
© 2015 IAS, Universität Stuttgart
397
6.3 Sicherheits- und Risikoanalysen
ZSA
Einführung in PSA/PRA (1/2)
 Probabilistische Sicherheitsanalyse (Probability Safety Assessment ,PSA),
auch probabilistische Risikoanalyse (Probability Risk Assessment, PRA), ist
ein quantitatives Verfahren zur Risiko-Untersuchung mittels probabilistischer
bzw. wahrscheinlichkeitsbasierender Methoden
 Entwickelt im Rahmen der amerikanischen Reaktorsicherheitsstudie „WASH
1400“ im Jahr 1975
 Methodischen Ansätze der Studie wurden u.a. in Deutschland übernommen,
überarbeitet und gelten als Referenzanalyse für Kernkraftwerke:
• Stufe 1: Ermittlung der Häufigkeit von Kernschäden im Reaktor
• Stufe 2: Ermittlung der Abläufe im Falle einer Kernschmelze
• Stufe 3: Analysen möglicher Folgen außerhalb des Kraftwerks
© 2015 IAS, Universität Stuttgart
398
6.3 Sicherheits- und Risikoanalysen
ZSA
Einführung in PSA/PRA (2/2)
 PSA/PRA bedient sich bekannter Methoden (FTA, FMEA,…) und wird heute
in allen Industriebereichen eingesetzt (Luftfahrt, Bahn, Chemie-Industrie)
 Wesentliche Kernfragen der PSA/PRA sind:
• Was kann versagen?
• Wie wahrscheinlich ist es?
• Was sind die Auswirkungen?
 Probabilistische Eingangsgrößen der Methode werden aus Betriebserfahrung
(z.B. einer Anlage) oder von vergleichbaren Systemen gewonnen
 Beispiele für Eingangsgrößen sind:
• Häufigkeit der störfallauslösenden Ereignisse
• Ausfallraten der Komponenten
• Verfügbarkeit bzw. Nichtverfügbarkeit der Teilsysteme
• Fehlerraten (Personenhandlungen, Redundanzen,…)
© 2015 IAS, Universität Stuttgart
399
6.3 Sicherheits- und Risikoanalysen
ZSA
Ablauf von PSA/PRA (1/2)
 Tiefe des Informationsgehalts der PSA/PRA ist abhängig vom jeweiligen
Anwendungsgebiet und der beteiligten Personen
 Idealerweise besteht ein PSA/PRA-Team aus:
Spezialisten
• Ingenieure
• Informatiker
• Naturwissenschaftler
Systemanalytiker
PSA/PRATeam
Verhaltensanalyst
Datenanalyst
Betriebspersonal/Nutzer
© 2015 IAS, Universität Stuttgart
400
6.3 Sicherheits- und Risikoanalysen
ZSA
Ablauf von PSA/PRA (2/2)
Identifikation der Gefahrenpotentiale
Beschreibung der Sicherheitstechnik,
die Gefahrenpotentiale verhindert
Störfälle bestimmen, die zur Freisetzung
der Gefahrenpotentiale führen
Analyse der Gefahrenpotentiale und
Überführung in ein Modell
Modell mit probabilistischen
Eingangsgrößen Versehen
Feststellung des Eintrittsrisikos und
eindeutige Bewertung der Ergebnisse
© 2015 IAS, Universität Stuttgart
401
6.3 Sicherheits- und Risikoanalysen
ZSA
Herausforderung „menschliche Handlungen“
 Grundlegende Problematik quantitativer Methoden ist der Umgang bzw. die
Bewertung menschlicher Handlungsweisen
 Menschliche Handlungen finden vor, während und nach einem Ereignis statt:
• Als auslösendes Ereignis bzw. Ursache
• Beinflussend mit Folge einer Eindämmung oder Verschlimmerung
• Als Reaktion auf ein Ereignis
 Handlungen müssen ebenso über Wahrscheinlichkeiten abgeschätzt werden
 Basis sind statistische Daten, die aber häufig fehlen oder mangelhaft sind
 Daher Verfahren, die eine Kombination beinhalten aus:
• Statistiken
• Extrapolation verschiedenster Informationsquellen
• Expertenbeurteilen (Soziologen, Psychologen,…)
© 2015 IAS, Universität Stuttgart
402
6.3 Sicherheits- und Risikoanalysen
ZSA
Einführung in PAAG (1/2)
 Verfahren zur qualitativen Untersuchung der Sicherheit eines Systems
 Normung nach IEC 61882 als HAZOP-Verfahren (Hazard and Operability Study)
 Es gilt das Vorgehen nach dem Prinzip:
• Prognose eines Ereignisses, das auftreten könnte
• Auffinden der Ursache
• Abschätzen der Auswirkungen
• Gegenmaßnahmen ableiten
 Entwickelt in der Chemieindustrie in den 1970er Jahren in England
 Berufsgenossenschaft Chemie setzte das Verfahren für Deutschland um
 Seit den 1990er wird das Verfahren auch in der Softwareentwicklung eingesetzt
© 2015 IAS, Universität Stuttgart
403
6.3 Sicherheits- und Risikoanalysen
ZSA
Einführung in PAAG (2/2)
 PAAG kann durchgeführt werden, wenn ein erster Entwurf eines System vorliegt
 Verfahren begleitet den gesamten Entwicklungsprozess
 Experten-Team aus erfahrenen Mitarbeitern (Bereiche Entwicklung, Betrieb,
Wartung und Pflege) definieren das Soll-Verhalten des Systems
 Auf Basis des Soll-Verhalten werden Parameter verändert, sodass
Abweichungen vom normalen Prozessbetrieb auftreten, die Gefährdungen
darstellen können
 Moderator führt das Experten-Team systematisch durch das Verfahren, indem
Leitwörter mit den veränderlichen Prozess-Parameter verbunden werden,
welche den Fokus der Analyse auf die Ursachen von Gefahren richtet
© 2015 IAS, Universität Stuttgart
404
6.3 Sicherheits- und Risikoanalysen
ZSA
PAAG Leitwörter
 Definierte Leitwörter (guidewords) sind dabei:
Leitwort (de)
Guideword (eng) Erklärung
Nein, nicht
No
Abweichung vom Soll-Verhalten
Mehr
More
Quantitativer Zuwachs
Weniger
Less
Quantitative Abnahme
Sowohl..als auch…
As well as
Zusätzliche Ereignisse zum Soll-Verhalten
Teilweise
Part of
Soll-Verhalten erfolgt unvollständig
Umkehrung
Reverse
Gegenteiliges als das Soll-Verhalten
Anders als
Other than
Etwas anders als das Soll-Verhalten
Früher/später
Earlier/later
Ein nicht erwarteter Zeitpunkt einer Aktion
Zuvor/danach
Before/after
Eine nicht erwartete Einordnung in eine Sequenz
Schneller/langsamer
Faster/slower
Eine nicht erwartete Änderung der Ablauf- bzw.
Ausführungsgeschwindigkeit
© 2015 IAS, Universität Stuttgart
405
6.3 Sicherheits- und Risikoanalysen
ZSA
Durchführung von PAAG
 Unterteilung in vier Phasen (nach Felix Redmill, Buch „System Safety: HAZOP
and Software-HAZOP“, 1999) :
Intialisierung
(initiating the study)
Planung
(planing the study)
Teamarbeit
(study meeting)
Schlussfolgerungen
(follow-up work)
© 2015 IAS, Universität Stuttgart
406
6.3 Sicherheits- und Risikoanalysen
ZSA
Initialisierung und Planung
 PAAG Verfahren wird von einem Verantwortlichen (initiator) gestartet, in dem
dieser einen Leiter (leader) benennt
 Aufgaben des Leiters sind:
• Auswahl des Teams (Experten, Nutzer und Protokollant)
• Auswahl der Leitwörter
• Planung der Teamarbeit
• Moderation der Diskussionsrunden
© 2015 IAS, Universität Stuttgart
407
6.3 Sicherheits- und Risikoanalysen
ZSA
Teamarbeit und Schlussfolgerung
 Moderator leitet die Diskussion
 Es wird dabei eine Tabelle angelegt, die Abweichungen vom Sollverhalten
enthält:
System
Komponente
Parameter
Leitwort
μC-Einheit
Mikrocontroller
Spannungs- NO
Versorgung
Ursache
Folge
Maßnahme
Verschleiß
Ausfall
Redundanz
 Teammitglieder schlagen im Anschluss an die Diskussion mögliche
Maßnahmen vor, wie kritische Fehlerfälle vermieden werden können
 Bis zur nächsten Diskussionsrunde werden die Maßnahmen umgesetzt
 Es erfolgt eine erneute Diskussion und somit die Probe, ob die kritischen
Fehlerfälle neutralisiert wurden
 Gesamter Vorgang wird dokumentiert:
© 2015 IAS, Universität Stuttgart
408
6.3 Sicherheits- und Risikoanalysen
ZSA
Frage zu Kapitel 6.3
Welchen Aussagen stimmen Sie zu?
□
Ziel von Risikoanalysen ist die Ableitung präventiver Maßnahmen.
□
PSA/PRA und PAAG sind beides qualitative Modelle der Risikoanalyse.
□
Erster Schritt einer PSA/PRA ist die Erstellung eines Modells.
□
Bei PAAG erfolgt eine Bewertung von Risikosituationen über Parameter.
© 2015 IAS, Universität Stuttgart
409
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§ 6 Zuverlässigkeits- und Sicherheitstechnik
6.1 Risiko, Gefährdung und Gefahr
6.2 Strategien der Zuverlässigkeits- und Sicherheitstechnik
6.3 Sicherheits- und Risikoanalysen
6.4 Ermittlung des Safety Integrity Levels (SIL)
© 2015 IAS, Universität Stuttgart
410
6.4 Safety Integrity Level (SIL)
ZSA
Definition eines Sicherheitsgrads
 Ein Sicherheitsgrad ist eine Einordnung dafür, wie ein sicherheitsrelevantes
System eine Sicherheitsanforderung erfüllt
 Sicherheitsgrade können in zwei Gruppen unterteilt werden
• Hinsichtlich systematischer Fehler
• Hinsichtlich zufälliger Ausfälle
Versagen
ODER
Systematischer Fehler
(Mensch)
© 2015 IAS, Universität Stuttgart
Zufälliger Ausfall
(Physik)
411
6.4 Safety Integrity Level (SIL)
ZSA
Safety Integrity Levels (1/2)
 Safety Integrity Levels (SIL) sind vier diskrete Stufen von SicherheitsAnforderungen bzw. -Integritäten an eine Sicherheitsfunktion
 Normung nach DIN 61508 (Sicherheitsgrundnorm)
 Bestimmung der jeweiligen SIL-Stufe über die Risikoanalyse eines Ausfalls
des technischen Systems und der davon ausgehenden Ereignisse
 Für jede Stufe ergeben sich sicherheitsgerichtete Entwicklungsprinzipien
die eingehalten werden müssen, um das Risiko einer Fehlfunktion zu
vermindern
 Nach Bestimmung einer SIL-Stufe können, falls nötig bzw. möglich,
Maßnahmen abgeleitet und durchgeführt werden, sodass die SIL-Stufe
reduziert werden kann
© 2015 IAS, Universität Stuttgart
412
6.4 Safety Integrity Level (SIL)
ZSA
Safety Integrity Levels (2/2)
 Das Vorgehen der SIL-Einstufung ist nicht über ein absolutes Verfahren
vorgegeben, sondern erfolgt anhand der qualitativen Abschätzung von
Risikoparametern:
•
Schadensausmaß
•
Häufigkeit der Gefahr bzw. des Aufenthalts von Personen im
Gefahrenbereich (Aufenthaltsdauer)
•
Möglichkeit, die Gefahr abzuwehren oder den Schaden zu begrenzen
•
Eintrittswahrscheinlichkeit eines gefährlichen Ereignisses
 Beurteilung ist schwer, da Umgang mit einem Ereignis oder Einordnung eines
Umstands oft nicht eindeutig klassifizierbar
 Einfaches, aber treffendes Beispiel: Anfahren „am Berg“
• Unterschiedliche Auffassung von „Berg“, wenn eine Person aus Küstenoder Alpen-Region stammt
© 2015 IAS, Universität Stuttgart
413
6.4 Safety Integrity Level (SIL)
ZSA
Ermittlung des Safety Integrity Levels
Werte
S1
Bedeutung
leichte Verletzungen
S2
Tod einer Person / ernste
dauerhafte Verletzung
S3
Tod mehrerer Personen
S4
Tod sehr vieler Personen
F1
selten bis öfters und/oder kurze
Aufenthaltsdauer
F2
häufige und/oder lange
Aufenthaltsdauer
P1
möglich unter bestimmten
Bedingungen
P2
kaum möglich
W1
sehr unwahrscheinlich
W2
unwahrscheinlich
W3
wahrscheinlich
S1
P1
F1
P1
F2
P2
F1
S3
F2
S4
© 2015 IAS, Universität Stuttgart
P2
S2
W3
W2
W1
-
-
-
SIL 1
-
-
SIL 1
SIL 1
-
SIL 2
SIL 1
SIL 1
SIL 3
SIL 2
SIL 1
SIL 3
SIL 3
SIL 2
SIL 4
SIL 3
SIL 3
-
SIL 4
SIL 3
414
6.4 Safety Integrity Level (SIL)
ZSA
Unabhängigkeit nach SIL
PM
DI
VER
VAL
GUT
≙
≙
≙
≙
≙
Projektmanager
Designer/Implementierer
Verifizierer
Validierer
Gutachter
darf dieselbe
Organisation sein
darf dieselbe
Person sein
SIL 1-2
SIL 0
PM
PM
GUT
GUT
DI, VER, VAL
DI
VER, VAL
SIL 2-3
SIL 3-4
PM
PM
GUT
GUT
DI
VER, VAL
© 2015 IAS, Universität Stuttgart
DI
VER
VAL
415
6.4 Safety Integrity Level (SIL)
ZSA
ASIL nach ISO 26262 (1/2)
 SIL-Stufen aus der Grundnorm DIN 61508 können direkt angewandt oder für
spezifische Bereiche angepasst werden
 In der Norm ISO 26262 wurde SIL in den Automotive-Bereich überführt und mit
ASIL (Automotive Safety Integrity Levels) bezeichnet
 ASIL ist ein qualitatives Maß für die Sicherheitsrelevanz einer Fehlfunktion und
ergibt sich aus den Parametern:
• Auftretenswahrscheinlichkeit E (Exposure)
Wie häufig sind Situationen, in denen die Fehlfunktion relevant ist?
• Kontrollierbarkeit C (Controllability)
Wenn die Fehlfunktion auftritt, wie gut kann sie beherrscht werden?
• Schwere der Schädigung S (Severity)
Wenn die Fehlfunktion nicht beherrscht wird, wie groß ist die Auswirkung?
© 2015 IAS, Universität Stuttgart
416
6.4 Safety Integrity Level (SIL)
ZSA
ASIL nach ISO 26262 (2/2)
 Methodik der ASIL Einstufung:
• Skala A bis D, wobei A die niedrigste und D die höchste Einstufung einer
Fehlfunktion darstellt
• Einstufung als QM (Qualitätsmanagement), d.h., dass eine Fehlfunktion
nicht als sicherheitsrelevant eingestuft wird
 Beispiele für ASIL von Gefährdungen aus der Praxis:
• Airbag löst ohne Bedarfsfall aus
• Ungewollte Beschleunigung
• Lenkunterstützung fällt aus
 Nach der Einstufung einer Fehfunktion erfolgt die Ableitung von
Maßnahmen, falls eine Reduzierung der Stufe nötig ist / möglich ist
© 2015 IAS, Universität Stuttgart
417
6.4 Safety Integrity Level (SIL)
ZSA
Frage zu Kapitel 6.4
Welchen Aussagen stimmen Sie zu?
□
□
□
□
Der Tod mehrerer Personen ist nicht über eine SIL-Stufe erfassbar und
muss bei jedem System ausgeschlossen werden.
SIL repräsentiert ein quantitatives Verfahren zur Risikobewertung.
Nach der Unabhängigkeit nach SIL 0 kann der Designer auch seine
Arbeit validieren.
Nach der Unabhängigkeit nach SIL 2-3 sind Verifikation und Validation
dem gleichen Projektmanagement unterworfen wie das Design.
© 2015 IAS, Universität Stuttgart
418
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
Gliederung
§ 1 Einführung, Begriffe und Normen
§ 2 Wahrscheinlichkeit und Zuverlässigkeit
§ 3 Fehlerbaumanalyse (FTA)
§ 4 Fehlermöglichkeits- und Einfluss-Analyse (FMEA)
§ 5 Softwarezuverlässigkeit
§ 6 Zuverlässigkeits- und Sicherheitstechnik
§ 7 Übungsaufgaben
© 2015 IAS, Universität Stuttgart
419
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§7 Übungsaufgaben
Aufgabe 1 – Zuverlässigkeitsblockdiagramm
Aufgabe 2 – Fehlerbaumanalyse (FTA)
Aufgabe 3 – Softwarezuverlässigkeit
© 2015 IAS, Universität Stuttgart
420
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Aufgabe 1 - Aufgabenstellung
Ein Steuergerät wird aus einem Mikrocontrollersystem und einem SpannungsVersorgungssystem aufgebaut.
Für die Ausfallraten der Teilsystem gilt:
𝛌µ𝐂 = 𝟖 ∙ 𝟏𝟎−𝟔 𝐡−𝟏
𝛌𝐒𝐕 = 𝟑 ∙ 𝟏𝟎−𝟓 𝐡−𝟏
A) Die Zuverlässigkeit des Gesamtsystems muss erhöht werden, daher sollen die
einzelnen Teilsysteme jeweils redundant ausgeführt werden. Ist es durch einfache
Redundanz möglich, eine Zuverlässigkeit von 75% bei einer Betriebszeit von 1,5
Jahren zu erreichen?
B) Wenn nein, wie ist dies durch Redundanz zu erreichen? Aus wirtschaftlichen
Gründen darf nur ein Teilsystem maximal aus 3 Komponenten ausgeführt werden.
C) Welche Verfügbarkeit weist das System für die höchstmögliche Zuverlässigkeit
auf, wenn eine Reparatur ca. 3 Tage in Anspruch nimmt?
© 2015 IAS, Universität Stuttgart
421
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Lösung Teil A (1/4)
µC1
Möglichkeit 1: Mikrocontroller redundant
SV
µC2
Für die einzelnen Komponenten gilt:
Parallelschaltung von µC1 und µC2:
Serienschaltung von SV und µC1/µC2:
© 2015 IAS, Universität Stuttgart
422
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Lösung Teil A (2/4)
µC1
Möglichkeit 1: Mikrocontroller redundant
SV
µC2
Für die gesamte Ausfallrate gilt:
Für die Zuverlässigkeit folgt:
© 2015 IAS, Universität Stuttgart
423
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Lösung Teil A (3/4)
SV1
Möglichkeit 2: Spannungsversorgung redundant
µC
SV2
Für die einzelnen Komponenten gilt:
Parallelschaltung von SV1 und SV2:
Serienschaltung von SV und µC1/µC2:
© 2015 IAS, Universität Stuttgart
424
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Lösung Teil A (4/4)
SV1
Möglichkeit 2: Spannungsversorgung redundant
µC
SV2
Für die gesamte Ausfallrate gilt:
Für die Zuverlässigkeit folgt:
© 2015 IAS, Universität Stuttgart
425
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Lösung Teil B (1/4)
Möglichkeit 3: Mehrfache Redundanz nach dem Schema:
µC1
Es gilt:
SV1
µC2
SV2
µC3
Parallelschaltung von SV1 und SV2:
Parallelschaltung von µC1/µC2/µC3:
© 2015 IAS, Universität Stuttgart
426
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Lösung Teil B (2/4)
µC1
SV1
µC2
SV2
Möglichkeit 3: Mehrfache Redundanz nach dem Schema:
µC3
Serienschaltung von SV1/SV2 und µC1/µC2/µC3:
Ausfallrate und Zuverlässigkeit:
© 2015 IAS, Universität Stuttgart
427
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Lösung Teil B (3/4)
Möglichkeit 4: Mehrfache Redundanz nach dem Schema:
SV1
Es gilt:
µC1
SV2
µC2
SV3
Parallelschaltung von SV1/SV2/SV3:
Parallelschaltung von µC1 und µC2 :
© 2015 IAS, Universität Stuttgart
428
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Lösung Teil B (4/4)
SV1
µC1
Möglichkeit 3: Mehrfache Redundanz nach dem Schema:
SV2
µC2
SV3
Serienschaltung von SV1/SV2/SV3 und µC1/µC2:
Ausfallrate und Zuverlässigkeit:
© 2015 IAS, Universität Stuttgart
429
Aufgabe 1 - Zuverlässigkeitsblockdiagramm
ZSA
Lösung Teil C
Für die Verfügbarkeit des Systems folgt:
• Berechnung der MTTR:
• Berechnung der Verfügbarkeit:
© 2015 IAS, Universität Stuttgart
430
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§7 Übungsaufgaben
Aufgabe 1 – Zuverlässigkeitsblockdiagramm
Aufgabe 2 – Fehlerbaumanalyse (FTA)
Aufgabe 3 – Softwarezuverlässigkeit
© 2015 IAS, Universität Stuttgart
431
Aufgabe 2 – Fehlerbaumanalyse (FTA)
ZSA
Aufgabe 2 - Aufgabenstellung
Ein System realisiert die Regelung des Kompressor-Drucks für eine
verfahrenstechnische Anlage. Um die geforderte Funktion zu erfüllen, benötigt
die Anlage einen Minimaldruck von 4 bar. Die Anlage soll 12 Jahre im Betrieb
sein.
Das Automatisierungssystem besteht aus einem Drucksensor, einer
Druckluftpumpe, der Spannungsversorgung für die Pumpe, einem Regelsystem
(Mikrocontrollersteuerung) und einer Spannungsversorgung für die
Mikrocontrollersteuerung. Ein zu hoher Kompressor-Druck soll in dieser
Betrachtung nicht berücksichtigt werden, dieser soll über ein Überdruckventil
verhindert werden.
Führen Sie für dieses System eine quantitative Fehlerbaumanalyse durch.
© 2015 IAS, Universität Stuttgart
432
Aufgabe 2 – Fehlerbaumanalyse (FTA)
ZSA
Aufgabe 2 - Kenngrößen
Die Ausfallraten sind wie folgt gegeben:
𝛌𝐏𝐮𝐦𝐩𝐞
= 𝟒 ∙ 𝟏𝟎−𝟗 𝐡−𝟏
𝛌𝐒𝐩𝐠.−𝐏𝐮𝐦𝐩𝐞 = 𝟐 ∙ 𝟏𝟎−𝟕 𝐡−𝟏
𝛌µ𝐂
= 𝟖 ∙ 𝟏𝟎−𝟖 𝐡−𝟏
𝛌𝐒𝐩𝐠.−µ𝐂
= 𝟐 ∙ 𝟏𝟎−𝟕 𝐡−𝟏
𝛌𝐒𝐞𝐧𝐬𝐨𝐫
= 𝟑 ∙ 𝟏𝟎−𝟗 𝐡−𝟏
Für die Betriebszeit gilt:
© 2015 IAS, Universität Stuttgart
433
Aufgabe 2 – Fehlerbaumanalyse (FTA)
ZSA
Lösung Schritt 1 – Erstellen des Fehlerbaums
Druck fällt unter 4 bar
Pumpe fällt aus bzw.
funktioniert nicht mehr
ODER
Spannungsversorgung
der Pumpe fällt aus
Regelsystem fällt aus
Pumpe ist defekt
ODER
Mikrocontroller fällt aus
© 2015 IAS, Universität Stuttgart
Spannungsversorgung
des µC fällt aus
Sensor fällt aus
434
Aufgabe 2 – Fehlerbaumanalyse (FTA)
ZSA
Lösung Schritt 2 – Unterbaum Zusammenfassen
Druck fällt unter 4 bar
Pumpe fällt aus bzw.
funktioniert nicht mehr
ODER
ODER-Verknüpfung wird nach
Spannungsversorgung
der Pumpe fällt aus
Regelsystem fällt aus
Pumpe ist defekt
Schema wie folgt zusammengefasst
ODER
(vgl. Kap 3.3):
Mikrocontroller fällt aus
© 2015 IAS, Universität Stuttgart
Spannungsversorgung
des µC fällt aus
Sensor fällt aus
435
Aufgabe 2 – Fehlerbaumanalyse (FTA)
ZSA
Lösung Schritt 3– Gesamtzuverlässigkeit berechnen
Druck fällt unter 4 bar
Pumpe fällt aus bzw.
funktioniert nicht mehr
ODER
ODER-Verknüpfung wird nach
Spannungsversorgung
der Pumpe fällt aus
Regelsystem fällt aus
Pumpe ist defekt
Schema wie folgt zusammengefasst
ODER
(vgl. Kap 3.3):
Mikrocontroller fällt aus
© 2015 IAS, Universität Stuttgart
Spannungsversorgung
des µC fällt aus
Sensor fällt aus
436
Zuverlässigkeit und Sicherheit von Automatisierungssystemen
ZSA
§7 Übungsaufgaben
Aufgabe 1 – Zuverlässigkeitsblockdiagramm
Aufgabe 2 – Fehlerbaumanalyse (FTA)
Aufgabe 3 – Softwarezuverlässigkeit
© 2015 IAS, Universität Stuttgart
437
Aufgabe 3 – Shooman-Modell
ZSA
Aufgabe 3 - Aufgabenstellung
Ein Software-Programm mit 5000 Anweisungen wurde 25 Tage getestet.
Durchschnittlich lief das Programm 6 Stunden pro Tag.
Es wurden dabei 20 Fehler gefunden und korrigiert.
Die Proportionalitätskonstante beträgt bei diesem Projekt 8 h-1.
Berechnen Sie die Fehlerrate und die Gesamtzahl der sich im Programm
befindlichen Fehler.
© 2015 IAS, Universität Stuttgart
438
Aufgabe 3 – Shooman-Modell
ZSA
Lösung (1/2)
Es gilt:
• Berechnung der Fehlerrate:
© 2015 IAS, Universität Stuttgart
439
Aufgabe 3 – Shooman-Modell
ZSA
Lösung (2/2)
Es gilt:
• Berechnung der Fehlerzahl:
© 2015 IAS, Universität Stuttgart
440
Appendix
ZSA
Literatur
[Göhn12a]
Göhner, Peter: Skript zur Vorlesung Automatisierungstechnik II, IAS, Stuttgart 2012.
[Göhn12b]
Göhner, Peter: Skript zur Vorlesung Softwaretechnik I, IAS, Stuttgart 2012.
[Göhn12c]
Göhner, Peter: Skript zur Vorlesung Softwaretechnik II, IAS, Stuttgart 2012.
[Jazd14]
Jazdi, Nasser: Skript zur Vorlesung Zuverlässigkeit und Sicherheit von Automatisierungssystemen,
IAS, Stuttgart, 2014.
[Bles11]
Blessing, Peter: Skript zur Vorlesung Sicherheit und Zuverlässigkeit, HSHN, Heilbronn, 2011.
[Bert10]
Bertsche, Bernd: Skript zur Vorlesung Zuverlässigkeitstechnik I und II, IMA, Stuttgart, 2010.
[BGJ+09]
Bertsche, Bernd; Göhner, Peter; Jensen, Uwe; Schinköthe, Wolfgang; Wunderlich, HansJoachim: Zuverlässigkeit mechatronischer Systeme, 1.Aufl., Berlin, Heidelberg, Springer-Verlag,
2009.
[MePa10]
Meyna, Arno; Pauli, Bernhard: Zuverlässigkeitstechnik – Quantitative Bewertungsverfahren, 2.Aufl.,
München, Wien, Hanser-Verlag, 2010.
[Balz08]
Balzert, Helmut: Lehrbuch der Softwaretechnik, 2.Aufl., Heidelberg, Spektrum Akademischer Verlag,
2008.
[BeHa09]
Benra, Juliane; Halang, Wolfgang: Software-Entwicklung für Echtzeitsysteme, 1.Aufl., Berlin,
Heidelberg, Springer-Verlag, 2009.
[Ligg09]
Liggesmeyer, Peter: Software Qualität -Testen, Analysieren und Verifizieren von Software, 2.Auflg.,
Heidelberg, Spektrum Akademischer Verlag, 2009
[Hala13]
Halang, Wolfgang: Funktionale Sicherheit – Echtzeit 2013, 1.Auflg., Berlin, Heidelberg, SpringerVerlag, 2013
© 2015 IAS, Universität Stuttgart
441
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement