ML19171A021
| ML19171A021 | |
| Person / Time | |
|---|---|
| Issue date: | 06/20/2019 |
| From: | Tekia Govan NRC/NRR/DIRS/IRGB |
| To: | |
| Govan T,415-6197, NRR/DIRS | |
| References | |
| Download: ML19171A021 (5) | |
Text
May 2019 Industry Feedback on BTP 7-19 (ML19135A401) Comment Number BTP 7-19 Section Comment Industry Recommendations 1 1.5 Section 1.5 notes that Clauses 6.2 and 7.2 of IEEE 603-1991 state -related means shall be provided in the control room to implement manual initiation of the automatically initiated protective Industry, including members of the subcommittee responsible for the standard, note that Clauses 6.2 and 7.2 applies to design basis events, and does not address criteria for beyond design basis events (i.e., CCF). Clarify that outside the control room manual actions to initiate diverse protective actions to address CCF are permitted. 2 1.8 The scope of spurious actuations caused by a software CCF is not technically bounded. Limit the scope of spurious actuations to be considered in the analysis using a reasonable set of criteria given that software CCF is a beyond design basis event. 3 1.9 1. 100% Testing is not feasible for complex digital projects that involve software; therefore it is not feasible to use. 2. Testability and diversity, as the only two options to adequately address CCF, are not effective. Change the guidance for Testability and add an option for Defensive Measures: 1. Testability- [Based on IEEE 7-4.3.2-2016 technical guidance] In conjunction with the testing expected in NRC regulatory guides 1.152 and 1.168, a system or component can be extensively tested to provide reasonable assurance that the system or component is not susceptible to CCF. The following individual criteria would be used: a. Throughout testing, allocated outputs are monitored for correctness (with respect to a reference of acceptable behavior) during testing for each of the test criteria objectives. b. The separate test criteria applied are as follows: i. Every possible combination of discrete inputs that are used by the logic (unused discrete inputs that are forced to a known state are excluded from this criteria)
May 2019 Industry Feedback on BTP 7-19 (ML19135A401) Comment Number BTP 7-19 Section Comment Industry Recommendations ii. The operational range of the analog inputs, with specianalog values that result in changes of logical state; as well as the analog inputs (unused analog inputs that are forced to a known state are excluded from this criteria); iii. Every logic path (this includes non-sequential logic paths); iv. Every functional state transition for each state machine or logical group of state machines. v. Any unreachable logic as a result of these tests will require further analysis to determine potential hazards c. The applicant should demonstrate that unused inputs cannot cause transition, mode, or configuration changes in the system or component. d. This testing should be conducted with test hardware representing the production hardware. 2. Defensive Measures a. Inherent design features i. Independent watchdog timers ii. Isolation devices iii. Segmentation iv. Self-testing/self-diagnosing b. Non-concurrent triggers c. Structured module software and module testing 3. The three design attributes of Testability, Diversity, and Defensive Measures should be considered in the aggregate to make a reasonable technical determination that CCF has been adequately addressed and does not need to be considered any further (i.e., no need to provide additional external diversity.)
May 2019 Industry Feedback on BTP 7-19 (ML19135A401) Comment Number BTP 7-19 Section Comment Industry Recommendations 4 3.1(8)b States that the diverse means should be initiated from the control room, which would include operator actions. State that the diverse means, which would include operator actions, could be initiated outside of the control room. 5 3.1(9) The scope of spurious actuations caused by a software CCF is not technically bounded. Limit the scope of spurious actuations to be considered in the analysis using a reasonable set of criteria given that software CCF is a beyond design basis event. 6 3.5 The paragraphs in Section 3.5 are disconnected and do not clearly describe the expectations in using manual actions as a diverse means to accomplish safety functions. Change the language in Section 3.5 to read: If manual operator actions are used as the diverse means or as part of the diverse means to accomplish a safety function, a suitable HFE analysis should be performed by the applicant to demonstrate that plant conditions can be maintained within recommended acceptance criteria for the particular AOO or postulated accident. When manual actions are credited and are required in less than thirty minutes, the applicant must justify that the time available and time required for the operator action to maintain the recommended acceptance criteria for the particular AOO or postulated accident is feasible and reliable. The acceptability of such actions is to be reviewed by the NRC and emergency procedures already in place that would be invoked to respond to such a beyond design basis event. The applicant must demonstrate that these manual actions are independent of the automatic actuation system with the postulated CCF. SRP Chapter 18, Revision 3, Attachment A, provides various methods available to the applicant to justify the feasibility and reliability of credited operator actions including diverse manual operator actions to cope with CCF. Attachment A does not limit these manual actions to the control room. Similar to FLEX strategies for beyond design May 2019 Industry Feedback on BTP 7-19 (ML19135A401) Comment Number BTP 7-19 Section Comment Industry Recommendations basis events, the applicant may make the justification that there is sufficient time to use manual operator action reliably outside of the control room to maintain plant conditions within the recommended acceptance criteria for the particular AOO or postulated accident. 7 3.7 The scope of spurious actuations caused by a software CCF is not technically bounded. Limit the scope of spurious actuations to be considered in the analysis using a reasonable set of criteria given that software CCF is a beyond design basis event. 8 4.7 Revision 4 to BTP 7-19 had guidance regarding LBLOCA and MSLB and Revision 7 does not. Use the language below for Section 4.7: If any identified vulnerabilities are not addressed by provision of alternate trip, initiation, or mitigation capability, justification should be provided. Justification may be based upon the availability of systems outside of the scope of the analysis that act to prevent or mitigate the event of concern. For example, I&C system vulnerability to CCF affecting the response to large-break loss-of-coolant accidents and main steam line breaks can credit existing primary and secondary coolant system leak detection, including pre-defined operating procedures that together enable operators to detect small leaks and take corrective actions before a large break occurs. 9 N/A 1. The A1 definition (part (2)) can have a wide scope because it does not clearly define a . 2. Under A2 and B1 of the graded approach the CCF evaluation is a Defense-in-Depth/Qualitative Assessment. Is the Defense-in-Depth analysis limited to the Defense-in-Depth discussion in RIS 2002-22, Supplement 1 (12 of 16)? If it is something beyond that, what defines a Defense-in-Depth analysis? 1. A1: Safety-consequences if not mitigated by other A1 systems. [adapted from IEC 61226 Ed. 3]
May 2019 Industry Feedback on BTP 7-19 (ML19135A401) Comment Number BTP 7-19 Section Comment Industry Recommendations Clarify what is expected for a Defense-in-Depth analysis for A2 and B1 categories. 10 General Some topics have guidance dispersed throughout the document in multiple sections, which makes the concepts difficult to understand. For example, manual operator actions are discussed in Section 1.5, Section 1.7, Section 3.1(8), and Section 3.5. Where appropriate, consolidate concepts to a limited number of sections for simplicity and overall clarity.