Transcript 3.1 Was ist Risiko?

Software in
sicherheitsrelevanten Systemen
Ralf Pinger / Stefan Gerken
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
Kapitel 3 - Risiko- und Gefährdungsanalyse
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Inhaltsübersicht
1.
2.
3.
4.
5.
6.
7.
Was ist Risiko?
Was ist Gefährdung?
Gefährdungsraten
Safety Integrity Level
Failure Modes and Effects Analysis (FMEA)
Fehlerbäume (Fault Trees)
Markovketten
Page 2
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.1 Was ist Risiko?
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Risiko ist
Eine Funktion von Schadenshäufigkeit und Schadensausmaß, also als
erwarteter Schaden (pro Zeiteinheit) (für eine bestimmte Grundgesamtheit)
Individuelles Risiko ri
Zulässiges
individuelles
Risiko
Mittleres
individuelles
Risiko
Kollektives
Risiko
Individuen
Page 3
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.1 Was ist Risiko?
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Unterschiedliche Arten von Risiko:
Individuelles Risiko Bezieht sich auf einzelne Personen
Kollektives Risiko
Bezieht sich auf Personengruppen bzw. die Gesellschaft
Risiko-Aversion
erhöhte Gewichtung von Großschäden
Grenzrisiko
größtes noch vertretbares Risiko
Restrisiko
verbleibendes Risiko nach Realisierung der
Sicherheitsmaßnahmen, besteht aus bewusst akzeptierten,
falsch beurteilten sowie nicht erkannten Risiken
Page 4
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
3.1 Was ist Risiko? – Gesetzliche Randbedingungen
Test model
Analysis
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
EN 292-1 (Sicherheit von Maschinen)
„Eine Maschine ... soll sicher sein. Jedoch ist absolute Sicherheit kein
komplett erreichbarer Zustand ...“
EBO §2 (1)
„ Bahnanlagen und Fahrzeuge müssen so beschaffen sein, dass sie den
Anforderungen der Sicherheit und Ordnung genügen. Diese
Anforderungen gelten als erfüllt, wenn die Bahnanlagen und Fahrzeuge
den Vorschriften dieser Verordnung und, soweit diese keine
ausdrücklichen Vorschriften enthält, anerkannten Regeln der Technik
entsprechen.“
Page 5
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.1 Was ist Risiko? – Beispiel Risikograph
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Risikograph nach IEC 61508-5
W3
Ca
X1
Pa
Fa
Cb
Fb
Cc
Cd
Fa
Fb
Fa
X2
W2
a
1
a
X4
Pb
X6
X3
X5
a = No special safety requirements
b = Single safe system not sufficient
13.04.2015
Ca
Minor Injury
Cb
Serious Injury, Single Death
Cc
Several Deaths
Cd
Many Deaths
Frequency & Exposure
Pb
Pa
Pb
Pa
Pb
Pa
2
1
a
Fa
Rare to Frequent
Fb
Frequent to Continuous
Possibility of Avoidance
3
4
2
3
1
b
4
Pa
Sometimes Possible
Pb
Almost Impossible
2
Fb
Page 6
Consequence
W1
3
Probability of Occurrence
W1
Very Slight
W2
Slight
W3
Relatively High
Safety Integrity Levels
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.2 Was ist Gefährdung?
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Gefährdung (englisch: Hazard)
EN 50129:
Hazard: A condition that could lead to an accident.
Leveson: Safeware
A hazard is a state or set of conditions of a system (or an object) that,
together with other conditions in the environment of the system (or object),
will lead inevitably to an accident (loss event). [....] A hazard is defined with
respect to the environment of the system or component. [....] What constitutes
a hazard depends upon where the boundaries of the system are drawn. [....]”
Page 7
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.2 Was ist Gefährdung?
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Gefährdung, Ursache, Unfall ...
Subsystemebene
Systemebene
Betrieb
Gefährdung
Ursache
Ursache
Unfall k
Gefährdung
Ursache
Unfall i
Subsystemgrenze
Systemgrenze
Ursachen
Page 8
13.04.2015
Folgen
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.3 Gefährdungsraten
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Gefährdungsrate lH(t): Rate für den Übergang eines System, das zum
Zeitpunkt t in einem nicht gefährlichem Zustand ist, in einen gefährlichen
Zustand
Rate ri,k (t): Grenzwert des Verhältnisses zwischen
 der Wahrscheinlichkeit, dass ein System, das zum Zeitpunkt t in einem
