Common-Cause Failure Database and Analysis System: …

NUREG/CR-6268Vol. 1INEEL/EXT-97-00696

Common-Cause Failure Database andAnalysis System: Overview

Prepared byF. Uv MarshaU/INEELA. MosIeh/Univ. of MDD. U RasmUSon/NRC

Idaho National Engineering and Environmental Laboratory

University of Maryland

Prepared forU.S. Nuclear Regulatory Commission

AVAILABIUTY NOTICE

Availability of Reference Materials Cited in NRC Publications

Most documents cited In NRC publications will be available from one of the following sources:

1. The NRC Public Document Room, 2120 L Street. NW., Lower Level. Washington, DC 20555-0001

2. The Superintendent of Documents. U.S. Government Printing Office, P. 0. Box 37082, Washington. DC

20402-9328

3. The National Technical Information Service, Springfield, VA 22161-0002

Although the listing that follows represents the majority of documents cited In NRC publications, it Is not in-tended to be exhaustive.

Referenced documents available for inspection and copying for a fee from the NRC Public Document Roominclude NRC correspondence and Internal NRC memoranda; NRC bulletins. circulars, information notices. in-spection and Investigation notices; licensee event reports; vendor reports and correspondence; Commissionpapers; and applicant and licensee documents and correspondence.

The following documents in the NUREG series are available for purchase from the Government Printing Office:formal NRC staff and contractor reports, NRC-sponsored conference proceedings, international agreementreports, grantee reports, and NRC booklets and brochures. Also available are regulatory guides, NRC regula-tions In the Code of Federal Regulations, and Nuclear Regulatory Commission Issuances.

Documents available from the National Technical Information Service Include NUREG-serles reports and tech-nical reports prepared by other Federal agencies and reports prepared by the Atomic Energy Commission,forerunner agency to the Nuclear Regulatory Commission.

Documents available from public and special technical libraries Include all open literature items, such as books,journal articles, and transactions. Federal Register notices. Federal and State legislation, and congressionalreports can usually be obtained from these libraries.

Documents such as theses, dissertations, foreign reports and translations, and non-NRC conference pro-ceedings are available for purchase from the organization sponsoring the publication cited.

Single copies of NRC draft reports are available free. to the extent of supply, upon written request to the Officeof Administration, Distribution and Mall Services Section, U.S. Nuclear Regulatory Commission. Washington.DC 20555-0001.

Copies of Industry codes and standards used In a substantive manner In the NRC regulatory process are main-tained at the NRC Library, Two White Flint North. 11545 Rockville Pike. Rockville. MD 20852-2738. for use bythe public. Codes and standards are usually copyrighted and may be purchased from the originating organiza-tion or, If they are American National Standards. from the American National Standards institute. 1430 Broad-way, New York, NY 10018-3308.

DISCLAIMER NOTICE

This report was prepared as an account of work sponsored by an agency of the United States Government.Neitherthe United States Government nor any agency thereof, norany of their employees, makes any warranty,expressed or implied, or assumes any legal liability or responsibility for any third party's use, or the results ofsuch use, of any information, apparatus, product, or process disclosed in this report, or represents that its useby such third party would not infringe privately owned rights.

NUREG/CR-6268Vol. IINEEL/EXT-97-00696

Common-Cause Failure Database andAnalysis System: Overview

Manuscript Completed: June 1998Date Published: June 1998

Prepared byF. M. Marshall/INEELA. Mosleh/Univ. of MDD. IM. Rasmuson/NRC

Idaho National Engineering and Environmental LaboratoryLockheed Martin Idaho Technologies CompanyIdaho Falls, ID 83415

Subcontractor:Department of Materials and Nuclear EngineeringUniversity of MarylandCollege Park, MD 20742-2115

Prepared forSafety Programs DivisionOffice for Analysis and Evaluation of Operational DataU.S. Nuclear Regulatory CommissionWashington, DC 20555-0001

NRC Job Code E8247

ABSTRACT

This volume of the Common Cause Failure Database and Analysis Systemreport presents an overview of common cause failure methods for use in the U.S.commercial nuclear power industry. It summarizes how data (on common causefailure events) are gathered, evaluated, and coded. It then describes the process forestimating probabilistic risk assessment (PRA) common cause failure parameters.It also references other volumes of this report for specific details.

Equipment failures that contribute to common cause failure events areidentified through searches of Licensee Event Reports (LERs) and Nuclear PlantReliability Data System (NPRDS) failure reports. Once common cause failureevents are identified by reviewing reports of equipment failures, INEEL staff enterthe event information into a personal computer data analysis system (CCF system)using the method presented in this and companion volumes. The events stored in theCCF system are used for common cause failure PRA parameter estimations usingcommon cause failure quantification methods.

.o. NUREG/CR-6268, Vol. 1

CONTENTS

A B STRA CT ........................................................................ iii

EXECUTIVE SUMMARY ........................................................... vii

ACRONY M S ....................................................................... ix

1. INTRODUCTION .............................................................. 1

2. OVERVIEW OF THE CCF DATA ANALYSIS PROCESS .............................. 3

2.1 Identification of Analysis Boundaries (I) ........................................ 3

2.2 Data Collection (2 and 3) ..................................................... 6

2.3 Event Analysis ............................................................. 7

2.3.1 NPRDS and LER Data Review and Coding (4 and 6) ....................... 72.3.2 NPRDS and LER Independent Event Counting (5 and 7) .................... 72.3.3 Quality Assurance (8) ................................................ 7

2.4 Load CCF and Independent Data (9 and 10) ...................................... 8

2.5 Independent QA Verification (11) .............................................. 8

2.6 CCF Parameter Estimation (12) ................................................ 8

3. CCF SOFTWARE AND PARAMETER ESTIMATES .................................. 9

3.1 Search Database (13) ....................................................... 10

3.2 Analyze Data from Search (14) ............................................... 10

3.3 Estimate CCF Parameters (15) ............................................... 11

4. GENERAL INSIGHTS FROM ANALYSIS OF CCF DATA ............................ 13

5. REFERENCES ................................................................ 23

GLO SSARY ....................................................................... 25

v NUREG/CR-6268, Vol. I

LIST OF FIGURES

1. CCF data analysis process ........................................................ 4

2. Software process flow diagram .................................................... 10

3. Parameter estimation example ..................................................... 12

4. Distribution of CCF events, by cause ............................................... 17

5. Distribution of CCF events, by shared cause factor .................................... 18

6. Distribution of all CCF events in database by year .................................... 19

7. Distribution of CCF events by year and source ....................................... 19

8. Distribution of complete CCF events by year ........................................ 20

9. Component-to-component variability of alpha factors .................................. 21

LIST OF TABLES

1. Number of events analyzed ........................................................ 2

2. Component types and systems analyzed for CCF events (1980-1995) ..................... 15

3. Emergency diesel generator CCF parameter estimations ................................ 16

4. Alpha and beta factors for motor operated valves (CCCG=6) ............................ 16

5. Alpha and beta factors for pumps .................................................. 16

NUREG/CR-6268, Vol. 1 vi

EXECUTIVE SUMMARY

The U.S. Nuclear Regulatory Commission's (NRC's) Office for Analysis andEvaluation of Operational Data (AEOD) and the Idaho National Engineering andEnvironmental Laboratory (INEEL) have developed and maintain a common causefailure (CCF) database for the U.S. commercial nuclear power industry. Previous studiesdocumented methods for identifying and quantifying CCFs. This report extends previousmethods by introducing a method for identifying CCF events, a collection of events fromindustry failure data, and a computerized system for quantifying probabilistic riskassessment (PRA) parameters and uncertainties.

