Neue Ideen zur Fehlerbaumanalyse Dipl.-Ing. Bernhard Kaiser Berliner Arbeitskreis Sicherheit 27.08.03 Neue Ideen zur Fehlerbaumanalyse Dipl.-Ing. Bernhard Kaiser Hasso-Plattner-Institut für Softwaresystemtechnik Tel. (0331) 5509-158 e-mail:bernhard.kaiser@hpi.uni-potsdam.de

Übersicht Integration Entwicklung + Sicherheitsanalyse Component Fault Trees Temporale Semantik von Fehlerbäumen: Stand der Technik Eigener Vorschlag: Zustand vs. Ereignis Zusammenfassung und Diskussion

Konstruktion vs. Sicherheitsanalyse Risk Analysis konstruktiv: Anforderungsanalyse, Spezifikation analytisch: Validation konstruktiv: Entwurf Implementierung analytisch: Verifikation Hazard Analysis +

Integration von Modellen Die Techniken für Systemmodellierung und für Sicherheitsanalyse von eingebetteten Systemen sind bislang noch nicht konsistent verbunden. 2. Bedarf für automatisierbare Integration verschiedener Beschreibungstechniken besteht, da die Komplexität heutiger Systeme eine manuelle Durchführung der Sicherheits/Zuverlässigkeitsanalyse unmöglich macht. Arbeitsansatz: Integration vorhandener Techniken über ein durchgängiges Framework (formale "Universal"-Sprache + Toolsuite)

Integration, z.B. Fehlerbaum/Zustandsdiagramm

Anforderungen an Sprache für Framework Systemaufbau und -verhalten Korrektes und unkorrektes Verhalten ausreichende Ausdrucksmächtigkeit (Zeitaussagen, Wahrscheinlichkeiten, Kausalfolgen, Annahmen) Verschiedene Modelle pro Komponente Qualifier z.B. Severity: functional / degraded / safe-failed / safety-critical Globale Referenzierung aller Betrachtungseinheiten z.B. Filename.xml:Component3.FTAModel.Event7 Abhängigkeiten für Analyse verfolgen Separierung von Tool-Spezifika (z.B. Graphik)

Erweiterung des Fehlerbaummodells Gerichtete azyklische Graphen statt Bäume bereits in der Vergangenheit vorgeschlagen Neues Komponentenkonzept 2003 veröffentlicht und in UWG3 realisiert Temporale Aussagen, State/Event-Semantik Untersuchung der stochastischen Gesetzmäßigkeiten Sichtung verwandter Arbeiten Abbildung auf Markovketten, Automaten oder Petri-Netze Behandlung von mehr als zwei Zuständen wichtig für Einbindung von Automatenmodellen Idee: Multi-valued Decision Diagrams

Übersicht Integration Entwicklung + Sicherheitsanalyse Component Fault Trees Temporale Semantik von Fehlerbäumen: Stand der Technik Eigener Vorschlag: Zustand vs. Ereignis Zusammenfassung und Diskussion

Classical Module Concept = + Modules are Independent Subtrees. Modules allow decomposing the Fault Tree.

Analysis by Modules Each Modul can be evaluated independently. The output of a Module is like a Basic event.

Deficiencies of Classical Module Concept Technical Components often influence each other => Technical Components need not be Modules!

Deficiencies of Classical Module Concept Module Borders may be orthogonal to Component Borders Attachment of (partial) Fault Trees to Components is not possible, if Components have external influences Division of Labour (e.g Supplier / OEM) is not possible Modelling of some Component by other models than Fault Trees is not possible

+ = New Component Concept "Component" means Technical Unit. Components may have Interfaces (Ports).

Analysis by Components out1 = in1 & e1 => P(out1) = P(in1) * P(e1) Components are Boolean Formulas. Quantitative Analysis is possible after all Formulas have been integrated.

Directed Acyclic Graphs Repeated Event Unique Event

