Two types of sensitivity analysis are included in this report. The first type addresses the impact on results by an assumed incompleteness of the failure data collection. The second type relates to the sensitivity of the time-dependent LOCA frequencies to different assumptions about leak detection and in-service inspection. The sensitivity analysis results are included in Section D.6.

D.3 Service Experience Data Application to the Base Case Study

The PIPExp database documents service experience with Code Class 1, 2 and 3 and non-safety related (or Class 4) piping in commercial nuclear power plants worldwide. For the time period 1970-2002, this database was queried for service experience data specific to the Base Case piping systems. The results of the database queries are summarized here, and they form the input to the data processing and failure parameter estimation in Sections D.4 and D.5.

D.3.1 PIPExp Database, Revision 2003.1

The pipe failure database utilized in the Base Case Study is called PIPExp. It is an ACCESS database and an extension of the OPDE database [D. 12-D. 13]. Since the conclusion of the original work in 1998 [D.11,

D.17], the pipe failure database has been significantly expanded both in terms of the absolute number of event records and the depth of the database structure (Appendix A provides additional details). Lessons learned through database applications have been used to enhance the structure. In this study of HPI//NMU-, FW-, RC — and RR-piping reliability the statistical analysis is based on service data as recorded in PIPExp and with cutoff date of December 31, 2002. The analysis is inclusive of applicable worldwide BWR — and PWR- specific service experience with Code Class 1 piping. As of 12-31-2002 the database accounted for approximately 1,992 and 3,621 critical reactor-years of operating experience with commercial BWR and PWR plants, respectively.

The database is actively maintained and periodically updated. The effort involved in populating the database while at the same time assuring data quality is not trivial. As an example, changing regulatory reporting thresholds imply that an ever increasing volume of raw data reside in restricted and proprietary database systems rather than in the public domain. For an event to be considered for inclusion in the database it undergoes screening for eligibility. For example:

• The equipment failure must be positively identified as a piping component failure external to the reactor pressure vessel (RPV). A failure involves a pressure boundary degradation, which can be non-through-wall (crack with a/t-ratio > 10%, where a = crack depth and t = wall thickness) or a through-wall leak.

• There must exist documented evidence in the form of a hard copy (e. g., USNRC Inspection Report, Licensee Event Report, ISI Summary Report, Problem Identification Form, Condition Report,

ASME Code Repair Relief Request, etc.) from which a sufficiently detailed case history is developed. The documented evidence of pipe degradation/failure must contain information on its location within a piping system (e. g., with reference to an isometric drawing and/or P&ID), metallurgy, operating conditions, impact on operation, method of discovery, failure history, etc. so that a data classification may be independently verified.

• Where the documented evidence is deemed incomplete, additional information is solicited through direct contact with plant personnel or by accessing supplemental data.

• There must be sufficient technical information available to fully address the complex relationships between piping reliability attributes (or design parameters) and influence factors (e. g., fabrication/welding techniques, environmental conditions such as water chemistry, flow conditions) on the one hand and degradation/failure mechanisms on the other.

• Differentiation between UT indications versus confirmed crack indications. Only the latter are included in the database given an a/t-ratio > 10%.

Following on the initial data screening, each event selected for inclusion in the database is subjected to a classification so that the unique reliability attributes and influence factors are identified. Including memo fields, text fields, numerical fields and data filters, up to 114 database fields describe each record of the database.