"Draft Meeting" is not in the list (Request, Draft Request, Supplement, Acceptance Review, Meeting, Withholding Request, Withholding Request Acceptance, RAI, Draft RAI, Draft Response to RAI, ...) of allowed values for the "Project stage" property.

Text

Work-in-Progress Copy of NEI 20-07, Draft Revision E (Non-Proprietary) to Support Public Meeting
	ML24211A227
Person / Time
Site:	Nuclear Energy Institute
Issue date:	07/21/2023
From:	Archambo N, Andy Campbell, Herb R, Odess-Gillet W; Constellation Energy Corp, Dominion Energy, Nuclear Energy Institute, Southern Nuclear Company, Westinghouse
To:	; Office of Nuclear Reactor Regulation
	Marshall M, NRR/DORL/LPL1
References
	EPID L-2023-NFN-0012 NEI 20-07, Rev. E
	Download: ML24211A227 (1)
	v • d • e

Guidance for Addressing Common Cause Failure in High Safety-Significant Safety-Related Digital l&C Systems Prepared by the Nuclear Energy Institute July 2024 WORK-IN-PROGRESS DRAFT TO SUPPORT MEETINGS WITH NRC STAFF. THIS IS NOT INTENDED TO REPRESENT A SUBMITTAL FOR REVIEW.

SOME SECTIONS OF THIS WORK-IN-PROGRESS DRAFT HAVE BEEN PURPOSEFULLY OMITTED.

nei.org NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 Revision Table Revision Description of Changes Date Responsible Person Modified Rev E Updated to account for SRM-SECY-22-0076.

7/21/ 23 Campbell, Alan Restructured to support safety case development.

nei.org NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 Acknowledgements This document was developed by the Nuclear Energy Institute. NEI acknowledges and appreciates the contributions of NEI members and other organizations in providing input, reviewing, and commenting on the document including:

NEI Project Lead:

NEI Project Team:

Notice Alan Campbell, NEI Warren Odess-Gillett, Westinghouse Neil Archambo, Archambo EC Ray Herb, Southern Nuclear Company Jeremy Chenkovich, Dominion Energy Mark Samselski, Constellation Energy Neither NEI, nor any of its employees, members, supporting organizations, contractors, or consultants make any warranty, expressed or implied, or assume any legal responsibility for the accuracy or completeness of, or assume any liability for damages result ing from any use of, any information apparatus, methods, or process disclosed in this report or that such may not infringe privately owned rights.

nei.org NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 Executive Summary Common Cause Failure (CCF) in High Safety-Significant, Safety-Related (HSSSR) Digital Instrumentation and Control (Dl&C) Systems is a significant technical and regulatory issue that must be overcome to modernize the existing operating nuclear power plants and enable new reactor technology to be deployed. Digital (or software) CCF has been addressed through the implementation of independent and diverse Instrumentation and Control {l&C) systems. Other means of addressing digital CCF (e.g.,

extensive testing) are available; however, their applications are limited. Additionally, diverse l&C systems add complexity to the facility, divert resources from safety-significant activities, and increase Operations and Maintenance (O&M) costs. Independence and diversity are indeed useful design techniques; these design techniques, as with all design techniques, should be used when supported by an engineering analysis. The Commission provided direction to NRC staff in SRM-SECY-22-0076 documenting an expanded policy that allows for new approaches to addressing CCF using risk insights.

NEI 20-04, "The Nexus Between Safety and Operational Performance in the U.S. Nuclear Industry,"

provides data that displays the impact of risk-informed initiatives on the U.S. nuclear industry. Between 1992 and 2020, the U.S. nuclear industry reduced Core Damage Frequency (CDF) on average by a factor of 10. Focusing on safety significant issues allows the allocation of resources in the manner that most effectively improves safety.

This document provides a Diversity and Defense-in-Depth (D3) analysis for the facility using risk insights and hazards analysis techniques. This document establishes a safety case framework using claims, arguments, and evidence to demonstrate that vulnerabilities to digital CCF have been adequately addressed by this D3 analysis.

This document provides the safety case framework that demonstrates the output of the EPRI Digital Engineering Guideline (DEG), Hazards and Consequence Analysis in Digital Systems (HAZCADS), and Digital Reliability Analysis Methodology (DRAM) processes (References 13, 14, and 15) provide a D3 analysis addressing the SRM-SECY-22-0076 policy.

I I

nei.org NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024

nei.org NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 Table of Contents 1

Introduction................................................................................................................................ 9 2

Definitions.................................................................................................................................. 9 3

Regulatory Basis.......................................................................................................................... 9 3.1 SRM-SECY-22-0076......................................................................................................... 9 3.1.1 SRM-SECY-22-0076 Points 1-3............................................................................ 9 3.1.2 SRM-SECY-22-0076 Point 4................................................................................. 9 3.2 Other Regulatory Requirements................................................................................... 10 4

