ML17306A000

From kanterella
Jump to navigation Jump to search
NEI 16-16 Presentation for 11/2/2017 Meeting Version 0
ML17306A000
Person / Time
Site: Nuclear Energy Institute
Issue date: 11/02/2017
From: Fregonese V
Nuclear Energy Institute
To:
Office of Nuclear Reactor Regulation
Holonich J
References
Download: ML17306A000 (13)


Text

Vic Fregonese MEETING BETWEEN THE U.S. NUCLEAR Nuclear Energy Institute REGULATORY COMMISSION STAFF AND THE NUCLEAR ENERGY INSTITUTE TO DISCUSS NEI 16-16, GUIDANCE FOR ADDRESSING November 2, 2017 DIGITAL COMMON CAUSE FAILURE

Topics for Discussion Follow on to September 7 meeting topics, discuss further areas to be clarified:

  • Definition of Common Cause Failure
  • Residual Uncertainty in CCF Sufficiently Low Conclusion
  • Relaxed Acceptance Criteria and Technical Basis for Beyond Design Basis Events
  • Technical Basis for CCF Sufficiently Low

Purpose/Intent of NEI 16-16 See marked-up handout.

Definition of Common Cause Failure Proposed Definitions Developed by Staff and Industry NRC Staff Proposal Industry Proposal Common Cause Failure (CCF) Common Cause Failure (CCF)

Loss of function to multiple structures, Loss of function to multiple structures, systems or systems or components due to a shared components due to a shared root cause (IEEE Std.

root cause (IEEE Std. 603-2009). 603-2009).

For this guideline, the following notes apply: 1)

Loss of function means a malfunction of multiple SSCs caused by a specific I&C failure source. 2)

Shared root cause is limited to I&C failure sources, We are adding these notes so including single random hardware component the definition is constrained to failure, an environmental disturbance, a software the usage in NEI 16-16 design defect, and a human error.

Residual Uncertainty in CCF Sufficiently Low Conclusion The information on this slide was presented in the September 7 meeting It is helpful to compare NEI 16-16 to NEI 01-01. The residual uncertainty of The residual software CCF in NEI 01-01 is based on uncertainty in uncertainties in quality and design NEI 01-01 is processes for software. NEI 16-16 applies significantly quality (as well as independence) as a reduced by the Likelihood Reduction measure only, P Measures leaving the CCF as not sufficiently low.

provided in NEI 16-16 Preventive Measures in NEI 16-16 use quality, independence, and additional design attributes (such as avoiding concurrent triggers) to further reduce the software CCF likelihood so that the residual uncertainty of software CCF is no more significant than the residual From NEI 01-01 uncertainty of hardware CCF, which is considered sufficiently low.

CCF Sufficiently Low NEI 16-16 Uses the term not credible. Now propose to use Sufficiently Low from draft Appendix D of NEI 96-07 Likelihood of a CCF caused by a single failure considered in a safety NEI 96-07 Appendix D:

analysis described in the FSAR 3.15 Sufficiently Low Sufficiently low means much lower than the likelihood of failures that are considered in the UFSAR (e.g.,

Adapted from Figure single failures) and comparable to 4-3 in NEI 01-01 other common cause failures that are not considered in the UFSAR (e.g., design flaws, maintenance Likelihood of a CCF caused by Not Sufficiently Low errors, and calibration errors).

other failure sources that are not considered in a safety analysis*

described in the FSAR Sufficiently Low

  • as defined in NEI 96-07 Rev 1 Decreasing Likelihood

Technical Basis for BDBE Presented at September 7 Meeting With [an] added degree of uncertainty regarding failures due to software, additional measures are appropriate for systems that are highly safety significant (i.e., high consequences on Figure 3-2) to achieve an acceptable level of risk. For digital upgrades to such systems, the defense- in-depth and diversity in the overall plant design are analyzed to assure that where there are vulnerabilities to common cause software failure, the plant has adequate capability to cope with these vulnerabilities (see Section 5.2). This defense-in-depth and diversity analysis is considered a beyond design basis concern, reflecting an understanding that while not quantifiable, the likelihood of a common cause software failure in a high quality digital system is significantly below that of a single active hardware failure.

