Software in sicherheitsrelevanten Systemen

Slides:



Advertisements
Ähnliche Präsentationen
Integrations- und Funktionstests im Rahmen des V-Modelles
Advertisements

Phasen und ihre Workflows
Stochastik und Markovketten
Vorlesung Programmieren II
Software in sicherheitsrelevanten Systemen
Frame-Logik Eine Einführung Andreas Glausch.
Qualitätssicherung von Software (SWQS)
Wilhelm-Raabe-Schule Fachbereich: Mathematik Thema: Lineare Funktionen
Gesetzliche Bestimmungen zu
Mörgeli + mörgeli consulting engineering m+m/am, AA ESI, Erweitertes Management Summary, (Version 3, – Datenschutz für Publikation)
Software in sicherheitsrelevanten Systemen
Projektumfeld Gesellschaftliche Strömungen Strukturen/ Gliederung
Kapitel 7 State-Machines/Zustandsautomaten
Algorithmen und Komplexität
FMEA Fehler-Möglichkeits- und Einfluß-Analyse Design- und Prozeß-FMEA
Systemanalyse In der Systemanalyse wird aus den fachspezifischen Anforderungen das Systemmodell erstellt; im Systemmodell ist spezifiziert, was das System.
Qualitätssicherung von Software
Prof. Dr. Holger Schlingloff
Qualitätssicherung von Software Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FIRST.
Risikoanalyse in der Kerntechnik
Sortierverfahren Richard Göbel.
Dynamische Programmierung (2) Matrixkettenprodukt
1 Vorlesung Informatik 2 Algorithmen und Datenstrukturen (02 – Funktionenklassen) Prof. Dr. Th. Ottmann.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (19 - Analyse natürlicher Bäume) Prof. Th. Ottmann.
Vorlesung Informatik 2 Algorithmen und Datenstrukturen (02 – Funktionenklassen) Tobias Lauer.
WS Algorithmentheorie 08 – Dynamische Programmierung (2) Matrixkettenprodukt Prof. Dr. Th. Ottmann.
Kapitel 5 Stetigkeit.
Vorlesung Regelungstechnik 2
WAS WILL WISSENSCHAFT? - Sagen: Was WIE ist
Technische Informatik I
Ausbilderinfos © Verlag Heinrich Vogel, München - Juni 2003 Allgemeines zur Schutzausrüstung: Die Schutzausrüstung soll bei Unfällen und Zwischenfällen.
Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2013.
Konzeption und Realisierung von DSS
04 b Ressourcenschichtplan. © beas group 2011 / Page 2 This documentation and training is provided to you by beas group AG. The documents are neither.
Variationsformalismus für das freie Teilchen
Spezifikation von Anforderungen
Software Engineering SS 2009
Beweissysteme Hartmut Klauck Universität Frankfurt WS 06/
Effiziente Algorithmen
Hartmut Klauck Universität Frankfurt SS
Information und Kommunikation Hartmut Klauck Universität Frankfurt SS
Information und Kommunikation Hartmut Klauck Universität Frankfurt SS
UML-Kurzüberblick Peter Brusten.
Wahrscheinlichkeitsrechnung
IKP Uni Bonn Medienpraxis EDV II Internet-Projekt
BBS-Schulung 2014: Harmonisierte Regelungen und Formulare
Das Kausalnetz als Kern eines DSS
deterministisches chaos
Zertifizierung Mario Grotschar 23. Mai 2007.
Arbeitserlaubnisschein (PTW)
Seminar Wien Einführung.
BBS-Schulung 2014: Harmonisierte Regelungen und Formulare
Swiss Nano-Cube Lerchenfeldstrasse 5, 9014 St.Gallen Tel. +41 (0) , Bildungsplattform zur Mikro-
deterministisches chaos
Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2014.
Software Engineering Strukturierte Analyse
Institut für Softwarewissenschaft – Universität WienP.Brezany 1 Beispiele (Frist: ) Beispiel 1: Sei  = {a, b} ein Alphabet und Q = {q 0, q 1 } eine.
Projektmanagement und Softwarequalität
 Gegenstandsbereich der Testtheorie: Analyse der Charakteristika von Tests:  Güte von Tests.  Struktur von Tests.  Schwierigkeit von Tests.  Gruppenunterschiede.
Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2016.
The International Patent System Änderungen der Ausführungsordnung mit Wirkung ab 1. Juli 2016.
Software in sicherheitsrelevanten Systemen
Eldar Dedic HA061 bbw - Hochschule
Software in sicherheitsrelevanten Systemen
Software in sicherheitsrelevanten Systemen
Fehlermöglichkeits- und Einflussanalyse (FMEA)
Software in sicherheitsrelevanten Systemen
Software in sicherheitsrelevanten Systemen
Software in sicherheitsrelevanten Systemen
 Präsentation transkript:

Software in sicherheitsrelevanten Systemen Ralf Pinger / Stefan Gerken Sommersemester 2014

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

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

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:1 000 000 pro Fahrtstunde (bei 250 Fahrstunden und 10000 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) 10.04.2017 Ralf Pinger / Stefan Gerken

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

3.1 Was ist Risiko? – Beispiel Risikograph Risikograph nach IEC 61508-5 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 10.04.2017 Ralf Pinger / Stefan Gerken

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

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

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

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

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

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

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

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

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

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

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

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

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