ML21089A062

NEI Responses to Initial NRC Comments on Draft NEI 20-07 Draft B - for Discussion with NRC_032621

ML21089A062
Person / Time
Site:	Nuclear Energy Institute
Issue date:	03/26/2021
From:	Nuclear Energy Institute
To:	Office of Nuclear Reactor Regulation
Govan T
References
NEI 20-07
Download: ML21089A062 (21)

Text

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 1

Reference #1 NRC Comment NEI Response Resolution 1

Assessing CCF Vulnerabilities a

Does the methodology described in draft NEI 20-07 require an assessment of potential common cause failure (CCF) vulnerabilities in a proposed system, prior to implementation of this methodology?

The CCF vulnerability assessment would be performed as part of, rather than prior to, applying the guidance in NEI 20-07. Results of the CCF vulnerability assessment would be provided in the Assurance Case.

For example, SDO 10.1.3.2 requires use of a hazard analysis method to identify hazardous control actions that can lead to an accident or loss. SCCF would be a primary focus of the hazard analysis. Application software requirements and constraints will be derived from the identified hazardous control actions.

It is possible that, as part of the standard digital design process, a CCF hazard analysis/CCF vulnerability assessment would have already been developed prior to implementation of NEI 20-07. If this is the case, then the results of the prior hazard analysis/CCF vulnerability assessment (if it meets the requirements of NEI 20-07) could be used and presented in the Assurance Case.

b How does the prescribed methodology in draft NEI 20-07 protect against potential CCF vulnerabilities in a generic sense, when different systems may have unique characteristics such as The SDOs are independent of any platform technology and application software.

The hazard analysis SDO, for example, performed for each system would consider integration of different systems from an application software perspective. Software development for each system would be 1 1/25/21 NRC Letter providing the summary of the Public Meeting held on 1/12/21 to discuss NEI 20-07, Draft B (ML21025A392)

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 2

Reference #1 NRC Comment NEI Response Resolution different platforms, application software, architectures, etc.?

assessed separately following the guidance in NEI 20-07 using the information collected in the hazard analysis.

NEI 20-07 focusses on addressing CCFs resulting from design defects in the internal platform software/hardware and application software.

The SDOs address the level of quality needed to reach the conclusion that CCFs resulting from design defects in the platform and application software need not be further considered or postulated.

NEI 20-07 does not address external system architecture - only platform hardware/software and application software. Some aspects of the system architecture will be addressed by ensuring the platform is installed using the Safety Manual requirements (part of the SIL3/SC3 certification). However, it is not the intent of NEI 20-07 to address all CCFs resulting from other aspects of the system architecture (e.g., date communications).

2 Executive Summary Comment -

Alignment with Related Guidance a

Draft NEI 20-07 appears to leverage a frequency argument to resolve CCF considerations in a similar manner to RIS 2002-22, Supplement 1, but for HSSSR systems. RIS 2002-22, Supplement 1, allows for frequency NEI 20-07 is not intended to be related to, consistent with, or parallel with RIS 2002-22 Supplement 1.

One risk-informed aspect to NEI 20-07 is the way an HSSSR system is determined. BTP 7-19

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 3

Reference #1 NRC Comment NEI Response Resolution (i.e. likelihood) arguments because it is focused on lower safety significant systems whose failure consequences of CCF is well understood and acceptable.

Its not clear how the approach in draft NEI 20-07 is consistent with RIS 2002-22, Supplement 1 or BTP 7-19, Revision 8, SRM to SECY 93-087 as well as SECY 18-0090 with regard to using a frequency argument to remove CCF from further consideration, but for an HSSSR system.

allows for site-specific PRA, if available, to support the determination of a HSSSR system.

NEI 20-07 is expected to be used for the highest safety-significant safety-related SSCs - the consequences of failure are therefore very high. NEI 20-07 adopts a level of quality to reach the conclusion that CCFs resulting from a design defect in the internal platform software/hardware or application software need not be further considered or postulated.

Similar to what has been achieved for hardware (e.g., HW Equipment Qualification), NEIs intent is that there is an achievable level of software quality over and beyond what is currently required to meet the NRC endorsed IEEE software standards. The SDOs provided in NEI 20-07 were selected to achieve this next level of software quality.