A CCF event consists of component failures that meet four criteria: (1) two or

more individual components fail or are degraded, including failures during demand,in-service testing, or deficiencies that would have resulted in a failure if a demand signalhad been received; (2) components fail within a selected period of time such that successof the PRA mission would be uncertain; (3) component failures result from a singleshared cause and coupling mechanism; and (4) a component failure occurs within theestablished component boundary.

Two data sources are used to select equipment failure reports to be reviewed forCCF event identification: the Nuclear Plant Reliability Data System (NPRDS), whichcontains component failure information, and the Sequence Coding and Search System(SCSS), which contains Licensee Event Reports (LERs). These sources served as thedevelopmental basis for the CCF data collection and analysis system. The CCF datacollection and analysis system consists of(l) CCF event identification methodology, (2)event coding guidance, and (3) a software system to estimate CCF parameters.

The CCF event identification process includes reviewing failure data to identifyCCF events and counting independent failure events. The process allows the analyst toconsistently screen failures and identify CCF events. The CCF event coding processprovides guidance for the analyst to consistently code CCF events. Sufficientinformation is recorded to ensure accuracy and consistency. Additionally, the CCFevents are stored in a format that allows PRA analysts to review the events and developunderstanding of how they occurred.

A software system stores CCF events, independent failure counts, and automatesPRA parameter estimations. The system employs two quantification models: the alphafactor and the multiple Greek letter. These models are used throughout the nuclearindustry. In addition, these parameter estimations can be used in a PRA to estimate basicevent probability and uncertainty.

This report is presented in four volumes: Overview, Event Definition andClassification, Data Collection and Event Coding, and Software Reference Manual.

Specific terms and acronyms are used throughout this report. The specific termsused are found in the glossary at the back of each volume. A list of acronyms followsthe executive summary.

vii NUREG/CR-6268, Vol. 1

ACRONYMS

AEOD Nuclear Regulatory Commission's MLE(NRC's) Office for the Analysis andEvaluation of Operational Data NPRDS

CCCG common cause component groupNRC

CCF common cause failureORNL

INEEL Idaho National Engineering and Envi-ronmental Laboratory PC

LER Licensee Event Report PRA

MGL multiple Greek letter SCSS

maximum likelihood estimate

Nuclear Plant Reliability Data Sys-tem

Nuclear Regulatory Commission

Oak Ridge National Laboratory

personal computer

probabilistic risk assessment

Sequence Coding and Search System

ix NUREG/CR-6268, Vol. 1

Common Cause Failure Databaseand Analysis SystemVolume I-Overview

1. INTRODUCTION

A general conclusion from probabilistic riskassessments (PRAs) of commercial nuclear powerplants is that common cause failures (CCFs) aresignificant contributors to the unavailability ofsafety systems. Efforts in past years to improveunderstanding and modeling of CCF events haveproduced several models, procedures, computercodes, and databases. Some efforts have col-lected limited amounts of data for use in CCFanalyses. Most of these efforts used operationalexperience data prior to 1984.

Until recently, lack of CCF event data wasa major problem, though significant progress wasmade with the publication of Classification andAnalysis ofReactor Operating Experience Involv-ing Dependent Events, EPRI NP-3967.' Twoknown deficiencies of EPRI NP-3967 are thelimited time frame for the study, and the lack ofdetails regarding independent events. In the areaofdata classification, analysis, and model parame-ter estimation, the detailed procedures of Proce-dures for Treating Common Cause Failures inSafety andReliability Studies, NUREG/CR-4780,Volumes I and 2,2 and Procedure for Analysis ofCommon Cause Failures in Probabilistic SafetyAnalysis, NUREG/CR- 5801,' have been viewedas too time consuming, despite wide acceptance ofthe basic approach.

In response to these deficiencies, the IdahoNational Engineering and Environmental Labora-tory (INEEL) staff and the Nuclear RegulatoryCommission's (NRC) Office for Analysis andEvaluation of Operational Data (AEOD ) havedeveloped a CCF data collection and analysis

system that includes a method for identifying CCFevents, coding and classifying those events for usein CCF studies, and a computer system for storingand analyzing the data. The system is based, inpart, on previous CCF methods and models. Thedata collection effort added a substantial numberof CCF events for use in CCF analyses above theprevious industry efforts to collect CCF data. Thegeneric data generated from these past studieshave been divided by component type, with noallowance given for differences that might existbetween systems. The current data collectioneffort has separated the data by system. Theprincipal products of this CCF data collection andanalysis system (CCF system) project are themethod for identifying and classifying CCFevents, the CCF database containing both CCFevents and independent failure counts, and theCCF parameter estimation software.

Documentation of this project is presented infour volumes: Overview, Event Definition andClassification," Data Collection and EventCoding,5 and Software Reference Manual."

The database contains common cause failureevents from 1980 through 1995. Table I showsthe number of records examined and the numberof CCF events found. It also shows that CCFevents are rare. Approximately 5 percent of allfailures involve some degree of common cause,and only 0.7 percent of all failures result in com-plete CCFs (events in which all redundant compo-nents completely fail). A more detailed display ofthe data in the database is in Table 2 of section 4of this volume.

I NUREG/CR-6268, Vol. 1

Table 1. Number of events analyzed.

Total number of records examined

Total number of LERs examined

Total number of NPRDS records ex-amined

CCF events found

From LERs

From NPRDS

Complete CCF events (events in whichall redundant components are failed)

31,910

11,884

20,026

1,533

673

860

235

