Software in sicherheitsrelevanten Systemen
Ralf Pinger / Stefan Gerken
Sommersemester 2013
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 2
Kapitel 3 - Risiko- und Gefährdungsanalyse
Inhaltsübersicht
1. Was ist Risiko?2. Was ist Gefährdung?3. Gefährdungsraten4. Safety Integrity Level5. Failure Modes and Effects Analysis (FMEA)6. Fehlerbäume (Fault Trees)7. Markovketten
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 3
3.1 Was ist Risiko?
Risiko ist
Eine Funktion von Schadenshäufigkeit und Schadensausmaß, also als erwarteter Schaden (pro Zeiteinheit) (für eine bestimmte Grundgesamtheit)
Individuen
Individuelles Risiko ri
KollektivesRisiko
MittleresindividuellesRisiko
ZulässigesindividuellesRisiko
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 4
3.1 Was ist Risiko?
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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 5
3.1 Was ist Risiko? – Gesetzliche Randbedingungen
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.“
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 6
3.1 Was ist Risiko? – Beispiel Risikograph
W 3 W 2 W 1
C a
C b
C c
C d
F a
F b
F a F b
P a
P b
P a
P a
P a
P b
P b
P b
X 1
X 2
X 3
X 4
X 5
X 6
a
1
2
3
4
b
a
a 1
1 2
2 3
3 4
F b
F a
Consequence Ca Minor Injury Cb Serious Injury, Single Death Cc Several Deaths Cd Many Deaths
Frequency & Exposure Fa Rare to Frequent Fb Frequent to Continuous
Possibility of Avoidance Pa Sometimes Possible Pb Almost Impossible
Probability of Occurrence W1 Very Slight W2 Slight W3 Relatively High
a = No special safety requirements b = Single safe system not sufficient Safety Integrity Levels
Risikograph nach IEC 61508-5
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 7
3.2 Was ist Gefährdung?
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. [....]”
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 8
3.2 Was ist Gefährdung?
Gefährdung, Ursache, Unfall ...
Ursachen Folgen
Subsystemgrenze Systemgrenze
Unfall i
Unfall k
SystemebeneSubsystemebene
Ursache
Ursache
Gefährdung
Gefährdung Ursache
Betrieb
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 9
3.3 Gefährdungsraten
Gefährdungsrate H(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 t in einen Zustand k wechselt, und
dem Zeitraum t (für t->0) in der Einheit h-1.Also: Rate [h-1] x Zeiteinheit [h] = Wahrscheinlichkeit
Ausfall- bzw. Reparaturrate bzw.: 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.
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 10
3.3 Gefährdungsraten
Typischer Verlauf einer Gefährdungsrate für sicherungstechnische Systeme: Die Gefährdungsrate schwingt sich ein, deshalb spricht man vereinfachend von H
Als Faustregel kann man H1/MTTH, MTTH ist aber (mathematisch) wesentlich aufwendiger zu bestimmen
0 2000 4000 6000 8000 10000
2.5 10 -10
5. 10 -10
7.5 10 -10
1. 10 -9
1.25 10 -9
1.5 10 -9
1.75 10 -9
2. 10 -9
U
U(t)
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 11
3.3 Gefährdungsraten – Beispiel Risikomatrix
Risikomatrix
Gefährdungsrate(pro System pro Stunde)
Risikoklassifikation
häufig 10-4-10-5 unzulässig unzulässig unzulässig unzulässig
wahrscheinlich 10-5-10-6 unzulässig unzulässig unzulässig Grenzrisiko
gelegentlich 10-6-10-7 unzulässig unzulässig Grenzrisiko zulässig
kaum vorstellbar 10-7-10-8 unzulässig Grenzrisiko zulässig zulässig
unwahrscheinlich 10-8-10-9 Grenzrisiko zulässig zulässig zulässig
unglaublich 10-9-10-10 zulässig zulässig zulässig zulässig
katastrophal kritisch marginal unbedeutend
Schadensausmaß
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 12
3.4 Safety Integrity Level
• Geeignete Balance zwischen Maßnahmen zur Fehlervermeidung und -beherrschung
• Bewusste Planung der Produkteigenschaft “Sicherheit”
• Risikoabwägung
Für beide Kategorien müssen Anforderungen gestellt werden
Quantifizierbar („Ausfallraten“)
Versagen der Signal-
technik
ODER
systemati-sche Fehler
Ausfälle u. Störungen
Nicht quantifizierbar, daher qualitative Stufung (SILs)
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 13
3.4 Safety Integrity Level
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)
SAFETY INTEGRITY
LEVEL Tolerable Hazard Rate
THR per hour and per function
4 10-9<THR 10-8 3 10-8 < THR 10-7 2 10-7 < THR 10-6 1 10-6 < THR 10-5
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 14
3.5 Failure Modes and Effects Analysis (FMEA)
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 Failure Mode Local System
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 15
3.5 Failure Modes and Effects Analysis (FMEA)
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...
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 16
3.6 Fehlerbäume (Fault Trees)
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 inder IEC 61025.
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 17
3.6 Fehlerbäume (Fault Trees) – Common Cause Failures
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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 18
3.7 Markovketten
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
Software in sicherheitsrelevanten SystemenSommersemester 2013
Model basedDevelopment
Model basedTesting
Modeltrans-formation
Applicationmodel Test model
Code (executable)
Modeltrans-formation
Testcases (executable)
Analysis
Model based Software Engineering
24.04.23 Ralf Pinger / Stefan GerkenPage 19
3.7 Markovketten
Grenzen: Nur anwendbar bei konstanten Übergangsraten (meistens gültig für
elektronische Einzelkomponenten)