A Brief History of CommonCause Failure Analysis

1
A Brief History of Common-Cause Failure Analysis
Presentation at the IAEA Technical Meeting on
CCF in Digital Instrumentation and Control
Systems for Nuclear Power Plants June 20, 2007
Bethesda, Maryland USA
2
Definition of CCF

• A common-cause failure event is an event in
  which
• Components fail within a selected time such that
  success of the PRA mission would be uncertain
• Component failures result from a single shared
  cause and coupling mechanism
• A component failure or fault occurs within the
  established component boundary
• Two or more components fail or are degraded,
  including failures during demand, in-service
  testing, or deficiencies that would have resulted
  in a failure if a demand signal had been received

3
Elements of CCFA

• Data Collection
• Common-cause failure event
• Exposed population
• Assessment of the degradation of the components,
  coupling factor, shared cause, etc.
• System Modeling
• Common-cause basic event
• Common-cause component group
• Estimation of CCF parameters

4
Early Efforts

• Epler (ORNL) 1969
• WASH-1400 1973
• K. Fleming (Beta Factor Method) 1975
• Fussell, et al. (Qualitative CCF Analysis) 1977
  
• Vesely (Marshall-Olkin Specializations) 1977
• Atwood (Binomial Failure Rate Model) 1977
• Edwards and Watson (UK) 1979
• Parry, et al. (C Factor) 1984
• Mosleh, et al (MGL, Alpha Factor) 1985
• CCF Benchmark Exercise 1985
• Mankamo (Common Load) 1983

5
EPRI and NRC Efforts

• EPRI
• Development of quantification methods
• Development of data classification concepts
• Development of defenses against CCFs
• NRC
• Methods development (early 1980s)
• Meetings with U.S. and U.K experts
• Resulted in Procedures for Treating Common Cause
  Failure in Safety and Reliability Studies
  (NUREG/CR-4780)

6
Additional Efforts

• Defenses (NUREG/CR-5460)
• Cause-defense matrices
• Methods (NUREG/CR-5801)
• Data collection efforts
• Started in early 1990s
• Data requirements (NUREG/CR-5471)
• Mosleh and Parry continued to develop data
  collection and classification concepts

7
CCF Database Development

• Developed and tested coding guidance
  (NUREG/CR-6268)
• Data sources are LERs, NPRDS, and EPIX
• Issued CCF Database in July 1998
• Initial database contained events from 1980
  through 1995
• Receive Feedback from users regarding coded
  events and software
• Today data is routinely collected and added to
  database and the CCF parameter estimates updated

8
Important Documentation

• NUREG/CR-6268, June 1998
• General CCF Guidance
• Coding Guidance
• Software Users Guide
• NUREG/CR-5497, October 1998
• CCF Parameter Estimations
• Updates available on NRC external web page
  (http//nrcoe.inel.gov/results)
• NUREG/CR-5485, November 1998
• PRA Guidance Update of NUREG/CR-4780

9
International CCF Efforts

• International Common-Cause Failure Data Exchange
  (ICDE) Project
• Operates under the auspices of OECD/NEA
• Canada, Finland, France, Germany, Spain,
  Switzerland, Sweden, United Kingdom, United
  States, Japan, Korea
• Data Exchanges
• MDPs, MOVs, EDGs, check valves, safety and relief
  valves, batteries, circuit breakers, level
  measurement devices, control rod drive
  assemblies, heat exchangers
• Data are proprietary, but available to INPO
  members
• Summary reports are available for MDPs, EDGs,
  MOVs, SRVs, check valves, and batteries

10
General Insights(from the CCF Database)

• A major contributor to CCF events is programmatic
  maintenance practices (frequency, quality in both
  procedures and performance)
• Another contributor is design problems
• Human errors related to procedures caused a small
  percentage of the total events
• A vast majority of the CCF events are not due to
  multiple failures in response to an operational
  demand, but result from a condition of
  equipment (e.g., inspection of one component
  revealing a deficiency leads to inspection of the
  redundant component, resulting in the discovery
  of the discovery of the same deficiency)

11
General Insights

• Quantitative methods are necessary for properly
  accounting for the effects of CCFs which in many
  cases dominate systems failure probabilities
• Equally important have been the qualitative
  insights from data classification
• Example understanding the nature of coupling
  factors is helpful in defining defenses and
  future system design guidance
• While many failure causes are component-specific,
  most coupling factors can be generalized to other
  domains (e.g., digital systems)
• Generic values of Beta factors (or similar ratio
  parameters) are remarkably similar across totally
  different systems and environments

12
Lessons Learned

• Data limitation dictated the nature of early
  methods (e.g., beta factor)
• Methods development is easier than data
  collection and classification
• Data collection and classification requires
  effort and resources

13
Comment on CCFA
C.A. Ericson II in Hazard Analysis Techniques for
System Safety (2005) said the following about
CCFA Since the inception of system safety,
there has always been a concern with regard to
CCFs and how to identify them. Many analysts
attempted to identify CCFs with hit-or-miss brute
force analyses without utilizing any sort of
coherent methodology. It was probably not until
1988 when Mosleh and his co-workers
NUREG/CR-4780 published their study and 1998
NUREG/CR-5485 when they published a study for
the U.S. Nuclear Regulatory Commission that CCFA
became more of a formalized analysis technique
with a coherent and comprehensive framework
(page 399).