Model-Based Safeta AnalysisApplication of Traditional and...

Application of Traditional and New Safety Analysis Techniques in

Model-Oriented Design

Thomas PeikenkampOFFIS

Model-Based Safety Analysis - 05/05/20062

Structure

•Introduction, Objectives, General Methodology•Safety Analysis Techniques•Used Technologies•Timing Problems•Extending the Scope of the Method


Introduction

• Safety Assessment Process

• Issues wicth traditional FTA and FMEA

• Objectives of model-based safety techniques

• Suggested methodology

• Implementation overview


Safety Assessment Process

• From Aerospace Recommended Practice - ARP 4754 “Certification Considerations for Highly Integrated or Complex Aircraft Systems”:

• The safety assessment process- is parallel to the design process- includes specific assessments conducted and updated during all phases of

the system development


Objectives

• To represent safety properties and requirements in the same notation of the system model

• To perform the safety analysis having the possibility to trace back through the results in the system model in order to understand unexpected behavior


Issues with classical fault tree analysis

• The coherency issue- How do models used for safety analysis relate to the actual design?- How can safety engineers keep track with ongoing evolvements and changes

in design models?• The plausibility issue

- How can a system designer relate a cut set to „her“ model?- How can she understand, how the cut-set can arise?

• The accuracy issue- How can mission phases,- How can numerical threshholds- .... be assessed without gross overapproximation?

• The completeness issue- How can a safety designer assert, that all minimal cut sets have been

identified?


Issues with classical FMEA

• The coherency issue ( as for FTA)

• The plausibility issue- How can the propagation of a failure be traced in the system

• The accuracy issue ( as for FTA)

• The completeness issue- How can it be assessed that all relevant effects have been considered?


Extended System Model

Results

Model analysis& verification tool

Safety Requirementscapturing

Model capturing

Failure Modescapturing

STEP 2

The Failure Modes are captured in the model providing an Extended System Model

STEP 3

The Safety Requirements are identified and introduced in the tool

STEP 1

A Statemate model is captured

STEP 4System model analysis based on verification techniques are used to find the cut-sets (combination of Failure Modes) that lead to the violation of the Safety RequirementsSTEP 5

Extraction of results (cut-sets, simulation traces). Output towards standard safety analysis tools.

Methodology


Implementation Overview

• Based on the aforementioned methodology techniques for the analysis of Statemate designs were developed ( STSA)

• Available as Plugin to Statemate• STSA supports

- Fault Tree Analysis - Failure Mode and Effect Analysis- Common Cause Analysis- Mission and Reliability Analysis- Testability Analysis- Human Error Analysis

• Based on a unique system model with a unique extension


Is it possible to violate a certain

safety requirement?

Safety

Is it possible for afault to

occur undetected?

Testability

Is it possible to continue flight in a failed configuration?

Operational Reliability

Will an erroneouslyflight procedure lead

to a safetyrequirement violation?

HumanError

Will a list of impacteditems violate independency

assumptionsof a functional model?

Common Cause Analysis

Applicability

STSA


Safety Analysis Techniques

• Fault Tree Analysis (FTA)

• Failure Mode and Effect Analysis (FMEA)

• Required analysis technology

• Detailed analysis: timing behaviour

• Other types of models and failures


Fault Tree Analysis (FTA)

• Traditional technique to identify failure combinations that are causal for a given safety-critical event (top-level event, TLE)

• Qualitative and quantitative (probabilistic) analysis possible

• Challenge: Take all possible inputs of the system into account

• Challenge: Consider dynamic systems

• Challenge: Consider failure combination even if they are distributed (over the system and/or over time)


FTA Input 1: Statemate Model


FTA Input 2: Failure Modes


FTA Input 3: Top-level Event (TLE)

Loss of all wheel braking should not occur

P_stable_X_steps_implies_finally_Q

Formalized by instantiation of STSA patten

(Pedal pressed) implies (Green pressure high) or (Blue pressure high))

Speaking in terms of the system‘s interface


FTA - Steps

Consider all runs of thesystem

F1F2

F4

F5

F3

Extract occuring failuresfrom each run (cut sets)

Check whether the failureswere necessary (minimality)

F1

F3

F5

Check for each run whetherit leads to top-level event TLE

TLE

Produce fault tree from thecollection of minimal cutsets ...


FTA - Result


FMEA - Failure Modes and Effects Analysis

• Established technique to investigate the effect of failures

• Re-use of existing failure models

• Full platform integration allowing for synergies with existingtechnology (e.g. CCA)


FMEA Input 1: Statemate Model


FMEA Input 2 – Failure Modes


And a set of System Failure Events or …

FMEA - Input (3)


FMEA - Input (3)

Loss of all wheel braking should not occur

P_stable_X_steps_implies_finally_Q

Formalized by instantiation of STSA patten

(Pedal pressed) implies (Green pressure high) or (Blue pressure high))

Speaking in terms of the system‘s interface

… Safety Requirements

Same as for FTA


And creates a FMEA like table in Excel format

FMEA - Output


Also: overview of System Failure Events

FMEA - Output (2)


And information about involved Failure Modes

