Leseprobe

Wolfgang Freese

Erstellung von Fehlerbäumen

Eine strukturierte und systematische Methode

ISBN (Buch): 978-3-446-44578-9

Weitere Informationen oder Bestellungen unter

http://www.hanser-fachbuch.de/978-3-446-44578-9

sowie im Buchhandel.

© Carl Hanser Verlag, München

Kennen Sie das? Es ist Freitag, später Nachmittag. In sprichwörtlich letzter Minute hat ein Kollege in der Spezifikation einen potenziellen Funktionsausfall gefunden, der bisher im technischen Sicherheitskonzept nicht berücksichtigt worden ist. Nun sollen Sie mittels Fehlerbaumanalyse nach möglichen Ursachen suchen und geeig-nete Sicherheitsmaßnahmen definieren. Das Problem: Die Randbedingungen sind alles andere als optimal. Von den Kollegen, die Sie benötigen, sind zwei auf einer Fortbildung, drei erkrankt, einer auf Dienstreise, und der Rest hat entweder Vater-schaftsurlaub oder ist schon auf dem Weg ins Stadion. Das Verständnis der Kolle-gen und Kolleginnen ist eh größtenteils eher gering. „Du immer mit Deinen Fehler-bäumen. Früher hat eine FMEA auch gereicht.“

Ihre Motivation könnte geringer kaum sein, aber es bleiben nur zwei Tage, dann müssen Ergebnisse vorliegen. Also machen Sie sich wie üblich selber dran, besor-gen sich den Schaltplan (per email vom Kollegen aus Indien – der arbeitet jetzt noch?), definieren als Top Level Event die Sicherheitslücke und legen los. Als es schließlich darum geht, die Resultate zu diskutieren, wird auch das zum Spieß-rutenlauf. Jedem rennt die Zeit davon; Sie mögen bitte per email mitteilen, welche Änderungen notwendig seien. Endgültig frustriert empfehlen Sie wie gewünscht ein paar Designänderungen, beschweren sich noch über die schlechte Zusammen-arbeit (interessiert aber niemanden) und setzen ihren Chef in Kopie in der Hoff-nung, dass es in Zukunft besser werden wird (wird es nicht). Immerhin haben Sie es mal wieder geschafft, den Karren aus dem Dreck zu ziehen. Ohne Sie hätte die Lieferung der Prototypen in einer Woche verschoben werden müssen. Der Kunde hätte getobt, der Chef hätte getobt, die Kollegen hätten getobt. So aber konnte der Zeitplan eingehalten werden, alle sind zufrieden.

Drei Wochen später fallen fünf Prototypen während der Wintertests in Skandi-navien aus. Der Kunde tobt, der Chef tobt, die Kollegen toben. Ursache ist nicht die Sicherheitslücke gewesen. Die von ihnen vorgeschlagenen Maßnahmen haben ge-griffen. Ursache war ein Designfehler an ganz anderer Stelle – ist nur leider im Rahmen der Fehlerbaumanalysen nicht aufgefallen. Aber wer denkt auch schon an den Einfluss der Umgebungstemperatur auf den Oszillator?

Vorwort

6 Vorwort

Das hier geschilderte Szenario ist frei erfunden und möglicherweise auch übertrie-ben. Aber das ein oder andere Detail des Geschehens wird manch Leser vielleicht aus eigener Erfahrung kennen. Hin und wieder ist man im täglichen Arbeiten weit weg vom Idealfall.

Gerade bei der Arbeit mit Fehlerbäumen ist es von besonderer Bedeutung, große Sorgfalt walten zu lassen. Ansonsten läuft man schnell Gefahr, fehlerhafte Fehler-bäume zu erstellen, die am Ende nur Zeit gekostet haben ohne die eigentlichen Show Stopper gefunden und geeignete Sicherheitsmaßnahmen definiert zu haben.

Zeitdruck, fehlende Kollegen, schlechte Vorbereitung, mangelhafte Spezifikatio-nen . . . – das sind nur einige der möglichen Ursachen für qualitativ minderwertige Fehlerbaumanalysen. Das mit Abstand größte Risiko besteht allerdings vermutlich darin, dass sehr häufig niemand mehr die Zeit findet, über die Fehler und Risiken nachzudenken und die eigene Arbeitsweise zu hinterfragen und dann zu verbes-sern. Dies gilt auch, wenn es darum geht, einen Fehlerbaum zu erstellen. Eine strukturierte und systematische Vorgehensweise scheint es nicht zu geben.

