Evaluation und Entwicklung von Bewertungsmodellen für die funktionale Sicherheit von elektronischen/elektrischen Systemen

Inhaltsverzeichnis

Einfuhrung

1 Grundlagen
1.1 Argumentation der Sicherheit von Software
1.2 Sicherheitsnormen
1.2.1 Entwicklung der Norm IEC 61508
1.2.2 ISO-Norm 26262
1.2.3 Norm DO-178B
1.3 Beschreibung der Ansatze im Umfeld der funktionalen Sicherheit
1.3.1 FMEA - Fehlermoglichkeiten- und Einflussanalyse
1.3.2 FMECA - Fehler-Moglichkeits- und kritische Einfluss-Analyse
1.3.3 FTA - Fehlerbaumanalyse
1.3.4 ETA - Ereignisbaumanalyse
1.4 Grundlegende Methodiken
1.4.1 BBN
1.4.2 GSN
1.5 Begriffsdefinitionen

2 Evaluation von Bewertungsmodellen
2.1 Definition der Bewertungskriterien
2.2 Bewertung der Ansatze
2.2.1 Bewertung des SERENE Modells
2.2.2 Bewertung des Modells von Gran
2.2.3 Bewertung des Modells von Brito und May
2.2.4 Bewertung des Modells von Kelly
2.2.5 Bewertung des Modells von Weaver
2.3 Zusammenfassende Darstellung der Modelle

3 Best Practices
3.1 Ausfuhrung der Best Practices
3.1.1 Struktur und Eigenschaften
3.1.2 Befullen der Wahrscheinlichkeitstabellen
3.1.3 Zielabhangige und zielunabhangige Modellierung
3.1.4 Definierte Vorgehensweise bei der Modellerstellung
3.1.5 Modularer Aufbau eines Netzes
3.2 Diskussion der Best Practices

4 Resumee
4.1 Zusammenfassung
4.2 Ausblick

Abbildungsverzeichnis

1 Badewannenkurve

2 Qualitat im Produktlebenszyklus (in Anlehnung an [IEC01])

3 Prinzip der Risikominderung (in Anlehnung an [DIN])

4 Normungsrahmen (in Anlehnung an [GKS+99])

5 Mit IEC 61508 verwandte Standards

6 Klassifizierung der Ansatze

7 Konvergierende Verbindungen

8 Divergierende Verbindungen

9 Parallele Verbindungen

10 A-priori Wahrscheinlichkeiten

11 Harte Evidenz: „Regen - Ja“

12 Harte Evidenzen: „Kein Regen“ und „Wasserrohrbruch - Ja“

13 Harte Evidenz: „Strafie ist nass - Nein“

14 Beziehung zwischen Prozess, Produkt und Ressourcen (in Anlehnung an [ML99])

15 Instantiierter Definitions/Syntese Baustein

16 Instantiierter Prozess-Produkt Baustein

17 Instantiierter Baustein zur Messung

18 Instantiierter Baustein zur Induktion

19 Instantiierter Baustein zum Abgleich

20 Ablaufplan fur die Auswahl des Bausteins (in Anlehnung an [ML99])

21 Primares Netz (in Anlehnung an [Gra02b])

22 Sekundares Netz (in Anlehnung an [Gra02b])

23 Generisches BBN Netz fur eine Phase (in Anlehnung an [BM06])

24 Generisches BBN Netz fur alle Phasen (in Anlehnung an [BM06])

25 Beziehung zwischen GSN- und Sicherheitsnachweiselementen (in Anleh­nung an [BM06])

26 Pattern „Fault Tree Analysis“ (in Anlehnung an [BM06])

27 Vorgehensweise bei der Konstruktion eines GSN Modells (in Anlehnung an

[Kel98])

28 Konzeptionelles Rahmenwerk (in Anlehnung an [Wea04])

29 Architektur des Pattern-Kataloges (in Anlehnung an [Wea04])

30 Pattern „Hazardous Software Failure Mode Decomposition44 (in Anlehnung an [Wea04])

31 Ausschnitt aus BBN

32 Ausschnitt aus BBN mit konvergierenden Verbindungen

33 Ausschnitt aus BBN mit divergierenden Verbindungen

34 Ausschnitt aus BBN

35 Effektivitat mit der die Methode angewendet wurde

Tabellenverzeichnis

1 Elemente der GSN - Goal Structuring Notation (in Anlehnung an [Fen06])

2 Multiplizitat (in Anlehnung an [Kel98])

3 Optionalitat (in Anlehnung an [Kel98])

4 Zusammenfassende Darstellung der Modellevaluation

5 Wahrscheinlichkeitstabelle

6 Wahrscheinlichkeitstabelle fur den Knoten mit konvergierenden Verbindun gen

7 Wahrscheinlichkeitstabelle fur den Knoten „Qualitat des Liferanten“

Einfuhrung

Obwohl sich Softwarefehler auch schon fur die Zeit zuvor nachweisen lassen, wird der erste bedeutende Softwarefehler oftmals auf das Jahr 1968 datiert: Im Rahmen der Mis­sion Apollo 8 der US-amerikanischen Weltraumbehorde NASA brachen die Astronauten Frank Borman, William Anders und James Lovell auf, den Mond zehnmal zu umrunden. Wahrend des Flugs fuhrte ein Softwarefehler zur teilweisen Loschung des Computerspei- chers. Obgleich dieser Softwarefehler keine sicherheitsrelevanten Folgen hatte, lautete er ein Zeitalter ein, in dem die Zuverlassigkeit und Sicherheit von Software stetig an Bedeu- tung gewinnt.

