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 Reference #1 NRC Comment NEI Response Resolution 1 Assessing CCF Vulnerabilities a Does the methodology described in The CCF vulnerability assessment would be draft NEI 20-07 require an assessment performed as part of, rather than prior to, of potential common cause failure applying the guidance in NEI 20-07. Results of (CCF) vulnerabilities in a proposed the CCF vulnerability assessment would be system, prior to implementation of provided in the Assurance Case.

this methodology?

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 The SDOs are independent of any platform methodology in draft NEI 20-07 technology and application software.

protect against potential CCF The hazard analysis SDO, for example, vulnerabilities in a generic sense, performed for each system would consider when different systems may have integration of different systems from an unique characteristics such as 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) 1

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff Reference #1 NRC Comment NEI Response Resolution different platforms, application assessed separately following the guidance in software, architectures, etc.? 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 NEI 20-07 is not intended to be related to, frequency argument to resolve CCF consistent with, or parallel with RIS 2002-22 considerations in a similar manner to Supplement 1.

RIS 2002-22, Supplement 1, but for HSSSR systems. RIS 2002-22, One risk-informed aspect to NEI 20-07 is the Supplement 1, allows for frequency way an HSSSR system is determined. BTP 7-19 2

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff Reference #1 NRC Comment NEI Response Resolution (i.e. likelihood) arguments because it allows for site-specific PRA, if available, to is focused on lower support the determination of a HSSSR system.

safety significant systems whose failure consequences of CCF is well NEI 20-07 is expected to be used for the highest understood and acceptable. safety-significant safety-related SSCs - the consequences of failure are therefore very Its not clear how the approach in high. NEI 20-07 adopts a level of quality to draft NEI 20-07 is consistent with RIS reach the conclusion that CCFs resulting from a 2002-22, Supplement 1 or BTP 7-19, design defect in the internal platform Revision 8, SRM to SECY 93-087 as software/hardware or application software well as SECY 18-0090 with regard to need not be further considered or postulated.

using a frequency argument to remove CCF from further Similar to what has been achieved for hardware consideration, but for an HSSSR (e.g., HW Equipment Qualification), NEIs intent system. 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 NEIs position is that, by definition, the HSSSR has severe consequences and consequences of failure of a HSSSR SSC is high.

that the approach in NEI 20-07 is NEI 20-07 provides guidance on platform attempting to justify the safety system selection and application software design through a very low likelihood development where software quality is the of occurrence of software CCF? focus.

3

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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, The existing gap is between the level of endorsed IEEE standards (e.g. IEEE software quality required to postulate the Std. 1012, IEEE Std. 7-4.3.2) have a effects of a CCF as a beyond design basis (BDB) potential gap that the methodology of event (i.e., software quality level achievable NEI 20-07 is addressing? This using existing endorsed standards), vs. the level statement seems to presume that of quality required to conclude a CCF is SDO concept are unique to IEC 61508. 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 4

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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 Yes. NEI 20-07 is expected to be used in methodology described in NEI 20-07, conjunction with the currently endorsed when used in conjunction with the software development standards. As stated in currently endorsed standards, can the response to Question 2a, NEIs position is provide a lower likelihood of software that there is a level of software quality over CCF in HSSSRs than current processes and beyond what is currently required to meet alone? 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 The present regulatory infrastructure development with such high quality that a for HSSSR systems acknowledges that licensee no longer needs to consider the it is possible to identify a potential CCF internal platform software/hardware or vulnerability due to a latent defect has application software or as a source of CCF.

such a low likelihood of occurrence that it may be treated as beyond Comparable to applying the testing criteria in design basis, and therefore its BTP 7-19 to eliminate software as a source of consequences may be evaluated using CCF, the SDOs provide a set of criteria that can best-estimate methods. The use of be applied to eliminate consideration of SCCFs best-estimate methods was intended resulting from internal platform to be less burdensome for licensees software/hardware and application software and applicants than typical reactor design defects in the D3 analysis.

safety thermal hydraulic analysis methods. The consequences of very There may be other sources of CCF that need to low likelihood of occurrence of CCFs be evaluated as part of the overall system due to latent defects still need to be architecture other than the platform 5

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff Reference #1 NRC Comment NEI Response Resolution evaluated to demonstrate reactor hardware/software and application software.