Auf dem Markt findet sich jede Menge Literatur zur Auswertung von Fehlerbäu-men. Das wundert nicht, denn die Methode ist bereits einige Jahrzehnte etabliert, die Mathematik bekannt. Auch ist die Zahl professioneller Software in den letzten Jahren kontinuierlich gestiegen und wird vermutlich weiter steigen. Sucht man aller-dings nach einem Artikel, einer wissenschaftlichen Arbeit oder einem Buch zum Thema der Erstellung eines Fehlerbaums, so wird man überrascht sein, wie wenig es hierzu gibt. Einen Fehlerbaum zu analysieren impliziert, dass der Fehlerbaum schon existiert. Wie aber einen solchen erstellen?

Das vorliegende Buch macht einen ersten Schritt, um diese Lücke zu schließen. Der Autor hat zunächst als Functional Safety Manager und mittlerweile Enginee-ring Group Manager Europe über einen Zeitraum von mehreren Jahren die hier vorgestellte Methode entwickelt, nachdem er selber immer wieder an Fehlerbäu-men von mangelhafter Qualität verzweifelt ist – die eigenen mit eingeschlossen. Viele Fehlversuche, Diskussionen mit Kollegen, Reviews, Gespräche auf Konferen-zen und nicht zuletzt der Gedankenaustausch im Internet haben dazu beigetragen, dieses Thema voranzutreiben. Es ist der ausdrückliche Wunsch des Autors, mit diesem Buch seine Methode zur Diskussion zu stellen, anstatt sie nur für sich zu verwenden, um sie basierend auf Rückmeldungen gemeinsam weiter verbessern und jedem zu Verfügung stellen zu können. Der enorme Vorteil liegt ja vor allem gerade darin, dass sie unabhängig von der Art des betrachteten Systems ein setzbar ist. Aus diesem Grunde adressiert das Buch nicht nur Functional Safety Manager der Automobilindustrie, sondern jeden, der mittels Fehlerbaumanalyse ver suchen möchte, Ursachen in einem System zu identifizieren, die zu einem Funktionsaus-fall führen können.

Lindlar, den 31. März 2015

Dr. Wolfgang Freese

Vorwort . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

Einleitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1 Funktionen und Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.1 Definitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

1.2 Standardmodell für technische Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2 Beispiel Scheibenwischer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.1 System Fahrer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2 System Fahrzeug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 System Scheibenwischer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3 Systematische Herleitung von Top-Ereignissen . . . . . . . . . . . . . . . 35

4 Initiale Fehlerbäume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.1 Fehlerfälle von Signalen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.1.1 Digitale Signale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484.1.2 Analoge Signale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504.1.3 Pulsweitenmodulierte Signale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.1.4 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514.1.5 Signalrauschen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.2 System Fahrer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.3 System Fahrzeug . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

4.4 System Scheibenwischer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4.5 System ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4.6 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Inhalt

8 Inhalt

5 Standard Fault Tree Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6 Fehlerbaum des Systems ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.1 Das System ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.2 Erstellung des Fehlerbaums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99

7 Software Fault Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.1 Spezifikation der Softwarekomponente . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1037.1.1 Definition der Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1047.1.2 Anforderungen an die Sw-Funktion . . . . . . . . . . . . . . . . . . . . . . . . . 1057.1.3 Spezifikation der Sw-Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

7.2 Top-Ereignis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7.3 Erstellung des Fehlerbaums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

8 Hardware Fault Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

8.1 Spannungsteiler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144

8.2 Tiefpassfilter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

8.3 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174

9 Verification Fault Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

9.1 Review Meeting als Verifikationsmaßnahme . . . . . . . . . . . . . . . . . . . . . . . 1769.1.1 Definition der Funktion Verifikation . . . . . . . . . . . . . . . . . . . . . . . . 1779.1.2 Spezifikation des Systems Review Meeting . . . . . . . . . . . . . . . . . . . 180

9.2 Herleitung des Top-Ereignisses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

9.3 Erstellung des initialen Fehlerbaums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859.3.1 Fehlerfälle der Action Item Liste . . . . . . . . . . . . . . . . . . . . . . . . . . . 1859.3.2 Fehlerfälle des Review Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1879.3.3 Fehlerfälle der Meeting Minutes . . . . . . . . . . . . . . . . . . . . . . . . . . . 1889.3.4 Initialer Fehlerbaum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

9.4 Analyse des Systems Review Meeting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189

9.5 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224

10 Qualitative Fehlerbaumanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

9Inhalt

11 Sicherheitsmaßnahmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233

11.1 Sicherheitsmaßnahmen als Ereignisse im Fehlerbaum . . . . . . . . . . . . . . 233

11.2 Standardisierter Fehlerbaum für Sicherheitsmaßnahmen . . . . . . . . . . . . 240

12 Externe Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253

13 Qualitätskriterien eines Fehlerbaums . . . . . . . . . . . . . . . . . . . . . . . . 259

14 Elektronisches Lenkradschloss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

14.1 Funktion und Fahrzeugarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267

14.2 Gefahrenanalyse und initialer Fehlerbaum . . . . . . . . . . . . . . . . . . . . . . . . 268

14.3 Analyse auf Fahrzeugebene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

14.4 Analyse des ESCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297

14.5 Analyse der ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304

14.6 Sicherheitsmechanismen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31414.6.1 Maßnahme auf der Ebene der ECU . . . . . . . . . . . . . . . . . . . . . . . . . 31514.6.2 Maßnahme auf der Ebene des ESCL . . . . . . . . . . . . . . . . . . . . . . . . . 32014.6.3 Überwachung von Eingangssignalen . . . . . . . . . . . . . . . . . . . . . . . . 323

Schlussbemerkung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Literaturverzeichnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333

Definition, Begriffserklärung, Beispiel

Anmerkungen, Hinweise

Bitte beachten

Fehlerbaumanalysen sind eine seit den 1950er Jahren etablierte Methode zur Ana-lyse von Systemen hinsichtlich der Fragestellung „Wie konnte das passieren?“ oder „Mit welcher Wahrscheinlichkeit kann das bei unserem System passieren?“ Moti-vation für die Entwicklung dieser Methode war die Suche nach den Ursachen eines bereits geschehenen Unglücks. Erst später wurde die Fehlerbaumanalyse auch präventiv eingesetzt, um für ein gegebenes System abschätzen zu können, mit wel-cher Wahrscheinlichkeit ein angenommener Fehlerfall passieren kann. Hierdurch ist es möglich geworden, Systeme iterativ sicherer zu machen bis ein akzeptables Restrisiko erreicht wurde.

Oftmals wird nicht erkannt, dass die Struktur eines Fehlerbaums mindestens ge-nauso viel Einfluss auf das Ergebnis der Analyse hat, wie die eigentliche Auswer-tung selbst. Das zusätzliche Risiko, das sich für die Sicherheit eines Systems er-gibt, wenn der Fehlerbaum z. B. unvollständig ist, kann leicht unterschätzt werden. Ein Blick auf den Markt zeigt jedoch relativ schnell, dass es nur sehr wenig Litera-tur dazu gibt, wie ein Fehlerbaum aufgebaut werden sollte. Dies ist umso erstaun-licher, da die Fehlerbaumanalyse schon seit mehreren Jahrzehnten in den unter-schiedlichsten Branchen zum Einsatz kommt. Auf Konferenzen, Workshops und in diversen Internetforen stellt man fest, dass scheinbar jeder einzelne eine für sich optimale Methode entwickelt hat. Viele davon sind sich ähnlich und offenbar er-folgreich, die Ergebnisse sprechen für sich. Auf der anderen Seite muss man aber auch immer wieder feststellen, dass sich gerade die Neulinge unter den Fehlerbaum-analysten z. T. sehr schwer damit tun, einen sinnvollen Fehlerbaum zu erstellen – sinnvoll im Sinne von: Dieser Fehlerbaum hilft effizient ein System sicherer zu machen. Diese Lücke auf dem Buchmarkt wenigstens ein bisschen zu schließen, ist das Ziel der vorliegenden Arbeit.

Ein Buch zum Thema Fehlerbaumanalyse zu schreiben, ist insofern eine Heraus-forderung, als dass es sehr viele unterschiedliche Aspekte dieser Methodik gibt, über die geschrieben werden könnte. Es war jedoch von Anfang an das Ziel, sich ausschließlich auf die Erstellung von Fehlerbäumen zu beschränken. Daher wird der Leser z. B. vergeblich nach mathematischen Grundlagen oder der Erklärung

Einleitung

12  Einleitung

von Grundbegriffen suchen. Auch die quantitative Auswertung von Fehlerbäumen wird nicht diskutiert. Es gibt mittlerweile zahlreiche Software Tools am Markt, mit denen sich diese Aufgabe weitestgehend automatisiert erledigen lässt.