Neben diesen blofien Fakten ist es fur das Verstandnis der Bedeutung dieses Softwarefeh- lers wichtig, den politisch-gesellschaftlichen Hintergrund, vor dem diese Mission durchge- fuhrt wurde, einer eingehenden Betrachtung zu unterziehen:

Hatten der Sputnikschock, der Start des ersten kunstlichen Erdsatelliten am 4. Oktober 1957, und der Weltraumaufenthalt des Kosmonauten Juri Gagarin am 12. April 1961 die gesamte westliche Welt geschockt und die vermeintliche technologische Uberlegenheit der Sowjetunion aufgezeigt, so musste von Seiten der Vereinigten Staaten von Amerika eine Reaktion erfolgen. Beschrankte sich diese zunachst auf die Reformierung des Bil- dungswesens und die Grundung der Weltraumbehorde NASA, so war es Prasident John F. Kennedy personlich, der die Initialzundung fur den Wettlauf ins All gab: Er war es, der 1961 bekannt gab, bis Ende des Jahrzehnts einen Menschen zum Mond schicken zu wollen.

Vor diesem Hintergrund werden Bedeutung und Wichtigkeit der Mondmissionen Apollo 8 und 9 deutlich, weshalb sich jedoch die folgende Frage aufdrangt: Wie konnte es selbst bei diesem Projekt nationaler Bedeutung und der entsprechend detaillierten Planung sowie dem hohen finanziellen sowie personellen Aufwand zu einem unerkannten Fehler in der Software kommen?

Oder weitergehend: Welche Bedeutung hat dies in einer Welt, in der die Anzahl der taglich genutzten Softwaresysteme so hoch ist, dass sie von den meisten Menschen nicht erfasst werden kann? Welche Bedeutung hat das Softwaresystem als potenzielle Fehlerquelle und somit die Sicherheit von Software in einer Welt, in der Software fester Bestandteil jedes Lebensbereichs ist?

Wie die folgenden Beispiele zeigen, sind Softwarefehler fur die unterschiedlichsten Bereiche dokumentiert:

- Anfang der 80er Jahre fuhrt ein Softwarefehler in Sibirien zur Explosion einer Gas- pipeline. Es wird spekuliert, dass der Fehler durch den US-amerikanischen Geheim- dienst CIA gezielt in der Software platziert wurde, die sich die UDSSR illegal an- eignete.
- Ein Softwarefehler fuhrt 1990 bei der Firma American Telephone & Telegraph Cor­poration zu einem Netzausfall, so dass von 60000 Telefonanschlussen aus fur mehrere Stunden keine Ferngesprache gefuhrt werden konnten.
- Im Jahr 1993 sorgt das so genannte Pentium-Divisionsproblem dafur, dass die Intel Pentium-Prozessoren bei der Division von Kommazahlen falsche Resultate liefern. Uber das beschadigte Image hinaus entsteht Intel ein finanzieller Schaden von 475 Millionen Dollar.
- Ein Softwarefehler am nationalen Krebsinstitut von Panama City fuhrt dazu, dass acht Menschen nach einer Strahlenbehandlung sterben, wahrend zwanzig weitere Personen durch Uberdosen verletzt werden. Die behandelnden Arzte mussen sich vor Gericht verantworten.

Hat bereits diese Auswahl gezeigt, dass fehlerhafte Software sowohl Menschenleben ge- fahrden als auch enorme Kosten verursachen kann, geht das Handelsblatt von Kosten „in Hohe von einigen Milliarden Euro“ [Fra02] per anno aus, die durch Softwarefehler bei industriellen Anwendungen entstehen.

Die heute uber Deutschlands Strafien rollenden Fahrzeuge sind nur schwerlich mit dem Automobil vergleichbar, das um die Jahrhundertwende von Carl Benz als erstes in Serie produziert wurde - zu grundlegend waren technischer Fortschritt und daraus resultierende Entwicklung seitdem. Die hohe Anzahl an verschiedenen softwaregestutzten Komponenten in Automobilen (ca. 90 - 100 in aktuellen Fahrzeugen) lasst es nur folgelogisch erscheinen, dass auch die Automobilhersteller in der Vergangenheit nicht vor dem Auftreten von Softwarefehlern geschutzt waren:

- Den Automobilhersteller Volvo zwang ein Softwarefehler zu einer Ruckrufaktion: Bei Fahrzeugen der Modellreihe XC90 konnte das Einfuhren des Schlussels in das Zundschloss zu einer Fehlfunktion fuhren, die sich auf die Klimaanlage auswirkte.
- Ein Softwarefehler in der Motorsteuerung konnte bei von BMW in der zweiten Jah- reshalfte 2008 montierten Triebwerken dazu fuhren, dass diese grundlos in das Not- laufprogramm umschalteten. Die Fahrzeuge mussten ein Softwareupdate erhalten.

Der Umgang mit der Sicherheit von Software wird in Zukunft noch an Bedeutung gewin- nen, da die Zahl Software gestutzter Systeme noch weiter ansteigen wird: Anders als in der Vergangenheit werden zukunftige Neuerungen laut Dr. Ing. Borusan, Leiter des Berliner Teils des Fraunhofer-Instituts fur Software- und Systemtechnik, weniger die mechanischen Teile als vielmehr den Bereich Elektronik und Software betreffen:

Die Innovation liegt zu 90 Prozent bei Elektronik und Software.

