Fault Tree Handbook - Nuclear Regulatory Commission

Transcription

NUREG-0492Fault Tree HandbookU.S. Nuclear RegulatoryCommission

NUREG-0492Fault Tree HandbookDate Published: January 1981W. E. Vesely, U.S. Nuclear Regulatory CommissionF. F. Goldberg, U.S. Nuclear Regulatory CommissionN. H. Roberts, University of WashingtonD. F. Haasl, Institute of System Sciences, Inc.Systems and Reliability ResearchOffice of Nuclear Regulatory ResearchU.S. Nuclear Regulatory CommissionWashington, D.C. 20555For sale by the U.S. Government Printing OfficeSuperintendent of Documents, Mail Stop: SSOP, Washington, DC 20402-9328

Available fromGPO Sales ProgramDivision.of Technical Information and Document ControlU.S. Nuclear Regulatory CommissionWashington, DC 20555Printed copy price: 5.50andNational Technical Information ServiceSpringfield, VA 22161

TABLE OF CONTENTSIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viiI.Basic Concepts of System Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 1-11.2.3.4.II.l.1-11-31-71-9Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . .The "Parts Count" Approach . . . . . . . . . . . . . . . . .Failure Mode and Effect Analysis (FMEA) . . . . . . . .Failure Mode Effect and Criticality Analysis (FMECA)Preliminary Hazard Analysis (PHA) . . . . . . . . . . . . .Fault ffazard Analysis (FHA) . . . . . . . . . . . . . . . . .Double Failure Matrix (DFM) . . . . . . . . . . . . . . . . .Success Path Models . . . . . . . . . . . . . . . . . . . . . . .Conclusions . ; . . . . . . . . . . . . .11-111 111-211-411-411-511-511-1011-12Orientation . . . . . . . . . . . .Failure vs. Success Models . .The Undesired Event ConceptSummary . . . . . . . . . . . . .111-1111-1III-3ID-4The Basic Elements of a Fault Tree . . . . . . . . . . . . . . . . . . . . . . . . . . IV-11.2.V.Fault Tree Analysis-Basic Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . ID-12.3.4.IV.Overview oflnductive Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11-11.2.3.4.5.6.7.8.9.III.The Purpose of System AnalysisDefinition of a System . . . . . .Analytical Approaches . . . . . .Perils and Pitfalls . . . . . . . . . .The Fault Tree Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IV-1Symbology-The Building Blocks of the Fault Tree . IV-1Fault Tree Construction Fundamentals . . . . . . . . . . . . . . . . . . . . . . . . V-11.2.3.4.S.6.7.Faults vs. Failures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Fault Occurrence vs. Fault Existence . . . . . . . . . . . . . . . . . . .Passive vs. Active Components . . . . . . . . . . . . . . . . . . . . . . .Component Fault Categories: Primary, SeconAary, and CommandFailure Mechanism, Failure Mode, and Failure Effect . . . . . . . .The "Immediate Cause" Concept . . . . . . . . . . . . . . . . . . . . .Basic Rules for Fault Tree Construction . . . . . . . . . . . . . . . . .iii.V-1V-1V-2V-3V-3V-6V-8

ivVI.TABLE OF CONTENTSProbability Theory-The Mathematical Description of Events . VI-1L2.3.4.5.6.7.8.9.IntroductionVI-1Random Experiments and Outcomes of Random Experiments . VI-1The Relative Frequency Definition of Probability . VI-3Algebraic Operations with Probabilities . VI-3Combinatorial Analysis . VI-8Set Theory: Application to the Mathematical Treatmentof Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VI-11Symbolism . . ·. VI-16Additional Set Concepts . VI-17Bayes' Theorem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VI-19VII. Boolean Algebra and Application to Fault Tree Analysis . VII-11.2.3.4.Rules of Boolean Algebra . VII-IApplication to Fault Tree Analysis . VII-4S hannon's Method for Expressing Boolean Functions inStandardized Forms . VII-12Determining the:Milliinal Cut Sets or Minimal Path Sets of aFault Tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VII-15VIII. The Pressure Tank Example . VIII-11.2.IX.The Three Motor Example . IX-11.2.X.System Definition and Fault Tree Construction . VIII-1Fault Tree Evaluation (Minimal Cut Sets) . VIII-12System Definition and Fault Tree Construction . IX-1Fault Tree Evaluation (Minimal Cut Sets) . IX-7Probabilistic and Statistical Analyses . X-11. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-12. The Binomial Distribution . X-13. The Cumulative Distribution Function . X-74. The Probability Density Function . X-95. . Distribution Parameters and Moments . , . X-106. Limiting Forms of the Binomial: Normal, Poisson . X-157. Application of the Poisson Distribution to System FailuresThe So-Called Exponential Distribution . X-198. The Failure Rate Function . X-229. An Application Involving the Time-to-Failure Distribution . X-2510. Statistical Estimation . X-2611. Random Samples . X-2712. Sampling Distributions . X-2713. Point Estimates-General . X-28