System Diagnostic Process........................................................................................................ 10 4.1 Process Overview......................................................................................................... 10 4.2 EPRI HAZCADS Overview.............................................................................................. 10 4.2.1 Identify Risk Reduction Target.......................................................................... 11 4.2.2 Identify Stakeholder Losses and System Hazards.............................................. 12 4.2.3 Model the Control Structure Hierarchy............................................................ 13 4.2.4 Identify Unsafe Control Actions........................................................................ 14 4.2.5 Allocate RRT Scores.......................................................................................... 14 4.3 EPRI DRAM Overview................................................................................................... 15 4.3.1 Initiation.......................................................................................................... 15 4.3.2 Identify Control Effectiveness Profile............................................................... 15 4.3.3 Develop Loss Scenarios.................................................................................... 15 4.3.3.1 Inadequate Controller Behavior........................................................... 15 4.3.3.2 Inadequate Control Algorithm............................................................. 15 4.3.3.3 Inadequate Feedback or lnformation................................................... 15 4.3.3.4 Inadequate Control Pathway............................................................... 15 4.3.3.5 Inadequate Process Behavior............................................................... 15 4.3.4 Mitigate Loss Scenarios.................................................................................... 15 4.3.4.1 Identify Control Methods.................................................................... 15 4.3.4.2 Score and Allocate Control Met hods.................................................... 15 4.4 Process Clarifications for US Regulatory Compliance..................................................... 15 4.4.1 EPRI HAZCADS Clarifications............................................................................. 15 4.4.2 EPRI DRAM Clarifications................................................................................. 16 4.4.3 Design Iteration............................................................................................... 16 5

Safety Case Development......................................................................................................... 16

nei.org NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 5.1 Safety Case Structure................................................................................................... 18 5.1.1 Safety Case Description.................................................................................... 21 5.1.2 Safety Case Uncertainty................................................................................... 21 5.2 Tier 1 Claim, Argument and Sub-Claims........................................................................ 21 5.2.1 Tier 1 Top Claim............................................................................................... 21 5.2.2 Tier 1 Argument and Sub-Claims...................................................................... 22 5.3 Tier 2 Arguments, Evidence and Sub-Claims................................................................. 23 5.3.1 Tier 2, Argument 1: EPRI HAZCADS and DRAM Efficacy..................................... 23 Supporting Evidence:........................................................................... 24 5.3.1.1 EPRI Research...................................................................................... 24 5.3.1.2 Supporting Evidence: NRC Research.................................................... 24 5.3.1.3 Supporting Evidence: STPA Use in Other Safety Crit ical Industries....... 24 5.3.1.4 Supporting Evidence: Systematic Control Method Scoring................... 24 5.3.1.5 Supporting Evidence: Risk Informed Principles..................................... 24 5.3.2 Tier 2, Argument 2: Postulated CCF Identification/Analysis.............................. 28 5.3.3 Tier 2, Argument 3: Addressing Postulated CCF................................................ 30 5.4 Tier 3 Arguments and Evidence.................................................................................... 30 5.4.1 Resolution of Tier 2, Sub-Claim 1...................................................................... 30 5.4.2 Resolution of Tier 2, Sub-Claim 2...................................................................... 31 5.4.3 Resolution of Tier 2, Sub-Claim 3...................................................................... 32 5.4.4 Resolution of Tier 2, Sub-Claim 4...................................................................... 32 6

Conclusion................................................................................................................................ 33 7

References................................................................................................................................ 33 Appendix A. Sample Template.............................................................................................................. A-1 Table of Figures Figure 1: Generic Control Structure Hierarchy........................................................................................ 13 Figure 2: Safety Case Simplified Diagram............................................................................................... 17 Table of Tables Table 1:Establish RRT Based on £:.CDF and l:.LERF................................................................................... 12

nei.org NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 Table 2: Types of Controllers and Their Attributes................................................................................. 13 Table 3: Target CEP for Systematic Capability........................................................................................ 15 Table 4: Example STPA Users................................................................................................................. 24

nei.org NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 1

INTRODUCTION Common Cause Failure (CCF) in High Safety-Significant, Safety-Related (HSSSR) Digital Instrumentation and Control (Dl&C) Systems is a significant technical and regulatory issue that must be overcome to modernize the existing operating nuclear power plants and enable new reactor technology to be deployed. Digital (or software) CCF has been addressed through the implementation of independent and diverse Instrumentation and Control {l&C) systems. Other means of addressing digital CCF (e.g.,

extensive testing) are available; however, their applications are limited. Additionally, diverse l&C systems add complexity to the facility as well as increase Operations and Maintenance (O&M) costs.

Independence and diversity are indeed useful design techniques; these design techniques, as with all design techniques, should be used when supported by an engineering analysis. The Commission provided direction to NRC staff in SRM-SECY-22-0076 documenting an expanded policy that allows for new approaches to addressing CCF using risk insights. NEI 20-04, The Nexus Between Safety and Operational Performance in the U.S. Nuclear Industry," provides data that displays the impact of risk-informed initiatives on the U.S. nuclear industry. Between 1992 and 2020, the U.S. nuclear industry reduced Core Damage Frequency (CDF) on average by a factor of 10. Focusing on safety significant issues allows the allocation of resources in the manner that most effectively improves safety.