[Koc04]

Dies und der Umstand, dass gerade in sicherheitsrelevanten Bereichen Softwaresysteme eingesetzt werden, machen es auch im Automobilbereich unabdingbar, die Qualitat von Softwaresystemen zu messen und zu bewerten.

Ziel dieser Arbeit ist es, die wesentlichen Ansatze zu evaluieren, die im Rahmen der funk- tionalen Sicherheit Anwendung finden. Dabei sollen vor allem jene Ansatze herausgegriffen werden, die bei der Bewertung oder dem Nachweis der funktionalen Sicherheit verwendet werden. Da diese Modelle bislang noch nicht in der Automobilindustrie zum Einsatz kom- men, besteht die Notwendigkeit, sie anhand eines gezielt entwickelten Kriterienkatalogs hinsichtlich ihrer Eignung fur den Einsatz in diesem Bereich zu bewerten. Anschliefiend ist zu identifizieren, welche bewahrten Vorgehensweisen fur die Modellierung eines Be- wertungsmodells fur die funktionale Sicherheit von E/E - Systemen herangezogen werden konnen. Nach der Identifikation dieser Vorgehensweisen, soll eine Diskussion erfolgen, innerhalb welcher die Integration und Kombination der Vorgehensweisen eruiert wird.

So verfolgt diese Arbeit drei zentrale Ziele:

1. Entwicklung eines Kriterienkatalogs vor dem Hintergrund der Anforderungen der Automobilindustrie
2. Anwendung des Kriterienkatalogs auf ausgewahlte Modelle
3. Herausstellung der bewahrten Vorgehensweisen

Hierzu werden in Kapitel 1 zunachst grundlegende Voruberlegungen bezuglich der Bewer- tung von Sicherheit angestellt. Daruber hinaus werden relevante Normen und Standards vorgestellt, eine Kategorisierung von Bewertungsmodellen vorgenommen sowie diesen zu- grundeliegende Methodiken dargestellt. Das Kapitel schliefit mit Definitionen der in dieser Arbeit verwendeten Begriffe.

Nachdem zu Beginn von Kapitel 2 die zu bewertenden Modelle vorgestellt und deren Auswahl begrundet wurde, kommt der fur die Bewertung entwickelte Kriterienkatalog zur Darstellung. Dieser wird auf funf unterschiedliche Modelle angewandt. Abschliefiend ermoglicht eine Zusammenstellung der Starken und Schwachen der bewerteten Modelle in Form einer Tabelle deren Vergleich.

Kapitel 3 stellt eine Zusammenschau der positiven Aspekte einzelner Modelle dar und erleichtert so die Implementierung eines Modells.

1 Grundlagen

Dieses Kapitel dient dazu, grundlegende Voruberlegungen bezuglich der Argumentation der Softwaresicherheit und allgemeiner sowie Automobil spezifischer Sicherheitsnormen auszufuhren, auf denen der weitere Inhalt dieser Arbeit basiert. Daruber hinaus werden zunachst drei Ansatze mit unterschiedlicher Zielrichtung diskutiert, welche sicherheitsfor- dernd wirken und teilweise in der Praxis angewendet werden.

1.1 Argumentation der Sicherheit von Software

In dieser Arbeit wurde einleitend bereits aufgezeigt, dass Softwareausfalle schwerwiegende Folgen haben konnen und daraus geschlussfolgert, dass dies eine Beurteilung der Sicherheit von Softwaresystemen notig macht. Sicherheit jedoch bedeutet die Abwesenheit von Risiko und dieses lasst sich bei Software im Gegensatz zu Hardware nicht messen. Von daher ist es notig, die Argumentation fur die Sicherheit anhand der Berucksichtigung festgelegter Standards zu fuhren, die risikomindernde Mafinahmen vorgeben.

Generell unterscheiden sich Hardware und Software in einigen Aspekten deutlich vonein- ander:

- Software ist im Gegensatz zu Hardware immateriell, daher konnen keine physikali- schen Fehler auftreten.
- Im Bereich Hardware finden sich Uberwachungs- und Architekturkonzepte.
- Fur Hardware lassen sich Ausfallraten angeben, die als Nenngrofien fur die Zuver- lassigkeit eines Systems dienen.
- Bei Software werden Qualitatsmanagement- und Qualitatssicherungsmafinahmen zur Fehlervermeidung angewendet.
- Die Einhaltung von Produkt- und Prozessanforderungen wird bei Software oft durch Normen bestimmt.

Aufgrund dieser Unterschiede zwischen Hardware und Software unterscheidet sich auch die Bewertung der Sicherheit von Softwaresystemen ganz zentral von der Sicherheitsmessung bei Hardware:

Da die Ausfallrate elektronischer Systeme nicht gleichmafiig uber ihre gesamte Lebens- dauer verteilt ist, ist es sinnvoll die Ausfallrate in Abhangigkeit der Zeit anzugeben. Die entsprechende Funktion fur technische Komponenten zeigt die in Abbildung 1 dargestellte Badewannenkurve.

Zu Beginn des Lebenszyklus eines technischen Elements fuhren Produktionsfehler zu ei- ner Vielzahl an Ausfallen. Diese fallen zumeist entweder bereits beim Hersteller an oder treten - so sie den Endkunden erreichen - innerhalb der vom Gesetzgeber festgelegten Gewahrleistungsfrist bzw. innerhalb der vom Hersteller gewahrten Garantiezeit an. Im Anschluss an diese Fruhphase ist die Ausfallrate bis auf einige wenige zufallige Ausfalle sehr gering, bevor Verschleifi und Alterung diese wieder ansteigen lassen. Die gestrichelte Linie deutet an, dass der Anstieg der Ausfallrate mit zunehmendem Alter nicht immer linear ist, sondern oftmals auf einem bestimmten Niveau konstant bleibt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 1: Badewannenkurve