TABLE OF CONTENTS14.15.16.XI.Point Estimates-Maximum Likelihood . . . . . . . . . . . . . . . . . . . X-30Interval Estimators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-35Bayesian Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . X-39Fault Tree Evaluation Techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . XI-11.2.3.Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI-1Qualitative Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI-2Quantitative Evaluations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XI-7XII. Fault Tree Evaluation Computer Codes . . . . . . . . . . . . . . . . . . . . . . . XII-11.2.3.4.5.6.Overview of Available Codes . . . . . . . . . . . . . . . . . . . . . . . . . . .Computer Codes for Qualitative Analyses of Fault Trees . . . . . . . .Computer Codes for Quantitative Analyses of Fault Trees .Direct Evaluation Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .PL-MOD: A Dual Purpose Code . . . . . . . . . . . . . . . . . . . . . . . .Common Cause Failure Analysis Codes . . . . . . . . . . . . . . . . . . . .XIl-1XII-2XII-6XII-8XII-11XII-12Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BIB-1

INTRODUCTIONSince 1975, a short course entitled "System Safety and Reliability Analysis" hasbeen presented to over 200 NRC personnel and contractors. The course has beentaught jointly by David F. Haasl, Institute of System Sciences, Professor Norman H.Roberts, University of Washington, and ·members of the Probabilistic Analysis Staff,NRC, as part of a risk assessment training program sponsored by the ProbabilisticAnalysis Staff.This handbook has been developed not only to serve as text for the System Safetyand Reliability Course, but also to make available to others a set of otherwiseundocumented material on fault tree construction and evaluation. The publication ofthis handbook is in accordance with the recommendations of the Risk AssessmentReview Group Report (NUREG/CR-0400) in which it was stated that the fault/eventtree methodology both can and should be used more widely by the NRC. It is hopedthat this document will help to codify and systematize the fault tree approach tosystems analysis.vii

CHAPTER I - BASIC CONCEPTS OF SYSTEM ANALYSIS1.The Purpose of System AnalysisThe principal concern of this book is the fault tree technique, which is asystematic method for acquiring information about a system.* The information sogained can be used in making decisions, and therefore, before we even define systemanalysis, we will undertake a brief examination of the decisionmaking process.Decisionmaking is a very complex process, and we will highlight only certain aspectswhich help to put a system analysis in proper context.Presumably, any decision that we do make is based on our present knowledgeabout the situation at hand. This knowledge comes partly from our direct experiencewith the relevant situation or from related experience with similar situations. Ourknowledge may be increased by appropriate tests and proper analyses of theresults-that is, by experimentation. To some extent our knowledge may be based onconjecture :Jd this will be conditioned by our degree of optimism or pessimism. Forexample, w may be convinced that "all is for the best in this best of all possibleworlds." Or, conversely, we may believe in Murphy's Law: "If anything can gowrong, it will go wrong." Thus, knowledge may be obtained in several ways, but inthe vast majority of cases, it will not be possible to acquire all the relevantinformation, so that it is almost never possible to eliminate all elements ofuncertainty.It is possible to postulate an imaginary world in which no decisions are made untilall the relevant information is assembled. This is a far cry from the everyday world inwhich decisions are forced on us by time, and not by the degree of completeness ofour knowledge . We all have deadlines to meet. Furthermore, because it is generallyimpossible to have all the relevant data at the time the decision must be made, wesimply cannot know all the consequences of electing to take a particular course ofaction. Figure 1-1 provides a schematic representation of these NINDIRECTINFORMATIONACQUISITIONIIITIME AT WHICHDECISION MUSTBE MADE TIME AXIS TFigure 1-1. Schematic Representation of the Decisionmaking Process*There are other methods for performing this function. Some of these are discussed brieflyin Chapter II.1-1