This document provides a Defense-in-Depth and Diversity (D3) analysis for the facility using risk insights and hazards analysis techniques. This document establishes a safety case using claims, arguments, and evidence to demonstrate that vulnerabilities to digital CCF have been adequately addressed by this D3 analysis. This document provides the safety case which provides the details that demonstrate the output of the EPRI Digital Engineering Guideline (DEG), Hazards and Consequence Analysis in Digital Systems (HAZCADS), and Digital Reliability Analysis Methodology (DRAM) processes (References 13, 14, and 15) provide a D3 analysis addressing the SRM-SECY-22-0076 policy.

This process may be applied to operating reactor licensees or new plant applicants. Licensees and applicants should ensure the Dl&C system design meets all other applicable regulatory requirements and applicable guidance. Applicants using this guidance for operating reactor license amendments and new plant applications using NUREG-0800 Standard Review Plan guidance can use this guidance to develop a D3 assessment to demonstrate that CCF has been adequately addressed. Applicants using this guidance for new plant applications using Regulatory Guide 1.233 can use this guidance to develop a D3 assessment to demonstrate the adequacy of special treatments applied to address CCF.

2 DEFINITIONS 3

REGULATORY BASIS 3.1 SRM-SECY-22-0076 3.1.1 SRM-SECY-22-0076 Points 1-3 3.1.2 SRM-SECY-22-0076 Point 4

NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

nei.org 9

July 2024 3.2 Other Regulatory Requirements Other regulatory requirements shall be addressed consistent with the applicants licensing basis. This guidance is only intended to address the applicant's approach to addressing CCF consistent with SRM-SECY-22-0076.

4 SYSTEM DIAGNOSTIC PROCESS The development of a safety case concluding that CCF has been adequately addressed is dependent on the analysis performed using the EPRI DEG, HAZCADS, and DRAM.

4.1 Process Overview

. These diagnostic processes provide effective means of identifying, analyzing, and addressing potential CCF. These processes are to be used within the context of the EPRI DEG which provides a systems engineering approach to the design and lifecycle management of Dl&C systems.

When using this process to support the modification of an operating plant, the applicant should refer to NISP-EN-004 for incorporation of these processes into the Standardized Design Process, IP-ENG-001.

EPRI Digital Engineering Guide (DEG) provides a systems engineering process by which engineers integrate digital technology into a nuclear power plant. It uses a graded approach based on configurability and consequence to address procurement, human factors engineering, data communications, cyber security, plant integration design, testing, configuration management and digital obsolescence management. The DEG provides an iterative design process to develop Dl&C systems. The DEG provides the Dl&C system scope, design, and plant interfaces for further analysis in the EPRI HAZCADS and DRAM processes. Insights (i.e., requirements and Control Methods) developed during the HAZCADS and DRAM processes are provided back into the DEG as design input. The design continues to mature as it progresses through the design phases and iterative diagnostic loops. Insights from HAZCADS and DRAM become more granular as the design reaches more granular levels of detail.

The following overview of EPRI HAZCADS and DRAM is intended to be descriptive, not instructional.

Practitioners of these processes should consult EPRI HAZCADS (Reference 14) and DRAM (Reference 15) for detailed guidance.

4.2 EPRI HAZCADS Overview EPRI HAZCADS is a diagnostic tool that identifies plant and system level hazards and consequences as well as their associated risk sensitivity. EPRI HAZCADS uses the Dl&C and system interface design information provided by the EPRI DEG as inputs to its diagnostic process. EPRI HAZCADS uses two hazard/failure analysis methodologies: Systems Theoretic Process Analysis (STPA) and Fault Tree Analysis (FTA). The result of HAZCADS is identification of Stakeholder Losses, System Hazards, UCAs, and RRTs. The EPRI HAZCADS outputs interface with downstream processes that further analyze and apply

nei.org 10 NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 Control Methods based upon causal factors. The following subsections are an overview of HAZCADS including the STPA process. For more information on these processes see References 14 and 36.

4.2.1 Identify Risk Reduction Target RRTs are identified based upon risk sensit ivity analyses using a PRA model. The RRT can be developed from one of five different pathways based upon the scope of the system under analysis, the stage of the design process, and whether the system(s) is modeled in the PRA.

When performing the risk sensit ivity analysis, the practit ioner should use the appropriate pathway based on the scope of the Dl&C system.

Pathway 1: Scope of digital system is not associated with systems modeled in the PRA.

This pathway relies on a qualitative assessment of the systems risk to the plant. This pathway should not be used in conjunction with NEI 20-07.

Pathway 2: Scope of digital systems is associated with a system modeled in the PRA.

This pathway directs the practit ioner to associate full system failure with surrogate events modeled in the PRA to determine the risk impact. This pathway should be used for Dl&C systems that fully control a plant system.

Pathway 3: Scope of digital systems is associated with a sub-system (or components of a system) modeled in PRA.

This pathway directs the practit ioner to associate failures of portions of the system associated with the Dl&C system with surrogate events modeled in the PRA to determine the risk impact. This pathway should be used for Dl&C systems that partially control a plant system.

Pathway 4: Scope of digital system is associated with multiple plant systems modeled in PRA.