In Anlehnung an die Badewannenkurve scheint es drei verschiedene Klassen fur Ausfalle zu geben. Die Klasse ist durch Zeitpunkt und Ursache bestimmt (Fruhphase = Entwicklung / Designfehler, Gebrauch = Zufallige Fehler, Ausmusterung = Verschleifi).

Fur Software jedoch trifft dies nicht zu, da hier Entwicklungsprozess und Herstellung iden- tisch sind und die Klassen Verschleifi und Alterung nicht existieren. Wenngleich umgangs- sprachlich selbstverstandlich von veralteter Software gesprochen wird, kann festgestellt werden, dass sie keinem Alterungsprozess in dem Sinn unterliegt, dass mit zunehmender Dauer mehr Ausfalle eintreten. Dies andert sich, wenn sich im Umfeld der Anwendung Anderungen ergeben oder neue Anforderungen gestellt werden, welche eine Erweiterung der Funktionalitat (also ein Update) notwendig machen. Von daher sind Entwicklungsfeh- ler die einzig mogliche Ursache von Softwareausfallen. Dies bedeutet, bei Software konnen im Gegensatz zu Hardware Fehler nur zum Zeitpunkt der Entwicklung injiziert werden, sofern wahrend des Gebrauchs keine Anpassung vorgenommen wird: „Important point is software becomes reliable overtime instead of wearing out. It becomes obsolete, if the environment, for wich it was developed, changes. Hence software may be retired due to environmental changes, new requirements, new expectations, etc"[AT94].

„Obwohl Software keinem Verschleifi und keiner Alterung unterliegt, lasst sich doch ihre Qualitat durch die [...] Badewannenkurve beschreiben“[Lau88]. Dies beruht auf dem Um- stand, dass die Fehler in der ersten Phase entdeckt und beseitigt werden. In der zweiten Phase werden Fehler weiterhin beseitigt, doch durch diesen Anderungsprozess kommen neue Fehler hinzu. „Das „Wartungspersonal“ ubersieht nicht mehr alle Konsequenzen der Anderung. In der Spatphase schliefilich hat das Personal den Uberblick uber das Sy­stem soweit verloren, dass mit jeder Anderung mehr Fehler erzeugt als beseitigt werden“ [Lau88].

Aufgrund ihrer immateriellen Beschaffenheit ist es bei Software von grofiter Bedeutung, die systematischen Fehler zu vermeiden. Dazu mussen in Softwareentwicklungsprozess sowie Softwarelebenszyklus entsprechende Mafinahmen integriert werden. Abbildung 2 zeigt die Abhangigkeit der Qualitat vom Produktlebenszyklus. Die Prozessqualitat tragt zur Verbesserung der Produktqualitat bei und diese wiederum zur hoheren Qualitat bei der Verwendung eines Produktes.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 2: Qualitat im Produktlebenszyklus (in Anlehnung an [IEC01])

Gerade bei sicherheitsrelevanten Systemen gilt es, das Risiko von SW-Fehlern zu mini- mieren. Dabei kommt in vielen unterschiedlichen Branchen und Domanen das ALARP- Prinzip (As Low As Reasonably Practicable - zu deutsch: so niedrig, wie vernunftigerweise praktikabel) zur Anwendung (dargestellt in Abbildung 3).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Prinzip der Risikominderung (in Anlehnung an [DIN])

Bestimmende Grofien des ALARP-Prinzips sind tolerierbares und intolerierbares Risiko, die eine Art Kontinuum bilden, auf dem das aktuelle Risiko zu verorten ist. Dieses kann unterschiedliche Positionen einnehmen:

- Das aktuelle Risiko ist hoher als das intolerierbare Risiko - eine Risikominderung ist notwendig und wird zumeist durch Sicherheitssysteme erbracht. Allerdings sind auch grundlegende Designanderungen denkbar.
- Ist das aktuelle Risiko jedoch gleich oder geringer als das tolerierbare Risiko, so ist keine weitere Reduzierung des Risikos notwendig.

Das ALARP-Prinzip kommt lediglich zum Tragen, wenn das aktuelle Risiko zwischen tole- rierbarem und intolerierbarem Risiko liegt. In diesem Bereich kann auch das Grenzrisiko festgelegt werden. Da es nicht quantitativ zu erfassen ist, wird es mittels sicherheits- technischer Festlegungen beschrieben, die teils durch Gesetze und Rechtsverordnungen definiert sind, teils auf Expertenmeinungen basieren. Werden diese sicherheitstechnischen Festlegungen eingehalten, so gilt es als sichergestellt, dass das aktuelle Risiko unter dem Grenzrisiko liegt. Innerhalb dieses Bereichs kann das aktuelle Risiko in zwei unterschied- lichen Bereichen verortet werden:

- Das aktuelle Risiko liegt oberhalb des Grenzrisikos, jedoch unterhalb des intolerier- baren Risikos. Eine Risikominderung wird nur dann angestrebt, wenn diese prakti- kabel ist und die Kosten hierfur nicht unverhaltnismafiig hoch sind.
- Liegt das aktuelle Risiko zwischen Grenzrisiko und allgemein tolerierbarem Risiko, so hangt eine Risikominderung davon ab, ob die Kosten fur eine weitere Minderung den dadurch entstehenden Nutzen ubersteigen oder nicht.