FAULT TREE HANDBOOK1-2The existence of the time constraint on the decisionmaking process leads us tomake a distinction between good decisions and correct decisions. We can classify adecision as good or bad whenever we have the advantage of retrospect. I make adecision to buy 1000 shares of XYZ Corporation. Six months later, I find that thestock has risen 20 points. My original decision can now be classified as good. If,however, the stock has plummeted 20 points in the interim, I would have toconclude that my original decision was bad. Nevertheless, that original decision couldvery well have been correct if all the information available at the time had indicated arosy future for XYZ Corporation.We are concerned here with making correct decisions. To do this we require:(1) The identification of that information. (or those data) that would be pertinentto the anticipated rlecision.(2) A systematic program for the acquisition of this pertinent information.(3) A rational assessment or analysis of the data so acquired.There are perhaps as many definitions of system analysis as there are peopleworking and writing in the field. The authors of this book, after long thought, somecontroversy, and considerable experience, have chosen the following definition:System analysis is a directed process for the orderly and timely acquisition andinvestigation of specific system information pertinent to a given decision.According to this definition, the primary function of the system analysis is theacquisition of information and not the generation of a system model. Our emphasis(at least initially) will be on the process (i.e., the acquisition of information) and noton the product (Le., the system model). This emphasis is necessary because, in theabsence of a directed, manageable, and disciplined process, the corresponding systemmodel will not usually be a very fruitful one.We· must decide what information is relevant to a given decision before the datagathering activity starts. What information is essential? What information isdesirable? This may appear perfectly obvious, but it is astonishing on how manyoccasions this rationale is not followed. The sort of thing that may happen isillustrated in Figure I-2.//. .Figure 1-2. Data Gathering Gone Awry/

1-3BASIC CONCEPTS OF SYSTEM ANALYSISThe large circle represents the information that will be essential for a correct decisionto be made at some future time. Professor Jones, who is well funded and who is a"Very Senior Person," is an expert in sub-area A. He commences to investigate thisarea, and his investigation leads him to some fascinating unanswered questionsindicated in the sketch by Ai. Investigation of Ai leads to A2 , and so on. Notice,however, that Professor Jones' efforts are causing him to depart more and more fromthe area of essential data. Laboratory Alpha is in an excellent position to studysub-area B. These investigations lead to Bi and B2 and so on, and the same thing ishappening. When the time for decision arrives, all the essential information is notavailable despite the fact that the efforts expended would have been able to providethe necessary data if they had been properly directed.The nature of the decisionmaking process is shown in Figure 1-3. Block Arepresents certified reality. Now actual reality is pretty much of a "closed book," butby experimentation and investigation (observations of Nature) we may slowlyconstruct a perception of reality. This is our system model shown as block B. Next,this model is analyzed to produce conclusions (block C) on which our decision willbe based. So our decision is a direct outcome of our model and if our model isgrossly in error, so also will be our decision. Clearly, then, in this process, the greatestemphasis should be placed on assuring that the system model provides as accurate arepresentation of reality as possible.zz00I-I C.:;J C.:;JAI-8Cl)wCl)wzc z zMODELTRUTHREALITYI-OUR PERCEPTIONOF REALITY0"'wu0CONCLUSIONSBASIS FORDECISIONFigure I-3. Relationship Between Reality, SystemModel, and Decision Process2.Definition of a SystemWe have given a definition of the process of system analysis. Our next task is todevise a suitable definition for the word "system." In common parlance we speak of"the solar system," "a system of government," or a "communication system," and inso doing we imply some sort of organization existing among various elements that

