Fault Tree Analysis validation

The overall concept of all of the following tools is that of risk analysis or risk assessment. Risk analysis helps to decide whether an aspect is GMP-critical or not. The risk analysis can be performed in a formal or more informal way. Following are two popular and import types of risk analysis. Another method, the fault tree analysis (FTA), has recently been used in the area of computer validation. This method is not described here, as it is a complex form of risk analysis. 

Validating the Development Assurance Level Fault Tree Analysis... 

Unfortunately, the state of the art in software hazard analysis appears to be woefully lagging. Even though traditional hazard analysis techniques like fault tree analysis and tailored versions of operating hazard analysis may be applied to the evaluation of software, validated, specific methods of software hazard analysis appear lacking. 

Those are also typical questions for deductive methods such as HAZOP or the fault tree analysis (FTA). The malfunctions (or error modes) also show in the tables of ISO 26262, part 5, Appendix D, which represent the foundation for the diagnostic coverage. Which of those error modes are relevant depends on the requirements and their context which are imposed on the functions. This is why at this in-depth level not only the architecture is analyzed but also the design and the realization. Therefore, such analyses are often on lower component level and performed by means of a Design-FMEA and define the basis for the design verification and validation (DV). 

Phuh Westerheide, Quirk, Taylor and Voges, Software fault tree analysis in Verification and Validation of Real time software ed W.J.Quick Springer Verlag 1985. 

In this context, the top event in a fault tree can be an accident or a conflict [45]. The probabilities for accidents can come from classic accident analysis [42], the corresponding ones for conflicts or mistakes (being at the other end of the tree structure) are not generally known and hard to extract [35, 42]. An example of such calculations as well as further information, for example, on validity of the method, can be found in [45]. The method seems to be able to generate sound results, especially on the connections between conflicts and accidents, although many assumptions are basically needed during evaluation [36]. 

Having defined the dependability criteria within the specification, the purpose of this activity will include an investigation of the relationship between the development lifecycle (including the proof of safety invariants, refinement of the dependability criteria/perspectives and validation/verification approaches) and the dependability lifecycle which includes safety analysis (eg, the relationship between fault trees, proof of safety invariants, and static analysis tools), fault detection/protection and failure detection/containment. 

The quantification process follows the large fault-tree linking method (Reference 4). The unavailability and unreliability values for the electric power system are obtained from a Markov model, which requires the setting of flags to turn parts of the linked model off and on. The review teams expressed concern about the complexity of the quantification process and the fact that several computer programs used by the PRA staff for the quantification have not been validated. However, no problems have been found, and the independent systems analysis by LANL has shown reasonable agreement with the SRS PRA. 

---