This pathway directs the practit ioner to associate failure of all plant systems controlled by the Dl&C system with surrogate events modeled in the PRA to determine the risk impact. This pathway should be used for Dl&C systems that fully control multiple plant systems.

Pathway 5: Systems Theoretic Informed Fault Tree This pathway directs the practit ioner to associate each Unsafe Control Action with a surrogate event modeled in the PRA to determine risk impact. This approach can be used after UCAs have been developed and in conjunction with Pathways 2, 3 and 4 to provide a more granular insight to the risk impact.

For large Light Water Reactors (LWRs) the result of the sensitivity study may be a change in Core Damage Frequency (CDF) and Large Early Release Frequency (LERF). Other reactor technologies may use different risk metrics specific to the reactor design. For those reactor technologies, the RRT thresholds should align with industry accepted guidance. For reactor technologies that use CDF and LERF, the t.CDF and t.LERF are then mapped to the regions in RG 1.174 Figures 4 and 5 and used to determine the RRT as shown in Table 1. For instance, assume the t.CDF of a complete failure of the HSSSR system is lE-3,

nei.org 11 NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 then to reach the level of non-risk-significance, the RRT would be A in Table 1. If tiCDF and tiLERF results provide different RRT results, then the most conservative RRT result is applied throughout the remaining process steps. If the tiCDF result is lE-2, then the RRT is not attainable and thus a new design needs to be created. Note that the changes in CDF and LERF as used in Table 1 are not indicative of the actual CDF or LERF expected after installation of the l&C system. The static and relative changes of CDF and LERF are used only for the purpose of providing a mechanism for risk-informing decisions about the HSSSR Dl&C design.

Table 1:Establish RRT Based on tiCDF and tiLERF RRT dCDF dLERF Change the Design tiCDF > lE-3 tiLERF > lE-4 A

lE-4 $ tiCDF $ lE-3 lE-5 $ tiLERF $ lE-4 B

lE-5 $ tiCDF $ lE-4 lE-6 $ tiLERF $ lE-5

./

C lE-6 $ tiCDF $ lE-5 lE-7 $ tiLERF $ lE-6 D

tiCDF $ lE-6 tiLERF $ lE-7 4.2.2 Identify Stakeholder Losses and System Hazards In accordance with STPA, Stakeholder Losses should be identified at a high level of abstraction, so they are relatively simple and bounding. Stakeholder Losses typically should not reference individual components or specific causes and may involve aspects of the environment that are not directly controlled by the system designer.

A Stakeholder Loss is related to one or more System Hazard. System Hazard identification in STPA identifies conditions that are inherently unsafe-regardless of the cause. Systems Hazards should be specified at a high-enough level that does not distinguish between causes related to technical failures, design errors, flawed requirements, or human procedures and interactions. The STPA Handbook identifies three basic criteria for defining System Hazards:

1. Hazards are states or condit ions (not component-level causes or environmental states).

2. Hazards will lead to a loss in some worst-case environment.

3. Hazards must describe states or conditions to be prevented.

As the system design matures in detail, new hazards may be uncovered and the list of hazardous system states can be revisited and revised, as needed. Once Hazards are created, a control structure is developed to model the HSSSR system. A hierarchical control structure is composed of control loops consisting of process models, feedback signals, command signals, sensors, control algorithms, controllers, and human operators. A controller may provide control actions to control some process and to enforce constraints on the behavior of the controlled process. The control algorithm represents the

nei.org 12 NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 controller's decision-making process-it determines the control actions to provide. Controllers also have process models that represent the controller's internal beliefs used to make decisions. Process models may include beliefs about the process being controlled or other relevant aspects of the system or the environment. Process models may be updated in part by feedback used to observe the controlled process.

4.2.3 M odel the Control Structure Hierarchy A control structure w ill emphasize functional relationships and functional interactions, w hich is very useful for identifying problems like design flaws, requirement flaws, human errors, software errors, and even traditional physical component failures. A control structure model does not typically capture purely physical relationships like physical proximity between components or fire propagation. The physical processes being controlled are typically specified at the lowest level of the control structure while every level above specifies functional controllers that make decisions and directly or indirectly control the physical processes.

The control structure should identify Controllers (which have programmed control algorithms and process models) and the Controlled Process(es). The interactions between the Controller and Controlled Process(es) are feedback (e.g., process variables indicating the stat us of the controlled process) and control actions (e.g., commands from the Controller to the Controlled Process element).

Controller Control Process Algorithm Model l

Control Acti ons Fee dback

'./

Controlled Process Figure 1: Generic Control Structure Hierarchy The Control Structure Hierarchy provides a graphical representation of the system and its relationships for further analysis. As the design matures through the iterative DEG process, the Control Structure Hierarchy also matures in detail allowing for more granular insights. A controller can be a human or technology, in which case the Process Model and Control Algorithm are as follows:

Table 2: Types of Controllers and Their Attributes Controller Human Technology Process Model Knowledge and beliefs of the Programmer's knowledge Controlled Process and beliefs of the Controlled Process