factor (which is a measure of the time between thefailures), and the shared cause factor (whichmeasures the analyst's uncertainty about a sharedcause). These are defined and explained later inthis volume, and further in Volumes 2' and 3.VProject objectives are (1) development of a com-prehensive database of CCF events using severaldata sources such as Licensee Event Reports(LERs)--contained in the Sequence Coding andSearch System maintained by Oak Ridge NationalLaboratory--and the Nuclear Plant ReliabilityData System (NPRDS) maintained by the Instituteof Nuclear Power Operations, and (2) automationof the data analysis and parameter estimationprocedures of References 2 and 3.

The INEEL staff, INEEL contractor staff,and AEOD staff developed a method for identify-ing CCF events and a personal computer-basedsystem for storing and analyzing CCF events. Thisvolume presents an overview of the CCF dataanalysis process, CCF software features, and asummary of general insights regarding CCFevents.

The computer software produced for thisproject uses the impact vector method introducedin Reference 2 and further refined in Reference 3.The basic information needed for understandingand coding a CCF event is based on the physicalcharacteristics of the event, and is recorded in thefollowing fields in the database: a componentdegradation parameter for each component in thespecified group of similar components, the timing

NUREG/CR-6268, Vol. 1 2

2. OVERVIEW OF THE CCF DATA ANALYSIS PROCESS

The first task of the CCF event databaseeffort was to develop specific guidance for dataanalysts to use in identification of CCF events.For this project the definition of a CCF event is(from Reference 2) "a subset of dependent failuresin which two or more component functional faultstates exist at the same time, or within a shortinterval, as a result of a shared cause." The basiccharacteristics ofa CCF event were translated intoengineering terms with examples to illustrate thedefinitions and concepts. The initial CCF eventsearch and screening criteria included similarcomponents, failure of components within a shorttime interval, and multiple failures resulting froma shared cause. All of these characteristics mustbe present for an event to be considered a CCFevent candidate.

The use of the term "shared cause" impliesthe presence of a coupling mechanism that rendersthe multiple components susceptible to failurefrom the same cause. Examples of couplingmechanisms are multiple identical componentswith the same defective design (hardware), acalibration procedure that specifies an incorrectset point for several relief valves (operational),and contamination of emergency diesel generator(EDG) fuel oil that disables all EDGs (environ-mental). The time interval is a concern becausemultiple failures that do not occur within the PRAmission time will not prevent successful operationof the safety system during an accident condition.

Failure of shared equipment (e.g., commoncooling water or AC power systems) is not consid-ered a CCF event because these events are usuallymodeled explicitly in the reliability logic models.In order for the CCF database to be a completecompilation of dependent events, however, thesedependent failure events are coded and includedin the CCF database. Another convention adoptedin the initial effort of this project is that similar

failures within a short time interval in differentpower plants of a multiple unit power plant siteare not considered a CCF event. This is becausean individual plant design typically does not relyon use of systems from another unit. Exceptionsto this are the EDGs and ultimate heat sinks. Incases where similar failures (e.g., all four EDGs ata two-unit site with the same defective design)are detected at multiple plants, a CCF event isentered into the database for each unit affected.These concepts and definitions are documented indetail in Volume 2.

Figure I demonstrates the major steps in theCCF data analysis process. The numbers inparentheses after each block in Figure 1 arereferences to the steps in the detailed procedure inVolume 3. The same numbers are given after thesection titles in the remainder of this section.

In summary, the CCF data analysis processconsists of six activities: identification ofanalysisboundaries, data collection, failure data reviewand coding, data entry, independent QA verifica-tion, and CCF parameter estimation. Each activityis discussed below in the following sections.

2.1 Identification of AnalysisBoundaries (1)

The initial step in the process is to identify theboundaries of the analysis, including the plantsystems and components to be analyzed, operationalevent boundaries, and data search strategies.Initially, a list of components for analysis wasdeveloped by identifying the components that arerisk important in several PRAs. The list includessuch components as batteries, auxiliary feedwatersystem pumps, and emergency diesel generators.Currently, only mechanical and electricalcomponents typically modeled in PRAs are beingconsidered.

3 NUREG/CR-6268, Vol. 1

(7)

CM 371 1

Figure 1. CCF data analysis process.

The staff identified the system successcriteria by defining system and component failuremodes. These are descriptions of how the systemand components within the system are required tooperate and accomplish their (safety or PRA-specific) mission. The failure modes definedinitially were those that correspond primarily tothe ones used in PRAs. For example, the safetyfunction of a pump is to start on specific demandcriteria, then to run for a given length of time(mission time). Pump failure to start includesevents such as the motor circuit breaker notracked in and a successful start of the pump motorwithout achieving rated pressure and flow. Pump

failure to run events include erratic speed control,lubrication system problems, or high vibration thatmay prevent operation for the full duration ofmission time. As the data review progressed,analysts recognized that other failure modes, nottypically used in PRA applications, such as failureto stop, exist in the operational data, and that itwould be useful to capture this information in thedatabase. Specific definitions of these additionalfailure modes, using operational data as examples,were documented to aid the data analysts in theirreview of the events. Analysts determined thefailure modes for both the CCF events and theindependent failures.


The component and system combinations arereferred to as a common cause component group(CCCG). The number of components in a CCCGis referred to as the size of the group, the CCCGsize, or the redundancy level. Each CCCG (e.g.,EDGs, auxiliary feedwater air-operated valves) isunique in the application of system and compo-nent boundaries, definition of failure, and theapplicable failure modes. Prior to performing anydata searches and downloads, the analysts estab-lished the CCCG boundaries and defined theapplicable failure modes to ensure that the datawere properly collected and consistently analyzed.For example, the auxiliary feedwater (AFW)pump boundary includes the driver (motor andcircuit breaker, or turbine and turbine governor)and the mechanical portion of the pump. Allrecords containing failures of these subcom-ponents were obtained. Examples of possiblefailure events for each component set were givento the data analyst to assist in determining theapplicability of the reported failure event to theCCF study. When a licensee reported a compo-nent degradation, the analyst had to determine theeffect of the degradation on the actual operabilityof the component. For example, failure of oneindicator light on a valve position indicator wasdetermined not to be a failure of the valve. Con-versely, an incorrectly positioned pump circuitbreaker that would have prevented a successfulpump start was considered a failure, even thoughthe deficiency was identified prior to an actualdemand.

The component boundaries are defined thesame as the components modeled in most PRAstudies. Component boundaries are defined priorto the date review so that each data analyst canconsistently identify failure reports that should beincluded within a single component analysis.While identifying the component boundaries, theanalyst identifies all components (includingsubcomponents) or portions of the system to beconsidered during the analysis.

When establishing component boundaries,the analyst considers CCF issues that affect

groups of similar components being evaluated.During the analysis, the system being evaluated isfirst partitioned into components. Componentpartitions are based on factors that can cause aCCF event. For example, pumps are partitionedinto pumps and drivers because CCF events maybe different for pumps and drivers. The drivers arefurther partitioned into turbines and motors for thesame reason. This partitioning is performedbecause some CCF events may affect only onetype of subcomponent, while other CCF eventsoccur across subcomponent boundaries. Forexample, failures that result in a loss of motiveforce for pump drivers are not the same as thefailures that result in the pumps losing suction.Likewise, failures that result in the failure ofmotive force for the steam turbine generally arenot similar to the failures that result in a loss ofelectrical power for a motor.

Prior to reviewing the failure records foridentification of CCF events, it is necessary tounderstand the system configuration at each plant.Understanding the configuration enables theanalyst to properly interpret the event and deter-mine the impact of the reported failure on thesystem and component operability with respect tothe PRA mission. The system configurationswere determined using data in the Nuclear PowerPlant System Sourcebooks,7 plant final safetyanalysis reports, plant drawings, and other avail-able sources. The system configuration analysisconsists of identifying the number of trains in-volved, the number of each type component(CCCG), and component configuration.

Once preparations are completed, the fol-lowing information is recorded for quality assur-ance documentation:

" A description of component boundaries. Thedescription includes a list of parts (sub-components and groups of similar compo-nents) analyzed with the CCCG.

" A description of failure modes used duringthe analysis.


" A description of relevant operational events,and definitions of failures and non-failures.

" Time boundaries for the data set and the dateof the download. Currently the NPRDS dataspan the period from January 1, 1984, throughDecember 31, 1995. (There are some NPRDSevents, both CCF and independent, used inthis data collection effort that occurred prior to1984, but were not entered into NPRDS untilafter 1984.) The LER data span the periodfrom January 1, 1980, through December 31,1995.

" Any special limitations on data used duringthe download such as the following:

- Exclude incipient failure reports, be-cause they are inconsistently reportedby licensees.

- Exclude nonsafety-related failurereports.

" The size of the CCCG. If it is unknown, anassumption is made and explained.

" Any special situations that should be consid-ered for a particular plant.

" Testing frequency for components of inter-est.

Using the above established system descrip-tions, boundaries of the component and system ofinterest, failure events, and applicable failuremodes, the data are downloaded and prepared foranalyst review. The INEEL staff downloads theNPRDS data, and the ORNL staff downloads theSCSS data in the form of LER numbers and LERabstracts for transmittal to the INEEL.

2.2 Data Collection (2 and 3)

The next step is to perform searches for CCFevents using available data sources. The sources

of component failure data most readily availableto the NRC are the NPRDS failure reports andLERs downloaded from SCSS. The NPRDS datareports contain detailed information about thefailure of a single component; thus, they must beconsidered in groups of two or more records withspecific characteristics to constitute CCF events.Conversely, LERs contain information about morecomplex plant events, and, due to the reportingcriteria, often contain information about multiplesimultaneous failures in a single report. INEELstaff developed database search strategies usingthe basic characteristics of a CCF event as de-scribed above. For the initial data collection andevaluation phase of the project, INEEL staffreviewed data from 1980 through 1995.

The staff collected NPRDS failure reportsfor CCCGs of interest. Once collected, the failurereports were grouped by failure date and plantdocket for consideration as potential CCF events.All failure reports that fall within one and aquarter surveillance testing interval are consideredto be potential CCF events, because of the possi-bility of the failure states to exist, undetected,until the next component is tested. Volume 35further discusses the timing factor.

The SCSS search algorithm has four basicparts: (1) any actual or potential failures ofmultiple components within one system coded onthe same step of the SCSS matrix, (2) any actualor potential failure of a system train linked to afailure in another train of the same system, (3) anyactual or potential failure of a component with atleast one or more actual or potential failures of thesame type of component in the same system codedafterward in the SCSS matrix, and (4) any fabrica-tion/manufacturing deficiency resulting in anactual or potential failure within the system. TheLERs retrieved using the four parts of the algo-rithm are combined into one group, resulting inthe total number of potential CCF events for thesystem or component of interest.

Once the CCF search algorithm is com-pleted, an algorithm for searching for independent


events is developed to complement the CCFsearches.

This is done by retrieving LERs on actual orpotential failures or degradations of the compo-nent and/or system of interest that were not re-trieved by any of the four elements of the CCFsearch algorithm. Similar to the NPRDS eventgrouping by failure date, the LERs are also group-ed by date to facilitate identification of potentialCCF events. Further discussion of the SCSS andNPRDS search details is contained in Volume 3V5

2.3 Event Analysis

The outputs from search strategies arepotential CCF events and events that could repre-sent independent failures. Data analysts read theLER abstracts and NPRDS report narratives ofpotential CCF events to determine when thecriteria for a CCF event are satisfied. All failureevents not included in a CCF event are consideredfor inclusion in the independent failure eventdatabases. The coded LER CCF events andindependent failures are compared to codedNPRDS CCF events and independent failures. Allduplicates are removed from the NPRDS CCFdata and independent NPRDS failure counts.

2.3.1 NPRDS and LER Data Review andCoding (4 and 6)

Once the NPRDS and LER data are groupedby plant docket and failure start date, potentialCCF events are identified. The data analysts readthe LER abstracts and the NPRDS failure narra-tives to identify CCF events. The criteria pre-sented in Volume 24 are used to identify CCFevents. As the CCF events are identified, INEELstaff complete the data coding in accordance withthe guidance provided in Volume 3K' Failures notincluded in a CCF event are coded and enteredinto the independent failure databases (one foreach CCCG).

2.3.2 NPRDS and LER IndependentEvent Counting (5 and 7)

Valid failures that are not coded as CCFevents during the CCF event analysis are consideredto be independent failure events. Independentfailure events are counted because the counts areused in the denominator in the overall CCF parame-ter estimation, as described in Volume 2.4 Independ-ent failure event data must be provided by system,component, failure mode, and docket. This informa-tion is determined for each independent failureidentified during the data review, for both theNPRDS and the LER data. Once this informationhas been identified, the independent failure data arecounted by docket, failure mode, component, andsystem.

2.3.3 Quality Assurance (8)

A quality assurance verification plan wasdeveloped to ensure consistency and accuracy inthe data analysis and CCF event coding. Thetwo-step quality assurance verification planincludes (1) INEEL review, by both a second dataanalyst and a PRA analyst, and (2) independentquality assurance verification, by a subcontractornot at the INEEL. A discussion of the review bya second data analyst follows; independent qualityassurance verification is discussed in Section 2.5.

A second INEEL data analyst evaluatesevery coded CCF event to ensure both properidentification of the CCF event and verification ofcoding accuracy. Any differences between thefirst and second codings are resolved by the twodata analysts prior to data entry. A PRA analystat the INEEL performs another review to ensurethat appropriate PRA concepts are consideredduring data coding.


2.4 Load CCF and IndependentData (9 and 10)

A database management system has beendeveloped for the CCF data. The CCF databasesystem was constructed using the SAGE-STsoftware.' Using the CCF database system, CCFevent data are entered into the CCF database byCCF event and by independent event counts.Accuracy of data entry is verified following by asecond data analyst reviewing the entered data.Independent failure event data (e.g., failure mode,component) are entered into the independentfailure databases, and the data entry is verified.

2.5 Independent QA Verification(11)

The independent QA verification activity isa full review of coded CCF events and CCFidentification and coding methods by recognizedCCF experts outside the INEEL. The independentQA verification ensures that coded CCF eventsare actually CCF events and that the CCF eventcoding is correct and consistent.

The following steps constitute the independ-ent QA verification:

* Copies of coded events, supporting docu-mentation, and printouts of CCF parameterestimates are transmitted to the personneldoing the independent QA verification.

" The independent QA personnel review theevents and identify potential changes. Theproposed changes are transmitted back tothe INEEL CCF database staff for resolutionprior to entry into the CCF database.

2.6 CCF Parameter Estimation(12)

After independent event count and CCFevent information have been entered into the CCFdatabase and quality assurance verification com-pleted, the next step is the estimation of CCFparameters using the software developed forperforming quantifications. Detailed guidance onthe use of the CCF software for parameter estima-tions is in Volume 46.

The parameter estimation software devel-oped for this project uses the impact vector meth-od described in Reference 2 and the approachintroduced in Reference 3 for evaluating the eventimpact vector based on physical characteristics ofthe event. These characteristics include compo-nent degradation parameter, timing factor, andshared cause factor. In addition, the softwareallows the user to modify the generic event impactfactors for plant-specific applications, includingmapping the impact vectors to account for differ-ences in CCCG size between the plant in whichthe event occurred and the plant for which thedata are being modified. Other software featuresinclude parameter estimations for both alphafactor and multiple Greek letter (MGL) models.

NUREG/CR-6268, Vol. I 8

3. CCF SOFTWARE AND PARAMETER ESTIMATES

The CCF database system was developed forthe personal computer. It contains the CCF eventsin a searchable database and options to estimateCCF parameters. It provides a number of capabil-ities to users with different interests and levels ofexpertise in CCF event analysis. The CCF systemhas two main options, allowing users to performeither generic analyses or plant-specific analysesof CCF events included in the database. Theparameter estimation process is a two-step pro-cess: (1) search of the CCF database to obtainonly the events of interest, usually sorted bysystem, component, and failure mode, and (2) useof the CCF system software to perform calcula-tions using the selected events.

Descriptions of the two parameter estimationoptions, generic and specific, follow:

1. Generic (data from multiple plants arepooled) analysis of CCF events included inthe database. Generic analysis includes aqualitative analysis of causes and severity ofCCF events and a quantification of genericCCF parameters (alpha factor and multipleGreek letter models). These can be used inrisk and reliability studies or other applica-tions such as trending of industry perfor-mance with respect to a single class offailures.

2. Plant-specific analysis of CCF events. Thisoption allows users to specialize (modify)the CCF events in the database for applica-tion to a specific plant by considering designand operational differences between theplant where the event occurred and the plantof interest (target plant), and to estimateCCF parameters that reflect the specificfeatures of the plant being studied. This isrecommended in Reference 2 as the pre-ferred approach for plant-specific analyses.

The data included in the CCF system are theresult of review and classification of LER andNPRDS data to identify and characterize CCFevents in terms of their causes, the functional stateof components affected in each event, and mecha-nisms responsible for propagation of the failure ordegraded state beyond a single component fail-ure. The event classification approach is summa-rized in Volume 2," and the detailed coding guid-ance for evaluating each event in terms of theattributes needed for quantification is provided inVolume 3.V

Flexibility is built into the CCF system toenable the PRA analyst to add or remove CCFevents from a set, provided by the database searchcapability, in recognition that a precise definitionof a CCF may vary from one PRA study to an-other. All events identified as dependent events inthe LER and NPRDS data are included in the CCFdatabase, but some are shared equipment depend-encies, modeled explicitly in PRAs. The events inthe database, therefore, include more events thanthose which might be appropriate for use in agiven PRA or other studies.

The classification of events (both CCFs andindependent failure data) represents the bestjudgment of experienced analysts who haveapplied a set of carefully designed rules to ensureconsistency and minimize subjectivity. The PRAanalyst, however, can modify various attributes ofthe events in a copy of the database, leaving theoriginal database intact as a reference point. Thistype of modification requires a relatively highdegree of experience and is not expected to be theprimary application of the CCF system.

While in the CCF system, an analyst maysearch the CCF database to obtain information onvarious aspects of the CCF data, such as thedistribution of proximate causes (collectively or

9 NUREG/CR-6268, Vol. I

component by component). The software allowsthe user to specify a subset of the attributes of theevents as the search criteria to obtain a subset ofthe database having those attributes. This enablesthe user to develop a statistical base for the studyof generic differences among different classes ofplants or systems, as well as a trend of CCF eventsby plant or across the industry.

Figure 2 contains the major steps in the CCFparameter estimation process. Steps 13 through15 in Figure 2 are a more detailed breakdown ofstep 12 in Figure 1. The same numbers follow thetitles for the remaining sections.

elude either all pump types, searching for motors,turbines, and pumps, or only one pump type, thenperform the CCF database search accordingly.

Using the search option, the PRA analystcan select the data fields of interest (system,component, failure mode, shared cause factor,cause, type, etc.), search the database on the basisof the coded event information entered in thosefields, and identify the events whose fields meetthe specified search criteria. For example, tosearch the database for the auxiliary feedwaterpumps that fail to start on demand and the eventsthat are important from a PRA perspective, thesearch criteria would specify the system code forauxiliary feedwater, component code for motor-driven pumps, turbine-driven pumps, motors,turbines, and pumps, failure mode of failure tostart, and event type of CCF. A search using thesecriteria would identify all events coded with thefield information meeting these criteria. Follow-ing the search, the events are saved in an "applica-tion" for analysis. Volume 46 discusses the me-chanics of the process.

3.2 Analyze Data from Search(14)

Once the analyst selects the events to beincluded in the analysis, using the CCF softwareto obtain the parameter estimations is straightfor-ward; the CCF database system performs allcalculations. Due to the relative rarity of CCFevents in operational experience, CCF events fromsimilar plants can be pooled together to obtainenough data for use in reliability and risk studies;these are the "generic" estimations. The analysisuses CCF data that involve degradations, as wellas those involving total failures. The data fromany search can be saved for future reference andcan be used with either the generic or plant-spe-cific software options.

COO 171 2

Figure 2. Software process flow diagram.

3.1 Search Database (13)

The CCF events that have been entered intothe database cover a large range of systems andcomponents and vary in importance from a PRAperspective. Searches for CCF events to beincluded in parameter estimations can be struc-tured to prevent inclusion of events irrelevant toan individual study. For example, prior to search-ing for AFW pump events, which include eithermotor-driven pump CCF events, turbine-drivenpump CCF events, or CCF events that includeboth pump types, the analyst must decide to in-


All CCF event data obtained in the searchand saved (discussed in Section 3.1) can be re-viewed for applicability for specific studies. Someevents may be coded in a manner that does notreflect the PRA analyst's perception of the events.Each event can be reviewed to give the PRAanalyst an opportunity to modify or delete theevent from consideration in the specific applica-tion. The data fields that can be modified arecomponent degradation level, timing factor, sharedcause factor, and average impact vector. Thesoftware system defaults to "not modifying" thedata. This does not modify the event informationin the original database. Once the PRA analyst hasdetermined and entered the data modifications, thesoftware calculates the average impact vector forthe selected set of CCF events. During sensitivitystudies, the average impact vector values can bechanged and saved for calculating parameterestimates.

Additionally, the PRA analyst may want toanalyze the CCF data for applicability to aparticular plant, using the plant-specific option. Inthis case, some data may not be applicable be-cause of a difference in plant configuration or inshared cause factors between the original eventand the target plant. As in the generic option,event data can be modified or an event may bedeleted from the analysis. The fields that can bemodified are cause, shock type, component degra-dation level, shared cause factor, map up factor,event type, timing factor, shared cause factor,average impact vector, and application specificimpact vector. Once the PRA analyst has deter-mined and entered the applicability of an event,the software calculates the specific impact vector.Similar to the average impact vector values, thespecific impact vector values can be modified andstored for use in parameter estimations.

3.3 Estimate CCF Parameters(15)

Once event data are prepared for parameterestimation (Section 3.2), the final analytical stepis to perform the parameter estimation using either

of the two different quantification methods (ge-neric or specific). In both options, the models areselected (alpha factor or multiple Greek letter,or both) and the calculations performed. Theoutput of the parameter estimations is displayed inseveral ways: tabular, graphically, electronicallyfor transfer to other software applications. Uncer-tainty calculations are also provided. Figure 3

displays an example of output from the CCFsystem showing summary results of an EDGanalysis, including generic estimates of the CCFfrequency parameters for the failure-to-start mode.

The parameter estimation software uses theimpact vector approach. Reference 2 andVolume 2" discuss the use of event impact vec-tors. This method classifies the individual CCFevents according to the level of their impact onthe overall CCF effect on the PRA study and theassociated uncertainties in numerical terms, usingthe assessments from the event coding. Theseimpact vectors represent the certainty that eachevent represents a CCF event. They are based onthe component degradation factor, the timingfactor, and the shared cause factor, discussedbriefly in Section 2. Once the individual eventimpact vectors are determined, the average impactvector for the CCCG of interest (e.g., EDGs) iscalculated. The independent event counts areincluded in the CCF database, sorted by system,component, failure mode, source (LER orNPRDS), and docket. The user has the option ofmodifying the independent event value if there isuncertainty about the number provided, or if thereare additional assumptions or information to beused in the analysis.

The generic analysis portion of the databaseincludes an estimation of CCF parameters, frompooled plant data, which can be used in risk andreliability studies, or other applications such astrending of industry performance with respect tospecific types of failures. CCF data are used inthe Accident Sequence Precursor (ASP) program,safety system reliability studies, and for resolutionof NRC Generic Issues.


The plant-specific analysis option of theCCF software allows the PRA analyst to modifyevent coding to adjust CCF event data for designor operational differences between the plantwhere the actual CCF event occurred and the plantto which the data are applied. The softwareallows the analyst to review each event and mod-ify various attributes of the event or delete theevent from consideration in parameter estima-tions. Two adjustment factors, the cause applica-bility factor and the shared cause factor applica-bility, can be used to reflect the analyst's interpre-tation of the differences between the two plants.

The changes are saved in a copy of the databasefor the particular application for use at a latertime, while the data in the original database arenot changed. As with the generic estimations, theanalyst may use the independent events that are inthe CCF database, by individual plant, or theanalyst may choose another value, based onknowledge of the target plant. Additionally, thesoftware includes the capability to adjust the sizeof the CCCG, using mapping factors, so that anevent that occurred at a plant with n similarcomponents may be applied to a plant that has msuch components.

Application:

Component:

Failure Mode:

EDGFS

Special Quantification Report

Unadjusted IndependentEvents:

Total Common Cause Events:

Average Event CCCG:

EDG

FS

764

55

2.83

CCCG Size Adjusted Ind. Events Count Summary Alpha Factors MGL Factors

2 522.96 NI 30.0822 aI 0.9683328 1-Beta 9.68E-001

N2 18.0860 a2 3.16E-002 Beta 3.16E-002

3 784.45 NI 24.0867 al 0.9620172 1-Beta 9.62E-001

N2 17.2720 a2 2.05E-002 Beta 3.79E-002

N3 14.6510 a3 1.74E-002 Gamma 4.58E-001

Note: "Staggered" testing on MGL Calculations? Y

Figure 3. Parameter estimation example.


4. GENERAL INSIGHTS FROM ANALYSIS OF CCF DATA

The CCF database developed in this projectis a rich source of information on various aspectsof common cause failure. Exploring the fullpotential of the database merits a dedicated activ-ity and is outside the scope of the current effort,which has focused on building the infrastructurefor such analyses. Nevertheless, some generalobservations have been made on the character ofCCF events, including their causes and sharedcause factors, and frequency of occurrence. Someof these insights are summarized in this section.

Table 2 lists the systems, component types,and failure modes for which CCF events havebeen collected and entered into the database. Italso contains the number of CCF events for eachsystem and component combination and thenumber of independent failure events. This tableis an expansion of Table I (Section 1), providinga more detailed list of the component data thathave been reviewed. Table 2 only shows theevent counts for failure modes that are relevant toPRA studies, whereas Table I includes all eventsfor all failure modes. Other failure modes, suchas failure to close for reactor trip breakers, werefound in the source data; these events were codedand entered into the CCF database, even thoughthey are not likely to be used in PRA studies.

Basic information about the nature of CCFevents is displayed in Figures 4 and 5, whichillustrate the distribution of CCF event proximatecauses and shared cause factors, respectively. Thisinformation provides a general picture of the typesof events that may be expected to occur, and whatdesign features might be most susceptible to CCFevents. These figures also illustrate the differentcharacteristics of partial CCF events and completeCCF events (events with timing factor, sharedcause factor, and component degradation values foreach component in the CCCG =1.0). Figures 6, 7,and 8 display the number of CCF events by year ofoccurrence.

A general review of the actual events andthe distributions provided in Figures 4 and 5,reveals the following insights regarding CCFevents:

A major contributor to CCF events is pro-

grammatic maintenance practices. The fre-quency of scheduling has been a factor in thenumerous wearout-caused and aging-causedevents. Additionally, the quality of the main-tenance, both in the procedures and in perfor-mance of the maintenance activities, is a keyfactor. Similar events have occurred at dif-ferent plants-lubrication of circuit breakers(too much, too little, or too long betweenlubrications), improperly set torque and limitswitches on MOVs that are reported asmisadjustments and not setpoint drift. Thisindicates that there are maintenance practicesthat need to be reviewed to reduce commoncause failure potential.

* Another contributor is design problems.Many of the design-related events resultedfrom a design modification, indicating thatperhaps the modification review processeswere not rigorous and resulted in CCF sus-ceptibilities.

" Human errors related to procedures caused a

small percentage of the total events, but theimpact of the individual events is usuallygreater, since human errors have overriddenthe programmatic controls. This is illustrated

by comparing Figure 4b with Figure 4a,which shows that human error causes a largerportion of complete CCF events than partialCCF events. Examples of events caused by

human error are all EDG day tanks simulta-

neously drained for a chemistry surveillance,two pump breakers racked out as the plant

changed modes from shutdown to power.


" A vast majority of the CCF events are not dueto multiple failures in response to an opera-tional demand, but result from a "condition ofequipment." The most common is inspectionor surveillance test of one component reveal-ing a deficiency that prompts the licensee toinspect/test the redundant component, result-ing in the discovery that the same defectivecondition exists on both components. Thisdemonstrates that detection of failures duringthe testing and surveillance program preventsCCF events from occurring during demandsituations.

" The CCF database contains several exam-ples where both CCF and independentevents recur at some, but not all, plants,perhaps indicating ineffective root causeanalysis and corrective action. Examples ofrepeated events are water in compressed airsystems, pump seal wearout, and turbinegovernor misadjustment. Additionally, notall plants experience the same type of recur-ring event. This indicates that plant-to-plantvariability exists in the CCF parameters thatmight cause the CCF parameter estimatesfor some plants to be higher than the indus-try average for certain component andsystem combinations. Thus, it is very im-portant to perform plant-specific CCF pa-rameter estimations for plant-specific PRAsand reliability studies.

With respect to quantification of commoncause failures, the overall conclusion is that, basedon the evaluation of over 15 years of operatingexperience data, CCF parameters for similarcomponents vary among systems and failuremodes. Table 3 displays maximum likelihoodestimates (MLE) for both EDG failure modes, failto start and fail to run. Tables 4 and 5 display theMLEs for both the alpha factors (a 2) and betafactors for several component and system combi-nations. These results illustrate that the parameterestimates vary for different failure modes withinthe same component group, and that they alsovary between different systems for the samecomponent.

Another useful observation is that commoncause failure parameters of different componentsare available. Figure 9 shows the component-to-component variability of the mean a, for varioussystem and component combinations. It alsoshows a beta distribution fit to these data. Theequation for this beta distribution is:

n(a) -c F(A+B) tA- (l--)B1-r(A)(B)

where A= 2.0291, B = 45.707.

a5% = 0.0079

oc, 5% = 0.0984amean = 0.0425


I.-

NA

0%

Table 2. Component types and systems analyzed for CCF events (1980-1995).No. of CCFEvents for No. of Independent Total No. of CCF Total Number of In-

PRA-relevant System and Failures for System Events for Corn- dependent FailuresComponent Type Failure Modes Systems Analyzed for the Component Type Component Type & Component Type ponent Type for Component Type

Air-Operated Valves Fail to Open Auxiliary Feedwater (PWR) 42 197 191 505

Fail to Close High Pressure Injection (BWR) 2 28Fail to Remain Closed Isolation Condenser (BWR) 1 9

Main Steam Isolation (BWR & PWR) 146 271

Batteries/Chargers No, High Output DC Power (BWR & PWR) 60 1,260 60 1,260

Check Valves Fail to Open Auxiliary Feedwater fPR) 59 201 147 556Fail to Close High Pressure Inijection (BWR/PWR) 23/21 84/145Fail to Remain Closed Low Pressure Injection (BWR/PWR) 23/21 88/38