Wahrend die Ausfallrate bei Hardware quantitativ messbar und prognostizierbar ist und somit eine eindeutige Aussage uber die Position des aktuellen Risikos moglich wird, ist dies fur Software nicht der Fall. Eine Qualitatsmessung in diesem Bereich zum Zeitpunkt der Entwicklung ist nicht moglich. Es ist lediglich moglich grob zu prognostizieren wie hoch die Wahrscheinlichkeit eines Fehlers sein mag. (vgl. [BFCH93]).

1.2 Sicherheitsnormen

Sowohl Normen als auch Standards „dienen der Rationalisierung, dem Schutz der Gesell- schaft, der Sicherheit und der Verstandigung“ [Sin08].

Eine Definition fur den Begriff Norm liefert die Norm DIN EN 45020: „Dokument, das mit Konsens erstellt und von einer anerkannten Institution angenommen wurde und das fur die allgemeine und wiederkehrende Anwendung Regeln, Leitlinien oder Merkmale fur Tatigkeiten oder deren Ergebnisse festlegt, wobei ein optimaler Ordnungsgrad in einem gegebenen Zusammenhang angestrebt wird“ [DIN98].

Die Abgrenzung von Normen und Standards bereitet insofern Probleme, als diese beiden Begriffe oftmals - falschlicherweise - synonym verwendet werden. Auch im Englischen existiert lediglich der Begriff standard, wobei jedoch zwischen De-facto-Standards und De-jure-Standards unterschieden wird.

Dieser Ansatz lasst sich auch auf die deutschen Begriffe Normen und Standards ubertra- gen: Demzufolge ist unter Norm eine Sonderform des Standards zu verstehen, „an dessen Entwicklung besondere Anforderungen hinsichtlich Konsens und Autorisierung gestellt werden. Entwurfe von Normen werden offentlich zur Diskussion gestellt und von einer autorisierten Normungsorganisation verabschiedet und veroffentlicht“ [Sin08].

In Abbildung 4 ist die „Normungspyramide“ dargestellt. Die gesetzliche Verbindlichkeit nimmt von oben nach unten ab. Im Gegensatz zu Normen werden Standards von In- teressenverbanden, kleineren Kreisen von Herstellern oder sogar einzelnen Unternehmen erarbeitet.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 4: Normungsrahmen (in Anlehnung an [GKS+99])

1.2.1 Entwicklung der Norm IEC 61508

Die Internationale Norm IEC 61508 tragt den Titel „Funktionale Sicherheit sicherheitsbe- zogener elektrischer/elektronischer/programmierbar elektronischer Systeme“ und wurde 1998 veroffentlicht. Sie kann als Basisnorm oder aber als Sicherheits-Grundnorm bezeich- net werden, da sie die Grundlage fur die Erstellung branchenspezifischer oder aber an- wendungsspezifischer Standards darstellt (so auch fur die noch zur Darstellung kommende Norm ISO CD 26262: Road vehicles - Functional safety). In Deutschland ist sie unter den Namen DIN EN 61508 und VDE 0803 bekannt. Ein Uberblick uber die von IEC 61508 abgeleiteten Normen ist in Abbildung 5 dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Mit IEC 61508 verwandte Standards

Zum Anwendungsgebiet von IEC 61508 gehoren alle sicherheitsbezogenen Systeme mit elektrischen, elektronischen oder programmierbar elektronischen Komponenten, wenn de- ren Ausfall eine Gefahr fur Mensch oder Umwelt darstellen kann.

IEC 61508 umfasst den gesamten Sicherheitslebenszyklus eines E/E/PE - Systems und somit samtliche Phasen von Konzept und Planung bis hin zu Aufierbetriebnahme und Deinstallation. Aufierdem umfasst es sowohl Gefahren verursachende Systeme als auch risikomindernde Systeme. Dennoch ist diese Norm keinesfalls eine Liste an Einzelanfor- derungen, sondern betrachtet vielmehr das Sicherheitsverhalten des Gesamtsystems.

Wichtiges Element der Norm IEC 61508 sind die Sicherheitsanforderungsstufen (Safety Integrity Level). Es existieren vier Stufen (SIL 1 bis SIL 4), mittels derer sich die Ri- sikominderung beschreiben lasst, die durch die Sicherheitsfunktionen erreicht wird oder aber erreicht werden muss (vgl. [KG04]).

1.2.2 ISO-Norm 26262

Unter dem Titel „Road vehicles - Functional safety“ entsteht aktuell auf Basis der Sicherheits- Grundnorm 61508 die ISO-Norm 26262 fur sicherheitsrelevante Systeme in Kraftfahrzeu- gen.

Ziel ist es, die allgemeine Norm 61508 auf den Bereich Automobilindustrie zu ubertragen. Der aktuelle Arbeitsstand ISO CD 26262 Baseline 11 schlagt, wie auch die Norn IEC 61508 „fur die einzelnen Sicherheits-Integritatslevel Techniken und Mafinahmen vor, die in den einzelnen Entwicklungsphasen zum Einsatz kommen sollen“. ISO CD 26262 wird spezielle SIL fur den Automobilbereich (ASIL - Automotive Safety Integrity Level) defi- nieren [Bor07, S. 246]. Es existieren 4 Stufen: von ASIL A bis ASIL D, wobei ASIL D fur die hochste Gefahrenstufe steht.

