ML20038A195

From kanterella
Jump to navigation Jump to search
NEI Dic Comments on BTP 7-19 Revision 8 to Support Feb 11 2020 Public Meeting
ML20038A195
Person / Time
Site: Nuclear Energy Institute
Issue date: 02/06/2020
From: Vaughn S
Nuclear Energy Institute
To: Tekia Govan
NRC/NRR/DRO/IRSB
Govan T, NRR/DRO, 415-6197
Shared Package
ML20038A193 List:
References
Download: ML20038A195 (8)


Text

NEI DI&C Working Group Comments on BTP 7-19, Revision 8 in support of the 2/11/2020 Public Meeting Topic and Comment/Basis Recommendation Affected Section(s)

1. Spurious Operations Table 1 - Spurious Operations (starting on page 7 has a high- Because licensing basis evidence that spurious Section A level overview) operations caused by a beyond design basis event Regulatory Basis (i.e., software CCF) is a licensing basis requirement Section 5 Perspectives on IEEE 603-1991 Clauses 4.8 and 5.6.3 per IEEE 603-1991, the spurious operations guidance proposed for Revision 8 to BTP 7-19 should be IEEE 603-1991 Clause 4 is about what, as a minimum, must removed and placed in another NRC guidance be documented in the design basis. Clause 4.8 in particular is document.

about conditions (hazards) that could degrade the safety system but provisions are provided so the safety system can perform its safety functions.

Clause 5.6.3 requires that safety systems can perform in the presence of the conditions identified in 4.8. In 4.8, what must be documented in the design basis is the set of hazardous conditions that (a) could degrade the safety system and (b) there are provisions incorporated to retain the capability to perform the safety function. It is clear the safety system does not have to prevent the conditions.

Rather, the safety system would be designed with provisions so it will continue to perform the safety function.

Again, 4.8 is about what must be in the design basis. It appears that the text in the draft BTP 7-19 is requiring evaluations of conditions that might not be in the design basis.

1

NEI DI&C Working Group Comments on BTP 7-19, Revision 8 in support of the 2/11/2020 Public Meeting Topic and Comment/Basis Recommendation Affected Section(s)

2. DI&C Categorization The definitions for the A1 - B2 categories need to be NEI recommends two options.

Section B.2.1 clarified to ensure predictable outcomes:

Table 2-1 Option #1 -

A1 Category:

1. Clarify the deterministic definitions in each of Regarding the statement if not mitigated by other A1 the four categories (A1 thru B2).

systems. Is there an inherent assumption that the A1 2. Remove the vertical labels of Safety systems normally relied upon for mitigation are not available Significant and Not Safety Significant.

or do not function? If so, one could postulate unacceptable 3. Incorporate the second paragraph after Table consequences for practically any accident if [the accident is] 2-1 (starts off with Risk insights in terms not mitigated by other A1 systems. of) into Table 2-1 such that it is clearly part of the categorization process. For example, B1 and B2 Categories: the Section 2.1 process could have various steps (i.e., step 1 - use Table 2-1 definitions; Does the term consequences to plant safety refer to dose step 2 - incorporate risk insights; step 3 -

consequences as it clearly does for A1 systems? make an integrated risk-informed decision)

B1 Category: Option #2 -

Regarding the statement Directly changes the reactivity or

1. Remove the deterministic definitions in A1 power level There are many balance of plant SSCs that thru B2 and replace them with a definition of can directly change steam demand and affect reactivity and safety-significant function and threshold reactor power level but would not be considered safety criteria for what is considered high and significant.

low Vertical Category Descriptions The labels of Safety Significant and Not Safety Significant are not appropriate given the deterministic and qualitative definitions provided in each of the four categories. The qualitative definitions may describe varying levels of safety 2

NEI DI&C Working Group Comments on BTP 7-19, Revision 8 in support of the 2/11/2020 Public Meeting Topic and Comment/Basis Recommendation Affected Section(s) from a DI&C deterministic perspective, but they do not describe safety significance from a risk-informed (i.e., RG 1.174) perspective.

If the labels of Safety Significant and Not Safety Significant remain, it will cause confusion in the categorization process and challenge current efforts in moving to embrace a more risk-informed approach to licensing and oversight functions.

3. 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 addressing just software CCF and remove any discussion Section A CCF hazards resulting from systematic faults caused by regarding hardware and or systems CCF.

Background latent defects in software or software-based logic.

Purpose 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.

3

