ML17306A000
| 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 Nuclear Energy Institute November 2, 2017 MEETING BETWEEN THE U.S. NUCLEAR REGULATORY COMMISSION STAFF AND THE NUCLEAR ENERGY INSTITUTE TO DISCUSS NEI 16-16, GUIDANCE FOR ADDRESSING DIGITAL COMMON CAUSE FAILURE
Topics for Discussion Follow on to September 7 meeting topics, discuss further areas to be clarified:
- Purpose/Intent of NEI 16-16
- 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)
Loss of function to multiple structures, systems or components due to a shared root cause (IEEE Std. 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, including single random hardware component failure, an environmental disturbance, a software design defect, and a human error.
Common Cause Failure (CCF)
Loss of function to multiple structures, systems or components due to a shared root cause (IEEE Std. 603-2009).
We are adding these notes so the definition is constrained to the usage in NEI 16-16
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 software CCF in NEI 01-01 is based on uncertainties in quality and design processes for software. NEI 16-16 applies quality (as well as independence) as a Likelihood Reduction measure only, leaving the CCF as not sufficiently low.
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 uncertainty of hardware CCF, which is considered sufficiently low.
From NEI 01-01 The residual uncertainty in NEI 01-01 is significantly reduced by the P Measures provided in NEI 16-16
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 NEI 96-07 Appendix D:
3.15 Sufficiently Low Sufficiently low means much lower than the likelihood of failures that are considered in the UFSAR (e.g.,
single failures) and comparable to other common cause failures that are not considered in the UFSAR (e.g., design flaws, maintenance errors, and calibration errors).
Not Sufficiently Low Sufficiently Low Decreasing Likelihood Likelihood of a CCF caused by a single failure considered in a safety analysis described in the FSAR Adapted from Figure 4-3 in NEI 01-01 Likelihood of a CCF caused by other failure sources that are not considered in a safety analysis*
described in the FSAR
- as defined in NEI 96-07 Rev 1
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 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 Position 4, Effects of Common Cause Failure] and is, therefore, approved.
From Oconee RPS/ESFAS SER (ML100220016)
From Oconee D3 Assessment (ML030920676)
See Also:
Technical Basis for CCF Sufficiently Low ( 1 of 3)
Presented at September 7 Meeting From RIS 2017-XX (ML17102B507)
From WBN2 Segmentation Analysis (ML102240384)
In contrast with the degradation-caused fault modes of traditional hardware characterized in Section 2.1, logic does not wear and tear from repeated usage.
If a system fails because of logic, it had some fault (defect or deficiency or weakness) from the time of introduction, but this fault remained latent until the occurrence of a triggering or enabling combination of inputs, state of the environment, state of the DI&C system, and state of the faulty logic.
From NUREG/IA-0254 (ML11201A179)
Logic does not fail in the traditional sense of degradation of a hardware component but the system could fail, due to a pre-existing logic fault, triggered by some combination of inputs and system-internal conditions.
From RIL-1002 (ML14197A201)
Software CCF = Defect + Concurrent Trigger See Also:
Technical Basis for CCF Sufficiently Low (2 of 3)
Presented at September 7 Meeting From RIS 2017-XX (ML17102B507)
From NEI 16-16 Appendix A continued from NEI 16-16 Appendix A An example, about concurrent triggers The configuration differences between controllers provide the technical basis for reasonable 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?