Es wird erwartet, dass Mitte des Jahres 2009 ein erster Entwurf veroffentlicht wird (vgl. [Con06, S. 15]).

1.2.3 Norm DO-178B

Die Norm DO-178B „Software Considerations in Airborne Systems and Equipment Cer- tification“ (Richtlinie zur Entwicklung von Software fur Gerate und Ausstattungen in der Luft- und Raumfahrt) muss bei der Entwicklung von Software eingehalten werden, die fur Luftverkehrssysteme bestimmt ist.

Auch DO-178B legt Sicherheitsintegritatsstufen fest. Hier wird unter funf unterschiedli- chen Stufen unterschieden - von A (kritischste Stufe) bis E (am wenigsten kritische Stufe). Stufe A bedeutet in diesem Fall katastrophale Auswirkungen bei einer Fehlfunktion der Software.

1.3 Beschreibung der Ansatze im Umfeld der funktionalen Si- cherheit

Bezugnehmend auf die Funktion, die die in dieser Arbeit analysierten Modelle erfullen, konnen die folgenden Kategorien (bzw. Zielsetzungen) identifiziert werden (siehe Abbil- dung 6).

1. Verbessern: Methoden / Mafinahmen um sicherheitsrelevante Fehler zu vermeiden oder zu identifizieren.
2. Nachweisen: Ansatze / Modelle, die dazu verwendet werden einen Nachweis zu erbringen, dass das System sicher ist.
3. Bewerten: Ansatze / Modelle fur die Bewertung unterschiedlicher Aspekte der funktionalen Sicherheit unter Berucksichtigung relevanter Standards.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Klassifizierung der Ansatze

In dieser Arbeit werden die Methoden nicht bewertet, die einen Beitrag zur Verbesse- rung der funktionalen Sicherheit leisten, da sie bereits etabliert sind und in der Praxis angewandt werden. Sie sind in der Literatur bereits ausfuhrlich beschrieben und sollen im folgenden nur in den Kapiteln 1.3.1, 1.3.2, 1.3.3. und 1.3.4 kurz vorgestellt werden.

1.3.1 FMEA - Fehlermoglichkeiten- und Einflussanalyse

Wurde eingangs bereits das US-amerikanische Raumfahrtprojekt Apollo angesprochen, so kann festgestellt werden, dass die FMEA (Failure Mode and Effects Analysis; zu deutsch: Fehlermoglichkeiten- und Einflussanalyse) gerade fur dieses Projekt entwickelt wurde (vgl. [KB95, S. 47]). Ziel hierbei war es, potenzielle Fehler und deren Folgen bereits vor ihrem Eintreten zu identifizieren, um somit die Moglichkeit zu erhalten, diese von vornherein zu verhindern. Deshalb ist es sinnvoll, diese Methode vor allem in fruhen Phasen des Entwicklungsprozesses einzusetzen. Heute kann die FMEA als bekannteste qualitative Zuverlassigkeitsmethode betrachtet werden [BL04, S. 106].

Uber die US-amerikanische Raumfahrt hinaus wird die FMEA heute auch in anderen sicherheitsrelevanten Bereichen eingesetzt, in denen die Sicherheit/Zuverlassigkeit kom- plexer Systeme eine wichtige Rolle spielt. Durch ihren Einsatz lassen sich sowohl die Entwicklungs- als auch die Produktqualitat steigern, indem sowohl wahrend Produkt- und Prozessplanung als auch zu einem spateren Zeitpunkt, wahrend Konstruktion und Fertigung, Fehlerpotenziale aufgedeckt werden, um somit die Entstehung von Fehlern baldmoglichst zu verhindern. Generell kann zwischen drei Arten von FMEA unterschie- den werden:

- System-FMEA: Untersuchung des Zusammenwirkens der einzelnen Komponenten innerhalb des Gesamtsystem und Analyse der zwischen diesen Komponenten beste- henden Schnittstellen
- Konstruktions-FMEA: Untersuchung einzelner Teile und Baugruppen eines Systems auf Grundlage der Konstruktionsplane; die hierbei identifizierten Ursachen potenzi- eller Fehler finden sich zumeist in Konstruktion und Fertigung
- Prozess-FMEA: Untersuchung von Fertigungs- und Montageprozess auf mogliche Fehlerquellen auf der Grundlage der Fertigungsplane; Weiterverfolgung von Fehlern, die im Rahmen der Konstruktions-FMEA identifiziert wurden

Gerade in der Automobilindustrie ist der Einsatz der FMEA weit verbreitet und dient vor allem im Bereich der Neuentwicklung dazu, Fehler bereits vor Produktionsbeginn zu identifizieren und zu beseitigen. Dadurch wird der Anderungsaufwand bei der spateren Produktion reduziert und es kommt zu einer Senkung der aus Fehlern resultierenden Kosten (vgl. [HTB03, S. 137] und [Vah08, S. 271]).

1.3.2 FMECA - Fehler-Moglichkeits- und kritische Einfluss-Analyse

Ausgehend von eben dieser FMEA wurde in den 60er Jahren des vergangenen Jahrhun- derts die FMECA (Failure Mode, Effects, and Criticality Analysis, zu deutsch: Fehler- Moglichkeits- und kritische Einfluss-Analyse) mit der Zielsetzung entwickelt, diese im Be­reich Flugsicherheit einzusetzen. Der zentrale Unterschied gegenuber der FMEA ist deren Erweiterung um eine Risikobewertung durch die „Bestimmung von absoluten Ausfallra- ten bzw. die Berechnung einer Kennzahl fur die Bedenklichkeit eines Fehlerzustandes“ ([TM03, S. 5]).

