ML20080G707
| ML20080G707 | |
| Person / Time | |
|---|---|
| Site: | Nuclear Energy Institute |
| Issue date: | 03/12/2020 |
| From: | Vaughn S Nuclear Energy Institute |
| To: | Borges J Office of Administration |
| References | |
| 85FR2152 00008, NRC-2019-0253 | |
| Download: ML20080G707 (12) | |
Text
March 12, 2020 Office of Administration Mail Stop: TWFN-7-A60M U.S. Nuclear Regulatory Commission Washington, DC 20555-0001
Subject:
Industry Comments on Draft Revision 8 to Branch Technical Position (BTP) 7-19, Guidance for Evaluation of Common Cause Failure Hazards Due to Latent Software Defects in Digital Instrumentation and Control Systems; 85 FR 2152-2153; Docket ID NRC-2019-0253 Project Number: 689
Dear Ms. Jennifer Borges:
The Nuclear Energy Institute (NEI) [1], on behalf of its members, submits the following comments on the draft Revision 8 to Branch Technical Position (BTP) 7-19, Guidance for Evaluation of Common Cause Failure Hazards Due to Latent Software Defects in Digital Instrumentation and Control Systems. We are supportive of the effort to revise this BTP and appreciate the opportunity to comment on the draft revision.
The NEI Digital Instrumentation and Control (DI&C) working group has been actively engaged with the staff in the revision to BTP 7-19 over the past year. The public meetings held during 2019 and into 2020 have been great opportunities to share technical and regulatory perspectives. Overall the NEI DI&C working group is pleased to see how this BTP revision has incorporated a graded approach into the DI&C categorization process and the techniques used to prevent and mitigate a software common cause failure (CCF) hazard.
Please find the attached comments on the current draft Revision 8 to BTP 7-19. Our intention is to provide recommendations, with sound technical and regulatory bases, that clarify the guidance to ensure both licensees and the NRC staff have a common understanding when submitting and reviewing a DI&C license amendment request (LAR.) As stations begin to consider plant modernization, we believe that it is this common understanding that will allow future digital modifications to be reviewed, approved, and implemented in an efficient and predictable manner.
Please contact me at sjv@nei.org and (202) 739-8163 if you have any questions or concerns.
Sincerely,
[1]
The Nuclear Energy Institute (NEI) is responsible for establishing unified policy on behalf of its members relating to matters affecting the nuclear energy industry, including the regulatory aspects of generic operational and technical issues. NEIs members include entities licensed to operate commercial nuclear power plants in the United States, nuclear plant designers, major architect and engineering firms, fuel cycle facilities, nuclear materials licensees, and other organizations involved in the nuclear energy industry.
STEPHEN J. VAUGHN Senior Project Manager, Engineering and Risk 1201 F Street, NW, Suite 1100 Washington, DC 20004 SUNSI Review Complete P: 202.739.8163 Template = ADM-013 sjv@nei.org E-RIDS=ADM-03 nei.org ADD: Mark Notich COMMENT (8)
PUBLICATION DATE: 1/14/2020 CITATION 85 FR 2152 March 12, 2020 Office of Administration Mail Stop: TWFN-7-A60M U.S. Nuclear Regulatory Commission Washington, DC 20555-0001
Subject:
Industry Comments on Draft Revision 8 to Branch Technical Position (BTP) 7-19, Guidance for Evaluation of Common Cause Failure Hazards Due to Latent Software Defects in Digital Instrumentation and Control Systems; 85 FR 2152-2153; Docket ID NRC-2019-0253 Project Number: 689
Dear Ms. Jennifer Borges:
The Nuclear Energy Institute (NEI) 1, on behalf of its members, submits the following comments on the draft Revision 8 to Branch Technical Position (BTP) 7-19, Guidance for Evaluation of Common Cause Failure Hazards Due to Latent Software Defects in Digital Instrumentation and Control Systems. We are supportive of the effort to revise this BTP and appreciate the opportunity to comment on the draft revision.
The NEI Digital Instrumentation and Control (DI&C) working group has been actively engaged with the staff in the revision to BTP 7-19 over the past year. The public meetings held during 2019 and into 2020 have been great opportunities to share technical and regulatory perspectives. Overall the NEI DI&C working group is pleased to see how this BTP revision has incorporated a graded approach into the DI&C categorization process and the techniques used to prevent and mitigate a software common cause failure (CCF) hazard.
Please find the attached comments on the current draft Revision 8 to BTP 7-19. Our intention is to provide recommendations, with sound technical and regulatory bases, that clarify the guidance to ensure both licensees and the NRC staff have a common understanding when submitting and reviewing a DI&C license amendment request (LAR.) As stations begin to consider plant modernization, we believe that it is this common understanding that will allow future digital modifications to be reviewed, approved, and 1
The Nuclear Energy Institute (NEI) is responsible for establishing unified policy on behalf of its members relating to matters affecting the nuclear energy industry, including the regulatory aspects of generic operational and technical issues. NEIs members include entities licensed to operate commercial nuclear power plants in the United States, nuclear plant designers, major architect and engineering firms, fuel cycle facilities, nuclear materials licensees, and other organizations involved in the nuclear energy industry.
Mr. Jennifer Borges March 12, 2020 Page 2 implemented in an efficient and predictable manner.
Please contact me at sjv@nei.org and (202) 739-8163 if you have any questions or concerns.
Sincerely, Stephen Vaughn cc: Mr. Eric Benner, NRR Mr. Wendell Morton, NRR Ms. Tekia Govan, NRR Mr. Michael Waters, NRR NRC Document Control Desk
NEI DI&C Working Group Comments on BTP 7-19, Revision 8 Topic and Comment/Basis Recommendation Affected Section(s)
- 1. Spurious Operations Perspectives on IEEE 603-1991 Clauses 4.8 and 5.6.3 Because IEEE 603-1991, Clauses 4.8 and 5.6.3, do Section A not provide a licensing basis requirement to analyze Regulatory Basis IEEE 603-1991 Clause 4.8 states that The conditions for spurious operations caused by a software CCF, Section 5 having the potential for functional degradation of safety NEI recommends:
system performance and for which provisions shall be incorporated to retain the capability for performing the 1. Deleting the reference to IEEE 603-1991 in safety functions (for example, missiles, pipe breaks, fires, Section A.1 Regulatory Basis and the loss of ventilation, spurious operation of fire suppression other references to spurious operations systems, operator error, failure in non-safety-related throughout the BTP.
systems). 2. Moving the guidance in Section 5 Spurious Operations from the draft Revision 8 of
- 1. In the example list, the phrase failure in non- BTP 7-19 to another NRC guidance safety-related systems is not intended to include document. NEI is very interested in a software CCF failure mode. Rather, in keeping continuing the technical discussion on DI&C with the other examples in clause 4.8, the failure and spurious operations. The NRC and the in not-safety-related systems should be NEI DI&C working group should schedule a interpreted as spatial proximity hazards to the public meeting in the near future to clarify qualification of nearby safety systems. A latent the technical details and the appropriate software defect in a non-safety-related system guidance to document the results.
should not be interpreted as a spatial proximity hazard similar to the other examples listed.
The term failure, as defined in IEEE 379, does not include design deficiencies (i.e., a latent software design error) in the scope. As such, the phrase failure in not-safety-related systems should not include software CCFs as a type of failure mode.
- 2. Based on the discussion in 1) above, the phrase having the potential for functional degradation of 1
NEI DI&C Working Group Comments on BTP 7-19, Revision 8 Topic and Comment/Basis Recommendation Affected Section(s) safety system performance should be interpreted in an operational context. Meaning that, if one of the example failures were to occur, the actual function of safety system performance would be challenged, therefore, an operability determination would typically be performed. If a latent software defect did occur in a non-safety-related system, it would not necessarily affect the actual function of safety system performance. The latent software defect may create an unanalyzed condition; however, the unanalyzed condition is not equivalent to a functional degradation of safety system performance.
Perspectives on SRM-SECY 93-087 SRM-SECY-93-087 refers to DI&C CCF events as a loss of more than one echelon of defense-in-depth. A spurious operation should not be considered a loss of defense-in-depth nor a loss of the safety function.
The current draft of BTP 7-19 does not equate "loss" with "spurious operation". Position 2 in SECY-93-087 states, "analyze each postulated common-mode failure for each event that is evaluated in the accident analysis section of the safety analysis report (SAR) using best estimate methods."; whereas BTP 7-19 states, "The spurious operation should be considered as an initiating event without a concurrent DBE." As such, spurious operations should not be analyzed the same way as a latent design error (e.g., latent software defect) that causes a loss of function.
2
NEI DI&C Working Group Comments on BTP 7-19, Revision 8 Topic and Comment/Basis Recommendation Affected Section(s)
- 2. Design Attributes Section 3.1, entitled Means to Eliminate CCF Hazard from Reword the 1st sentence in the last paragraph of Section 3.1. Further Consideration does not explicitly state that the Section 3.1 to read:
design attributes described in Sections 3.1.1, 3.1.2, and 3.1.3 can be used collectively in eliminating the CCF If the application demonstrates that the use of hazard from further consideration. these design attributes, in any combination or on their own, for an A1 system or component meet the In Section 3, entitled Diversity and Defense-in-Depth criteria within this BTP, the CCF hazard has been (D3) Assessment at the end of the first paragraph it eliminated from further consideration.
notes that the results of the D3 assessment should show that vulnerabilities to CCF hazards have been adequately addressed through any combination of the following:
Similar language should be used in Section 3.1 to clarify that a combination of design attributes (Sections 3.1.1, 3.1.2, and 3.1.3) can be used in determining that the CCF hazard has been eliminated from further consideration.
- 3. DI&C Categorization The definitions for the A1 - B2 categories need to be See suggested revision to Table 2-1 at the end of Section B.2.1 clarified to ensure predictable outcomes: this comment table for more detail.
Table 2-1 A1 Category: 1. Reword the 2nd deterministic definition under A1 to read Failure could directly lead Regarding the statement if not mitigated by other A1 to accident conditions that may cause systems. Is there an inherent assumption that the A1 unacceptable consequences (i.e., exceeds systems normally relied upon for mitigation are not siting dose guidelines for a DBE) and no available or do not function? If so, one could postulate other A1 systems are able to provide the unacceptable consequences for practically any accident if safety function.
[the accident is] not mitigated by other A1 systems. 2. Incorporate the second paragraph after Table 2-1 (starts off with Risk insights in B1 and B2 Categories: terms of) into Table 2-1 such that it is 3
NEI DI&C Working Group Comments on BTP 7-19, Revision 8 Topic and Comment/Basis Recommendation Affected Section(s) clearly part of the categorization process.
Does the term consequences to plant safety refer to This change would justify the vertical labels dose consequences as it clearly does for A1 systems? of Safety Significant and Not Safety Significant; otherwise the labels would be B1 Category: misleading because the deterministic definitions do not effectively characterize Regarding the statement Directly changes the reactivity safety significance.
or power level There are many balance of plant SSCs 3. Revise the part of the 1st definition under that can directly change the secondary side of the plant B1 to read Directly changes the reactivity and affect reactivity and reactor power level, but would or power level of the reactor that could not be considered safety significant. initiate an accident sequence... Another approach could be to note that some Vertical Category Descriptions changes (e.g., a change in steam demand for a PWR) is an indirect effect on reactor The labels of Safety Significant and Not Safety power level and reactivity. This would Significant are not appropriate given the deterministic preclude any failure of a balance of plant and qualitative definitions provided in each of the four (BOP) component that causes a minor categories. The qualitative definitions may describe increase (or decrease) in the secondary side varying levels of safety from a DI&C deterministic to be considered safety significant.
perspective, but they do not describe safety significance 4. Revise the 2nd definition under B1 and B2 to from a risk-informed (i.e., RG 1.174) perspective. removed the phrases that refer to consequences and replace it with the If the labels of Safety Significant and Not Safety concept of an impact on plant safety.
Significant remain, it will cause confusion in the categorization process and challenge current efforts to embrace a more risk-informed approach to licensing and oversight functions.
- 4. Software vs. The very last sentence of the first paragraph of the NEI recommends limiting the scope of BTP 7-19 to Hardware CCF Background section states This BTP is focused on just software CCF and remove any discussion Section A addressing CCF hazards resulting from systematic faults regarding hardware and or systems CCF.
Background
Purpose 4
NEI DI&C Working Group Comments on BTP 7-19, Revision 8 Topic and Comment/Basis Recommendation Affected Section(s) caused by latent defects in software or software-based logic.
CCF due to hardware is mentioned earlier in the paragraph, however the last sentence indicates that CCF due to hardware is not being addressed by this document.
In the Purpose section, second paragraph, fourth sentence states:
However, in integrated DI&C systems, a single random hardware failure can have cascading effects, similar to a CCF hazard (e.g., loss of multiple functions within a safety group, or spurious operation of functions within multiple safety groups). Single random hardware failures with cascading effects are considered DBEs, because random hardware failures are expected during the life of the facility.
Two comments on the above statement:
- 1. Earlier in the document it was stated that CCF was considered beyond design basis. This statement seems to contradict that earlier statement by now suggesting this postulated CCF hazard is not beyond design basis.
- 2. This statement seems to be addressing hardware whereas an earlier statement in the Background section of the document indicated that BTP 7-19 focuses only on systematic errors due to software or software-based logic.
5
NEI DI&C Working Group Comments on BTP 7-19, Revision 8 Topic and Comment/Basis Recommendation Affected Section(s)
- 5. Justification for Not Revision 4 of BTP 7-19 contained guidance that would Recommend changing Section 8.6 to read:
Correcting Specific accept system vulnerability to certain beyond design basis Vulnerabilities events (i.e., common-mode failure in the protection 8.6. Justification for Not Correcting Specific Section 8.6 system affecting the response to large-break loss-of- Vulnerabilities coolant accidents and main steam line breaks). This interpretation has been previously used in licensing Justification should be provided for not correcting actions. This acceptance was based upon the provision of any identified vulnerabilities not addressed by other primary and secondary coolant system leak detection, and aspects of the application such as design attributes, pre-defined operating procedures that together enable defensive measures, or provision of alternate trip, operators to detect small leaks and take corrective actions initiation, or mitigation capability. This includes any before a large break occurs. In effect, the vulnerabilities NRC-approved credited operator action taken to were judged to be acceptably mitigated based on manual prevent the AOO or postulated accident from operator actions with a recognition that a best-estimate occurring. These justifications will be reviewed on a treatment of these beyond design basis event scenarios case-by-case basis. For example, the use of accepted that they would evolve over time rather than primary and secondary coolant system leak occurring as instantaneous double-ended guillotine breaks detection and pre-defined operating procedures (as analyzed in Chapter 15). that collectively enable operators to detect leaks and take corrective actions before a large break BTP 7-19 should be revised to specifically allow the develops. This mitigation strategy would be used previously accepted resolution of software CCF in the in lieu of more in-depth human factors evaluation protection system affecting the response to large-break of manual operator actions or the addition of loss-of-coolant accidents and main steam line breaks diverse actuation features to address instantaneous based on the provision of primary and secondary coolant double-ended breaks coincident with a postulated system leak detection, and pre-defined operating protection system software CCF.
procedures that together enable operators to detect small leaks and take corrective actions before a large break occurs. This mitigation strategy would be used in lieu of more in-depth human factors evaluation of manual operator actions or the addition of diverse actuation features to address instantaneous double-ended breaks coincident with postulated a protection system CCF.
6
NEI DI&C Working Group Comments on BTP 7-19, Revision 8 Topic and Comment/Basis Recommendation Affected Section(s)
- 6. Quality of NSR Second paragraph states: Replace the entire last (2nd) paragraph in Section equipment 3.2.1 and the 3rd and 4th sentences in the first Section B.3.2.1 For existing systems that are NSR, the quality of these paragraph in Section 3.2.2 (begins with If the Section B.3.2.2 systems should be similar to systems required by the equipment used and ends with Generic Letter ATWS rule (i.e., 10 CFR 50.62), as described in the 85-06) with:
enclosure of Generic Letter 85-06.
NSR systems that are credited in the analysis that This is a new requirement. In past cases feedwater are in continuous use (e.g., the normal RCS systems have been used as a credited existing system, inventory control system or normal steam which may not have similar quality characteristics. generator level control system) are not required to be meet any augmented quality standards. NSR In Revision 7 of BTP 7-19, Section 3.4 stated: systems that are credited in the analysis that are not in continuous use (i.e., standby,) reliability data Other systems that are credited in the analysis that are in and operational experience can be used to continuous use (e.g., the normal RCS inventory control conclude that the system will perform its intended system or normal steam generator level control system) function(s) when demanded are not required to be upgraded to the augmented quality discussed above.
In crediting existing NSR systems (3.2.1), to include equipment used to perform credited manual operator actions (3.2.2), continuously operating equipment should not be required to meet the augmented quality standard.
For non-continuously operating NSR equipment (i.e.,
stand-by equipment,) it should be sufficient to provide evidence of reliability (i.e., data and operational experience) to substantiate that the system will perform its intended function when demanded. Evidence of reliability, can be used to meet any expectation of sufficient quality for non-safety-related systems.
7
NEI DI&C Working Group Comments on BTP 7-19, Revision 8 Topic and Comment/Basis Recommendation Affected Section(s)
- 7. Tech Specs Last paragraph of 3.1.1 states: Provide the appropriate link to the Regulatory Basis Section 3.1.1 section and a clarifying example of how an It should be noted that because each redundant safety- allowable time would be restricted.
related division is credited for compliance with the single-failure criterion and is now additionally credited to prevent the CCF hazard, the allowable time that a division can be bypassed as specified in the technical specification may be more restrictive than if the redundancy is solely credited for meeting the single-failure criterion. The consistency of proposed changes and technical specifications should be addressed in the application.
It is not clear how a software CCF could be a factor in the Technical Specification allowable time for a division to be bypassed.
- 8. Robust Design The 2nd paragraph of the section entitled Purpose starts Recommend changing the 2nd paragraph to read:
Process by stating:
Section A.4 This BTP is intended to address an applicants This BTP is intended to address an applicants approach approach to address CCF hazards caused by latent to address CCF hazards caused by latent defects in the defects in the software or software-based logic, software or software-based logic. This type of CCF hazard which are considered beyond-design-basis events.
is considered a beyond-design-basis event for structures, systems, and components (SSCs) that employ a robust design process to reduce the likelihood of design defects.
The way the 2nd sentence above is constructed could led one to assert that if a robust design process was not employed, then the software CCF hazard would no longer be considered a beyond design basis event.
8
NEI DI&C Working Group Comments on BTP 7-19, Revision 8 Recommended Edits to Table 2-1 Safety-Related Non-Safety-Related Safety A1 DI&C SSCs B1 DI&C SSCs Significant*
A significant Relied upon to initiate and complete control Directly changes the reactivity or power level of contributor to actions essential to maintain plant parameters the reactor that could initiate an accident sequence plant safety within acceptable limits established for a DBE. or affects the integrity of the safety or barriers (fuel cladding, reactor vessel, or Failure could directly lead to accident containment).
conditions that may cause unacceptable or consequences (i.e., exceeds siting dose Failure may result in unacceptable guidelines for a DBE) and no other A1 systems consequences to has a high impact on plant are able to provide the safety function. safety due to integration of multiple control functions into a single system.
Application should include a D3 assessment as described in Section B.3 Application should include a qualitative assessment as described in Section B.4 Not Safety A2 DI&C SSCs B2 DI&C SSCs Significant*
Not a significant Provides an auxiliary or indirect function in the Does not have a direct effect on reactivity or contributor to achievement or maintenance of plant safety. power level of the reactor or affect the integrity plant safety Or of the safety barriers (fuel cladding, reactor Maintains the plant in a safe shutdown state vessel, or containment).
after the plant has reached initial safe And shutdown state.9 Failure does not have consequences to impact plant safety or whose failure can be detected and Application should include a qualitative mitigated with significant safety margin.
assessment as described in Section B.4 Application may need to include a qualitative assessment as described in Section B.4 if the proposed design could introduce conditions10 that have not been previously analyzed in the SAR.
- Risk insights in terms of safety consequences from site-specific probabilistic risk assessments (PRAs) can be used to support the safety-significance determination in categorizing the DI&C SSC system. Use of such risk insights should be an input to an integrated decision-making process for categorizing the proposed DI&C SSC system. The application should document the basis for categorizing the proposed DI&C SSC system, including any use of risk insights.
9