Thus, NEI 20-07 is not based on failure likelihood or acceptable consequences. NEI 20-07 will be modified to remove the language that implies frequency of occurrence.

b Is it NEIs position that any CCF of a HSSSR has severe consequences and that the approach in NEI 20-07 is attempting to justify the safety system design through a very low likelihood of occurrence of software CCF?

NEIs position is that, by definition, the consequences of failure of a HSSSR SSC is high.

NEI 20-07 provides guidance on platform selection and application software development where software quality is the focus.

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 4

Reference #1 NRC Comment NEI Response Resolution Similar to HW qualification, NEIs position is that it is possible to develop software with such high quality that a CCF resulting from an application software design defect or internal platform software/hardware design defect no longer needs to be postulated.

Note that CCFs resulting from the system architecture will still need to be addressed (i.e.,

CCF resulting from other sources in the system architecture other than application software or platform hardware/software).

3 Executive Summary Comment -

Current Processes versus NEI 20-07 a

Is it NEIs position that existing, endorsed IEEE standards (e.g. IEEE Std. 1012, IEEE Std. 7-4.3.2) have a potential gap that the methodology of NEI 20-07 is addressing? This statement seems to presume that SDO concept are unique to IEC 61508.

The existing gap is between the level of software quality required to postulate the effects of a CCF as a beyond design basis (BDB) event (i.e., software quality level achievable using existing endorsed standards), vs. the level of quality required to conclude a CCF is adequately addressed and does not need to be postulated (i.e., additional level of software quality provided by NEI 20-07).

Note that if a licensee is committed to specific IEEE standards for software development, then that licensee would be expected to use these IEEE standards in addition to NEI 20-07.

NEI 20-07 is not intended to replace the IEEE standards - NEI 20-07 is intended to provide

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 5

Reference #1 NRC Comment NEI Response Resolution guidance that results in raising the level of quality beyond that provided by the IEEE standards. NEI considers the SDO concept unique to IEC 61508.

b Is it NEIs position that the methodology described in NEI 20-07, when used in conjunction with the currently endorsed standards, can provide a lower likelihood of software CCF in HSSSRs than current processes alone?

The present regulatory infrastructure for HSSSR systems acknowledges that it is possible to identify a potential CCF vulnerability due to a latent defect has such a low likelihood of occurrence that it may be treated as beyond design basis, and therefore its consequences may be evaluated using best-estimate methods. The use of best-estimate methods was intended to be less burdensome for licensees and applicants than typical reactor safety thermal hydraulic analysis methods. The consequences of very low likelihood of occurrence of CCFs due to latent defects still need to be Yes. NEI 20-07 is expected to be used in conjunction with the currently endorsed software development standards. As stated in the response to Question 2a, NEIs position is that there is a level of software quality over and beyond what is currently required to meet the NRC endorsed IEEE software standards.

The SDOs provided in NEI 20-07 were selected to achieve this next level of software quality.

The goal of NEI 20-07 is to provide guidance on platform selection and application software development with such high quality that a licensee no longer needs to consider the internal platform software/hardware or application software or as a source of CCF.

Comparable to applying the testing criteria in BTP 7-19 to eliminate software as a source of CCF, the SDOs provide a set of criteria that can be applied to eliminate consideration of SCCFs resulting from internal platform software/hardware and application software design defects in the D3 analysis.

There may be other sources of CCF that need to be evaluated as part of the overall system architecture other than the platform

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 6

Reference #1 NRC Comment NEI Response Resolution evaluated to demonstrate reactor safety objectives and regulatory dose acceptance criteria limits are being met. As currently written, NEI 20-07 seems to suggest otherwise.

hardware/software and application software.

NEI 20-07 only addresses CCFs resulting from design defects in the application software and internal platform software/hardware. External system architecture considerations such as channel interconnections, network communications etc. are not addressed in NEI 20-07. NEI recognizes that all potential sources of CCF must be considered as part of the overall system design and integration.

4 Executive Summary Comment - EPRI Research a