safety objectives and regulatory dose NEI 20-07 only addresses CCFs resulting from acceptance criteria limits are being design defects in the application software and met. As currently written, NEI 20-07 internal platform software/hardware. External seems to suggest otherwise. 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 NEI 20-07 is heavily leveraged on research leveraged in this document. The staff conducted by EPRI on the efficacy of SIL would need to understand more certification for nuclear power [EPRI Technical details on this research and its Report 3002011817, dated July 2019]. Some in applicability and technical the NRC staff have reviewed this EPRI report as assumptions as it pertains to it was used in the development of NEI 17-06, addressing CCF in nuclear Guidance on Using IEC 61508 SIL Certification applications, types of to Support the Acceptance of Commercial devices/components considered, Grade Digital Equipment for Nuclear Safety software Related Applications, which is currently under applications, etc., and how theyre NRC review for endorsement. Some in the NRC organized/configured. This is to staff also conducted an audit of the SIL ensure we have relevant comparison certification process as part of development of of data. For example, with regard to NEI 17-06 and are familiar with the application 1.6 billion operating hours, how much and requirements of IEC 61508.

of that data is valid with respects to the Regarding the 1.6 billion operating hours in the components, systems, operating EPRI research, all the EPRI harvested data is system platforms, etc. that are valid with respect to components, systems, 6

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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 Yes, it is NEIs position that IEC 61508 provides implementation of IEC 61508 in an the level of SDOs for both platform and adequate manner is sufficient to application software to eliminate their render SWCCF not credible consideration as a source of CCF.

(sufficiently low for platforms, not applications)? What about the The guidance in NEI 20-07 is intended to be application software? 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 7

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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 Per the guidance in NEI 20-07, platforms are followed in totality to achieve the required to meet SIL3/SC3 requirements as stated goals within. In the context of specified in IEC 61508. Thus, for platforms, IEC NEI 20-07, is IEC 61508 being utilized 61508 is being used in its entirety.

in its entirety or are only certain portions of IEC 61508 being utilized? If The guidance in IEC 61508 was strategically only partially, what is that scope? synthesized to harvest only the necessary elements needed to develop high-quality application software.

c The methodology in NEI 20-07 To comply with the guidance in NEI 20-07, appears to be a process that uses platforms would need to meet the aspects of IEC 61508 without requirements of SIL3/SC3 as specified in IEC necessarily requiring the 61508. Thus, internal platform hardware and platform/application software to be software are required to be compliant with IEC compliant with IEC 61508. Is that the 61508.

approach being taken by NEI 20-07?

(Note: IEC 61508 is not a nuclear As described in the response to Question 5B, standard but an the SDOs for developing application software industrial standard. IEC 61513 is a were strategically synthesized from IEC 61508.

nuclear though and its not clear why Only portions of the guidance applicable to this standard was not used). 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 8

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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 NEI 20-07 is not intended to be related to, provide methodologies that are consistent with, or parallel with RIS 2002-22 consistent with the guidance of RIS Supplement 1 nor is NEI 20-07 intended to be 2002-22 Supplement 1 and its used for SSCs implemented under 50.59. The definition of sufficiently low and reason for mentioning 50.59 was to indicate requirements under 10 CFR 50.59? 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 NEI does not envision NEI 20-07 being used for being used under 10 CFR 50.59? 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 NEI 20-07 will be used for activities that will 96-07, Appendix D? Does the require a LAR to implement. The Assurance document identify residual gaps Case referred to in NEI 20-07 would be part of between it and technical guidance the LAR package.

9

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff Reference #1 NRC Comment NEI Response Resolution that complements NEI 96-07, The initial draft of NEI 20-07 mentioned 50.59 Appendix D? 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 The guidance provided in NEI 20-07 is based on software development process (e.g. a mature standard (IEC 61508) and years of BTP 7-14) and has previously EPRI research on quality platform and software determined that a high-quality development. Based on this research, NEI feels software development process is strongly that application of the guidance sufficient to consider software CCF a provided in NEI 20-07 will result in selection of beyond design basis event, but not the highest quality platform and development necessarily sufficient to eliminate the of the highest quality application software, potential for CCF. NEI should describe beyond that which can be achieved using how the methodology in NEI 20-07 is existing standards. As stated above, NEI 20-07 sufficiently different than current is intended to be used in addition to the processes such that potential software existing NRC endorsed standards on software CCF consideration can be eliminated. 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 It is NEIs position that if a licensee provides an evaluation/analysis needed if this Assurance Case that provides the arguments document is implemented? and evidence that the SDOs are met, there is no need to further consider or postulate SCCFs 10

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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 SDO 10.1.3.2 requires use of a hazard analysis this document points to that is method to identify hazardous control actions performed to highlight potential CCF that can lead to an accident or loss. SCCF vulnerabilities? vulnerabilities are the primary focus of this hazard analysis.