Circuit Breakers Fail to Open DC Power (BWR & PWR) 8 112 116 989Fail to Close AC Power (BWR & PWR) 82 746Fail to Remain Closed Reactor Trip Breakers (fail to open only) (PWR) 26 131

Emergency Diesel Generators Fail to Start, Run Emergency Power (BWR & PWR) 131 1.346 131 1.346Heat Exchangers Fail to Transfer Heat Containment Spray MEWR) 10 14 18 29

Residual Heat Removal (BWR/PWR) 8 15

Motor-Operated Valves Fail to Open Auxiliary Feedwater (PWR) 27 422 192 2,568Fail to Close Containment Spray (PWR) 15 250

Fail to Remain Closed High Pressure Injection (BWR/PWR) 11/40 369/292Isolation Condenser (BWR) 2 44Low Pressure Injection (BWR/PWR) 61/23 492/470Pressurizer (WR) 7 155Refueling Water Storage Tank (PWR) 6 74

Pumps Fail to Start Auxiliary Feedwater PWR) 51 919 280 3,507Emergency Service Water (BWR & PWR) 141 1,184

High Pressure Injection !WR/PWR) 2/42 343/481Low Pressure Injection (BWR/PWR) 9/25 148/362Standby Liquid Control (BWR) 10 70

Relief Valves Fail to Open BWR Primary System 37 237 115 976