Grundlegende Idee der FMECA ist es, in jeder einzelnen Komponente eines Systems jeden potenziellen Fehler und all dessen mogliche Folgen zu identifizieren, so dass eine Klassifizierung der Fehler hinsichtlich ihrer Schwere moglich wird.

Entsprechend ihrer Zielsetzung lasst sich die FMECA in Form eines Dreischritts durch- fuhren:

- Analysephase: Das Ziel, bereits wahrend fruher Phasen der Entwicklung Fehler und Fehlerursachen zu identifizieren, macht es notig, auf bereits vorhandene Erfahrun- gen zuruckzugreifen. So werden unter Einbezug von Mitarbeitern aus verschiedenen Bereichen alle potenziellen Fehler aufgelistet. Darauf aufbauend werden zunachst die Folgen untersucht, die das Auftreten eines Fehlers hatte, um anschliefiend Feh- lerursachen zu identifizieren.
- Den in der ersten Phase identifizierten Fehlern werden in der Phase der Risikobe- wertung Risikoprioritatszahlen zugeordnet. Diese werden auf Basis der Eintritts- wahrscheinlichkeit, der Folgen und des Risikos des Unentdecktbleibens eines Fehlers gebildet. Daruber hinaus kommen Prufmafinahmen fur die Funktionen der einzelnen Komponenten zur Darstellung.
- In der dritten Phase der Mafinahmenentwicklung werden geeignete Mafinahmen getroffen, um die in der Analysephase identifizierten Fehlerursachen zu vermeiden. Hierbei werden zuerst Gegenmafinahmen fur die Fehlerursache getroffen, der in der Phase der Risikobewertung die hochste Risikoprioritatszahl zugewiesen wurde.

O’Connor et al. stellen fest, „FMECA is not appropriate fur software designs“ [O’C06, S. 211]. Dies ist darauf zuruckzufuhren, dass sich Vorhersagen fur Ausfalle von Software- systemen schwieriger treffen lassen als fur den Bereich Hardware (vgl. [O’C06, S. 206ff]). Generell kann festgestellt werden, dass die Prognose von Ausfallraten bei Software aktuell noch Forschungsthema ist.

1.3.3 FTA - Fehlerbaumanalyse

Eine Erganzung der FMEA stellt die FTA (Fault Tree Analysis; zu deutsch: Fehler­baumanalyse) dar, deren Einsatz vor allem dann angeraten ist, wenn bei der Entwicklung sicherheitsrelevanter Systeme „hohe Fehlerrisiken bestehen und interdependente Fehler­ursachen existieren“ [Ada98, S. 178].

FMEA und FTA hangen insofern zusammen, als sie jeweils das Ergebnis des anderen als Ausgangspunkt wahlen. Anders als die intuitive Fehlerfindung der FMEA jedoch stellt die FTA eine wissenschaftliche Methode dar, die nicht von einem moglichen Fehler aus- geht und dessen Ursachen und Folgen untersucht, sondern vielmehr ausgehend von einem unerwunschten Ereignis dessen potenzielle Ursachen untersucht.

Im Rahmen dieser Analyse werden die Strukturen des zu untersuchenden Systems in der klaren Form einer Baumstruktur dargestellt, um somit die Identifikation potenzieller Fehlerquellen und deren Verknupfungen zu ermoglichen. Die Auswertung dieser Baum- struktur fuhrt ausgehend vom unerwunschten Ereignis zu den Ausfallursachen. Generell liefert die Fehlersuche mittels FTA sowohl quantitative als auch qualitative Ergebnisse.

Die Wahrscheinlichkeit, mit der das unerwunschte Ereignis auftritt, lasst sich nun aus den Auftrittswahrscheinlichkeiten der Ursachenkombinationen ableiten (vgl. [Ada98, S. 177] und [HTB03, S. 137]).

1.3.4 ETA - Ereignisbaumanalyse

Die qualitative Methode Event Tree Analysis (ETA, zu deutsch: Ereignisbaumanalyse) wird zwar auch bei Risikostudien eingesetzt, dient jedoch in erster Linie zur Analyse von Storfallen technischer Systeme. Als induktive Analyse bietet sie die Moglichkeit, ausge- hend von einem Anfangsereignis eine Aussage uber die Folgeereignisse und die potenziellen Endzustande zu treffen. Bei der ETA lassen sich zwei grundlegende Leistungen unterschei- den:

- Sie ermoglicht die ubersichtliche Darstellung der Ereignisablaufe, deren potenzieller Verzweigungen und logischer Zusammenhange. So lassen sich die Umstande identi- fizieren, unter denen ein Anfangsereignis bestimmte Ereignisablaufe in Gang setzt und einen bestimmten Endzustand nach sich zieht.
- Daruber hinaus ermoglicht ETA eine Wahrscheinlichkeitsauswertung fur diese Zu­sammenhange, so dass sich die Wahrscheinlichkeit sowohl fur die vorgeschalteten Ereignisablaufe als auch fur das Auftreten bestimmter Endzustande ermitteln lasst. Das heifit, ist die Haufigkeit des Ausgangszustands bekannt, konnen die Haufigkeiten fur alle Zwischen- und Endzustande berechnet werden.

Festzustellen ist, dass die vorwarts gerichtete ETA sich komplementar zu der ruckwarts gerichteten FTA verhalt, die ausgehend vom unerwunschten Endzustand die Ursachen identifiziert (vgl.[Rup02]).