The hazard analysis specified by SDO 10.1.3.2 is Some analysis of the design a global analysis considering all aspects of the (architecture) beyond the software system and architecture, including both seems implied by SDOs relating to hardware and software. Thus, the identified 6.3s 1st principle. For example, hazardous control actions will cover much 10.1.3.2 through 10.1.3.5. 10.1.3.2 more than application software. Some of the identifies constraints derived from hazardous control actions identified will not hazardous control actions, which may apply to the application software while others imply something that enforces the will. This SDO requires that results of the constraint that is not the application hazard analysis be used to generate specific software itself. 10.1.3.4 identifies application software requirements and hardware constraints. 10.1.3.5 constraints as they apply to the system - both identifies constraints imposed by the hardware and software.

I&C system design.

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 11

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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 NEI 20-07 addresses Position 1 of SECY 93-087:

SRM to SECY 93-087 and why SRM to Identify CCF vulnerabilities in the systems.

SECY 93-087 is not referenced.

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 12

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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 BTP 7-19 provides an exclusion of software that of digital CCF to be both software and meets the specified testing criteria. Similarly, hardware, consistent with SRM to NEI 20-07 is providing an exclusion for SECY 93-087. Is it NEIs position that platforms and application software that meet NEI 20-07 provides adequate coverage the SDOs.

with respect to the scope of CCF considerations in BTP 7-19, Revision NEI 20-07 focuses only on internal platform 8? 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 It is NEIs position that the processes are fill the gap that is perceived within complimentary and overlap but address 13

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff Reference #1 NRC Comment NEI Response Resolution current NRC processes (e.g. BTP 7-14) different objectives. The current set of NRC-or is it attempting to be endorsed software development standards complimentary to current processes, allow crediting a CCF as a BDB event. Applying or both? Industry has not formally the SDOs provided in NEI 20-07 would allow an communicated of such a gap to the applicant to deterministically assess that CCF NRC. Industry has previously associated with design defects in the platform expressed concerns with the level of and application software has been adequately effort with current NRC practices and addressed and need not be further considered NEI 20-07 would appear to add an or postulated.

additional layer of complexity to licensing and design work.

11 General Comments on Section 6, titled First Principles of Protection Against Software CCF a The principles listed in this section First principles do not need acceptance criteria.

