Software in sicherheitsrelevanten Systemen

Präsentation zum Thema: "Software in sicherheitsrelevanten Systemen"—  Präsentation transkript:

1 Software in sicherheitsrelevanten Systemen
Ralf Pinger / Stefan Gerken Sommersemester 2014

2 Kapitel 3 - Risiko- und Gefährdungsanalyse
Inhaltsübersicht Was ist Risiko? Was ist Gefährdung? Gefährdungsraten Safety Integrity Level Failure Modes and Effects Analysis (FMEA) Fehlerbäume (Fault Trees) Markovketten Ralf Pinger / Stefan Gerken

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) Ralf Pinger / Stefan Gerken

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 Beispiel: Todesfallrisiko eines 22-jährigen Pkw-Fahrers 2.5x10-4 pro Jahr 1:4000 pro Jahr 1: pro Fahrtstunde (bei 250 Fahrstunden und km Fahrstrecke) 0.5% während des Lebens (40 Jahre Lenktätigkeit, Korrekturfaktor 2 für Abnahme des Risikos im Alter) 2.5x10-8 pro Fahrkilometer mittlere Verkürzung der Lebenserwartung um 77 Tage Erhöhung des Todesfallrisikos um 20% Erhöhung des Todesfallrisikos von 1:750 auf 1:620 pro Jahr  Klare Festlegung der Einheiten und Randbedingungen notwendig!  Wahrscheinlichkeitstheoretische Aussagen! Individuelle Risikoakzeptanz: Ein Beispiel: Kategorie 1: Das Risiko ist freiwilliger Natur mit einem hohen Selbstbestimmungsgrad (z. B. Bergsteigen) Kategorie 2: Das Risiko ist in starkem Maße selbst beeinflussbar (z. B. Individualverkehr) Kategorie 3: Das Risiko ist nur beschränkt vermeidbar und beeinflussbar (z. B. Zugunfall). Kategorie 4: Das Risiko besitzt einen hohen Fremdbestimmungsgrad und wird quasi unfreiwillig eingegangen (z. B. Unfall in chem. Fabrik) Ralf Pinger / Stefan Gerken

5 3.1 Was ist Risiko? – Gesetzliche Randbedingungen
EN (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.“ Der Gesetzgeber überlässt es in der Regel technischen Normen, genauere Festlegungen zu treffen. Es findet so gut wie keine explizite Diskussion über Risikogrenzwerte statt. Pragmatisch geht man häufig davon aus, dass die Gesellschaft die aktuellen Risiken akzeptiert (quasi plebiszitär), wenn es keine Diskussion gibt. Ralf Pinger / Stefan Gerken

6 3.1 Was ist Risiko? – Beispiel Risikograph
Risikograph nach IEC Ursprünglich aus DIN V 19250, dann übernommen von IEC Probleme: Restrisiko wird nicht explizit ausgewiesen Was wird betrachtet: eine Funktion, ein Zug, ein Passagier ...? Die Kategorien sind subjektiv definiert, daher Ergebnisse auch subjektiv Anpassung an CENELEC gescheitert, da Restrisiko nicht einfach ausweisbar Risikograph nicht einheitlich, evtl.. Braucht jeder Anwendungsbereich einen eigenen Graphen Ralf Pinger / Stefan Gerken

7 Gefährdung (englisch: Hazard)
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. [....]” EN: Unspezifisch – Alles ist eine Gefährdung Ralf Pinger / Stefan Gerken

8 3.2 Was ist Gefährdung? Gefährdung, Ursache, Unfall ...
Dies ist eine über die Forderungen von CENELEC hinausgehende Interpretation. Sie soll folgendes erreichen: Mehr Klarheit Strukturierung und Verringerung der Komplexität (weniger Gefährdungen pro System) Man kann jetzt zu jedem Hazard den „Eigentümer“ identifizieren, nämlich den Sicherheitsverantwortlichen des zugehörigen Systems. Dieser trägt die Verantwortung, die er für Ursachen=Gefährdungen an der Subsystemgrenze dem Sicherheitsverantwortlichen des Subsystems übertragen kann. Beispiel: Mehrere hundert Gefährdungen sind ohne Strukturierung durchaus keine Seltenheit (Railtrack). Ralf Pinger / Stefan Gerken

9 3.3 Gefährdungsraten 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. Wahrscheinlichkeiten sind zwar dimensionslos, es muss jedoch unmissverständlich definiert werden, worauf sie sich beziehen (System, Einheiten ...). Ralf Pinger / Stefan Gerken

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 lH. Wahrscheinlichkeiten sind zwar dimensionslos, es muss jedoch unmissverständlich definiert werden, worauf sie sich beziehen (System, Einheiten ...). e-Funktion da es sich um Halbleitertechnik handelt, die typischerweise diese Charakteristik aufweisen. X-Achse: Stunden Y-Achse: Raten Als Faustregel kann man lH~1/MTTH, MTTH ist aber (mathematisch) wesentlich aufwendiger zu bestimmen Ralf Pinger / Stefan Gerken

11 3.3 Gefährdungsraten – Beispiel Risikomatrix
Tabelle muss anwendungsspezifisch kalibriert (wie?) und abgestimmt werden Parameter: Grenzrisiko, Anzahl Betrachtungseinheiten (Personen, Züge), Anzahl Gefährdungen, externe Faktoren Vorsicht: Häufig wird Wahrscheinlichkeit statt Gefährdungsrate als Parameter benutzt. Auf was bezieht sich die Wahrscheinlichkeit (eine Stunde, ein Jahr,...)? Ralf Pinger / Stefan Gerken

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 Ralf Pinger / Stefan Gerken

13 3.4 Safety Integrity Level
Balance mittels sogenannter SIL-Tabellen Vorgehensweise wird in EN beschrieben Hinter den Tabellen stecken Heuristiken, keine wissenschaftlichen Begründungen Fast jeder Sicherheitsstandard weltweit verwendet SILs (offensichtlich zur Zeit State-of-the-art) Annahme. System mit 10^8 Sicherheitsfunktionen, jede Sicherheitsfunktion erfüllt SIL 4 => bei 10 Stunden Betrieb ist die Wahrscheinlichkeit für den Ausfall einer dieser Sicherheitsfunktionen = 1. Ein GAU bei einem Atomkraftwerk wird alle 4000 Jahre erwartet. Bei 100 Atomkraftwerken in Betrieb, passiert ein GAU alle 40 Jahre. Offenbar ist dies das akzeptierte Risiko dieser Technologie. Ralf Pinger / Stefan Gerken

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, ...) Ralf Pinger / Stefan Gerken

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... Eine FMEA-Tabelle ist auch immer ein wenig individuell, da sie die Erfahrung des Erstellers, aber auch die Erfordernisse des speziellen Systems und dessen Architektur widerspiegelt. Ralf Pinger / Stefan Gerken

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 in der IEC Ralf Pinger / Stefan Gerken

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 Common Cause Failures müssen betrachtet werden, damit die korrekten Werte herauskommen Ralf Pinger / Stefan Gerken

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 Ralf Pinger / Stefan Gerken

19 3.7 Markovketten Grenzen:
Nur anwendbar bei konstanten Übergangsraten (meistens gültig für elektronische Einzelkomponenten) 0: normaler zweikanaliger Betrieb 1: einkanaliger Betrieb 2: System ausgefallen Ralf Pinger / Stefan Gerken