definierten Zustand i ist, innerhalb eines Zeitraums Dt in einen Zustand k
wechselt, und
 dem Zeitraum Dt (für Dt->0) in der Einheit h-1.
Also: Rate [h-1] x Zeiteinheit [h] = Wahrscheinlichkeit
Ausfall- bzw. Reparaturrate l bzw. m : Rate für den Übergang eines System,
das zum Zeitpunkt t nicht ausgefallen bzw. ausgefallen ist, in einen Zustand,
in dem es ausgefallen bzw. wieder betriebsfähig ist. Bei HW-Komponenten
wird im Allgemeinen eine konstante Ausfallrate angenommen.
Page 9
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.3 Gefährdungsraten
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
 Typischer Verlauf einer Gefährdungsrate für sicherungstechnische
Systeme: Die Gefährdungsrate schwingt sich ein, deshalb spricht man
vereinfachend von lH.
-9
2. 10
-9
1.75 10
lU
-9
1.5 10
-9
1.25 10
lU(t)
-9
1. 10
-10
7.5 10
-10
5. 10
-10
2.5 10
0
2000
4000
6000
8000
10000
 Als Faustregel kann man lH~1/MTTH, MTTH ist aber (mathematisch)
wesentlich aufwendiger zu bestimmen
Page 10
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.3 Gefährdungsraten – Beispiel Risikomatrix
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Risikomatrix
Risikoklassifikation
Gefährdungsrate
(pro System pro Stunde)
häufig
10 -10
-4
-5
unzulässig
unzulässig
unzulässig
unzulässig
wahrscheinlich
10 -10
-5
-6
unzulässig
unzulässig
unzulässig
Grenzrisiko
gelegentlich
10 -10
-6
-7
unzulässig
unzulässig
Grenzrisiko
zulässig
kaum vorstellbar
10 -10
-7
-8
unzulässig
Grenzrisiko
zulässig
zulässig
unwahrscheinlich
10 -10
-8
-9
Grenzrisiko
zulässig
zulässig
zulässig
unglaublich
10 -10
-9
-10
zulässig
zulässig
zulässig
zulässig
katastrophal
kritisch
marginal
unbedeutend
Schadensausmaß
Page 11
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.4 Safety Integrity Level
Modeltransformation
Code
(executable)
Testcases
(executable)
• Geeignete Balance zwischen
Maßnahmen zur
Fehlervermeidung und beherrschung
Versagen
der Signaltechnik
• Bewusste Planung der
Produkteigenschaft “Sicherheit”
• Risikoabwägung
ODER
systematische Fehler
Modeltransformation
Ausfälle u.
Störungen
 Für beide Kategorien müssen
Anforderungen gestellt werden
Nicht quantifizierbar,
daher qualitative
Stufung (SILs)
Page 12
13.04.2015
Quantifizierbar
(„Ausfallraten“)
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.4 Safety Integrity Level
Modeltransformation
Code
(executable)
SAFETY INTEGRITY
LEVEL
4
3
2
1
Modeltransformation
Testcases
(executable)
Tolerable Hazard Rate
THR per
hour and per function
-9
-8
10 <THR  10
-8
-7
10 < THR  10
10-7 < THR  10-6
-6
-5
10 < THR  10
 Balance mittels sogenannter SIL-Tabellen
 Vorgehensweise wird in EN 50129 beschrieben
 Hinter den Tabellen stecken Heuristiken, keine wissenschaftlichen
