Berliner Arbeitskreis Sicherheit 27.08.03
Download
1 / 32

Dipl.-Ing. Bernhard Kaiser Hasso-Plattner-Institut für Softwaresystemtechnik Tel. (0331) 5509-158 - PowerPoint PPT Presentation


  • 73 Views
  • Uploaded on

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:[email protected] Integration Entwicklung + Sicherheitsanalyse Component Fault Trees

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Dipl.-Ing. Bernhard Kaiser Hasso-Plattner-Institut für Softwaresystemtechnik Tel. (0331) 5509-158' - jereni


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

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:[email protected]


Bersicht

Integration Entwicklung + Sicherheitsanalyse

Component Fault Trees

Temporale Semantik von Fehlerbäumen: Stand der Technik

Eigener Vorschlag: Zustand vs. Ereignis

Zusammenfassung und Diskussion

Übersicht


Konstruktion vs sicherheitsanalyse
Konstruktion vs. Sicherheitsanalyse

Risk

Analysis

konstruktiv:

Anforderungsanalyse,

Spezifikation

analytisch:

Validation

konstruktiv:

Entwurf

Implementierung

analytisch:

Verifikation

Hazard

Analysis

+


Integration von modellen
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)



Anforderungen an sprache f r framework
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

Erweiterung des Fehlerbaummodells


Bersicht1

Integration Entwicklung + Sicherheitsanalyse

Component Fault Trees

Temporale Semantik von Fehlerbäumen: Stand der Technik

Eigener Vorschlag: Zustand vs. Ereignis

Zusammenfassung und Diskussion

Übersicht


Classical module concept
Classical Module Concept

=

+

Modules are Independent Subtrees.

Modules allow decomposing the Fault Tree.


Analysis by modules
Analysis by Modules

Each Modul can be evaluated independently.

The output of a Module is like a Basic event.


Deficiencies of classical module concept
Deficiencies of Classical Module Concept

Technical Components often influence each other

=>

Technical Components

need not be Modules!


Deficiencies of classical module concept1
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
New Component Concept

+

=

"Component" means Technical Unit.

Components may have Interfaces (Ports).


Analysis by components
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
Directed Acyclic Graphs

Repeated Event

Unique Event


Components are directed acyclic graphs
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
Component Reuse

  • Same Type of Component can be referenced several times

  • All internal events are independent

... contains

2

instances

of ...


Component reuse1
Component Reuse

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

Differences


Bersicht2

Integration Entwicklung + Sicherheitsanalyse

Component Fault Trees

Temporale Semantik von Fehlerbäumen: Stand der Technik

Eigener Vorschlag: Zustand vs. Ereignis

Zusammenfassung und Diskussion

Übersicht


Related work
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


Bersicht3

Motivation: Integration Entwicklung + Sicherheitsanalyse

Component Fault Trees

Temporale Semantik von Fehlerbäumen: Stand der Technik

Eigener Vorschlag: Zustand vs. Ereignis

Zusammenfassung und Diskussion

Übersicht


Zustands ereignis semantik
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
Neue Gates: Beispiele für AND

Es gibt kein simples AND zwischen zwei Events!



Integration of fault trees
Integration of Fault Trees

traditional:

proposed:

States and Events become distinguishable.

Typed Gates provide correct calculation rules.


Integration of markov chains
Integration of Markov Chains

traditional:

proposed:

Transitions are displayed as probabilistic events.

Events can be referenced by causal edges.


Integration of statecharts for software
Integration of StateCharts for Software

traditional:

proposed:

Transition are displayed as events.

Causal relations become visible.


Software with faults
Software with Faults

Additional states and transitions mark faulty behaviour.

Need for manual techniques such as FMEA / HAZOP.


Safety analysis
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


Bersicht4

Motivation: Integration Entwicklung + Sicherheitsanalyse

Component Fault Trees

Temporale Semantik von Fehlerbäumen: Stand der Technik

Eigener Vorschlag: Zustand vs. Ereignis

Zusammenfassung und Diskussion

Übersicht


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)


ad