Fail to Close Pressurizer (PWR) 22 334

Fail to Remain Closed Steam Generator (PWR) 56 405

Safety Valves Fail to Open Pressurizer (PWR) 6 119 38 280Fail to Close Steam Generator (PWR) 32 161

Fail to Remain Closed

Strainers Fail to Allow Flow Containment Spray (PWR) 1 0 39 162Emergency Service Water (BWR & PWR) 36 162Supession Pool (BWR) 2 0

Table 3. Emergency diesel generator CCF parameter estimations.

Fail to Start Fail to Run

___G2___G____G=4 CCCG=2 CCCG-3 CCCG-=4

Alpha Factor Alpha Factor Parameter Estimations

a, 0.968333 0.957241 0.950567 0.961131 0.939467 0.954343

a2 3.16E-2 2.45E-2 1.04E-2 3.88E-2 3.66E-2 1.18E-2

a- 1.82E-2 1.58E-2 - 2.38E-2 2.38E-2

a4 - 1.31E-2 - - 1.82E-2

MGL Parameter MGL Parameter Estimations

1-Beta 9.68E-1 9.57E-1 9.60E-1 9.61E-1 9.39E-1 9.46E-I

Beta 3.16E-2 4.27E-2 3.94E-2 3.88E-2 6.05E-2 5.38E-2