Vom Leser wird erwartet, dass er die Methode der Fehlerbaumanalyse grundsätz-lich kennt und weiß, wann sie eingesetzt wird. Möglicherweise hat er schon einige oder gar viele Fehlerbäume erstellt und analysiert. Dieses Buch soll ihm dabei helfen, dass Fehlerbäume zukünftig besser strukturiert sind und darüber hinaus Bereiche und Aspekte umfassen, die bisher vielleicht noch gar nicht in Betracht gezogen wurden.

Um den Leser nicht gleich zu Anfang durch zu viele theoretische Betrachtungen zu verlieren, wurde Wert darauf gelegt, so schnell wie möglich zum Thema zu kom-men und die systematische Erstellung von Fehlerbäumen im Detail zu erklären. Daher werden in Teil 1 des Buches lediglich einige grundlegende Betrachtungen an den Anfang gestellt, bevor im eigentlichen Hauptteil (Teil 2) mittels der Bei-spielfunktion die Herleitung von Top Level Events sowie der Aufbau der Fehler-bäume auf den unterschiedlichen Ebenen (System, Software, Hardware) vorgestellt werden. Dass ein Fehlerbaum nicht nur für technische Systeme, sondern auch für Prozesse, Methoden oder Tools anwendbar ist, wird am Beispiel des Review Mee-tings als Verifikationsmaßnahme erläutert.

Darüber hinaus werden im letzten Teil des Buches allgemeinere Aspekte von Fehlerbäumen betrachtet: Eigenschaften der qualitativen Fehlerbaumanalyse, das Hinzufügen von Sicherheitsmaßnahmen, die Berücksichtigung von externen Kom-ponenten und Modulen sowie die Herleitung und Anwendung von Qualitätskrite-rien. Es ist hinzuzufügen, dass bewusst darauf verzichtet wurde, Sicherheitsmaß-nahmen an jeder denkbaren Stelle im Text und in den Diagrammen hinzuzufügen. Diesem Thema ist ein eigenes Kapitel gewidmet. Durch den Verzicht sind die dar-gestellten Fehlerbäume deutlich übersichtlicher und verständlicher, ohne dass die jeweilige Kernaussage verzerrt oder gar verloren gegangen ist.

Die in diesem Buch abgedruckten Fehlerbäume sind bewusst einfacher gehalten, als es in der Praxis häufig der Fall ist. Fehlerbäume können sehr schnell sehr umfangreich werden und der eigentliche Aspekt im jeweiligen Abschnitt wäre zu stark in den Hintergrund getreten.

Einige Begriffe haben sich in der Branche durchweg in der jeweiligen englischen Übersetzung etabliert, wie z. B. Review Meeting. Der Autor hat beschlossen, auf die Verwendung einer nicht üblichen Übersetzung in die deutsche Sprache zu verzich-ten, da er darin weder einen literarischen Gewinn noch eine Verbesserung der Lesbarkeit und Verständlichkeit des Textes erkennen kann.

Es sei noch angemerkt, dass dieses Buch nicht zum Ziel hat, technische Systeme mithilfe einer Modellsprache wie SysML [1] oder UML [2] vollständig zu beschrei-ben. Daher wurde auf die konsequente Verwendung dieser oder anderer Standards

verzichtet, zumal die Erfahrung des Autors gezeigt hat, dass derartige Sprachen viel zu wenig verbreitet sind, als dass erwartet werden könnte, dass jeder poten-zielle Leser dieses Buches einen Gewinn daraus ziehen könnte. Das primäre Anlie-gen war, den Kerngedanken zu vermitteln und aus diesem Grunde ist die Alltags-sprache bewusst gegenüber einer Modellsprache bevorzugt worden.

Einleitung 13

Teil 1Vorbereitende Überlegungen

Wie im Vorwort angekündigt, werden im ersten Teil des Buches einige grundle-gende Themen erörtert, die für das Verständnis des Hauptteils wichtig sind.

So sollen zunächst die Begriffe Funktion und System definiert werden, da diese häufig nicht klar voneinander getrennt verwendet werden. Für die Struktur der Spezifikationen sowie die Definition von Anforderungen und somit letzten Endes für die Qualität der Fehlerbäume ist dies allerdings von großer Bedeutung.

Anschließend wird eine Beispielfunktion, die in den späteren Kapiteln immer wie-der verwendet werden wird, um die jeweiligen Aspekte anschaulicher zu machen, im Detail vorgestellt.

