Fault Tree Analysis verification

Rothbart, G. et al., 1981, Verification of Fault Tree Analysis, Vols. 1 and 2 EPRINP-15 May. 

The first step of safety verification is to verify that the software requirements are consistent with or satisfy safety constraints. Safety verification exists to provide evidence that associated risk has been reduced or eliminated [1]. Safety verification is not the same as functional verification. Functional verification assures that the software fully satisfies its specifications, while safety verification uses the results of the safety analysis process to assure that the software meets the safety requirements [20]. The safety verification can be done in two ways [1] (1) static analysis which looks over the code and design documents of the system (e.g. fault tree, formal verification) and (2) dynamic analysis requires the execution of the software to check all of the systems safety features. Static analysis is the same as a structured code review. Systems can be proven to match requirements, but it will not catch any safety states that the requirements miss [Ij. The dynamic analysis has the ability to catch unanticipated safety problems, but it cannot prove that a system is safe (e.g. software testing). 

The techniques for quantifying the predicted frequency of failures are just the same as those previously applied to plant availability, where the cost of equipment failure was the prime concern. The tendency in the last few years has been towards a more rigorous application of these techniques (together with third-party verification) in the field of hazard assessment. They include Fault Tree Analysis, Failure Mode Effect Analysis, Common Cause Failure Assessment, and so on. These will be explained in Chapters 5 and 6. 

A hierarchical functional decomposition could be applied similar to a positive Fault Tree Analysis , if be applying with the lowest function DeMorgan s law , a complete set of malfunction for the lowest malfunction could be evaluated. If these malfunctions would be analyzed from the bottom to the top (potential violations of safety goals) verification for completeness could be demonstrated. This bottom-up approach could be done by means of an FMEA, so that additional safety mechanism could be defined as measures of the FMEA (Fig. 4.67). 

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. 

Used in conjunction with ISA-TR84.00.04-2005 Part 1, the example set forth in this technical report is provided to illustrate howto apply ANSI/ISA-84.00.01-2004 Parts 1-3 (lEC 61511 Mod). It is intended to demonstrate one method to meet the requirements of the standards. The reader should be aware that ANSI/ISA-84.00.01-2004 Parts 1-3 (lEC 61511 Mod) is performance based, and that many approaches can be used to achieve compliance. Some of the methods applied in this example include what-if and HAZOP techniques for hazard and risk analysis, LOPA for allocation of safety functions to protection layers, fault tree analysis for SIL verification, and ladder logic to document the application software requirements. Other techniques and tools could be utilized at each of these steps in the safety lifecycle to meet the requirements of the standards. 

In this study detailed fault trees with probability and failure rate calculations were generated for the events (1) Fatality due to Explosion, Fire, Toxic Release or Asphyxiation at the Process Development Unit (PDU) Coal Gasification Process and (2) Loss of Availability of the PDU. The fault trees for the PDU were synthesized by Design Sciences, Inc., and then subjected to multiple reviews by Combustion Engineering. The steps involved in hazard identification and evaluation, fault tree generation, probability assessment, and design alteration are presented in the main body of this report. The fault trees, cut sets, failure rate data and unavailability calculations are included as attachments to this report. Although both safety and reliability trees have been constructed for the PDU, the verification and analysis of these trees were not completed as a result of the curtailment of the demonstration plant project. Certain items not completed for the PDU risk and reliability assessment are listed. 

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. 

---