1.4 Grundlegende Methodiken 1.4.1 BBN

Das Bayessche Theorem „ist eine analytische Methode“, die aus der Wahrscheinlichkeits- theorie kommt, um die Veranderungen einer ursprunglichen Wahrscheinlichkeitseinschat- zung „durch neu hinzukommende Informationen abzubilden“[Gra05, S.95].

Die Formel fur zwei Ereignisse A und B wird als Bayes Theorem bezeichnet und lautet:

Abbildung in dieser Leseprobe nicht enthalten

Wobei

P(A) die A-priori-Wahrscheinlichkeit fur ein Ereignis A

P(B|A) die Wahrscheinlichkeit fur ein Ereignis B unter der Bedingung, dass A eingetreten ist

P(B) die A-priori-Wahrscheinlichkeit fur ein Ereignis B.

Zur Ermittlung der bedingten Wahrscheinlichkeit tragt das Bayessche Theorem insofern bei, als es in einem Bayesschen Netz die Ermittlung der bedingten Wahrscheinlichkeit P(A|B) aus der bedingten Wahrscheinlichkeit P(B|A) ermoglicht.

Definition eines Bayesschen Netz: Sei [Abbildung in dieser Leseprobe nicht enthalten] eine Menge von Aussagenvariablen, sei P eine gemeinsame Verteilung uber V, und sei G = (V,t) ein gerichteter azyklischer Graph. Fur jedes [Abbildung in dieser Leseprobe nicht enthalten] bezeichne pa [Abbildung in dieser Leseprobe nicht enthalten] die Menge aller Elternknoten, de [Abbildung in dieser Leseprobe nicht enthalten] die aller Nachkommen und nd (A_i) c V die Menge aller Nicht-Nachkommen von Ai.

[Abbildung in dieser Leseprobe nicht enthalten] wird Bayessches Netz genannt, wenn fur jede Variable Ai gilt

Abbildung in dieser Leseprobe nicht enthalten

wenn also jede Variable Ai bedingt unabhangig ist von ihren Nicht-Nachkommen nd (A_i) bei gegebenen Werten ihrer Elternknoten pa (A_i) [BKI08, S.383].

Da bei gegebenen Werten der Elternknoten alle Variablen unabhangig sein mussen, lasst sich die gemeinsame Verteilung P wie folgt berechnen:

Abbildung in dieser Leseprobe nicht enthalten

Aufbauend auf den Uberlegungen des englischen Mathematikers Thomas Bayes (1702 - 1761), wurden Bayessche Netze zu Beginn der 1980er Jahre im Bereich der Experten- systeme eingefuhrt: Anders als bisher sollten Experten Entscheidungen nicht langer aus- schliefilich aufgrund ihres Wissens und ihrer Beobachtung treffen, sondern dabei durch Computerprogramme unterstutzt werden. Erst gegen Ende der 80er Jahre wurden Bayes­sche Netze auch in Real-World-Anwendungen eingesetzt.

Ein Bayessches Netz ist ein gerichteter azyklischer Graph. Die Knoten stellen in so ei- nem Graphen Zufallsvariablen dar. Die Kanten entsprechen bedingten Abhangigkeiten zwischen den Zufallsvariablen. Die Knoten konnen kontinuierliche oder diskrete Werte einnehmen.

Da jeder Knoten mit anderen Knoten in Verbindung steht, beeinflusst eine Veranderung der Default-Wahrscheinlichkeit eines Knotens immer auch die Wahrscheinlichkeitsvertei- lungen an nachgelagerten Knoten. Die durch einen einzelnen Informationsinput ausgeloste „Kettenreaktion“ wird als „Propagation der Information im Netz“ bezeichnet. Sie kann den Zustand des gesamten Modells nachhaltig, und aufgrung der moglicherweise komple- xen Zusammenhange im Modell, „unvorhersehbar“ verandern [Pet05].

Die d-Separation ist ein Mechanismus, der unabhangige Knoten in ein eigenes Bayessches Netz abtrennen kann. D-Separation wird wie folgt definiert: „Zwei disjunkte Variablen (Knoten) in einem Bayesschen Netz siend d-separiert, wenn es fur alle Pfade zwischen A und C eine dazwischen liegende Variable B gibt, so dass die Verbindung entweder seriell oder divergierend ist und B instanziert ist (die Wertauspragung von B ist bekannt) oder die Verbindung ist konvergierend und weder B, noch einer der Nachfolger von B sind instanziert“ [Kap07, S.15]. In Abbildungen 7, 8 und 9 sind die drei Verbindungsarten eines Bayesschen Netzes dargestellt.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Konvergierende Verbindungen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 8: Divergierende Verbindungen

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 9: Parallele Verbindungen

Um Wirkungsweise eines Bayesschen Netztes zu verdeutlichen ist in den Abbildungen 10 bis 13 ein kleines Beispiel dargestellt. Das Wissen, dass es regnet (Abbildung 11), erhoht die Wahrscheinlichkeit, dass die Strafie nass ist auf 93%.

Wenn allerdings bekannt ist, dass es nicht regnet und ein Wasserrohrbruch etstanden ist, andert sich die Wahrscheinlichkeit, dass die Strafie nass ist auf 10% (Abbildung 12). In Abbilldunb 13 sind die Wahrscheinlichkeiten zu sehen fur den Fall, dass die Strafie nicht nass ist.

[...]