nei.org 13 NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 Control Algorithm Procedures Internal Programming As the design matures, the Control Structure Hierarchy will also mature to represent the same level of detail. During the initial design phase, one Controller may be representative of the entire system (e.g.,

Reactor Protection System) and one Controlled Process may be representative of all equipment under control. As the design matures, the Control Structure Hierarchy will represent the actual controllers (including operators), their allocated Feedback and Control Actions, the sensors providing the feedback, and end-devices (e.g., actuators) that execute the Control Actions.

4.2.4 Identify Unsafe Control Actions Each Control Action identified during the control structure hierarchy modelling will be the basis for establishing UCAs. EPRI HAZCADS states that there are four types of UCAs:

1. Control action not provided when conditions require it.

2. Control action provided when conditions do not require it.

3. Control action provided too early, provided too late, or provided in the wrong order.

4. Control action stopped too soon or provided too long.

An important attribute in determining a UCA is the timing requirements associated with a given control action. Realistic times should be considered in lieu of overly conservative estimates for improbable licensing basis events. For example, a realistic break opening time should be used to determine the necessary response time to a Large Break Loss of Coolant Accident in lieu of an assumed double-ended guillotine break). These timing estimates are considered in the development of UCAs as well as performance of the risk sensitivity analysis.

Each UCA should have a consistent structure composed of the Controller, UCA type (see previous list),

Control Action, and context. The Controller and Control Action should be consistent with the Control Structure Hierarchy. The context provides the condition[s] in w hich the Control Action is unsafe. EPRI HAZCADS notes that UCAs should be developed by a cross-disciplined team of people know ledgeable in design, safety, operations, maintenance and PRA.

Each UCA should inherit the most conservative RRT of the System Hazards it is associated with. If RRT Pathway 5 is used then each UCA will be analyzed and assigned a unique RRT.

4.2.5 Allocate RRT Scores After completion of the previous steps, practitioners w ill have identified Stakeholder Losses, System Hazards, a Control Structure Hierarchy, UCAs and RRTs. The final step is to associate the RRTs with each system element.

1. Compare the control structure hierarchy to the l&C system architecture design.

2. Map the control actions in the control structure hierarchy to the system elements in the l&C system architecture design.

nei.org 14 NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024

3. Assess each control action for dependencies.

4. Map the highest UCA RRT score for each control action to the system elements associated with the control action (including their dependencies).

4.3 EPRI DRAM Overview 4.3.1 Initiation 4.3.2 Identify Control Effectiveness Profile 4.3.3 Develop Loss Scenarios 4.3.3.1 Inadequate Controller Behavior 4.3.3.2 Inadequate Control Algorithm 4.3.3.3 Inadequate Feedback or Information 4.3.3.4 Inadequate Control Pathway 4.3.3.5 Inadequate Process Behavior 4.3.4 Mitigate Loss Scenarios 4.3.4.1 Identify Control Methods 4.3.4.2 Score and Allocate Control Methods 4.4 Process Clarifications for US Regulatory Compliance EPRI HAZCADS and DRAM were not developed specifically for U.S. regulatory compliance. Instead, these processes were developed based on best practices from safety critical industries, international standards, and other bodies of knowledge. The following sections provide clarifications specific to compliance with U.S. NRC regulation, policy, and/or guidance.

4.4.1 EPRI HAZCADS Clarifications The following are clarifications to the EPRI HAZCADS that shall be considered by the applicant to adequately address vulnerabilities of CCF.

1.

nei.org 15 NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 4.4.2 EPRI DRAM Clarifications 4.4.3 Design Iteration EPRI HAZCADS is intended to be implemented in each phase of the design process. Each step of this process should be performed in each phase of the design process. As the design progresses, the detail in the Control Structure Hierarchy should become more granular demonstrating l&C fundamental design principles such as independence, redundancy, etc. that influence the hazards analysis and downstream processes (e.g., EPRI DRAM).

The results of the analysis at the conceptual design phase should provide sufficient information for a licensing application to address potential vulnerabilities to CCF. Practitioners should continue to implement EPRI HAZCADS and DRAM as defined within the EPRI DEG as a diagnostic tool and inform design decisions. As the design matures, if the results of the hazards and reliability analysis alter the results of the licensing application, the applicant should inform the NRC and submit supplemental information describing the change in accordance with the licensing process (e.g., Dl&C-ISG-06 for License Amendment Request).

5 SAFETY CASE DEVELOPMENT The safety case structure provided in this section was informed by ISO/ I EC/ IEEE 15026-2:2022. The safety case starts with a top-level claim for the system and uses a structured argument and evidence to support the claim. Through multiple levels of subordinate claims (sub-claims), the structured argument connects the top-level claim to the evidence.

The safety case is constructed by connecting key elements, which include:

Claims which are assertions about a property of the system. Claims that are asserted as true without justification become assumptions and claims supporting the argument are called sub-claims.

Arguments which link the evidence to the claim, which can be deterministic, probabilistic or qualitative.

nei.org 16 NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 Evidence which supplies the basis for the justification of the claim. Some sources of evidence may include the design, the development process, testing, and inspections.