Gamma - 4.25E-1 7.35E-1 - 3.94E-1 7.80E-1

Delta - - 4.52E-1 - - 4.33E-1

Adj. Independent Events 522.96 784.45 1,045.9 450.98 676.47 901.96

Fail to Start Fail to RunNumber of Independent Failure Events: 764 Number of Independent Failure Events: 587Number of Common Cause Failure Events: 55 Number of Common Cause Failure Events: 76

Table 4. Alpha and beta factors for motor operated valves (CCCG=6).

Alpha Factor (a,) Beta Factor (P)System Fail to Open Fail to Close Fail to Open Fail to Close

Auxiliary Feedwater - PWR 1.50E-2 2.33E-2 3.27E-2 6.28E-2

High Pressure Safety Injection - PWR 2.21E-2 3.12E-2 5.95E-2 3.76E-2

Low Pressure Safety Injection - PWR 1.21E-2 9.28E-3 1.65E-2 1.65E-2

Low Pressure Coolant Injection - BWR 1.27E-2 1.90E-2 3.39E-2 4.60E-2

Table 5. Alpha and beta factors for pumps.

Alpha Factor (a2 ) Beta Factor (0)System CCCG Fail to Start Fail to Run Fail to Start Fail to Run

Emergency Service Water- BWR & PWR 6 3.23E-2 8.92E-3 8.38E-2 3.54E-2