Begründungen
 Fast jeder Sicherheitsstandard weltweit verwendet SILs (offensichtlich zur
Zeit State-of-the-art)
Page 13
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.5 Failure Modes and Effects Analysis (FMEA)
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
FMEA - Was wäre, wenn etwas versagt?
Die funktionale FMEA (FFA) bezieht sich auf eine (System-)Funktion. Als Richtschnur
kann man folgende prinzipielle Versagensarten betrachten:
 totaler Ausfall (Funktion wird überhaupt nicht erbracht)
 Versagen der Schnittstelle (falsche Eingabe, ...)
 Funktion wird erbracht, wenn nicht gefordert
 fehlerhafte Ausführung der Funktion (zu spät, nicht vollständig, ...)
Effect
Component
Page 14
13.04.2015
Failure Mode
Local
Ralf Pinger / Stefan Gerken
System
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.5 Failure Modes and Effects Analysis (FMEA)
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Die Ergebnisse einer FFA (Functional Failure Analysis) werden in einer Tabelle
protokolliert, die (mindestens) die folgenden Kategorien enthält:
 Referenz: Eindeutige Referenz auf die Funktionsbeschreibung (z. B. eine
Nummer), um die Rückverfolgbarkeit zu gewährleisten
 Funktion: Benennung der Funktion
 Ausfallart: Beschreibung der Art des Funktionsversagens
 Effekt: Was resultiert aus dem Funktionsversagen?
 Wirkung/Gefährdung: Welche Gefährdung entsteht? Entsteht eine Gefährdung
unmittelbar/mittelbar?
 Bemerkung: Platz für Kommentare, Rechtfertigung, Anmerkungen ....
Weitere (optionale) Einträge können sein:
 Häufigkeit: (geschätzte) Häufigkeit des Auftretens des Funktionsversagens
 Schwere: (geschätztes) Ausmaß des resultierenden Unfalls...
Page 15
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.6 Fehlerbäume (Fault Trees)
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Der Fehlerbaum
 stellt Ereigniskombinationen in Boolescher Logik dar,
 die zum Top-Ereignis führen und
 verwendet im Wesentlichen UND- und ODER-Verknüpfungen
Eine Fehlerbaumanalyse
 wird eingeordnet als deduktive Methode
 hat die systematische Analyse aller möglichen Ursachen eines bestimmten
unerwünschten Ereignisses (Top-Ereignis) als Ziel
 erfolgt Top-down rückwärts vom Top-Ereignis zu den Ursachen
Jedes Ereignis im Baum, für das keine weiteren Ursachen ermittelt werden
(können), stellt ein so genanntes Basisereignis dar.
Die normativen Grundlagen sowie einfache Rechenregeln finden sich in
der IEC 61025.
Page 16
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
3.6 Fehlerbäume (Fault Trees) – Common Cause
Failures
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Grenzen:
 ist nur bei Wahrscheinlichkeiten exakt
 bei der Berechnungen von Eintrittsraten liefert das Verfahren nur
Näherungswerte
 UND-verknüpfte Ereignisse müssen unabhängig voneinander sein,
ansonsten sind zusätzlich ODER-Verknüpfungen erforderlich
 Keine zeitliche Abfolge modellierbar
Page 17
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.7 Markovketten
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)

Markovketten sind Zustandsübergangsdiagramme, mit deren Hilfe zeitliche
Verläufe von Zustandsvariablen mit Aufenthaltswahrscheinlichkeiten und
Übergangsraten ermittelt werden können

Hierzu müssen zuerst die verschiedenen möglichen Zustände eines Systems
festgelegt werden (Normalbetrieb, gefährliche oder ungefährliche
Ausfallzustände)

Danach werden die möglichen Übergänge zwischen den Systemzuständen
bestimmt mitsamt der Übergangsraten in Richtung der gefährlichen bzw.
ungefährlichen Zustände

Aus dem Markovmodell kann unmittelbar ein lineares
Differenzialgleichungssystem abgeleitet werden
Page 18
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013
Model based
Software Engineering
Model based
Development
Model based
Testing
Application
model
Test model
Analysis
3.7 Markovketten
Modeltransformation
Code
(executable)
Modeltransformation
Testcases
(executable)
Grenzen:
 Nur anwendbar bei konstanten Übergangsraten (meistens gültig für
elektronische Einzelkomponenten)
Page 19
13.04.2015
Ralf Pinger / Stefan Gerken
Software in sicherheitsrelevanten Systemen
Sommersemester 2013