A simplified diagram of an assurance case is shown in Figure 1.

supports Argument support upports Sub-Claim 1 Sub-Claim 2 support~

supports I

I Argument Argument T

T is evidence forl

~

is evidence fo~

I

/

I Evidence Evidence Figure 2: Safety Case Simplified Diagram The results of the analysis performed should be described and summarized to provide arguments supporting the sub-claims, in conjunction, supporting a top claim. Each argument should be supported by analytical results. These detailed analytical results should be referenced and available for regulatory audit/ inspection.

IAEA NP-T-3.27 provides an international perspective regarding establishing the dependability for safety-related Dl&C systems. This approach is not intended to directly comply with this IAEA technical report; however, the concepts described in the general approach provide context for applicants establishing dependability. The technical report describes an approach that is "property based, vulnerability aware and standards informed."

A property based approach focuses directly on the behavior of, and constraints on, the system or software being assessed.

These attributes are described in typical design documents accompanying a new system design or plant modification. The EPRI DEG provides the design process associated with these properties to determine system requirements, interfaces with other plant SSCs, and testing requirements have been met.

Vulnerabilities are weaknesses in a system that could be detrimental to dependability (e.g., if division by zero is not caught by error handling) but are not strictly faults.

nei.org 17 NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 EPRI HAZCADS and DRAM provide the processes required to identify and address vulnerabilities to the system.

Compliance with standards is an important part of the dependability assessment and[... ]

adequate compliance with standards will need to be demonstrated as part of the overall licensing or approvals process.

Licensing processes associated with new reactor licensing or plant modifications already require compliance with appropriate licensing basis standards.

5.1 Safety Case Structure

nei.org 18 NEI CONFIDENTIAL INFORMATION - M EMBER USE ONLY-DO NOT DISTRIBUTE.

nei.org 19 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

nei.org 20 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 5.1.1 Safety Case Description SRM-SECY-22-0076, Point 1 states:

The applicant must assess the defense in depth and diversity of the facility incorporating the proposed digital l&C system to demonstrate that vulnerabilities to digital CCFs have been adequately identified and addressed.

The technical process described in EPRI HAZCADS and DRAM produces a defense-in-depth and diversity analysis that demonstrates vulnerabilities to digital CCF have been adequately identified and addressed.

5.1.2 Safety Case Uncertainty 5.2 Tier 1 Claim, Argument and Sub-Claims 5.2.1 Tier 1 Top Claim

NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

nei.org 21

July 2024 5.2.2 Tier 1 Argument and Sub-Claims

nei.org 22 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 5.3 Tier 2 Arguments, Evidence and Sub-Claims 5.3.1 Tier 2, Argument 1: EPRI HAZCADS and DRAM Efficacy

nei.org 23 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

5.3.1.1 Supporting Evidence: EPRI Research 5.3.1.2 Supporting Evidence: NRC Research 5.3.1.3 Supporting Evidence: STPA Use in Other Safety Critical Industries 5.3.1.4 Supporting Evidence: Systematic Control Method Scoring 5.3.1.5 Supporting Evidence: Risk Informed Principles SRM-SECY-22-0076 Point 2 states:

NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 nei.org 24

July 2024 When using a risk-informed approach, the applicant must include an evaluation of the approach against the Commission's policy and guidance, including any applicable regulations, for risk-informed decision making. The NRC staff will review applications that use risk-informed approaches for consistency with established NRC policy and guidance on risk-informed decision-making (e.g., Regulatory Guide {RG) 1.174, "An Approach for Using Probabilistic Risk Assessment in Risk-Informed Decisions on Plant-Specific Changes to the Licensing Basis," RG 1.233, "Guidance for a Technology-inclusive, Risk-informed, and Performance-based Methodology to Inform the Licensing Basis and Content of Applications for Licenses, Certifications, and Approvals for Non-Light-Water Reactors)." [emphasis added]

NRC Regulatory Guide (RG) 1.174 provides guidance for operating reactors using risk information for licensing basis changes. RG 1.233 provides guidance for new reactor applicants to establish licensing basis events, System, Structure and Component (SSC) classification, and defense-in-depth adequacy using risk information. When using NEI 20-07, the appropriate Regulatory Guide should be used to provide guidance for risk-informed applications. The following discussions provide information addressing key concepts in both documents.

RG 1.174 identifies a set of key principles to be addressed in risk-informed decision making (RIDM) for licensing basis changes. The five principles for risk-informed decision making are:

Principle 1: The proposed licensing basis change meets the current regulations unless it is explicitly related to a requested exemption (i.e., a specific exemption under 10 CFR 50.12).

Principle 2: The proposed licensing basis change is consistent with the defense-in-depth philosophy.

Principle 3: The proposed licensing basis change maintains sufficient safety margins.

Principle 4: When proposed licensing basis changes result in an increase in risk, the increases should be small and consistent with the intent of the Commission's policy statement on safety goals for the operations of nuclear power plants.

Principle 5: The impact of the proposed licensing basis change should be monitored using performance measurement strategies.