1-4FAULT TREE HANDBOOKmutually interact in ways that may or may not be well defined. It seems reasonable,then, to establish the following definition:A system is a deterministic entity comprising an interacting collection ofdiscrete elements.From a practical standpoint, this is not very useful and, in particular cases, wemust specify what aspects of system performance are of immediate concern. Asystem performs certain functions and the selection o( particular performanceaspects will dictate what kind of analysis is to be conducted. For instance: are weinterested in whether the system accomplishes some task successfully; are weinterested in whether the system fails in some hazardous way; or are we interested inwhether the system will prove more costly than originally anticipated? It could wellbe that the correct system analyses in these three cases will be based on differentsystem defintions.The word "deterministic,' in the definition implies that the system in question beidentifiable. It is completely futile to attempt an analysis of something that cannotbe clearly identified. The poet Dante treated the Inferno as a system and divided itup into a number of harrowing levels but, from a practical standpoint, such a systemis not susceptible to identification as would be, for example, the plumbing system inmy home. Furthermore, a system must have some purpose-it must do. something.Transportation systems, circulating hot water piping systems, local school systems allhave definite purposes and do not exist simply as figments of the imagination.The discrete elements of the definition must also, of course, be identifiable; forinstance, the individual submarines in the Navy,s Pacific Ocean Submarine Flotilla.Note that the discrete elements themselves may be regarded as systems. Thus, asubmarine consists of a propulsion system, a navigation system, a hull system, apiping system, and so forth; each of these, in tum, may be further broken down intosubsystems and sub-subsystems, etc.Note also from the definition that a system is made up of partsrbr subsystems thatinteract. This interaction . which may be very complex indeed, generally insures thata system is riot simply equal to the sum of its parts, a point that will be continuallyemphasized throughout this book. Furthermore, if the physical nature of any partchanges-for example by failure-the system itself also changes. This is an importantpoint because, should design changes be made as a result of a system analysis, thenew system so resulting will have to be subjected to an analysis of its own. Consider,for example, a four-engine aircraft. Suppose one engine fails. We now have a newsystem quite different from the original one. For one thing, the landing characteristics have changed rather drastically. Suppose two engines fail. We now have sixdifferent possible systems depending on which two engines are out of commission.Perhaps the most vital decision that must be made in system definition is how toput external boundaries on the system. Consider the telephone sitting on the desk. Isit sufficient to define the system simply as the instrument itself (earpiece, cord andcradle), or should the line running to the jack in the wall be included? Should thejack itself be included? What about the external lines to the telephone pole? Whatabout the junction box on the pole? What about the vast complex of lines, switchingequipment, etc., that comprise the telephone system in the local area, the nation, the

1-5BASIC CONCEPTS OF SYSTEM ANALYSISworld? Clearly some external boundary to the system must be established and thisdecision will have to be made partially on the basis of what aspect of systemperformance is of concern. If the immediate problem is that the bell is not loudenough to attract my attention when I am in a remote part of the house, the externalsystem boundary will be fairly closed in. If the problem involves static on the line,the external boundary will be much further out.It is also important in system definition to establish a limit of resolution. In thetelephone example, do I wish to extend my analysis to the individual components(screws, transmitter, etc.) of which the instrument is composed? Is it necessary todescend to the molecular level, the atomic level, the nuclear level? Here again, adecision can be made partially on the basis of the system aspect of interest.What we have said so far can be represented as in Figure I4. The dotted lineseparates the system from the environment in which it is embedded. Thus, thisdotted line constitutes an external boundary. It is sometimes useful to divide thesystem into a number of subsystems, A, B, C, etc. There may be several motivationsfor doing this; most of them will be discussed in due course. Observe also that one ofthe subsystems, F, has been broken down, for purposes of the analysis, into itssmallest sub-subsystems. This constitutes a choice of an internal boundary for thesystem. The smallest sub-subsystems, a, b, c, etc., are the "discrete elements"mentioned in the general definition of a system.TYPICALSUBSYSTEMS SYSTEM-A----- - k00pqfIIIISMALLESTS LIB-SUBSYSTEM(LIMIT OFRESOLUTION)IL------------------------ Figure 1-4. System Definition: External and Internal BoundariesThe choice of the appropriate system boundaries in particular cases is a matter ofvital importance, for the choice of external boundaries determines the comprehensiveness of the analysis, whereas the choice of a limit of resolution limits the detail ofthe analysis. A few further facets of this problem will be discussed briefly now, andwill be emphasized throughout the book, especially in the applications.The system boundaries we have discussed so far have been physical boundaries. Itis also possible, and indeed necessary in many cases, to set up temporal or time-likeboundaries on a system. Consider a man who adopts the policy of habitually tradinghis present car in for a new one every two years. In this example, the system is the

1-6FAULT TREE HANDBOOKcar and the system aspect of interest is the maintenance policy. It is clear that, underthe restriction of a two-year temporal boundary, the maintenance policy adoptedwill be one thing; it will be quite a different thing if the man intends to run the carfor as long as possible. In some applications, the system's physical boundaries mightactually be functions of time. An example of this would be a system whose temporalboundaries denote different operating phases or different design modifications. Aftereach phase change or design modification, the physical boundaries are subject toreview and possible alteration.The system analyst must also ask the question, "Are the chosen systemboundaries feasible and are they valid in view of the goal of the analysis?" To reachcertain conclusions about a system, it may be desirable to include a large system"volume" within the external boundaries. This may call for an extensive,time-consuming analysis. If the money, time and staff available are inadequate forthis task and more efficient analysis approaches are not possible, then the externalboundaries must be "moved in" and the amount of information expected to resultfrom the analysis must be reduced. If I am concerned about my TV reception, itmight be desirable to include the state of the ionosphere in my analysis, but thiswould surely be infeasible. I would be better advised to reduce the goals of myanalysis to a determination of the optimum orientation of mv roof antenna.The limit of resolution (internal boundary) can also be established -fromconsideration,s of feasibility (fortunately!) and from the goal of the analysis. It ispossible to conduct a worthwhile study of the reliability of a population of TV setswithout being concerned about what is going on at the microscopic andsubmicroscopic levels. If the system failure probability is to be calculated, then thelimit of resolution should cover component failures for which data are obtainable. Atany rate, once the limit of resolution has been chosen (and thus the "discreteelements" defined), it is interactions at this level with which we are concerned; weassume no knowledge and are not concerned about interactions taking place at lowerlevels.We now see that the external boundaries serve to delineate system outputs (effectsof the system on its environment) and system inputs (effects of the environment onthe system); the limits of resolution serve to define the "discrete elements" of thesystem and to establish the basic interactions within the system.The reader with a technical background will recognize that our definition of asystem and its boundaries is analogous to a similar process involved in classicalthermodynamics, in which an actual physical boundary or an imaginary one is usedto segregate a definite quantity of matter ("control mass") or a definite volume("control volume"). The inputs and outputs of the system are then identified by theamounts of energy or mass passing into or out of the bounded region. A system thatdoes not exchange mass with its environment is termed a "closed system" and aclosed system that does not exchange energy with its surroundings is termed an"adiabatic system" or an "isolated system." A student who has struggled withthermodynamic problems, particularly flow problems, will have been impressed withthe importance of establishing appropriate system boundaries before attempting asolution of the problem.A good deal of thought must be expended in the proper assignment of systemboundaries and limits of resolution. Optimally speaking, the system boundaries andI -

BASIC CONCEPTS OF SYSTEM ANALYSIS1-7limits of resolution should be defined before the analysis begins and should beadhered to while the analysis is carried out. However, in practical situations theboundaries or limits of resolution may need to be changed because of informationgained during the analysis. For example, it may be found that system schematics arenot available in as detailed a form as originally conceived. The system boundaries andlimits of resolution, and any modifications, must be clearly defined in any analysis,and should be a chief section in any report that is issued .,,,,,,.---./10-4/'' -4.------EXTENDEDSYSTEM BOUNDARY/I\1 \'\\.',3,,-.-------SYSTEM BOUNDARYIII/Figure 1-5. Effect of System Boundaries on Event ProbabilitiesTo illustrate another facet of the bounding and resolution problem, considerFigure 1-5. The solid inner circle represents our system boundary inside of which weare considering events whose probabilities of occurrence are, say, of order 10-3 orgreater. If the system boundaries were extended (dotted circle) we would include, inaddition, events whose probabilities of occurrence were, say, of order 10-4 orgreater. By designing two-fold redundancy into our restricted system (solid circle) wecould reduce event probabilities there to the order of oo-3)(10-3) 10-6 but thenthe probabilities of events that we are ignoring become overriding, and we aresuffering under the delusion that our system is two orders of magnitude safer ormore reliable than it actually is. When due consideration is not devoted to matterssuch as this, the naive reliability calculator will often produce such absurd numbersas 10-l 6 or 10-18. The low numbers simply say that the system is not going to failby the ways considered but instead is going to fail at a much higher probability in away not considered.3.Analytical ApproachesBecause we are concerned, in this volume, with certain formal processes ormodels, it should come ·as no great suprise that these processes or models can becategorized in exactly the same way as are the processes of thought employed in thehuman decisionmaking process. There are two generic analytical methods by meansof which conclusions are reached in the human sphere: induction and deduction. It isnecessary at this point to discuss the respective characteristics of these approaches. ·

