RESOLUCIÓN N° 489/MAYEPGC/

The following sections discuss FTA topics that are relevant to aerospace applications. Figure 9- 1, extracted from the NASA PRA Procedures Guide [1], shows the role of the FT modeling in a typical PRA. The block labeled “Logic Modeling” corresponds to event tree and fault tree modeling of accident sequences (accident scenarios) as discussed previously in Section 1.6 of this handbook. Because FTs are workhorses of a PRA, and can be used as stand-alone models, this handbook focuses on fault trees modeling techniques. For information on scenario-based PRA modeling, the reader should consult Reference 1.

Certain PRA model considerations for aerospace applications are discussed in Section 9.1. The last two sections of the chapter describe two specific uses of FTs either in a PRA or as a stand- alone —to support development of a new design (an important current use by NASA) and to support analysis for an implemented design such as the Space Shuttle.

Objectives Definition System Familiarization Initiating Events Identification Structuring Scenarios Logic Modeling Quantification and Integration Uncertainty Analysis Data Collection and Analysis

Interpretation of Results Sensitivity Analysis Importance Ranking

Figure 9-1. A Typical PRA Task Flow

9.1 Separating Qualitative and Quantitative Considerations in FTA as Exemplified in a

Phased Mission Analysis

For certain aerospace applications, the goal is to model the different phases of a mission. An example is the Space Shuttle, which can be modeled as having three phases in its mission— Ascent, Orbit and Entry. If a system goes through different phases in a mission then the failure

Focus of this handbook

phases can be ignored. However, when the fault trees are quantified for the different phases then the interactions among the different phases need to be taken into account. For example, if there is an event in the fault tree that describes the component being failed in a given phase, then the component may be failed due to its failing in the given phase or may be failed due to its failing in a previous phase. When the probability of the component being failed in a phase is quantified then the probabilities of the component failing in the past phases need to be evaluated as well as in the present phase. In this quantification, different component failure rates in the different phases may be used as well as different repair criteria. A number of computer codes handle these inter-phase evaluations to simplify the analyst’s tasks. This separation of the qualitative and quantitative considerations in phased missions is an example of the general separation of the qualitative and quantitative considerations in FTA in general.

9.2 Fault Trees for System Design

A fault tree can also be constructed for a system that is being designed as well as for a system that is implemented and operating. Even though the general principles used in constructing these two different types of fault trees are the same, there are differences in the strategies used, in the scope of the fault trees, and the level of resolution of the fault trees. The basic principles applicable to the construction of fault trees for design are discussed here. Fault trees constructed for already operating systems are discussed in the next section.

In constructing a fault tree for a system that is being designed, the detailed specifications for the system or the detailed schematic for the system are not generally available. Often only the top- level logic for the system is available, this consisting of its basic functions and general interfaces. Even with this limited information, a fault tree can be an important tool in assisting in the design of the system. Furthermore, a fault tree can serve as a primary tool for providing a performance- based design for the system.

For evaluating a system design, the fault tree to be developed is a top-level fault tree showing the general logic and relationships for the design. To quantify the fault tree, where specific data are not available, generic data from published data sources are used. When using generic databases, data on heritage systems, suitably modified to take into account risk significant design changes, are used and the data that brackets the component or subsystem that is being investigated is determined by comparing the general characteristics of the design with the characteristics associated with the generic data. The bracketed results from the design fault tree gives useful information on the range of failure probability or reliability achievable with the design. One of the example fault trees that will be described was used for a system design.

When the design fault tree is quantified the importances and sensitivities of the different parts of the design are obtained. This is useful information and shows what parts of the system drive the failure probability and reliability. The designer can then focus on the important and sensitive parts. One of the greatest benefits resulting from carrying out any FTA is the establishment of design priorities for all elements of the fault tree and thereby for the design effort. Often, only a few of the elements, or contributors, will drive the failure probability and reliability. The FTAs that have been performed in the past generally show that less than 20% of the contributors dominate the failure probability and the reliability. Often, in fact, 90% or more of the result is driven by as little as 10% or less of the contributors.

The application of the design fault tree can be carried one step further. In this case it can be used as a tool for performance-based design. The example of the design fault tree that will be described is an application of FTA for performance-based design. In carrying out a performance-based fault tree evaluation, a failure probability goal is assigned to the top event. This goal is then allocated down through the fault tree to the modules and subsystems in the design. The allocated values that are obtained for the modules and subsystems indicate whether the design has the capability of meeting the top goal. In other words, these values indicate what is sometimes called the “achievability” of the design goal. Various allocations can be selected to determine their feasibilities. Furthermore, by incorporating CCFs into the fault tree evaluations, not only can the number of redundant elements required be determined but also whether diversity is required as opposed to simple identical unit redundancy. For diversity, the redundant capabilities must be provided without relying on identical units to guard against common dependencies. It can be further required that proven technologies be used to provide the functions. In this case, the allocated values provide performance requirements to the suppliers of the system. Design fault trees can therefore be important tools to assist in focusing the design effort and providing performance-based requirements for the design.

9.3 Fault Trees for an Implemented System

When a fault tree is constructed for an implemented and operational system, detailed design and operational information is generally available. In this case, the goal in carrying out a FTA is often to improve the system or to diagnose problems within the system. The fault tree may also be constructed to monitor system safety or reliability performance. When a fault tree is constructed for an implemented system the tree is developed down to a level containing the contributors of interest and for which data is available. This often means constructing the fault tree down to the major component level, e.g. to a valve, pump, and control module level. Because of their low failure probabilities, piping and wiring is not generally modeled unless the objective is specifically to go to this level of detail or if there is suspicion that global effects, such as aging or wearout, have increased the failure probabilities. Also, fault trees are generally not developed to a detailed contact or part level for a component such as a valve stem because of the lack of data to support quantification of such detailed models.

The capability of a FTA to establish priorities among fault tree elements is very useful. Different importance measures may be calculated in FTA for different applications. By including resource expenditures, burden-to-importance ratios can be calculated to show the imbalances between resource expenditures and the importance to risk. Using these importance measures and using cost-benefit principles, resource expenditures on operational systems can be optimally re- allocated to maximize their effectiveness. In many past applications, resources have been re- allocated resulting in significant reductions in total resource expenditures with no impacts on the failure probability or risk. In particular cases, resource expenditures have been reduced as much as 40% or more. If the total resource expenditure is held fixed then the resources can be re- allocated to significantly reduce the current failure probability and risk. In many cases the failure probabilities have been significantly reduced, sometimes by a factor of 10 or more, using

elements in a system can be established and input to the fault tree to determine the system implications. Performance criteria on the system can then be used to determine the appropriate actions to take. Monitoring of system performance can also be conducted by periodically updating the fault tree quantification with current data. Formal approaches exist for incorporating new data into the baseline fault tree quantification. Defect data and soft failure (partial failures) data can also be incorporated, in addition to hard failure data. The use of FTA in this way can be referred to as a “proactive” use.

The FTA can also be used reactively. In this case, when a system failure occurs the fault tree can be used to diagnose the potential causes and to identify the most effective corrective measures. If a component failure occurs, the fault tree can be used to identify the significance of the failure with respect to the overall failure of the systems and identify those remaining components in the system that are most important in preventing the top event (precursor or “near miss” analysis). This evaluation can sometimes be performed using the importance measures produced by the FTA.

9.4 References

1. Probabilistic Risk Assessment Procedures Guide for NASA Managers and Practitioners, NASA, Version 1.1, August 2002.