EPRI research appears heavily leveraged in this document. The staff would need to understand more details on this research and its applicability and technical assumptions as it pertains to addressing CCF in nuclear applications, types of devices/components considered, software applications, etc., and how theyre organized/configured. This is to ensure we have relevant comparison of data. For example, with regard to 1.6 billion operating hours, how much of that data is valid with respects to the components, systems, operating system platforms, etc. that are NEI 20-07 is heavily leveraged on research conducted by EPRI on the efficacy of SIL certification for nuclear power [EPRI Technical Report 3002011817, dated July 2019]. Some in the NRC staff have reviewed this EPRI report as it was used in the development of NEI 17-06, Guidance on Using IEC 61508 SIL Certification to Support the Acceptance of Commercial Grade Digital Equipment for Nuclear Safety Related Applications, which is currently under NRC review for endorsement. Some in the NRC staff also conducted an audit of the SIL certification process as part of development of NEI 17-06 and are familiar with the application and requirements of IEC 61508.

Regarding the 1.6 billion operating hours in the EPRI research, all the EPRI harvested data is valid with respect to components, systems,

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 7

Reference #1 NRC Comment NEI Response Resolution currently in use?

operating systems, platforms, etc. that are currently in use. The research evaluated the systematic process for programmable logic solvers (i.e., IEC 61508 based SIL certification),

and evaluated the predictive reliability of that process to the actual failure rate data. The conclusion was that the systematic process can predict accurately the failure rate of the logic solver.

5 Executive Summary Comment - IEC 61508 a

Is it NEIs position that implementation of IEC 61508 in an adequate manner is sufficient to render SWCCF not credible (sufficiently low for platforms, not applications)? What about the application software?

Yes, it is NEIs position that IEC 61508 provides the level of SDOs for both platform and application software to eliminate their consideration as a source of CCF.

The guidance in NEI 20-07 is intended to be used in the selection of platform software/hardware and for the development of high-quality application software such that SCCF due to a software design defect no longer needs to be considered or postulated.

As previously stated, NEI 20-07 only addresses SCCF resulting design defects in the internal platform software/hardware and application software. CCFs resulting from the system architecture other than the platform hardware/software and application software still need to be addressed. In other words, simply meeting the requirements of NEI 20-07

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 8

Reference #1 NRC Comment NEI Response Resolution does not ensure that the entire integrated system is immune from all potential sources of CCFs.

B Standards are generally written to be followed in totality to achieve the stated goals within. In the context of NEI 20-07, is IEC 61508 being utilized in its entirety or are only certain portions of IEC 61508 being utilized? If only partially, what is that scope?

Per the guidance in NEI 20-07, platforms are required to meet SIL3/SC3 requirements as specified in IEC 61508. Thus, for platforms, IEC 61508 is being used in its entirety.

The guidance in IEC 61508 was strategically synthesized to harvest only the necessary elements needed to develop high-quality application software.

c The methodology in NEI 20-07 appears to be a process that uses aspects of IEC 61508 without necessarily requiring the platform/application software to be compliant with IEC 61508. Is that the approach being taken by NEI 20-07?

(Note: IEC 61508 is not a nuclear standard but an industrial standard. IEC 61513 is a nuclear though and its not clear why this standard was not used).

To comply with the guidance in NEI 20-07, platforms would need to meet the requirements of SIL3/SC3 as specified in IEC 61508. Thus, internal platform hardware and software are required to be compliant with IEC 61508.

As described in the response to Question 5B, the SDOs for developing application software were strategically synthesized from IEC 61508.

Only portions of the guidance applicable to application software were taken from IEC 61508-3.

EPRI research focused on platforms developed using IEC 61508. Results of their research indicate very high quality and reliability in platforms that used IEC 61058 for development

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 9

Reference #1 NRC Comment NEI Response Resolution in applications where safety is a paramount concern. NEI 20-07 builds on the EPRI research.

IEC 61513 was not considered when developing NEI 20-07. IEC 61513 is a system level standard whereas IEC 61508 is focused on single failures that can be consequential.

6 Executive Summary Comment -

Applicability to 10 CFR 50.59 a