From NEI 01-01 Section 3.3.2 From ANS Glossary 2009

Acceptance Criteria for Beyond Design Basis Event (BDBE)

Presented at September 7 Meeting Acceptance Criteria

1. For each anticipated operational occurrence in the design basis occurring in conjunction with each single postulated CCF, the plant response calculated using realistic assumptions should not result in radiation release exceeding 10 percent of the applicable siting dose guideline values or violation of the integrity of the primary coolant pressure boundary.
2. For each postulated accident in the design basis occurring in conjunction with each single postulated CCF, the plant response calculated using realistic assumptions should not result in radiation release exceeding the applicable siting dose guideline values, violation of the integrity of the primary coolant pressure boundary, or violation of the integrity of the containment (i.e., exceeding coolant system or containment design limits).

From BTP 7-19 Rev. 7 (ML16019A344)

The ONS RPS/ESPS design includes diverse means to provide all required safety functions in the event of a software CCF. Safety functions that adequately From Oconee D3 Assessment (ML030920676) address each licensing basis event are provided in the design of the Diverse Actuation System. Based on this information, the NRC staff has determined that the proposed modification to the RPS/ESPS system complies with [ISG 2 Staff See Also:

Position 4, Effects of Common Cause Failure] and is, therefore, approved.

Technical Basis for CCF Sufficiently Low ( 1 of 3)

Presented at September 7 Meeting From WBN2 Segmentation Analysis (ML102240384)

In contrast with the degradation-caused Logic does not fail in the traditional fault modes of traditional hardware sense of degradation of a hardware characterized in Section 2.1, logic does component but the system could fail, not wear and tear from repeated usage. due to a pre-existing logic fault, If a system fails because of logic, it had triggered by some combination of some fault (defect or deficiency or inputs and system-internal conditions.

weakness) from the time of introduction, but this fault remained latent until the From RIL-1002 (ML14197A201) occurrence of a triggering or enabling combination of inputs, state of the See Also:

From RIS 2017-XX (ML17102B507) environment, state of the DI&C system,

Technical Basis for CCF Sufficiently Low (2 of 3)

Presented at September 7 Meeting An example, about concurrent triggers From RIS 2017-XX (ML17102B507) continued from NEI 16-16 Appendix A The configuration differences between controllers provide the technical basis for reasonable From NEI 16-16 Appendix A assurance that triggers are non-concurrent

Technical Basis for CCF Sufficiently Low (3 of 3)

Consistent with the guidance provided in NEI 01-01, this attachment specifies three general categories of proposed design-related characteristics (described in Table 1 below) that can be used to develop justifications that demonstrate low likelihood of failure for a proposed modification. The aggregate of the three qualitative assessment categories form the technical basis for developing justifications based upon the likelihood of failure (i.e., single failures and CCF) of a digital I&C modification to a system or components.

From RIS 2017-XX (ML17102B507)

The underlying design details in NEI 16-16 Appendix A provide the technical basis for each preventive measure. Licensees may develop alternate measures, but they must also provide their own technical basis.

Review

  • NEI provided responses to NRC Regulatory Purpose Discussion handout
  • NEI 16-16 will use same definition of CCF as NRC proposed definition, but with notes to align with purpose of NEI 16-16
  • NEI 16-16 will use the same definition of sufficiently low provided in Appendix D
  • NEI 16-16 will incorporate a figure illustrating CCF likelihood, adapted from NEI 01-01, and using the definition of sufficiently low
  • The technical basis for BDBE is well founded in existing guidance and precedents
  • The design details provided in NEI 16-16 Appendix A form the technical bases to demonstrate low likelihood of failure for a proposed modification (draft RIS 2017-XX) as long as those design details are fully implemented. Alternate measures require their own justification.

Questions or Comments?