The licensing and design processes of a HSSSR Dl&C system should ensure that the Dl&C system meets applicable regulations, be consistent with the defense-in-depth philosophy of the plant, maintain margins, manage risk such that it is acceptable, and continue to monitor performance. Principles 1, 2 and 3 are met through existing analysis required in licensing processes. Principles 4 and 5 are specific to the use of risk information and require supplemental information to be considered.

The objective of the NEI 20-07 methodology is to identify hazards, unsafe control actions, and Loss Scenarios to address vulnerabilities to CCF as part of a systems-oriented, integrated Dl&C evaluation. By utilizing this methodology, the failures in design and operations can be identified by modeling the potential interactions between software errors, human errors, component failures, and component interaction. By integrating hazard identification and PRA sensitivity analysis, RRTs can be derived in terms of order of magnitude of risk reduction that must be addressed with appropriate Control Methods in the design process and concept of operations; and still meet the five guiding principles. This process

nei.org 25 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 provides guidance for protection against Dl&C CCFs through the identification of Loss Scenarios and Control Methods that reduce the identified risks, providing a defense-in-depth assessment basis. In other words, many of the defense-in-depth elements in terms of elimination and mitigation to different points in a potential Loss Scenario involving nuclear safety impacts are included.

The licensee implementing this process can demonstrate alignment with the five principles for risk-informed decision-making process in RG 1.174 using these concepts.

Principle 1 Considerations: Existing licensing processes for new plants and operating plant modifications address requirements for ensuring current regulations are met unless an exemption is requested. No additional guidance is necessary.

Principle 2 Considerations: Existing licensing processes for new plants and operating plant modifications address demonstration of the defense-in-depth philosophy. This approach provides evidence to support a safety claim that adequate defense-in-depth exists. No addit ional guidance is necessary.

Principle 3 Considerations: Existing licensing processes for new plants and operating plant modifications address requirements for maintaining sufficient safety margins. No additional guidance is necessary.

Principle 4 Considerations: Due to lack of consensus in quantifying software reliability, quantifying an absolute value of the proposed modification to plant risk is not considered in this approach. EPRI HAZCADS and DRAM does not provide a quantitative approach; rather, it describes a conservative, bounding risk analysis as allowed in RG 1.174 Section 2.2 which states:

In other applications, calculated risk-importance measures or bounding risk calculations may be adequate.

The results of the risk sensitivity analysis are used to apply a graded approach to applying Control Methods to the proposed design iteratively throughout the design process. As previously described, the results derived from EPRI HAZCADS and DRAM do not represent an absolute value of the impact of the proposed modification on plant risk. Rather, the results inform the graded approach to allocating systematic Control Methods.

For large LWR, the graded approach is consistent with the acceptance guidelines for changes to Core Damage Frequency and Large Early Release Frequency described in RG 1.174 Section 2.4.

Aspects of the proposed modification that result in changes to CDF or LERF that map to Region 1 in RG 1.174 Figures 4 and 5 apply the most rigorous approach; whereas those that map to Region 3 apply the least rigor while maintaining the design basis commitments and consistency with the facility's defense-in-depth philosophy and safety margins.

For other reactor technologies, approved risk metrics should be established to use risk-informed approaches. Additionally, "regions" similar to RG 1.174 Figures 4 and 5 should be established to be consistent with the graded approach described within this document.

To use this method, certain PRA model attributes need to be met. These are:

nei.org 26 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024

1. The PRA models the as-built, as-operated and maintained HSSSR system being replaced and reflects the operating experience. New plants without as-built PRA models will utilize up-to-date PRA models that reflect the current design status of the plant.

2.

Key assumptions and sources of uncertainty in the PRA models that can impact the assessment are addressed by assuming everything in the HSSSR system fails. By assuming the CCF occurs, uncertainty associated with the HSSSR Dl&C system is a negligible factor since this process provides a bounding assessment of the failure of the HSSSR Dl&C system. Because this process requires the use of a high-fidelity PRA model, other sources of uncertainty (e.g., parameter uncertainty) are unaffected by the sensitivity analysis performed by this process.

Additionally, RG 1.174 Section 2.6 states:

In making a regulatory decision, risk insights (including their associated uncertainties) are integrated with considerations of defense in depth and safety margins. The degree to which the risk insights (and their uncertainties) play a role[... ] depends on the application. [... ]

Traditional engineering analysis provides insight into available margins and defense in depth. With few exceptions, these assessments are performed without any quantification of risk. However, a PRA can provide insights into the strengths and weaknesses of the plant design and operation relative to defense in depth.

The process described in EPRI HAZCADS and DRAM combines risk insights from the PRA sensitivity study with a hazards analysis performed by a multidisciplinary team to identify the potential vulnerabilities to CCF, their impact on the plant, and identify effective measures to address risk-significant vulnerabilit ies. This process provides the system designers with greater insights to potential sources of failure and provides insights to the most risk-significant CCF vulnerabilities that need to be addressed. Control Methods applied to address these CCF vulnerabilities are qualitatively scored by a mult idisciplinary team and applied in a graded approach.

Principle 5 Considerations: RG 1.174 Section 3 states:

The licensee should propose monitoring programs that adequately track the performance of equipment that, when degraded, can affect the conclusions of the licensee's engineering evaluation and integrated decision-making that support the change to the licensing basis. The program should be capable of trending equipment performance after a change has been implemented to demonstrate that performance is consistent with the assumptions in the traditional engineering and probabilistic analyses conducted to justify the change. [... ] The program should be structured such that (1) SSCs are monitored commensurate with their safety importance (i.e., monitoring for SSCs categorized as having low safety significance may be less rigorous than that for SSCs of high safety significance), (2) feedback of information and corrective actions is timely, and (3) degradation in SSC performance is detected and corrected before plant safety can be compromised. The potential impact of observed SSC degradation on similar components in different systems throughout the plant should be considered.

nei.org 27 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 EPRI DRAM describes the application of Control Methods that are applied to address identified potential CCF vulnerabilities. Control Methods are scored for their ability to Protect, Detect, and Respond & Recover. These three elements are considered for each Loss Scenario identified. The Protect function is intended to prevent a Loss Scenario from occurring and may include monitoring programs to detect adverse trends. The Detect function is intended to monitor system performance, identify a degraded system condition, and notify plant personnel prior to an adverse plant event from occurring. The Respond & Recover function is intended to provide a means of response after a loss occurs. The combination of these three functions ensures the Control Methods that have been applied to any given Loss Scenario provide appropriate rigor to ensure SSCs perform their intended functions OR the degraded condition is identified, and the plant remains in a safe state.

The practitioner should ensure system health monitoring and preventative maintenance activities address ongoing reliability indicators for the Dl&C system. These activities can be credited for tracking and trending the Dl&C system performance.

The process does not rely on the reliability of the Dl&C system to be modeled in the PRA to address CCF; therefore, ongoing monitoring activities associated with ensuring the as-built PRA model is consistent with the results of this process are not necessary. Subsequent changes to the plant and PRA model after the implementation of the HSSSR Dl&C system should consider the impacts of the change on the results of this process.

RG 1.233 "contains the NRC staff's general guidance on using the methodology described in NEI 18-04 to select [Licensing Basis Events), classify SSCs, assess the adequacy of a design in terms of providing layers of DID, identify appropriate programmatic controls, and help determine the appropriate scope and level of detail for information provided in applications for licenses, permits, certifications, and approvals for advanced non-LWR designs." EPRI HAZCADS and DRAM do not provide quantitative reliability data for Dl&C systems. RG 1.233 provides the scope of functions under control and reliability targets for a safety-related Dl&C system via the Licensing Basis Event selection and SSC classification (including defense-in-depth functions). These criteria are inputs to the initial/conceptual design phase. EPRI HAZCADS and DRAM can be used as a diagnostic tool based on the early design and continues through detailed design to provide insights used to identify and inform special treatments to address postulated CCFs.

5.3.2 Tier 2, Argument 2: Postulated CCF Identification/Analysis

nei.org 28 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024

nei.org 29 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

5.3.3 Tier 2, Argument 3: Addressing Postulated CCF 5.4 Tier 3 Arguments and Evidence I

5.4.1 Resolution of Tier 2, Sub-Claim 1

NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 nei.org 30

July 2024 5.4.2 Resolution of Tier 2, Sub-Claim 2

nei.org 31 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 5.4.3 Resolution of Tier 2, Sub-Claim 3 5.4.4 Resolution of Tier 2, Sub-Claim 4

nei.org 32 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

July 2024 6

CONCLUSION Using Dl&C system design information provided from EPRI DEG output documents, the EPRI HAZCADS process is effective at identifying Stakeholder Losses, System Hazards, UCAs that can lead to a postulated CCF, and RRTs to assess CCF risk significance. UCAs that are present in mult iple redundancies of a Dl&C system and impact nuclear safety factors appropriate for the reactor technology are considered CCFs. EPRI DRAM uses the EPRI HAZCADS results to identify Systematic Loss Scenarios that may lead to each CCF. Using the RRT and Systematic Loss Scenarios, Control Methods are applied to each causal factor (i.e., Loss Scenario) commensurate with the risk significance identified.

The safety case provided w ithin this document presents a clear, logical approach for the applicant to demonstrate that vulnerabilit ies to CCF have been adequately addressed in HSSSR Dl&C systems for both operating and new reactors. The safety case provides the claims, arguments, and evidence necessary to demonstrate alignment with the Commission direction in SRM-SECY-22-0076.

7 REFERENCES

nei.org 33 NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

APPENDIX A. SAMPLE TEMPLATE This Appendix describes a sample template for a submittal using NEI 20-07. The submittal could be in support of a new reactor application using any licensing framework (10 CFR 50, 10 CFR 52, etc.) or license amendment request.

NEI CONFIDENTIAL INFORMATION - MEMBER USE ONLY-DO NOT DISTRIBUTE.

nei.org A-1

v t e Letter Sequence '
EPID:L-2023-NFN-0012, (Open)
Initiation Request Acceptance... Administration Questions Answers Results Approval... Other:
MONTHYEAR2024-11-04 [Table View]

ML24211A227

Text

Navigation menu

Search