Is it the intention of this document to provide methodologies that are consistent with the guidance of RIS 2002-22 Supplement 1 and its definition of sufficiently low and requirements under 10 CFR 50.59?

NEI 20-07 is not intended to be related to, consistent with, or parallel with RIS 2002-22 Supplement 1 nor is NEI 20-07 intended to be used for SSCs implemented under 50.59. The reason for mentioning 50.59 was to indicate that, if desired, a licensee could use the guidance in NEI 20-07 for projects implemented under 50.59 - although it is not recommended.

For clarity, NEI plans remove any reference to 50.59 in NEI 20-07.

b How does NEI envision this document being used under 10 CFR 50.59?

NEI does not envision NEI 20-07 being used for projects implemented under 50.59. NEI 20-07 is intended to be used on HSSSR SSCs that would typically require a LAR to implement. NEI intends to remove any reference to 50.59 in NEI 20-07.

c Is this document consistent with NEI 96-07, Appendix D? Does the document identify residual gaps between it and technical guidance NEI 20-07 will be used for activities that will require a LAR to implement. The Assurance Case referred to in NEI 20-07 would be part of the LAR package.

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 10 Reference #1 NRC Comment NEI Response Resolution that complements NEI 96-07, Appendix D?

The initial draft of NEI 20-07 mentioned 50.59 in case a licensee desired to use the guidance in a lesser safety-significant SSC. However, NEI realizes that most, if not all, licensees will continue to use the RIS Supplement on lesser safety-significant projects. As such, NEI intends to remove mention of 50.59 in NEI 20-07.

7 Introduction Section Comment -

Software Development Process a

NRC staff already requires rigorous software development process (e.g.

BTP 7-14) and has previously determined that a high-quality software development process is sufficient to consider software CCF a beyond design basis event, but not necessarily sufficient to eliminate the potential for CCF. NEI should describe how the methodology in NEI 20-07 is sufficiently different than current processes such that potential software CCF consideration can be eliminated.

The guidance provided in NEI 20-07 is based on a mature standard (IEC 61508) and years of EPRI research on quality platform and software development. Based on this research, NEI feels strongly that application of the guidance provided in NEI 20-07 will result in selection of the highest quality platform and development of the highest quality application software, beyond that which can be achieved using existing standards. As stated above, NEI 20-07 is intended to be used in addition to the existing NRC endorsed standards on software development. There is overlap between the two sets, but there are also SDOs not covered by BTP 7-14, RGs and endorsed IEEE standards.

8 Background Section Comment -

Additional Analysis a

Is it NEIs position that there is no evaluation/analysis needed if this document is implemented?

It is NEIs position that if a licensee provides an Assurance Case that provides the arguments and evidence that the SDOs are met, there is no need to further consider or postulate SCCFs

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 11 Reference #1 NRC Comment NEI Response Resolution resulting from design defects in the internal platform software/hardware or application software. The Assurance Case would be provided as part of a LAR for the HSSSR system.

A licensee would still need to consider CCFs resulting from other aspects of the system architecture and plant integration.

B Is there any sort of evaluation/analysis this document points to that is performed to highlight potential CCF vulnerabilities?

Some analysis of the design (architecture) beyond the software seems implied by SDOs relating to 6.3s 1st principle. For example, 10.1.3.2 through 10.1.3.5. 10.1.3.2 identifies constraints derived from hazardous control actions, which may imply something that enforces the constraint that is not the application software itself. 10.1.3.4 identifies hardware constraints. 10.1.3.5 identifies constraints imposed by the I&C system design.

SDO 10.1.3.2 requires use of a hazard analysis method to identify hazardous control actions that can lead to an accident or loss. SCCF vulnerabilities are the primary focus of this hazard analysis.

The hazard analysis specified by SDO 10.1.3.2 is a global analysis considering all aspects of the system and architecture, including both hardware and software. Thus, the identified hazardous control actions will cover much more than application software. Some of the hazardous control actions identified will not apply to the application software while others will. This SDO requires that results of the hazard analysis be used to generate specific application software requirements and constraints as they apply to the system - both hardware and software.