1-8FAULT TREE HANDBOOKInductive ApproachesInduction constitutes reasoning from individual cases to a general conclusion. If,in the consideration of a certain system, we postulate a particular fault or initiatingcondition and attempt to ascertain the effect of that fault or condition on systemoperation, we are constructing an inductive system analysis. Thus, we might inquireinto how the loss of some specified control surface affects the flight of an airplane orinto how the elimination of some item in the budget affects the overall operation ofa school district. We might also inquire how the non-insertion of given control rodsaffects a scram system's performance or how a given initiating event, such as a piperupture, affects plant safety.Many approaches to inductive system analysis have been developed and we shalldevote Chapter II to a discussion of the most important among them. Examples ofthis method are: Preliminary Hazards Analysis (PHA), Failure Mode and EffectAnalysis (FMEA), Failure Mode Effect and Criticality Analysis (FMECA), FaultHazard Analysis (FHA), and Event Tree Analysis.To repeat-in an inductive approach, we assume some possible componentcondition or initiating event and try to determine the corresponding effect on theoverall system.Deductive ApproachesDeduction constitutes reasoning from the general to the specific. In a deductivesystem analysis, we postulate that the system itself has. failed in a certain way, andwe attempt to find out what modes of system/component* behavior contribute tothis failure. In common parlance we might refer to this approach as a "SherlockHolmesian" approach. Holmes, faced with given evidence, has the task ofreconstructing the events leading up to the crime. Indeed, all successful detectives areexperts in deductive analysis.Typical of deductive analyses in real life are accident investigations: What chain ofevents caused the sinking of an "unsinkable" ship such as the Titanic on its maidenvoyage? What failure processes, instrumental and/or human, contributed to the crashof a commercial airliner into a mountainside?The principal subject of this book, Fault Tree Analysis, is an example of deductivesystem analysis. In this technique, some specific system state, which is generally afailure state, is postulated, and chains of more basic faults contributing to thisundesired event are built up in a systematic way. The broad principles of Fault TreeAnalysis, as well as details relating to the applications and evaluation of Fault Trees,are given in later chapters.In summary, inductive methods are applied to determine what system states(usually failed states) are possible; deductive methods are applied to determine how agiven system state (usually a failed state) can occur.*A component can be a subsystem, a sub-subsystem, and sub-sub-subsystem, etc. Use of theword "component" often avoids an undesirable proliferation of "subs."

BASIC CONCEPTS OF SYSTEM ANALYSIS4.1-9Perils and PitfallsIn the study of systems

Fault Tree Handbook Date Published: January 1981 W. E. Vesely, U.S. Nuclear Regulatory Commission F. F. Goldberg, U.S. Nuclear Regulatory Commission