FMEA - Output (3)


Traces for user-selected Cause/Impact pairs

FMEA - Output (4)


• Can consider consequences of more than one failure

• Can reuse cut sets of FTA

• Can produce traces for cause/impact pairs

• Further uniformisation with other analysis tasks (eg. FTA): Minimal duration of events and an initialization phase can be specified

• Several techniques to implement failure propagation

FMEA - Features


Analysis Technology

• To address the needs of particular analyses, severaltechnologies are exploited

• Among the technologies used we have- Verification (invariant checking)- Bounded Model Checking- Reachability Analysis

• Their most important features are discussed in the following ...


Technology – Verification

• Can standard verification techniques be used to perform safetyanalyses?

• Reminder: Formal Verification checks ...

... for a given system model

LEVEL > ALARM_LOW_LEVEL and LEVEL < ALARM_HIGH_LEVEL

... and a given safety requirement

... whether themodel satisfiesthe requirement


Technology - Verification

• to check for each combinations of failures whether it leads to aviolation of the safety requirement

• in particular to execute 2n verification runs when n failures are present.

• � prohibitively expensive

Using formal verification to obtain results comparable to fault tree analysis requires


Technology – Bounded Model Checking

However, there may be more thanthe identifiedcut sets

BMC is able to identify

• cut sets

• behaviour underlying the identified cutsets


Technology – Bounded Model Checking

• Given extended system model (i.e. model extended withfailures) and a top-level event, BMC may answer question of theform

- Is it possible to reach a top-level event within N steps (assuming that thefailures of given cut set are activated)?

• Questions like- What is a complete collection of cut sets?- Given a collection of cut sets: Is it complete?

can (in practice) not be answered by BMC

• � BMC techniques need to be complemented for typical safetyapplications


Technology – Reachability

• How: Compute all states in the extended system model that canbe reached

• Allows for complete traversal of the model

• Does not require to put a bound in the analysis question like „isit possible to reach safety critical state within n steps“.

• Causality of failures can be computed easily

• More complex than invariant checking (it is not goal-oriented)

Combination of techniques appropriate


General objectives:

• to understand if there are relationships among the occurrence of the system components failures (ordering)

• to understand if the duration of the failure is significant in respect to the safety requirement (duration)

• to understand if the amount of the time interleaving among the occurrence of the system components failures is significant in respect to the safety requirement (delay)

• to understand if the impact of failures are related to a specific system phase (system phase)

Detailed Analyses: Timing


• Fault trees (cut sets, RBDs, ...) provide static information aboutdynamic systems.

• More dynamic information useful- to avoid overly pessimistic results- to obtain better quantitative results

• ISAAC approach: Provide dynamic information in case the staticis not sufficient.

Timing


Monitor fails Command fails

Usually failures do nothappen simultaneously

Monitor failsCommand fails

What if they order ischanged?

For a given cut set the platform checks whether the ordering of failures (in this cut set) is important.

Timing


For Testability

Message 2

Message 5

Message 3

Display

BITE

Other models can be added in the ISAAC framework allowing to treat other aspects related to complex system design.

System

PROCEDURE MODELPROCEDURE MODEL

VISIONVISION MOTORMOTOR

PROCESSINGPROCESSING

LEARNINGLEARNING

For Human Error Analysis

Cognitive Model

Composition of these models allows to simulate and analyze complex interactions in a

unified frame

Composition with Other Models

For Common Cause Identification

Geometric Model


Testability

• Subject of the analysis is the Built In Test Equipment (BITE)

• The testability of the BITE is the capability of the system - to detect its safety critical fault configurations, - to alert the crew about the occurrence of unsafe system operating conditions

through the generation of appropriate warnings and, possibly, - to take (or suggest) corrective actions

• The goal of the testability analysis is to check to what extent the above objectives are met

• The need is to design and verify testability properties of a system in an effective way


Testability

To check• full coverage of safety critical fault

configurations• analysis of situational awareness

(capability in isolating the causes of a given failure in order to take the appropriate corrective actions)

• to analyze if SW & HW used for testability does not lend itself to hazardous situations (e.g. provision of false warning)

Fault DetectionAnalysis

Fault IsolationAnalysis

False AlarmAnalysis


Common Cause Analysis - Example


Conclusion

• The method provides “unambiguous way” to share information between safety and design

• “Formal models” including both nominal and failed behaviors can be checked against safety related requirements

• Analyses traditionally performed in different environments can be performed in the same framework


Conclusion

The result is:

• To improve the confidence of having considered all the aspects (functional, installation, operational, testability, human factors)

• To ensure awareness of safety-related aspects during the design process, since the early phases of development

• To alleviate the analyst job, by means of automated analysis tools

• To facilitate the verification of possible design alternatives


Conclusion: Contributions to Extended System Model (ESM)

ESM

System Designer Safety Engineer

• functions

• requirements

• nominal behaviour

• safety requirements

• completeness of ESM

• capturing failures

• disfunctional behaviour

Model-Based Safeta AnalysisApplication of Traditional and...

Documents

Transcript of Model-Based Safeta AnalysisApplication of Traditional and...