SDO 10.1.3.4 requires identification of hardware constraints that need to be considered when developing the application software are documented and complete. For example, if a specific channel response time is

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 12 Reference #1 NRC Comment NEI Response Resolution identified as a system requirement, then the time required for the application software to process a given input signal would need to be considered in addition to the field instrumentation (hardware) response time.

This may place a constraint on the application software processing time due to the fixed hardware response time.

Overall system and performance requirements will typically be developed through two separate sources - basic system functional and performance requirements and requirements discovered when applying the hazard analysis process. SDO 10.1.3.5 ensures that, in addition to requirements discovered through application of the hazard analysis process, system performance requirements and constraints are also documented and applied, as applicable, when developing the application software.

9 Section 5 Comment - SRM to SECY 93-087 and Scope a

Its not clear how NEI 20-07 maps to SRM to SECY 93-087 and why SRM to SECY 93-087 is not referenced.

NEI 20-07 addresses Position 1 of SECY 93-087:

Identify CCF vulnerabilities in the systems.

NEI 20-07 is based on the position that internal platform software/hardware and application software can be selected/developed with such high quality that SCCF resulting from a design defect in the platform internal

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 13 Reference #1 NRC Comment NEI Response Resolution software/hardware or application software no longer needs to be considered or postulated.

There may be other CCFs that need to be postulated (e.g., due to various system architecture configurations), but SCCF due to a design defect in the application software or internal platform software/hardware would no longer need to be considered.

b BTP 7-19, Revision 8, includes sources of digital CCF to be both software and hardware, consistent with SRM to SECY 93-087. Is it NEIs position that NEI 20-07 provides adequate coverage with respect to the scope of CCF considerations in BTP 7-19, Revision 8?

BTP 7-19 provides an exclusion of software that meets the specified testing criteria. Similarly, NEI 20-07 is providing an exclusion for platforms and application software that meet the SDOs.

NEI 20-07 focuses only on internal platform software/hardware and application software development. A SIL 3/SC3 platform certification does address internal hardware of the platform. Additionally, SDO 9.2.3.1 states that when platform elements are integrated at the system level, subsystem level, or among other elements, they are integrated in accordance with the Safety Manual that complies with IEC 61508-2 Annex D or 61508-3 Annex D. The Safety Manual does address some elements of external architecture hardware.

10 Section 5 Comments - Gaps in Current Regulatory Processes a

Is the approach of this document to fill the gap that is perceived within It is NEIs position that the processes are complimentary and overlap but address

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 14 Reference #1 NRC Comment NEI Response Resolution current NRC processes (e.g. BTP 7-14) or is it attempting to be complimentary to current processes, or both? Industry has not formally communicated of such a gap to the NRC. Industry has previously expressed concerns with the level of effort with current NRC practices and NEI 20-07 would appear to add an additional layer of complexity to licensing and design work.

different objectives. The current set of NRC-endorsed software development standards allow crediting a CCF as a BDB event. Applying the SDOs provided in NEI 20-07 would allow an applicant to deterministically assess that CCF associated with design defects in the platform and application software has been adequately addressed and need not be further considered or postulated.

11 General Comments on Section 6, titled First Principles of Protection Against Software CCF a

The principles listed in this section have a description (with the subsection headers themselves acting as the principle itself) but do not appear to have guidance. Its not clear how a licensee or application can apply them without specified acceptance criteria or similar type of consideration.

First principles do not need acceptance criteria.

Rather, they provide a principle-based conceptual understanding of the phenomena.

It is the SDOs that provide the analysis guidance and acceptance criteria to meet the first principles. NEI 20-07 states, This approach begins by establishing a set of first principles for the protection against software CCF in digital instrumentation and control (DI&C) systems and then subsequently decomposing these first principles into safe design objectives (SDOs).