Die im Hauptteil vorgestellte Methode zur systematischen Erstellung von Fehler-bäumen setzt die Top-Ereignisse als gegeben voraus. Wie diese aus der Spezifika-tion des Systems und der Definition der Funktion hergeleitet werden können, wird ebenfalls im Detail beschrieben.

1Fehleranalysen werden durchgeführt, um nach Ursachen dafür zu suchen, dass benötigte Funktionen nicht mehr wie erforderlich bereitstehen. Typische Beispiele aus dem Automotive-Bereich sind etwa die folgenden:

� Der Motor des Scheibenwischers wird nicht mehr aktiviert, wenn der Fahrer den Scheibenwischer anfordert.

� Das Seitenfenster wird hochgefahren, ohne dass der Knopf des Fensterhebers betätigt worden ist.

� Der Blinker beginnt erst nach einer Verzögerung zu blinken. � Die Frontscheinwerfer gehen plötzlich aus. � Das Fahrzeug beschleunigt während der Fahrt ohne Aufforderung durch den Fahrer.

� Das Lenkradschloss verriegelt während der Fahrt.Sowohl die Funktionsdefinition als auch die Spezifikation des Systems sind nicht nur die Grundlage für die Entwicklung und Produktion des Systems, sondern ins-besondere auch für die Fehleranalyse. Egal, ob der Ausgangspunkt ein angenom-mener Funktionsausfall, ein negatives Testergebnis oder eine Kundenreklamation ist, stets wird man sich anhand von Systemarchitektur, Softwaredesign, Schaltplan etc. auf die Suche nach den möglichen Ursachen machen. Fehlerhafte Dokumente sind daher im doppelten Sinn gefährlich. Eine besondere Bedeutung kommt der Struktur von Anforderungen zu, insbesondere der Bedeutung der Begriffe Funk­tion und System. Eine Fehleranalyse beruht grundsätzlich auf einem Funktionsfeh-ler (sollte es zumindest). Aus rein funktionaler Sicht ist ein Systemfehler unkri-tisch, solange die geforderte Funktionalität gewährleistet ist. Dies kann zwar zu latenten Fehlern im Sinne der ISO 26262 führen, aber die Relevanz wird üblicher-weise mittels einer FMEA untersucht.

Die Analyse von Funktionsfehlern beginnt dementsprechend bei der Definition der Funktion und wird auf das System und somit die Spezifikation des Systems (bzw. der Systeme) ausgedehnt. Wenn nun aber die Dokumente schon schlecht struktu-riert sind, dann werden die Analysen und insbesondere die Fehlerbäume nur in den seltensten Fällen brauchbare Ergebnisse liefern.

Funktionen und Systeme

A

Action Item Liste 179Ausgangssignale 23

B

Butterworth-Filter 164

C

Coding Guideline 109Compiler Issues 109

D

Document Management 109Draft Version 178

E

Eingangssignale 23Error 85Externe Komponenten 253

F

Fehlerbaum – Herleitung des initialen 69 – initialer 47

Fehlerbaumanalyse – qualitativ 227

Fehlerbäume – Checkliste 264

Funktion 18Funktionsanalyse 44

H

Hardware Fault Tree 143

I

Item 37

K

Kommunikation 51Komponenten 21Komponentenebene 21Kondensatoren 171

L

LIN-Kommunikation 51

M

Meeting Minutes 188Method Description 183

Q

Qualitätskriterien eines Fehler-baums 259

Index

334  Index

R

Rahmenanalyse 213Review Meeting 176, 183Review Report 178, 187

S

Safety Goal 36Scheibenwischer 18Sicherheitsanalyse 261Sicherheitsmaßnahmen 233Sicherheitsziele 38Signalarten 23Signale – analoge 50 – digitale 48 – Fehlerfälle 48 – pulsweitenmodulierte 51

Signalrauschen 53Software-Bug 123Software-FTA 101Spannungsteiler 144Standardmodelle von Spezifikationen 21Standard Patterns 71Standard-Systemmodell – der Sw-Funktion 111

Subsystem 20Subsystem HW In Key 84Subsystem HW In Wiperswitch 82Subsystem HW Out Wipermotor 84

Subsystem HW Out Wiperswitch 84Subsystem uC 84Sw-Funktion 105 – Spezifikation 106

System 18, 24Systemausfälle 47System ECU 66, 82System Fahrer 53System Fahrzeug 59System Scheibenwischer 64Systems Review Meeting 180

T

Tiefpassfilter 163Top-Ereignis 35, 113

U

Use Cases 19

V

Verification Fault Tree 175Verifikationsmaßnahme 176

Z

Zustandswechsel 41