Auxiliary Feedwater - PWR 4 1.25E-2 1.23E-2 4.79E-2 2.31E-2

High Pressure Safety Injection - PWR 3 2.18E-2 1.61E-2 5.28E-2 2.56E-2

Low Pressure Safety Injection - PWR 2 6.31E-2 5.34E-2 6.31E-2 5.34E-2

Low Pressure Coolant Injection - BWR 4 3.14E-2 6.40E-3 3.17E-2 6.40E-3

Standby Liquid Control - BWR 2 9.80E-2 3.24E-2 9.80E-2 3.24E-2


V Environment

a. Distribution of causes of complete and partial CCF events.

V Environment

b. Distribution of causes of only the complete CCF events.

Figure 4. Distribution of CCF events by cause.


Maintenance

51.6%

4.

11.7%

32.5%

Environment

a. Distribution of shared cause factors for both complete and partial CCF events.

FH-7d;7r

~Fj~nment

P Maintenance

t~a

b. Distribution of shared cause factors for only the complete CCF events.

Figure 5. Distribution of CCF events by shared cause factor.


SC

U-

00

Ez

80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95

Year

Figure 6. Distribution of all CCF events in database by year.

Figure 7. Distribution of CCF events by year and source.19 NUREG/CR-6268, Vol. 1

a

LL

06E

I.U

o15

a,0

10

E

z5

80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95

Year

Figure 8. Distribution of complete CCF events by year.


0.18

0.16

0.14

0.12

0.1

-" 0.08

0.06

0.04

0.02

0

0 0 0 C 0 ; 0 6 0 0 0 0 C5

Figure 9. Component-to-component variability of alpha factors.

5. REFERENCES

1. K. N. Fleming and A. Mosleh, Classification andAnalysis of Reactor Operating Experience InvolvingDependent Events, EPRI NP-3967, June 1985.

2. U.S. Nuclear Regulatory Commission, Procedures for Treating Common Cause Failures in Safety andReliability Studies, NUREG/CR-4780, Volume 1, January 1988, and Volume 2, January 1989.

3. U.S. Nuclear Regulatory Commission, Procedure for Analysis of Common Cause Failures inProbabilistic Safety Analysis, NUREG/CR-580 1, April 1993.

4. U.S. Nuclear Regulatory Commission, Common Cause Failure Database andAnalysis System, Volume2, Event Definition and Classification, NUREG/CR-6268, June 1998, INEEL/EXT-97-00696.

5. U.S. Nuclear Regulatory Commission, Common Cause Failure Database andAnalysis System, Volume3, Data Collection and Event Coding, NUREG/CR-6268, June 1998, INEEL/EXT-97-00696.

6. U.S. Nuclear Regulatory Commission, Common Cause Failure Database andAnalysis System, Volume4, CCF Software Reference Manual, NUREG/CR-6268, June 1998, INEEL/EXT-97-00696.

7. Science Applications International Corporation (SAIC),NuclearPower Plant Sstem Sourcebook, SanDiego, California, 1989.

8. Idaho National Engineering and Environmental Laboratory, AdaSAGE Reference Manual, Version4.1.1, Idaho.


GLOSSARY

Application-A particular set of CCF eventsselected from the common cause failure databasefor use in a specific study.

Average Impact Vector-An average over theimpact vectors for different hypotheses regardingthe number of components failed in an event.

Basic Event-An event in a reliability logic modelthat represents the state in which a component orgroup of components is unavailable and does notrequire further development in terms of contribut-ing causes.

Common Cause Event-A dependent failure inwhich two or more component fault states existsimultaneously, or within a short time interval,and are a direct result of a shared cause.

Common Cause Basic Event-In system modeling,a basic event that represents the unavailability ofa specific set of components because of sharedcauses that are not explicitly represented in thesystem logic model as other basic events.

Common Cause Component Group-A group of(usually similar [in mission, manufacturer, main-tenance, environment, etc.]) components that areconsidered to have a high potential for failure dueto the same cause or causes.

Common Cause Failure Model-The basis forquantifying the frequency of common causeevents. Examples include the beta factor, alphafactor, and basic parameter, and the binomialfailure rate models.

Complete Common Cause Failure-A commoncause failure in which all redundant componentsare failed simultaneously as a direct result of ashared cause; i.e., the component degradationvalue equals 1.0 for all components, and both thetiming factor and the shared cause factor are equalto 1.0.

Component-An element of plant hardware de-signed to provide a particular function.

Component Boundary-The component boundaryencompasses the set of piece parts that are consid-ered to form the component.

Component Degradation Value (p)-The assessedprobability (0.0 < p < 1.0) that a functionally orphysically degraded component would fail tocomplete the mission.