B Without specified acceptance criteria, its not clear how a licensee or applicant can adequately determine whether the stated goals of this document (i.e.

See earlier comments regarding the term sufficiently low. Documented adherence to the SDOs provided in NEI 20-07 offers evidence that the acceptance criteria for selection of a high-quality platform and development of high-

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 15 Reference #1 NRC Comment NEI Response Resolution sufficiently low finding with regard to software CCF) has been achieved.

quality application software at a level such that a CCF due to a design defects in the internal platform software/hardware and application software no longer needs to be considered or postulated has been met.

For example, the acceptance criteria for a platform not being a source of CCF is evidence that the platform meets the SIL3/SC3 requirements identified in SDO 9.1.3.1 and is integrated within the requirements of SDO 9.2.3.1. For application software, the acceptance criteria would be the documented evidence that all relevant application software SDOs were achieved.

NEI 20-07 requires development of an Assurance Case to detail how the various SDOs were met for both the platform and application software.

12 General Comments on Acceptance Criteria a

Does draft NEI 20-07 describe/provide general acceptance criteria for all portions of the methodology that are used to ultimately make a determination of sufficiently low with regard to the likelihood of software CCF?

See earlier comments regarding the term sufficiently low. NEI 20-07 is not intended to be related to, consistent with, or parallel with RIS 2002-22 Supplement 1.

To a degree, NEI 20-07 provides a deterministic approach for evaluating platform software/hardware and development of application software in that by applying the

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 16 Reference #1 NRC Comment NEI Response Resolution prescribed SDOs, a CCF due to a design defect in the internal platform software/hardware or application software does not need to be further considered or postulated.

NEI 20-07 will add the following statement:

Documentation that the acceptance criteria were met consists of documented evidence that relevant SDOs were addressed adequately. A licensee will build an Assurance Case as part of a LAR package to clearly detail how the SDOs were met.

B Does draft NEI 20-07 address relevant acceptance criteria in BTP 7-19, Revision 8, including Section 3.1.3?

Yes - If the SDOs in NEI 20-07 are applied, the design attributes/defensive measures that are used to meet those SDOs, will meet the acceptance criteria in BTP 7-19, Revision 8, Section 3.1.3.

13 Section 6 Comment Section 6 of the document states the following: The first principles listed in this section are considered bounding and complete and represent the starting point for decomposition of SDOs.

a Clarify what is the basis for stating that the first principles in Section 6 is both bounding and complete. On the surface, with regard to software development, there would appear to NEI agrees that bounding is not an applicable term in describing the scope of the first principles. It is accurate to state that the first principles are complete. NEIs position is that these first principles are complete. NEI

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 17 Reference #1 NRC Comment NEI Response Resolution be more considerations than whats currently listed.

welcomes NRC feedback regarding the first principles provided in NEI 20-07.

NEI will revise NEI 20-07 to remove bounding from the discussion on first principles.

b What is meant by the term bounding? Bounding with current regulations?

See response to Question 13a.

14 Section 6 Comment Section 6 of the document states the following: The first principles of protection against software CCF will be achieved by executing the SDOs.

a The principles listed in this section are generally understood to be identified/covered within existing IEEE standards the NRC staff has already endorsed and the subsections in Section 6 are silent in this respect. Is it NEIs position that existing, endorsed IEEE standards (e.g. IEEE Std. 1012, IEEE Std. 7-4.3.2) have potential gaps that the methodology of NEI 20-07 is addressing?

NEI is not taking the position that there are any identified gaps with IEEE standards. The IEEE standards have a different objective than NEI 20-07 as expressed in the response for 10a.

Rather, NEIs intent is that NEI 20-07 is a means to adequately address CCFs caused by latent design defects in the platform software/hardware and associated application software.

15 Section 9 Comment Section 9.1 of the document states the following, in part: Use of IEC 61508 as a source for developing SDOs to protect against software CCF

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 18 Reference #1 NRC Comment NEI Response Resolution a

Does NEI intend to include the relevant portions of IEC 61508 as part of this review or does NEI believe that NEI 20-07 has sufficient information contained therein to facilitate the staffs review?

NEIs intent is that NEI 20-07 has enough information to facilitate the staffs review and does not plan to submit any portions of IEC 61508 for review and endorsement by the NRC.

As stated in NEI 20-07, the SDOs are synthesized from the relevant guidance in IEC 61508 and other industry standards.

16 Software Quality Assurance Argument of NEI 20-07 (B.1 Figure)

RIS 2002-22 Supplement 1, describes the qualitative assessment concept where the aggregate of considerations of deterministic design features, software quality and operating experience can be used to make a sufficiently low determination. The RIS supplement is clear that operating experience alone cannot be used as a sole basis for a sufficiently low determination and isnt truly a substitute for the two other aspects.

NEI 20- 07 Section 6.4, 9.1.2 and other sections would appear to make the case that a focus on software quality and supplemental operating history (presumably of the exact same software package) alone are sufficient to demonstrate a sufficiently low likelihood of failure of an entire HSSSR system. This appears to be the case in NEI 20-07 is not intended to mirror the guidance in RIS 2002-22 Supplement 1. The next draft of NEI 20-07 will remove any connection to RIS 2002-22 Supplement 1.

NEI 20-07 does not rely solely on operating experience when assessing a platforms susceptibility to SCCF - the platform must meet the requirements of a SIL3/SC3 system set forth in IEC 61508.

Additionally, operating experience, when used in the context provided in NEI 20-07, only applies to internal platform software and hardware. The concept of platform operating experience is derived from EPRI research on SIL certified platforms. EPRI reviewed several platforms currently in operation and those that were SIL3 certified and in operation for approximately 1.6 billion operating hours had no evidence of experiencing a SCCF. This

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 19 Reference #1 NRC Comment NEI Response Resolution lieu of additional consideration of architectural design or deterministic design features (e.g. defensive measures) that can also demonstrate high reliability/dependability. This would not appear consistent with either the RIS supplement 1 or BTP 7-19, Revision 8, which both provide for reliance on these aspects to demonstrate system reliability/dependability to the effects of a digital CCF (hardware or software) or to prevent its occurrence, in addition to software quality.

supports the correlation between operating experience and quality.

As stated previously, NEI 20-07 only addresses CCFs resulting from design defects in the internal platform software/hardware and associated application software (i.e., not the system architecture as a whole). The concept behind NEI 20-07 is that by applying the relevant SDOs, CCFs resulting from design defects in the internal platform software/hardware and application do not need to be further considered or postulated.

NEI may consider to addressing the complete system architecture in NEI 20-07 in a future revision. However, at this time, NEI is focusing solely on SDOs for high-quality platform selection and application software development such that a software CCF does not need to be further considered or postulated.

a Is it NEIs position that software quality and operating experience (presumably of the same software package) alone, is sufficient to demonstrate a sufficiently low likelihood of failure for an entire system?

NEI position is that it is possible to develop such high-quality software that SCCF caused by software design defects no longer needs to be considered or postulated.

As stated above, NEI 20-07 does not rely solely on operating experience when assessing a platforms susceptibility to SCCF - the platform must meet the requirements of a SIL3/SC3 system set forth in IEC 61508.

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 20 Reference #1 NRC Comment NEI Response Resolution Software defects are only one contributor to CCF. Other aspects still need to be addressed, such as the whole system architecture. NEI 20-07 does not currently address whole system architecture.

Therefore, it is not NEIs position that adherence to the guidance in NEI 20-07 is enough to conclude that a fully integrated system is not susceptible to CCF.

b Are there any aspects of the methodology of NEI 20-07 that focus on architectural design and/or design features to also demonstrate high reliability/dependability?

Yes - If architecture in this question is referring to HSSSR digital system architecture. SDO 9.1.3.1 requires the platform to meet or exceed a Systematic Capability of SC3 (as for a SIL 3 system) as described in IEC 61508. Part of the SC3 certification pertains to the internal architecture of the platform, which includes both hardware and software. SDO 9.2.3.1 addresses platform integration and states, in part, that when platform elements are integrated at the system level, subsystem level, or among other elements, they are integrated in accordance with the Safety Manual that complies with IEC 61508-2 Annex D or 61508-3 Annex D. The Safety Manual requires application of specific external architectural design elements in order to maintain the SC3 certification.

With respect to both platform and application software, NEI 20-07 presents specific design

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 21 Reference #1 NRC Comment NEI Response Resolution objectives that, when met, will constitute a safe system that is, highly reliable and dependable.

Note that the focus of NEI 20-07 is on HSSSR platform and application software because these elements are the most probable cause of CCF in a HSSSR system.