Components are Directed Acyclic Graphs Directed Acyclic Graphs extend Trees Explicit Repeated Events become Obsolete Globally unique IDs distinguish Events Each Component is an ID Namespace

Component Reuse ... contains 2 instances of ... Same Type of Component can be referenced several times All internal events are independent

Component Reuse Components may be developped independently File BrkSys.xml File WhlBrk.xml Components may be developped independently Components may be stored in different files or repositories Division of Labour is possible

Differences Traditional FTA Downward Hierarchy Modules must be independent Modules <-> technical units Modules are like Basic Events Modules have a Probability Tree Structure Repeated Events No hierarchical Name Structure New Component Concept Inward Hierarchy Components with input ports Components = technical units Components are Formulas Modules have associated BDD Directed Acyclic Graph Unique Events Component = Name Space

Übersicht Integration Entwicklung + Sicherheitsanalyse Component Fault Trees Temporale Semantik von Fehlerbäumen: Stand der Technik Eigener Vorschlag: Zustand vs. Ereignis Zusammenfassung und Diskussion

Related Work Dugan, Coppit, Sullivan: Dynamic Fault Trees (Dynamic Parts analyzed by Markov Models) Thums, Reif, Schellhorn: FTs with Interval Timed Logic Górski, Wardzinski: FTA with timed Gates (Specified in Z) Buchacker: FTA + Stochastic Petri Nets Hura, Atwood: FTA + Petri Nets McDermid: FTA + Finite State Machines, autom. Generation Leveson: Software Fault Trees Segala et al: Probab. Automata Liggesmeyer, Rothfelder: Automatic Generation of FTs

Übersicht Motivation: Integration Entwicklung + Sicherheitsanalyse Component Fault Trees Temporale Semantik von Fehlerbäumen: Stand der Technik Eigener Vorschlag: Zustand vs. Ereignis Zusammenfassung und Diskussion

Zustands-/Ereignis-Semantik Im Gegensatz zu existierenden Ansätzen hier Unterscheidung: Zustand (dauert an) Ereignis (Punktuelles Ereignis) Erweiterte FT-Gates mit typisierten Eingängen/Ausgängen Zustände/Ereignisse finden sich auch in anderen Modellen wieder Grundlage für gemeinsame formale Modellierungssprache

Neue Gates: Beispiele für AND Es gibt kein simples AND zwischen zwei Events!

Formal Language for Integration

Integration of Fault Trees traditional: proposed: States and Events become distinguishable. Typed Gates provide correct calculation rules.

Integration of Markov Chains traditional: proposed: Transitions are displayed as probabilistic events. Events can be referenced by causal edges.

Integration of StateCharts for Software traditional: proposed: Transition are displayed as events. Causal relations become visible.

Software with Faults Additional states and transitions mark faulty behaviour. Need for manual techniques such as FMEA / HAZOP.

Safety Analysis Manual Steps: Enrichment of Design Models by faulty behaviour Safety modelling by traditional techniques (FTA, Markov Chain) Translation of models into Formal Framework Language Combination of Component Models at their Ports Recursive resolution and analysis of required properties Transformation to BDDs, MDDs, Stochastic Petri Nets, Markov Chains Probabilistic Analysis by traditional techniques

Übersicht Motivation: Integration Entwicklung + Sicherheitsanalyse Component Fault Trees Temporale Semantik von Fehlerbäumen: Stand der Technik Eigener Vorschlag: Zustand vs. Ereignis Zusammenfassung und Diskussion

Zusammenfassung und Diskussion Integration von Beschreibungstechniken und Sicherheitsanalysetechniken für eingebettete Systeme Formale Sprache vermittelt zwischen Modellen Etablierte Modelle bedürfen teilweise der Formalisierung Komponentenkonzept für Fehlerbäume ist eingeführt Vorschlag: Zustands-/Ereignissemantik für Fehlerbäume Werkzeug UWG soll Konzept realisieren (Sprache: XML)