NEI DI&C Working Group Comments on BTP 7-19, Revision 8 in support of the 2/11/2020 Public Meeting Topic and Comment/Basis Recommendation Affected Section(s)

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.
4. Justification for Not Revision 4 of BTP 7-19 contained guidance that would accept BTP 7-19 should be revised to specifically allow the Correcting Specific system vulnerability to certain beyond design basis events previously accepted resolution of common-mode Vulnerabilities (i.e., common-mode failure in the protection system failures in the protection system affecting the Section 8.2 affecting the response to large-break loss-of-coolant response to large-break loss-of-coolant accidents and Section 8.6 accidents and main steam line breaks). This interpretation main steam line breaks based on the provision of has been previously used in licensing actions. This primary and secondary coolant system leak acceptance was based upon the provision of primary and detection, and pre-defined operating procedures that secondary coolant system leak detection, and pre-defined together enable operators to detect small leaks and operating procedures that together enable operators to take corrective actions before a large break occurs.

detect small leaks and take corrective actions before a large This mitigation strategy would be used in lieu of more break occurs. In effect, the vulnerabilities were judged to be in-depth human factors evaluation of manual acceptably mitigated based on manual operator actions with operator actions or the addition of diverse actuation a recognition that a best-estimate treatment of these features to address instantaneous double-ended beyond design basis event scenarios accepted that they guillotine breaks coincident with postulated a would evolve over time rather than occurring as protection system CCF.

4

NEI DI&C Working Group Comments on BTP 7-19, Revision 8 in support of the 2/11/2020 Public Meeting Topic and Comment/Basis Recommendation Affected Section(s) instantaneous double-ended guillotine breaks (as analyzed Suggested changes:

in Chapter 15).

8.2. Documentation of Assumptions The application documents any assumptions made to compensate for missing information in the design description materials or to explain interpretations of the analysis guidelines as applied to the system. For example, the design basis assumption of instantaneous double-ended guillotine breaks for large-break loss-of-coolant accidents and main steam line breaks can be replaced with a more realistic treatment for break opening times for the best-estimate evaluations. The use of primary and secondary coolant system leak detection and pre-defined operating procedures that together enable operators to detect leaks and take corrective actions before a large break develops.

8.6. Justification for Not Correcting Specific Vulnerabilities Justification should be provided for not correcting any identified vulnerabilities not addressed by other aspects of the application such as design attributes, defensive measures, or provision of alternate trip, initiation, or mitigation capability. This includes any NRC-approved credited operator action taken to prevent the AOO or postulated accident from occurring. These justifications will be reviewed on a 5

NEI DI&C Working Group Comments on BTP 7-19, Revision 8 in support of the 2/11/2020 Public Meeting Topic and Comment/Basis Recommendation Affected Section(s) case-by-case basis. For example, the use of primary and secondary coolant system leak detection and pre-defined operating procedures that together enable operators to detect leaks and take corrective actions before a large break develops. 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 guillotine breaks coincident with postulated a protection system CCF.

5. Quality of NSR Second paragraph states: Modify the sentence to state:

equipment Section B.3.2.1 For existing systems that are NSR, the quality of these For existing systems that are NSR and not systems should be similar to systems required by the continuously operating, the reliability of these ATWS rule (i.e., 10 CFR 50.62), as described in the systems should be consistent with licensee design enclosure of Generic Letter 85-06. programs and processes.

This is a new requirement. In past cases feedwater systems have been used as a credited existing system, which may not have similar quality characteristics.

6

NEI DI&C Working Group Comments on BTP 7-19, Revision 8 in support of the 2/11/2020 Public Meeting Table 1 - Spurious Operations Safety-related controls with direct Non-safety related controls with Non-safety related controls with connection to safety components direct connection to safety no direct connection to safety components components Beyond Design Beyond Design Beyond Design Design Basis Design Basis Design Basis Basis Basis Basis Single failure Software CCF Credible Software CCF No Software CCF criterion and to prevent failures in and in control requirements in control consequential actuation consequential systems and in IEEE Std 603 systems and failures caused (Clause 4.12 actions by control room control room by design basis has been cited other systems, HMI causes HMI causes event (Clause for some LARs) as spurious spurious 5.1) Software CCF documented actuation of actuation of Qualification for from control in Clause 4.h safety-related non safety-environment room HMI of the design components related and external causes basis components events to avoid spurious (qualification), that represent hardware CCF actuation shall not new (Clauses 4.h and (only new prevent the transients not 5.2) plant safety systems evaluated in precedents) from meeting Chapter 15 its requirements.

Requirements for isolation, physical 7

NEI DI&C Working Group Comments on BTP 7-19, Revision 8 in support of the 2/11/2020 Public Meeting separation and consideration of single random failures are specified.

(Clause 5.6.3)

Note: Protection Note: CCF Note: It is often considered that the design basis events evaluated system safety from ESFAS in Chapter 15 are related to a failure assessment of the non-safety functions are not generally related systems, but they are not. There are some events that are derived from considered as specified for evaluation in SRP Chapter 15 that would only occur analysis of source of with multiple non-mechanistic failures (e.g., loss of all feedwater, specific spurious loss of feedwater enthalpy, etc.).

postulated actuation in initiating events approved in FSAR Chapter precedents

15. These events have been standardized in SRP Chapter 15.

(Clauses 4.1 and 4.2) 8