Component State-Component state defines thecomponent status in regard to its intended func-tion. Two general categories of component statesare defined, available and unavailable.

* Available-The component is available if it iscapable of performing its function according to aspecified success criterion. (N.B., available is notthe same as availability.)

a Unavailable-The component is unavailable ifthe component is unable to perform its intendedfunction according to a stated success criterion.Two subsets of unavailable states are failure and

functionally unavailable.

- Failure-The component is not capable ofperforming its specified operation accordingto a success criterion.

- Functionally unavailable-The componentis capable of operation, but the functionnormally provided by the component isunavailable due to lack of proper input, lackof support function from a source outsidethe component (i.e., motive power, actuationsignal), maintenance, testing, the improperinterference of a person, etc.


a Potentially unavailable-The component iscapable of performing its function according to asuccess criterion, but an incipient or degradedcondition exists. (N.B., potentially unavailable isnot synonymous with hypothetical.)

- Degraded--The component is in such a statethat it exhibits reduced performance butinsufficient degradation to declare the com-ponent unavailable according to the speci-fied success criterion.

- Incipient-The component is in a conditionthat, if left unremedied, could ultimatelylead to a degraded or unavailable state.

Shared Cause Factor/Mechanism-A set of causesand factors characterizing why and how a failureis systematically induced in several components.

Date-The date of the failure event, or date thefailure was discovered.

Defense-Any operational, maintenance, anddesign measures taken to diminish the frequencyand/or consequences of common cause failures.

Dependent Basic Events-Two or more basicevents, A and B, are statistically dependent if, and

only if,

P[AflB] = P[BIA]P[A] = P[AIB]P[B] # P[A]P[B],

where P[X] denotes the probability of event X.

Event-An event is the occurrence of a componentstate or a group of component states.

Exposed Population-The set of componentswithin the plant that are potentially affected by thecommon cause failure event under consideration.

Failure Mechanism-The history describing theevents and influences leading to a given failure.

Failure Mode-A description of componentfailure in terms of the component function thatwas actually or potentially unavailable.

Failure ModeApplicability-The analyst's proba-bility that the specified component failure modefor a given event is appropriate to the particularapplication.

Impact Vector-An assessment of the impact anevent would have on a common cause componentgroup. The impact is usually measured as thenumber of failed components out of a set ofsimilar components in the common cause compo-nent group.

Independent Basic Events--Two basic events, A

and B, are statistically independent if, and only if,

P[AfnB] = P[A]P[B],

where P[X] denotes the probability of event X.

Mapping-The impact vector of an event must be"mapped up" or "mapped down" when the ex-posed population of the target plant is higher orlower than that of the original plant that experi-enced the common cause failure. The end resultof mapping an impact vector is an adjusted impactvector applicable to the target plant.

Mapping Up Factor-A factor used to adjust theimpact vector of an event when the exposedpopulation of the target plan is higher than that ofthe original plant that experienced the commoncause failure.

Potential Common Cause Failure-Any commoncause event in which at least one componentdegradation value is less than 1.0.

Proximate Cause-A characterization of thecondition that is readily identified as leading tofailure of the component. It might alternativelybe characterized as a symptom.


Reliability Logic Model-A logical representationof the combinations of component states thatcould lead to system failure. A fault tree is anexamaple of a system logic model.

Root Cause-The most basic reason for a compo-nent failure which, if corrected, could preventrecurrence. The identified root cause may varydepending on the particular defensive strategyadopted against the failure mechanism.

Shared-Cause Factor (c)-A number that reflectsthe analyst's uncertainty (0.0 < c < 1.0) about theexistence of coupling among the failures of two ormore components, i.e., whether a shared cause offailure can be clearly identified.

Shock-A shock is an event that occurs at a ran-dom point in time and acts on the system; i.e., allthe components in the system simultaneously.There are two kinds of shocks distinguished bythe potential impact of the shock event, i.e., lethaland nonlethal.

System-The entity that encompasses an interact-ing collection of components to provide a particu-lar function or functions.

Timing Factor (q) -The probability (0.0 < q •

1.0) that two or more component failures (ordegraded states) separated in time represent acommon cause failure. This can be viewed as anindication of the strength-of-coupling in synchro-nizing failure times.


NRC FORM 335 U.S. NUCLEAR REGULATORY COMMISSION 1. REPORT NUMBER(2-89) (Assigned by NRC, Add Vol.,

NRCM 102. BIBLIOGRAPHC DATA SHEET Supp., Rev., and Addendum3201. 3202 (See Instructions on the reverse) Numbers, if any.)

NUREG/CR-6268INEEL/EXT-97-00696

2. TITLE AND SUBTITLE 3. DATE REPORT PUBLISHED

Common Cause Failure Database and Analysis System MONTH YEAR

Volume 1 - Overview June 19984. FIN OR GRANT NUMBER

E82475. AUTHOR(S) 6. TYPE OF REPORT

TechnicalF. M. Marshall, A. Mosleh, University of Maryland, D. M. Rasmuson, USNRC 7. PERIOD COVERED (Inclusive Dates)

N/A8. PERFORMING ORGANIZAITON - NAME AND ADDRESS (If NRC, provide Division, Office or Region, U.S. Nuclear Regulatory Commission,and mailing address; if contractor, provide name and mailing address.)

Idaho National Engineering and Environmental LaboratoryLockheed Martin Idaho Technologies Co.P.O. Box 1625Idaho Falls, ID 83415-3129

Subcontractor:Department of Materials and

Nuclear EngineeringUniversity of MarylandCollege Park, MD 20742-2115

9. SPONSORING ORGANIZATION - NAME AND ADDRESS (If NRC, type "Same as above"; If contractor, provide NRC Division, Office or Region,

U.S. Nuclear Regulatory Commission, and mailing address.)

Safety Programs DivisionOffice for Analysis and Evaluation of Operational DataU.S. Nuclear Regulatory CommissionWashington, DC 20555-0001

10. SUPPLEMENTARY NOTES

11. ABSTRACT (200 words or less)This volume of the Common Cause Failure Database and Analysis System report presents an overview of common cause

failure methods for use in the U.S. commercial nuclear power industry. It summarizes how data (on common cause failureevents) are gathered, evaluated, and coded. It then describes the process for estimating probabilistic risk assessment (PRA)common cause failure parameters. It also references other volumes of this report for specific details.

Equipment failures that contribute to common cause failure events are identified through searches of Licensee Event Reports(LERs) and Nuclear Plant Reliability Data System (NPRDS) failure reports. Once common cause failure events are identifiedby reviewing reports of equipment failures, INEEL staff enter the event information into a personal computer data analysissystem (CCF system) using the method presented in this and companion volumes. The events stored in the CCF system areused for common cause failure PRA parameter estimations using common cause failure quantification methods.

12. KEY WORDS/DESCRIPTORS (List words or phrases that will assist researchers in 13. AVAILABILITY

locating the report.) STATEMENTUnlimited14. SECURITY CLASSIFICATION

Common cause failure (This page)Unclassified

(This report)Unclassified

15. NUMBER OF PAGES

16. PRICE

NRC FORM 335 (2-89)

Federal Recycling Program

1NUREGICt-q6R6, VoL 1

UNITED STATEgSNUCLEA(R RGULATORlY COMMISSýION

WASHINGOMN, DC 90555000

OPFFIPAL, BUSINE8SSPENA;lY FOB PJtWAT UES3

Uommon4au3~ wauure jia1aornami~naiynu.zyuem: uvcrvww

POS.TAGOEý*qAfL6EES PND)IUSNRCi

0