have a description (with the Rather, they provide a principle-based subsection headers themselves acting conceptual understanding of the phenomena.

as the principle itself) but do not It is the SDOs that provide the analysis appear to have guidance. Its not clear guidance and acceptance criteria to meet the how a licensee or application can first principles. NEI 20-07 states, This apply them without specified approach begins by establishing a set of first acceptance criteria or similar type of principles for the protection against software consideration. 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, See earlier comments regarding the term its not clear how a licensee or sufficiently low. Documented adherence to applicant can the SDOs provided in NEI 20-07 offers evidence adequately determine whether the that the acceptance criteria for selection of a stated goals of this document (i.e. high-quality platform and development of high-14

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff Reference #1 NRC Comment NEI Response Resolution sufficiently low finding with regard to quality application software at a level such that software CCF) has been achieved. 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 See earlier comments regarding the term general acceptance criteria for all sufficiently low. NEI 20-07 is not intended to portions of the methodology that are be related to, consistent with, or parallel with used to ultimately make a RIS 2002-22 Supplement 1.

determination of sufficiently low with regard to the likelihood of To a degree, NEI 20-07 provides a deterministic software CCF? approach for evaluating platform software/hardware and development of application software in that by applying the 15

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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 Yes - If the SDOs in NEI 20-07 are applied, the acceptance criteria in BTP 7-19, design attributes/defensive measures that are Revision 8, including Section 3.1.3? 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 NEI agrees that bounding is not an applicable that the first principles in Section 6 is term in describing the scope of the first both bounding and complete. On principles. It is accurate to state that the first the surface, with regard to software principles are complete. NEIs position is that development, there would appear to these first principles are complete. NEI 16

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff Reference #1 NRC Comment NEI Response Resolution be more considerations than whats welcomes NRC feedback regarding the first currently listed. 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 See response to Question 13a.

bounding? Bounding with current regulations?

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 NEI is not taking the position that there are any generally understood to be identified gaps with IEEE standards. The IEEE identified/covered within existing IEEE standards have a different objective than NEI standards the NRC staff has already 20-07 as expressed in the response for 10a.

endorsed and the subsections in Rather, NEIs intent is that NEI 20-07 is a means Section 6 are silent in this respect. Is it to adequately address CCFs caused by latent NEIs position that existing, endorsed design defects in the platform IEEE standards (e.g. IEEE Std. 1012, software/hardware and associated application IEEE Std. 7-4.3.2) have potential gaps software.

that the methodology of NEI 20-07 is addressing?

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 17

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff Reference #1 NRC Comment NEI Response Resolution a Does NEI intend to include the NEIs intent is that NEI 20-07 has enough relevant portions of IEC 61508 as part information to facilitate the staffs review and of this review or does NEI believe that does not plan to submit any portions of IEC NEI 20-07 has sufficient information 61508 for review and endorsement by the NRC.

contained therein to facilitate the staffs review? 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 NEI 20-07 is not intended to mirror the the qualitative assessment concept guidance in RIS 2002-22 Supplement 1. The where the aggregate of considerations next draft of NEI 20-07 will remove any of deterministic design features, connection to RIS 2002-22 Supplement 1.

software quality and operating experience can be used to make a NEI 20-07 does not rely solely on operating sufficiently low determination. The RIS experience when assessing a platforms supplement is clear that operating susceptibility to SCCF - the platform must meet experience alone cannot be used as a the requirements of a SIL3/SC3 system set forth sole basis for a sufficiently low in IEC 61508.

determination and isnt truly a substitute for the two other aspects. Additionally, operating experience, when used NEI 20- 07 Section 6.4, 9.1.2 and other in the context provided in NEI 20-07, only sections would appear to make the applies to internal platform software and case that a focus on software quality hardware. The concept of platform operating and supplemental operating history experience is derived from EPRI research on SIL (presumably of the exact same certified platforms. EPRI reviewed several software package) alone are sufficient platforms currently in operation and those that to demonstrate a sufficiently low were SIL3 certified and in operation for likelihood of failure of an entire HSSSR approximately 1.6 billion operating hours had system. This appears to be the case in no evidence of experiencing a SCCF. This 18

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff Reference #1 NRC Comment NEI Response Resolution lieu of additional consideration of supports the correlation between operating architectural design or deterministic experience and quality.

design features (e.g. defensive measures) that can also demonstrate As stated previously, NEI 20-07 only addresses high reliability/dependability. This CCFs resulting from design defects in the would not appear consistent with internal platform software/hardware and either the RIS supplement 1 or BTP 7- associated application software (i.e., not the 19, Revision 8, which both provide for system architecture as a whole). The concept reliance on these aspects to behind NEI 20-07 is that by applying the demonstrate system relevant SDOs, CCFs resulting from design reliability/dependability to the effects defects in the internal platform of a digital CCF (hardware or software) software/hardware and application do not or to prevent its occurrence, in need to be further considered or postulated.

addition to software quality. 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 NEI position is that it is possible to develop quality and operating experience such high-quality software that SCCF caused by (presumably of the same software software design defects no longer needs to be package) alone, is sufficient to considered or postulated.

demonstrate a sufficiently low likelihood of failure for an entire As stated above, NEI 20-07 does not rely solely system? 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.

19

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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 Yes - If architecture in this question is referring methodology of NEI 20-07 that focus to HSSSR digital system architecture. SDO on architectural design and/or design 9.1.3.1 requires the platform to meet or exceed features to also demonstrate high a Systematic Capability of SC3 (as for a SIL 3 reliability/dependability? 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 20

NEI Responses to NRC Comments1 on NEI 20-07, Draft B 3/26/21 DRAFT - For Discussion with NRC Staff 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.

21