ML21162A073: Difference between revisions

From kanterella
Jump to navigation Jump to search
(StriderTol Bot change)
(StriderTol Bot change)
Line 15: Line 15:


=Text=
=Text=
{{#Wiki_filter:J.
{{#Wiki_filter:}}
UNITED STATES NUCLEAR REGULATORY COMMISSION WASHINGTON, D.C. 20555-0001 June 11, 2021 MEMORANDUM TO:            Jeanne Johnston, Chief Long Term Operations and Modernization Branch Division of Engineering and External Hazards Office of Nuclear Reactor Regulation FROM:                      Tekia V. Govan, Project Manager /RA/
Reactor Assessment Branch Division of Reactor Oversight Office of Nuclear Reactor Regulation
 
==SUBJECT:==
 
==SUMMARY==
OF THE PUBLIC MEETING TO DISCUSS THE NUCLEAR ENERGY INSTITUTES PRE-SUBMITTAL OF NEI 20-07, DRAFT C, HELD ON MAY 18, 2021 On May 18, 2021, the U.S. Nuclear Regulatory Commission (NRC) staff held a meeting with the Nuclear Energy Institute (NEI) to discuss pre-submittal activities for NEI 20-07, Draft C, "Guidance for Addressing Software Common Cause Failure in High Safety-Significant Safety-Related Digital I&C Systems" (Agencywide Documents Access and Management System (ADAMS) Accession Nos. ML21130A596 and ML21130A597 [mark-up]). NEI has requested staff engagement on this guidance document prior to submitting a request for formal NRC endorsement.
As follow-on to several public meetings held in April 2021 to discuss NEI 20-07, NEI provided documented responses to NRC staff comments on NEI 20-07, Draft B (ADAMS Accession No. ML21120A598). This meeting focuses on how NEI has addressed these comments and incorporated the applicable changes in to Draft C of NEI 20-07.
Meeting Summary During the meeting, the NRC staff commented that NEI 20-07, Draft C, appears to only focus on the frequency element of the risk argument. The risk consideration only addresses the potential frequency of occurrence of a common cause failure (CCF), without taking into account the consequences of a high safety significant safety related (HSSSR) failure due to a CCF.
Because the discussion on this topic appears incomplete, it was not clear that NEI 20-07, Draft C, provides sufficient technical basis to abstain the need for deterministic design features such as diversity. In light of this feedback, NEI committed to revising NEI 20-07 Draft C, which would result in a restructuring of its content to include a more comprehensive description of a CONTACT: Tekia V. Govan, NRR/DRO (301) 415-6197
 
J. Johnston                                          risk-informed approach that incorporates a more technically refined frequency/consequence discussion. The NRC staff also followed up by asking NEI whether the guidance would include some diversity aspects as described during this meeting, to which NEI indicated that they would explore this aspect more after the meeting.
As a result of this meeting, and the commitment to revise NEI 20-07, Draft C, the NRC staff noted the following actions:
General
: 1. After internal discussion, NEI would inform NRC staff of their intent to move forward with additional work on a new draft of NEI 20-07, in light of challenges with current CCF policy (i.e. SRM to SECY 93-087).
: 2. NEI will update/refine the definition of the term platform as it pertains to NEI 20-07 processes.
Applicable to NEI 20-07, Draft C, Section 5
: 3. Review the first paragraph that provides a description of the gap between NEI 20-07 processes and NRCs currently endorsed processes. Modify the language to ensure that it is clear that NEI is not implying that there is a deficiency in the NRCs currently endorsed processes, as NEI clarified during this public meeting. NEI also committed to providing more explicit detail in this section about what the gap is between NEI 20-07 processes and NRCs currently endorsed processes.
Applicable to NEI 20-07, Draft C, Section 9
: 4. In Section 9.1, clarify what is meant by the use of the term designer. This includes clearly defining the responsibilities of this role as it pertains to NEI 20-07 processes.
: 5. Provide more detail/evidence that demonstrates how NEI 20-07 bridges the gap between the reliability argument and the conclusion that CCF does not need to be postulated once the processes of NEI 20-07 has been implemented. To date, it is not clear to NRC staff that there is adequate justification to reach the stated conclusion.
: 6. Determine if safety integrity level 3 reliability numbers are comparable to existing system reliability rates.
: 7. Determine if NEI 20-07 should be restructured for a system-level process based on consequence considerations as a result of high-risk characteristics of HSSSR systems.
Applicable to NEI 20-07, Draft C, Section 11
: 8. Provide clarification that Section 11 was essentially a placeholder section.
Additionally, the NRC staff pointed out that International Electrotechnical Commission (IEC) 61508-3 had a number of diversity elements that would seem appropriate to incorporate into NEI 20-07 to ensure that there is a baseline of diversity designed into the system architecture, as this would align with Safe Design Objective (SDO) 10.1.3.2 as its a system level SDO. The NRC staff also reiterated its comment from a previous
 
J. Johnston                                                meeting that NEI should consider whether the document should be revised to be a system-level process. If so, then diversity elements in IEC 61508-3 would align as they are for the system architecture and would help provide a path forward to address consistency with SRM to SECY 93-087. NEI stated that it would take the action to see if these diversity aspects could be leveraged into NEI 20-07.
: 9. Clarify whether SDO 10.1.3.2 is focused on the application software or is it a system level criterion. This clarification is needed, as it pertains to diversity, so that its clear to the user of this document whether the execution of this SDO would result in potentially adding diversity centric SDOs.
: 10. Enhance the level of detail in SDO 10.1.3.2 to provide more information on what a hazard analysis for this SDO would entail and what methods are appropriate/adequate to address identified hazards. This clarification will help ensure there are parameters in place to evaluate the efficacy of the chose hazard analysis method.
: 11. NEI clarified that hazardous control methods (methods used to address hazards identified by SDO 10.1.3.2) would become new higher-level system requirements and not new SDOs. The NRC staff stated that there does not appear to be a mechanism in place that tracks or controls this aspect of the design process within NEI 20-07. NEI committed to clarifying how hazardous control methods are dispositioned.
As a result of this meeting and the action items discussed during the meeting, the NRC staff also reviewed and provided comments on NEI 20-07, Draft C. These comments can be found in Enclosure 2 of this summary but should not be considered NRCs final comments on this guidance document. The NRC staff anticipates that NEI will incorporate these comments in a future revision to NEI 20-07 and that the comments that are not addressed and/or incorporated be discussed at a future public meeting. provides the attendance list for this meeting.
Next Steps/Action Item The next public meeting is scheduled for Thursday, July 1, 2021. During this meeting NEI will provide a presentation on the restructuring of NEI 20-07 that will contain a more risk informed approach for addressing diversity and defense in depth for CCF.
Conclusion At the end of the meeting, NRC and industry management gave closing remarks. NEI and other nuclear industry representatives expressed appreciation for the open dialogue.
 
==Enclosure:==
 
As stated
 
ML21162A073                                    *via e-mail OFFICE NRR/DRO/IRSB/PM NRR/DEX/ELTB/TR NRR/DEX/ELTB NRR/DRO/IRSB/PM NAME  TGovan*        WMorton*        JJohnston*  TGovan*
DATE  06/10/2021      06/10/2021      06/11/2021  06/11/2021 LIST OF ATTENDEES PUBLIC MEETING TO DISCUSS THE NUCLEAR ENERGY INSTITUTES PRE-SUBMITTAL OF NEI 20-07, DRAFT C May 18, 2021 8:00 AM to 12:00 PM Microsoft Teams Meeting ATTENDEE                                          ORGANIZATION
: 1. Eric Benner                                    NRC
: 2. Wendell Morton                                  NRC
: 3. Tekia Govan                                    NRC
: 4. Maxine Segarnick                                NRC
: 5. Jeanne Johnston                                NRC
: 6. Bob Weisman                                    NRC
: 7. Rossnyev Alvarado                              NRC
: 8. David Rahn                                      NRC
: 9. Sergui Basturescu                              NRC
: 10. Sheldon Clark                                  NRC
: 11. Eric Bowman                                    NRC
: 12. Ismael Garcia                                  NRC
: 13. Norbert Carte                                  NRC
: 14. Paul Rebstock                                  NRC
: 15. Steve Vaughn                                  NEI
: 16. Jana Bergman                                  Curtiss-Wright
: 17. Neil Archambo                                  Duke Energy
: 18. Steve Geier                                    NEI
: 19. Warren Odess-Gillett                          Westinghouse/NEI
: 20. Tom Basso                                      NEI
: 21. Mike Wiwel                                    PSEG Nuclear LLC
: 22. John Connelly                                  Exelon
: 23. Bernie Dittman                                NRC
: 24. David Herrell                                  MPR
: 25. Ty Rogers                                      GE Hitachi Nuclear Energy
: 26. David Jarosh                                  Unknown
: 27. Marty Flynn                                    Entergy
: 28. Robert Armistead                              Member of the Public
: 29. Richard Stattel                                NRC
: 30. Sushil Birla                                  NRC
: 31. Richard Supler                                Enercon
: 32. William Roggenbrodt                            NRC
: 33. Eugene Keller                                  NRC
: 34. Mike Bailey                                    MEPPI
: 35. Frances Pimental                              NEI Enclosure 1
 
NEI 20-07 ENCLOSURE 2: NRC STAFF COMMENT ON NEI-20-07, DRAFT C GUIDANCE FOR ADDRESSING SOFTWARE COMMON CAUSE FAILURE IN HIGH SAFETY-SIGNIFICANT SAFETY-RELATED DIGITAL I&C SYSTEMS Draft C Prepared by the Nuclear Energy Institute May 2021
© NEI 2021. All rights reserved.                                      nei.org
 
NEI 20-07, Draft C                              DRAFT                                          May 2021 Acknowledgements NEI would like to thank the NEI DI&C Working Group for developing this document.
NOTICE 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 resulting from any use of, any information apparatus, methods, or process disclosed in this report or that such may not infringe privately owned rights.
© NEI 2021. All rights reserved.                                                                nei.org 7
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 Executive Summary Commented [A1]: NEI should explain whether this new statement means that they are changing their view on the Implementation of digital technology at nuclear power stations can provide significant benefits in            effectives of the proposed SDOs for protecting against software CCF.
component and system reliability which can result in improved plant safety and availability. However, a software defect in a digital system or component can introduce a safety hazard through a potential            Rationale - The previous version of NEI 20-07 included software common cause failure (CCF).                                                                          statements such as the following [emphasis added]: This document provides an alternative to these two methods
[diversity and testing methods] to eliminate the Branch Technical Position (BTP) 7-19, Revision 8, provides three separate methods licensees can use to        consideration of CCF for a safety-related system. However, the new statement does not portray such a strong position and eliminate CCF hazards from further consideration. These three methods are (1) use of diversity within        instead, could be interpreted to mean that despite the the DI&C system, (2) use of testing, or (3) use of defensive measures. NEI 20-07 is best aligned with the    application of the proposed SDOs, some residual defects may remain undetected and persist as latent defects. Such a third method presented in BTP 7-19, Revision 8 (Section 3.1.3)  the use of defensive measures. NEI 20-      residual risk would need to be assessed by the 07 provides objective criteria in the form of safe design objectives (SDOs) that are used to provide a        licensee/vendor as part of the D3 analysis to be done for the entire I&C architecture/system assessment.
defense against software CCF resulting from a software design defect. The SDOs are used for selection of platform hardware and software, and the development of application software. The approach in NEI          Commented [A2]: This statement may be misleading since software quality standards are not the only means they rely 20-07 begins by establishing a set of first principles for the protection against software CCF in digital    upon. They also use segmentation, simplification, diversity, instrumentation and control (DI&C) systems and then subsequently the decomposition of these first            and defense in depth.
principles into SDOs. This document also proposes using an assurance case method to demonstrate that          Commented [A3]: The technical basis for this extrapolation is unclear. How does the extrapolation consider each of the the software application and the platform that hosts the application software in a high safety-significant    following?
safety-related (HSSSR) system have been adequately addressed. When a Diversity and Defense-in-Depth (D3) analysis for the HSSSR system is performed, and the assurance case demonstrates that the              1.The application will not have had 1.6 billion hours of operating experience.
platform and the associated application software has adequately addressed CCF, then these parts of the system can be exempted from being postulated as a source of CCF. This does not exclude the need for              2.The application will not be designed for generic use or be accompanied by the equivalent of a safety manual.
an HSSSR system D3 analysis because other CCF vulnerabilities may be identified (e.g., data communications).                                                                                                3.The application will not have been independently certified as meeting a SIL or SC level.
Numerous industries have managed to successfully implement software-based digital technology. Many            Each of the above were provided as basis for platforms.
of these industries manage extremely dangerous processes yet have found a way to safely and reliably          Did the technical basis for the platform consider the following?
operate using digital technology by capitalizing on the use of quality software design standards, such as IEC 61508. Research conducted by EPRI on the use of IEC 61508 for software development has revealed              1.Uncertainty regarding the degree that the sampled data (i.e., 12 devices) represent all SIL 3 certified devices.
conclusive results that demonstrate IEC 61508 safety integrity level (SIL) certified digital equipment achieve their designated SIL reliability targets [4]. EPRI conducted a review of software-based platforms        2.Uncertainty regarding the degree the methods used in the EPRI research could identify CCFs. (i.e., warranty return with over 1.6 billion hours of operation. The software used in these platforms was designed to a Safety          data may not be an effective means to identify SW errors).
Integrity Level (SIL) Systematic Capability of 3 as defined in IEC 61508. The research revealed no 3.Uncertainty regarding the degree the individual vendor evidence that any of the platforms experienced a software CCF during the more than 1.6 billion hours of          practices beyond the minimal required for SIL 3 certification operation. Based on this research, it can be reasonably concluded that use of the guidance in IEC 61508          may contribute to its observed performance.
when developing platform software and extrapolating to application software will result in reasonable        Commented [A4]: NEI should explain why the synthesized assurance that a latent software defect will not lead to a software CCF.                                      information from IEC 61508-3 did not include that associated with diversity.
Development of the guidance in this document began by establishing a set of first principles for the          Rationale - Some excerpts from IEC 61508-3 (2010) related to the topic of diversity [emphasis added] which are not included protection against software CCF in HSSSR digital I&C (DI&C) systems. The software CCF first principles        in the proposed NEI 20-07 SDOs:
were derived and synthesized from EPRI research and industry operating experience and are used to 1.Section 7.4.2.13: g) There shall be evidence that all establish a framework for industry consensus on the fundamental principles upon which an approach to            credible failure mechanisms of the software element have adequately address software CCF can be developed. From these software CCF first principles a set of              been identified and that appropriate mitigation measures safe design objectives (SDOs) were established for application software, synthesized from IEC 61508 and          have been implemented.
NOTE 3 Appropriate mitigation measures include:
other industry standards, that address the software CCF first principles. The SDOs are for use in selection
* appropriate system architecture (e.g. partitioning, of a platform and when developing application software in HSSSR systems and components.                          wrappers, diversity, credibility of checking of outputs);
* exception handling.
Documenting an assurance case based on adherence to these SDOs will facilitate the demonstration of 2.Section 7.4.3.2: The software architecture design shall be established by the software supplier and/or            ... [1]
© NEI 2021. All rights reserved.                                                                    nei.org 8
 
NEI 20-07, Draft C                                DRAFT                                        May 2021 reasonable assurance that the target software contains no software design defects that could lead to a software CCF.                                                                                              Commented [A5]: Based upon this statement, I suggest an assessment of confidence in sufficient regulatory certainty regarding the following:
The guidance in this document is intended to be applied on digital upgrades to HSSSR systems and equipment that require a license amendment to implement. The Assurance Case developed through use              1. Licensees will submit an adequate assurance case for adherence to the SDOs of this document will be part of the license amendment request documentation package.
2.Staff will be able to reach reasonable assurance that the defined scope contains no software design defect that could NEI 20-07 applies to all holders of operating licenses under Title 10 of the Code of Federal Regulations        lead to a CCF (10 CFR) Part 50, Domestic Licensing of Production Facilities and all holders of combined licenses under 10 CFR Part 52, Licenses, Certifications, and Approvals for Nuclear Power Plants. Although the      If the NRC has sufficient regulatory certainty, then it seems reasonable that this approach could move forward.
guidance in NEI 20-07 primarily focuses on power reactors, other licensees may also use the guidance in NEI 20-07 when selecting platforms and developing application software in HSSSR systems. However,          If the NRC does not have sufficient regulatory certainty, then the assessment could identify what could be done (if anything) certain aspects of NEI 20-07 guidance discuss regulatory requirements that may not fully apply to these    to get to the point of sufficient regulatory certainty.
licensees (e.g., Appendix B, Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants).                                                                                                  Commented [A6]: Beyond power reactors, what other licensees is NEI referring to specifically.
This document was developed by the NEI Digital I&C Working Group, in support of the industry response      The statement seems to imply, for example, non-commercial to Modernization Plan #1 (MP#1) Protection Against Common Cause Failure in the NRCs Integrated            NPP licensees (NPUFs?). It seems including greater scope could cause additional NRC staff/organization involvement, Strategy to Modernize the Nuclear Regulatory Commissions Digital Instrumentation and Control              which might extend the review process.
Regulatory Infrastructure (SECY-16-0070, ADAMS Accession No. ML16126A140). MP#1, contained in Suggest NEI delete the final two sentences unless as it is  of SECY-16-0070, is identified as a high priority within the NRC Action Plan.                  ambiguous.
© NEI 2021. All rights reserved.                                                                  nei.org 9
 
NEI 20-07, Draft C                                                DRAFT                                                                    May 2021 TABLE OF CONTENTS 1      Introduction ................................................................................................................................ 11 2      Background ................................................................................................................................. 11 3      Definitions ................................................................................................................................... 12 4      Purpose ....................................................................................................................................... 13 5      NRC Regulatory Framework Versus Implementation Level Activities to Address Software CCF .. 14 6      First Principles of Protection Against Software CCF ..................................................................... 15 7      Scope and Applicability................................................................................................................ 17 8      Software CCF Evaluation Process................................................................................................. 18 9      Software at the Platform and Platform Integration Levels .......................................................... 19 10      Software at the Application and Plant Integration Levels ............................................................ 22 11      Assurance Case Development ..................................................................................................... 35 12      Summary and Conclusion ............................................................................................................ 36 13      References................................................................................................................................... 36 Appendix A: Connection Between Software CCF First Principles and NRC Regulatory Framework .......... 37 Appendix B: Assurance Case Development .............................................................................................. 44
© NEI 2021. All rights reserved.                                                                                                            nei.org 10
 
NEI 20-07, Draft C                                  DRAFT                                        May 2021 1    Introduction Digital instrumentation and control (DI&C) systems can be vulnerable to a software common cause failure (CCF) as a result of a latent defect in the software or software developed logic, which could defeat the redundancy achieved by the system architecture. When identical digital equipment is applied across multiple trains of a safety related system, an undetected software defect could be triggered by certain plant and/or system conditions and cause a simultaneous failure of multiple safety related trains.
Similarly, when previously separate control functions are combined within the same digital component or system, a latent software defect that is triggered by an untested condition can result in simultaneous failure of multiple functions.
These types of common cause systematic failures may not have been considered in the plant safety              Commented [A7]: NRC requirements are essentially performance based (i.e., they prescribe what must be analyses while random failures (e.g., hardware failures due to a degradation mechanism) are better            achieved, not what or how it must be done) and require understood. This document focuses on systematic failures due to a latent defect in software, and an          diversity and defense in depth as well as the Consideration of approach to providing reasonable assurance through a quality software development process that the            the possibility of systematic, nonrandom, concurrent failures of redundant elements in the design of protection systems and common cause systematic failure of an application is adequately addressed.                                    reactivity control systems. regardless of equipment type.
This approach begins by establishing a set of first principles for the protection against software CCF in high safety-significant safety-related (HSSSR) digital I&C (DI&C) systems. Appendix A provides a mapping between these first principles and NRC regulation. These CCF first principles, derived and synthesized from EPRI research and industry operating experience, provides a framework for industry consensus on the fundamental principles upon which an approach to adequately address CCF can be developed. From these software CCF first principles a set of safe design objectives (SDOs) are established, synthesized from IEC 61508 and other industry standards, that address the software CCF first principles. Ultimately the licensee would demonstrate, using an assurance case demonstrating compliance to the SDOs, providing reasonable assurance that the HSSSR DI&C system does not have a latent software design defect that could lead to a software CCF, by demonstrating compliance to the SDOs.
2    Background Compared to their analog counterparts, properly designed digital systems are generally more robust, reliable, and more capable of preventing malfunctions of multiple controlled systems or components using redundancy, logic, and other design attributes. In addition, digital technology can be provided with the ability to select a preferred state on a controlled system in the event of a DI&C failure, thus affording the designer some alternatives that can improve plant safety and reliability. Digital technology can also provide immediate annunciation of problems with associated diagnostic capabilities not available in their analog counterparts.
Software CCFs are the result of latent defects in the software triggered by an untested condition. Once triggered, a software defect can lead to misbehavior of a system or component. The same software defect in multiple trains of a safety-related system can be simultaneously triggered and lead to a software CCF. The greater the likelihood of a software defect, the greater the likelihood of experiencing a software CCF. The inverse is also true  decreasing the likelihood of a software defect will decrease the likelihood of experiencing a software CCF. This document provides an approach to demonstrate that a software CCF is adequately addressed for a HSSSR DI&C system. The approach is based on mature industry standards, primarily IEC 61508, used worldwide in the development of high-quality software used in high safety-significant systems.
© NEI 2021. All rights reserved.                                                                  nei.org 11
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 3    Definitions Application Software - Software logic added to a platform for a particular situation or purpose to satisfy    Commented [A8]: NEI should explain why they opted not to use the IEC 61508-4 definition for this term, which defines it a set of end-user requirements (e.g., post-accident monitoring, reactor trip).                                as: part of the software of a programmable electronic system that specifies the functions that perform a task related to the Common Cause Failure (CCF) - Loss of function to multiple structures, systems, or components due to a          EUC [equipment under control] rather than the functioning of, and services provided by the shared root cause [IEEE 603-2018].                                                                            programmable device itself.
Rationale - Such an approach would ensure alignment Concurrent Trigger - A triggering condition on multiple segments/elements that occur at or about the          between the SDOs in NEI 20-07 and the synthesized same time.                                                                                                    information from IEC 61508-3.
D3 - Diversity and Defense-in-Depth Defensive Measures - Design attributes to prevent, limit, or reduce the likelihood of a software CCF.
Design Attributes - Hardware and software design features that contribute to high dependability. Such features include built-in fault detection and failure management schemes, internal redundancy and diagnostics, and use of software and hardware architectures designed to minimize failure consequences          Commented [A9]: NOTE: This could include allocation to different applications / physical equipment of any of the and facilitate problem diagnosis.                                                                              following:
: 1) primary and alternate channels, Design Control Measures (DCMs) - The application of a formal methodology to the conduct of product                2) controls for independent trains of equipment
: 3) functions associated with different layers in a line-of-development activities.                                                                                          defense against a particular design basis event or abnormal operating occurrence Latent Software Defect - Undetected errors in functional requirements, software design, or software            However, most of the discussion appears focused on implementation.                                                                                                diagnostics to eliminate undetected failures (which goes along with the and facilitate problem diagnosis ending to the sentence).
Platform - Software and hardware that is integrated to provide basic generic functionality for use by Commented [A10]: NEI should explain how this term as various applications (e.g., programmable logic controller).                                                    defined aligns with the IEC 61508-3 terminology.
Process Discipline - Strict adherence to approved and documented methodologies and processes.                  Rationale - The proposed definition seems to equate the term platform with programmable logic controller or PLC. The way that IEC 61508-3 seems to be structured is that a Random Failure - A failure occurring at a random time, which results from one or more of the possible          software architecture could apply to a PLC, which for NEI is an example of a platform, and not just to an I&C system.
degradation mechanisms in the hardware [IEC 61508-4, Section 3.6.5].                                          Therefore, the IEC 61508-3 requirements such as those listed in my comment in the Executive Summary section above Safe Design Objective (SDO) - Objective criteria for addressing the potential for a software defect being      would seem to be applicable at the platform (or PLC) level.
introduced during the software development and integration processes.
Safety Classification (Classes) - An assignment based on functionality and safety significance. Different safety classifications (classes) require different levels of requirements (e.g., Class 1E versus non-Class 1E, or safety-related and non-safety-related).
Software - The programs used to direct operations of a programmable digital device. Examples include computer programs and logic for programmable hardware devices, and data pertaining to its operation
[IEEE 7-4.3.2-2016].
Software CCF - The result of a latent software defect on multiple segments/elements due to a concurrent trigger.
© NEI 2021. All rights reserved.                                                                    nei.org 12
 
NEI 20-07, Draft C                                DRAFT                                        May 2021 Software Module - Construct that consists of procedures and/or data declarations and that can also interact with other such constructs [IEC 61508-4, Definition 3.3.5]
Software Tools - A sequence of instructions and commands used in the design, development, testing, review, analysis, or maintenance of a programmable digital device or its documentation. Examples include compilers, assemblers, linkers, comparators, cross-reference generators, de-compilers, editors, flow charters, monitors, test case generators, integrated development environments, and timing analyzers. (Adapted from IEEE Std 610'-1990].
Software Module - Construct that consists of procedures and/or data declarations and that can also interact with other such constructs [61508-4 Clause 3.3.5].
System - Defined as either protection, control or monitoring and comprised of one or more programmable electronic devices, including integrated and supporting elements such as power supplies, sensors and other input devices, data highways and other communication paths, and actuators and other output devices [Adapted from IEC 61508-4].                                                          Commented [A11]: By using this definition NEI appears to be including the actuated devices (e.g. pump and valve).
Systematic Capability - Measure (expressed on a scale of SC 1 to SC 4) of the confidence that the          Actuator common definition:
systematic safety integrity of an element meets the requirements of the specified SIL, in respect of the      An actuator is a device that uses a form of power to convert a control signal into mechanical motion.
specified element safety function, when the element is applied in accordance with the instructions specified in the compliant item safety manual for the element [61508-4].                                  This seems contradictory to NEIs response when I pointed out IEC definition of system includes actuated devices while the IEEE 603 boundary of safety system excludes them. Then Systematic Failure - Related in a deterministic way to a certain cause, which can only be eliminated by    Warren O.G. indicated exclusion of actuators was desired.
a modification of the design or of the manufacturing process, operation procedures, documentation, or      Clarity is needed that identifies the context and scope of the I&C system (platform and application) as used in this other relevant factors. [IEC 61508-4, Section 3.6.6].                                                      document.
Triggering Condition - System states (conditions) that can manifest a latent software defect and create the potential for a software CCF.
Design Attributes - Design or design process attributes within the target digital equipment to prevent, limit or reduce the likelihood of a CCF. Design or design process attributes can be assembled together to establish a preventive, limiting, or likelihood reduction measure. Defensive measures are distinguished from coping or mitigating measures, which are external to the target digital equipment and credited to maintain the plant in a safe condition after the CCF occurs.                                              Commented [A12]: It is unclear which definition of Design Attributes reflects NEI 20-07s intent. This is a 2nd definition of the term, which is not identical to the first.
Validation - Confirmation by examination and provision of objective evidence that the requirements for a specific intended use are fulfilled. [61508-4 Clause 3.8.2].                                            Observations:
1.The first definition focuses on tangible product features referred to as design features (excluding process).
Verification - Confirmation by examination and provision of objective evidence that the requirements          2.This second definition additionally includes design process attributes.
have been fulfilled [61508-4].
Furthermore, it is not clear what the final sentence adds to this 4    Purpose                                                                                              definition. There is a separate definition for Defensive Measures and it seems any clarification of Defensive Measures belongs there.
The purpose of this document is to:
: 1. Establish a set of DI&C software CCF first principles to provide a framework for industry consensus on the fundamental principles upon which an approach to adequately address software CCF can be developed. Appendix A provides a mapping between these first principles and existing NRC regulatory framework.
© NEI 2021. All rights reserved.                                                                nei.org 13
 
NEI 20-07, Draft C                                DRAFT                                                      May 2021
: 2. Provide a set of SDOs, representing a decomposition of the first principles, that can be used to demonstrate that a software CCF is adequately addressed.
: 3. Explain the use of an assurance case to demonstrate that the SDOs are adequately addressed to reach the conclusion that a software CCF is adequately addressed for an HSSSR DI&C system.
5  NRC Regulatory Framework Versus Implementation Level Activities to Address Software CCF NEI 20-07 is intended to fill the gap between the NRC regulatory framework and implementation level activities associated with development of HSSSR software. This gap is filled by the establishment of a consensus set of software CCF first principles and the detailed SDOs addressing those first principles.
In contrast, the nuclear industry has developed, and the NRC has endorsed, objective criteria for                        Commented [A13]: It is not clear what this paragraph is in contrast to. What is it in contrast to? What is being complying with the regulatory requirements associated with cyber security, electromagnetic                                contrasted to what?
compatibility (EMC) and human factors engineering (HFE) related activities. NEI 20-07 will provide Commented [A14]: Does it? Or will it when? Isnt objective criteria for evaluation of HSSSR software to adequately address software CCF.                                  satisfying the SDOs intended to be the objective criteria?
This process of developing objective criteria to demonstrate that further consideration of CCF of HSSSR software due to a software design defect can be eliminated, involves establishing a set of first principles for software CCF for industry consensus, and their relationship to the NRC regulatory framework. These first principles are then decomposed into SDOs that serve to provide criteria for establishing that software CCF is adequately addressed for a HSSSR DI&C system.                                                            Commented [A15]: NEI should explain the necessary and sufficient evidence that supports this claim and associated argument.
Figure 1 below illustrates how NEI 20-07 bridges the gap between the NRC regulatory framework and implementation level activities associated with development of HSSSR software.                                            Rationale - If the EPRI research provides the necessary and sufficient evidence in support of this claim and associated argument then, the NRC staff would need to perform a detailed review of the EPRI research in support of the NEI 20-07 endorsement.
NRC Regulatory Framework Alternate approach - Despite the best efforts to eliminate from further consideration a given digital I&C CCF via the implementation of hazard control measures (e.g.,
implementation of quality-related requirements), some residual defects may remain undetected and persist as latent defects within the platform or system. But as written, these statements imply that via the implementation of the NEI 20-07s SDOs, any potential residual defects are eliminated from further consideration (i.e., the residual risk is effectively Objective Criteria Software CCF First Principles                                                      retired). So an alternate method to provide the necessary and sufficient evidence to substantiate such a claim and associated argument could be via the application of the Testing criteria discussed in BTP 7-19, Section 3.1.2 (Use of (NEI 20-07)
Testing to Eliminate Potential Common-Cause Failure from Further Consideration). Specifically, demonstrating via the Application of SDOs                                                          Testing criteria that the residual risk associated with a CCF of a given platform software is effectively retired (i.e., equal to zero risk) after implementing the NEI 20-07s SDOs. In other words, if the residual risk of a CCF for a given platform software is effectively retired by implementing the NEI 20-07s SDOs then by definition, such a platform should be able to meet the testing criteria in Section 3.1.2 of BTP 7-19.
Otherwise, the residual risk would need to be assessed as part of the D3 analysis to be done by the licensee/vendor for Implementation Level                                                          the entire I&C architecture/system assessment.
(Evidence that SDOs are met)
© NEI 2021. All rights reserved.                                                                            nei.org 14
 
NEI 20-07, Draft C                                  DRAFT                                            May 2021 Figure 1 Connection Between NRC Regulatory Framework and Implementation Level Activities 6      First Principles of Protection Against Software CCF The first principles against software CCF represent a synthesis of EPRI research and industry best software design practices. The first principles listed in this section are considered complete and represent the starting point for decomposition of SDOs. They include the role software design defects play in the initiation of a systematic failure as well as first principle techniques to adequately address the effects of latent software design defects. The first principles of protection against software CCF will be achieved by executing the SDOs.
6.1      Software quality depends on complete and correct requirements, design, review, implementation, and testing Software quality depends on complete and correct requirements, design, review, implementation, and test. A software defect in an I&C system is an error of commission or omission that results in the related plant systems or components to not function or perform as required by the plant design.
6.1.1      Software design quality depends on requirements quality Software design depends largely on a complete and correct understanding of the functional and performance requirements of the affected plant systems and components. There is no method or combination of methods that can guarantee 100% complete and correct requirements for a digital-based system. However, requirements engineering methods may be applied with the appropriate rigor depending on the risks due to a requirements error.
6.1.2      Implementation quality depends on design quality and process rigor It is important to differentiate design quality from implementation quality because design is about decisions based on requirements and architecture while implementation is about realization of software elements based on the design. Design quality is also a function of how completely and correctly the design is expressed and reviewed. While implementation and test quality can be no greater than design quality, inadequate implementation and test quality can result in an incomplete or incorrect realization of the design.
There is no method or combination of methods than can guarantee 100% complete and correct software design and implementation. However, engineering methods can provide some measure of protection against an incomplete or incorrect design and such methods may be scaled and applied with appropriate rigor depending on the risk significance of the affected system elements.
6.2      Concurrent triggering conditions are required to activate a latent software defect Failures due to a latent defect in software are systematic failures in that a requirements error or omission, an incomplete or incorrect design, or an incomplete or incorrect implementation is a necessary ingredient, as well as the plant or system states that can reveal incomplete or incorrect requirements, design, or implementation. Undetected errors in requirements, design and implementation are called latent defects, and the plant or system states that manifest them (and result in failures) are called triggering conditions.
© NEI 2021. All rights reserved.                                                                    nei.org 15
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 When defective DI&C equipment is running in multiple segments of a system and the system does not function or perform correctly due to the latent defect when the system encounters the same plant or system conditions in multiple segments (i.e., a concurrent trigger), the result is a software CCF.
6.2.1    A common defect depends on the quality and commonality of the equipment                              Commented [A16]: These are not the only factors.
A common software defect is a single requirements, design or implementation error that is present in two or more system elements (e.g., subsystems, controllers, control segments, divisions, etc.). If the        Commented [A17]: There are also other types of common software defects.
defect is discovered during system design, test or operation, then it should be corrected. If the defect remains undiscovered (or uncorrected), then it is a latent defect.
6.2.2    A triggering condition depends on system conditions A latent defect is a requirements, design or implementation error that remains undiscovered because the actual system states or conditions applied or encountered during inspection, test and operations did not reveal it. System states and conditions can range from the plant process states (fluid, electrical, etc.)
to faulted conditions (and how they are managed) in the platform or application software.
When in service and system conditions arrive at a state when the latent defect causes an incorrect or incomplete functional response, or the defect causes the system to fail to meet performance requirements, then the defect is considered triggered. If actual system conditions are constrained to the same conditions applied or encountered during inspection, test and operations, and all defects discovered during those conditions are corrected, then any remaining latent defects will not be triggered.
6.2.3    A concurrent triggering condition depends on timing and commonality of system conditions If a latent defect is present in two or more system elements but each element is encountering different conditions, then the likelihood of it being triggered at the same time depends on how much difference there is in the conditions encountered by each element or how much time it takes for each element to encounter the same condition.
For example, a defect may be triggered in one element and detected/corrected in time before the same defect is triggered in another element that encounters the same conditions, provided there is enough time. In this case, the result is not a software CCF.
Note that two or more system elements that have the same latent defect and always encounter the same conditions at the same time will trigger the defect in all elements at the same time if the triggering conditions are encountered. In this case, the result is a software CCF.
6.3    The effects of a software CCF can be reduced by design First Principles 6.1 and 6.2 are focused on the concept of prevention (albeit without a 100% guarantee) as a means for protection against a software CCF. The principles of limitation, detection and response/recovery also provides means for protection against software CCF with an emphasis on reducing its effects.
© NEI 2021. All rights reserved.                                                                  nei.org 16
 
NEI 20-07, Draft C                                  DRAFT                                            May 2021 6.3.1    The plant systems or components affected by a software CCF can be limited by design The principle of limiting the number of plant systems or components that can be physically controlled or affected by a system or subsystem where a software CCF is not adequately prevented will, by design, limit the effects of the software CCF to just those systems or components.
For example, consider a system that applies the elements of one platform, and the system is composed of many control segments where each segment is provided with redundant elements, such as a main/backup pair of controllers. A software CCF of all control segments due to a latent defect in a platform element common to all segments is adequately prevented. However, a pair of controllers in an individual control segment do not encounter sufficiently different conditions such that a software CCF is not prevented within that segment. In this case, limiting the number of plant components per segment will limit the effects of a software CCF in one segment to just those components that are controlled by that segment.
6.3.2    An I&C system can be designed to force a preferred state in the event of a software CCF Software diagnostic features not subject to the software CCF can provide a means to detect and respond by forcing an I&C system to a preferred state in the event of software CCF. A preferred state may be fail-as-is, fail-off, shutdown, etc., with an attendant notification or alarm.
6.3.3    Detection of an event or condition due to a software CCF provides an opportunity for response and recovery Detection of a software CCF provides an opportunity to respond and recover from the event. If the software CCF occurs in a system that can initiate a plant event, or it occurs in a mitigating system that is required to respond to an initiating event, then independent means for detection and response via automation and/or manual action can terminate the sequence of events within acceptable limits.
6.4    Operating history can provide evidence of software quality Operating history can provide evidence of adequate software quality. The depth and rigor of acceptable operating history (e.g., relevant, successful, substantial, available errata, etc.) from all safety industries can also be scaled and matched to the risk of a software CCF in various system elements.
7    Scope and Applicability Although the technical guidance in this document may be applied to any system or component that contains software, the primary focus is on HSSSR DI&C systems. Risk insights from site-specific probabilistic risk assessments (PRAs) can be used to support the safety-significance determination in categorizing the DI&C system or component. Use of such risk insights should be an input to an integrated decision-making process for categorizing the proposed DI&C system or component. The two criteria below are additional inputs to consider in determining the high safety-significant categorization:
: 1. Safety-related SSCs relied upon to initiate and complete control actions essential to maintain plant parameters within acceptable limits established for a DBE; or
© NEI 2021. All rights reserved.                                                                      nei.org 17
 
NEI 20-07, Draft C                                    DRAFT                                  May 2021
: 2. Safety-related systems and equipment whose failure could directly lead to accident conditions that may cause unacceptable consequences (i.e., exceeds acceptable limits for a DBE) and no other safety-related systems or components are able to provide the safety function.
8    Software CCF Evaluation Process The software CCF evaluation process is illustrated in Figure 2.
HSSSR Digital System or Component Verify Platform Software Meets SDOs Provided in Section 9.0 Yes    Verify Application Software Application Software?            Meets SDOs Provided in Section 10.0 No Document Results in the Assurance Case Section 11.0 End Software CCF Evaluation Figure 2 HSSSR Software CCF Evaluation Process                                Commented [A18]: This process appears to have no option for inability to verify SDOs are met, yet there is an option for some not being met with justification (i.e. taking exceptions).
Section 9 below provides goals and SDOs for evaluating HSSSR platform software. Section 10 provides goals and SDOs for evaluating HSSSR application software. Section 11 describes the elements of an      That aspect of the process should be clarified (consider accompanying the figure with a description).
assurance case to clearly document adherence to the SDOs as well as any exceptions taken to the guidance in this document.                                                                              Additionally, it is not clear where a D3 analysis fits in with respect to addressing CCFs requiring D3 based on evaluation (or scope not covered in software CCF scope of NEI 20-07).
This should also be clarified and described.
© NEI 2021. All rights reserved.                                                            nei.org 18
 
NEI 20-07, Draft C                                    DRAFT                                              May 2021 9    Software at the Platform and Platform Integration Levels 9.1    Platform Software Systematic Capability EPRI report 3002011817, Safety Integrity Level (SIL) Certification Efficacy for Nuclear Power [4]
reviewed failure data associated with nine operating platforms with SIL 3 certification based on IEC 61508 criteria. The platforms reviewed had a cumulative operating history of over 1.6 billion hours (after SIL3 certification). The researchers found that for those cases where systematic failures caused the estimated field failure rate to exceed the predicted failure rate, the systematic failures typically resulted from manufacturing process issues, and in no cases did they result from software faults, including                Commented [A19]: This clause implies that occasionally the two characteristics are not comparable.
software common cause failures.. The report concluded that SIL certifications appear to be an accurate indicator of platform level reliability. If high reliability is achieved via the process of SIL 3 certification    What is or leads to the circumstance of significantly low failure then the converse can be assumed: low failure rates can be achieved. A software CCF needs a latent                rate and systematic capability being not comparable?
defect and will manifest itself when coincident with a trigger mechanism. A platform certified with a              What does NEI 20-07 put in place to ensure the two remain significant low failure rate is also certified in terms of systematic capability, and often the two are            comparable (assuming comparability is essential to the overall approach)?
comparable. The IEC 61508 standard provides means for assuring a quantifiable failure rate as well as a Commented [A20]: Should this statement be clarified to corresponding means for assuring confidence in systematic capability.                                              indicate the identified reliability target range applies only to low demand mode of operation?
When determining the achieved random capability (SIL) and systematic capability (SC) of a platform, the NOTE: IEC 61508-4 defines low demand mode of operation certifier determines the safe and dangerous failure modes of its functions. When a platform is applied,            as frequency of demands is no greater than one per year.
the designer is responsible for assuring any constraints in the platform certification are implemented in NOTE: Application of IEC 61508-4 in the process sector (per the applied functions in order to achieve the requisite random and systematic capability at the                    IEC 61511) includes life-cycle monitoring of both the observed application level. IEC 61508 defines 4 safety integrity levels, labeled from SIL 1 to SIL 4. SIL 3 is the          hazardous event demand rate and observed equipment unsafe failure rate to ensure design assumptions remain valid highest safety integrity level that is commonly necessary for the most safety significant industrial              for the risk reduction methods (e.g., allocated SIL) included in operations. SIL 3 certification involves the requirements for high levels of resistance to systematic              the design. NEI 20-07 does not include a SDO to address confirmation of similar design assumptions.
design failures.
Commented [A21]: Is the use of the following terms in these two paragraphs correct and clear?
The Platform OEM is responsible for determining the functional safety requirements, selecting certified              1. certifier equipment consistent with those requirements, and verifying the application achieves the necessary                    2. designer
: 3. Platform OEM random and systematic capability for the safety functions. Platform functions that are rated for SIL 3 operation can be used for high reliability targets of E-4 to <E-3 probability of failure on demand                These two paragraphs introduce these terms for roles, but in reading the paragraph their use and meaning is not clear and without redundancy.                                                                                                appears incorrect.
SIL ratings determine the functional safety requirements that need to be fulfilled. There are different            Is certifier the right word in first paragraph? Is this synonymous with Platform OEM (i.e. the original equipment recommendations for software development and design techniques based on SILs. The SIL and SC rating                manufacturer of the platform) is based on quantitative and qualitative factors such as the development process.                                    Understanding is that the Platform OEM submits for certification with a proposed SIL and supporting analysis, and the certifying body evaluates the analysis when EPRIs report on SIL certification [4] concludes that, SIL 3 (the second most rigorous of the four defined          certifying.
in IEC-61508) requirements, takes a deep look into the products hardware and software, as well as the            Is certifier intended to mean the one submitting the platform for certification (not the certifying body)?
projects functional safety management processes and documentation, to demonstrate the products safety integrity for performing safety functions. IEC-61508 provides objective and effective criteria to          Is the designer as used in the 1st paragraph, synonymous with system integrator or application system designer?
ensure functional safety. The EPRI report further states that, The SIL 3 certification process is rigorous          The responsibility to assure any constraints in the platform enough that many products fail a certification audit, at least the first time around (i.e., they do not            certification are implemented in the applied functions in order to achieve the requisite random and systematic achieve SIL 3 certification without needing some sort of design change). The most common type of                      capability at the application level indicate this is the case.
design change needed is an improvement in diagnostic coverage. Superior diagnostics, along with the Is Platform OEM the right word in 2nd paragraph?
associated programming to ensure the equipment is placed in a safe state once the diagnostics detect a                The description indicates the Platform OEM selects certified failure, drive the safe failure fraction up by converting dangerous undetected failures into safe detected            equipment and verifies the application. This would appear to be the system integrator or application system failures. This is often necessary to satisfy the SIL 3 failure rate requirements, as well as the SIL 3                designer unless it is strictly referring to components used within the platform.
&#xa9; NEI 2021. All rights reserved.                                                                        nei.org 19
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 architectural constraints. The SIL3 certification process is not an audit but rather a systematic and methodical assessment against the criteria of IEC 61508 by an accredited third party.
IEC 61508 describes Systematic Capability (SC) as a measure (expressed on a scale of SC 1 to SC 4) of the confidence that the systematic safety integrity of a device meets the requirements of the specified SIL, in respect of the specified safety function, when the device is applied in accordance with the instructions specified in the device safety manual. Systematic capability is determined with reference to the requirements for the avoidance and control of systematic faults. For a device comprised of hardware and software, the interactions between hardware and software failure mechanisms are considered.
The NRC Regulatory Guides and endorsed IEEE standards are intended to meet 10 CFR 50 Appendix B quality requirements. They are process criteria that when applied, allows the treatment of software CCF as a beyond design basis condition. The IEC 61508 standard not only provides quality process criteria, but also includes software design techniques and measures to assure sufficient systematic capability.
The quality process and the design techniques and measures are both applied at the platform level and application level. Applying this additional level of design techniques and measures in IEC 61508 can allow for the conclusion to be reached that a CCF sourced by a SIL3/SC3 certified platform does not need to be postulated.                                                                                            Commented [A22]: The additional level of design techniques and measures (for both platform and application) seems to be the key to a potential alignment between NRC A CCF is a type of systematic failure, and therefore, CCF is directly addressed by addressing systematic      staff and NEI.
capability. Based on the rigor of IEC 61508 SIL/SC3 certification to achieve sufficient systematic To potentially align, the following three questions are relevant:
capability and the results of the EPRI report, use of a platform certified to the requirements of SIL 3 and SC3 provides reasonable assurance that software CCF in the platform has been adequately addressed              1.Which (set)of design techniques and measures might staff accept, if any to conclude CCF sourced by a SIL3/SC3 and need not be considered a source.                                                                            certified platform does not need to be postulated?
Note that certification to the requirements of SIL 3 and SC3 is not enough to conclude a platform can be        2.Which design techniques and measures go beyond what current NRC regulations and guidance address?
used in a safety related application. The platform must meet applicable 10 CFR 50 Appendix B quality requirements as well as any specific environmental qualification requirements. Appendix B quality and          3.With respect to the supporting EPRI research, which were applied in the platforms evaluated (which seems necessary environmental qualification requirements are beyond the scope of this document.                                supporting technical basis)?
Commented [A23R22]: This comment is related to the 9.1.1    Goals                                                                                              staffs comment on the Executive Summary section regarding some of the diversity-related requirements in IEC 61508 that were not captured (or synthesized) in the NEI 20-07 SDOs.
The safe design objectives for platform software systematic capability are intended to achieve the Commented [A24]: Why is environmental qualification objectives or properties provided in the following clauses of IEC Std. 61508-3:                              requirements outside the scope of this document?
* 7.4.1 - Objectives                                                                                Based on the NEI 20-07 approach, a platform safety manual should include its environmentally qualified envelope, and the SIL certification of the equipment includes the platform
* 7.4.2 - General Requirements                                                                      hardware. The certified equipment envelope would need to be compatible with the plants environmental qualification requirements for the certification to hold. Furthermore, it
* 7.4.3 - Requirements for Software Architecture Design                                              appears that an evaluation of this compatibility would be performed by the application system designer before selecting the platform.
* 7.4.4 - Requirements for Support Tools, Including Programming Languages Any special environmental qualification tests (as additional evidence) may be seen as outside the scope of this
* 7.4.5 - Requirements for Detailed Design and Development - Software System Design                  document, but the requirements would appear to be within its scope.
* 7.4.6 - Requirements for Code Implementation
* 7.4.7 - Requirements for Software Module Testing
&#xa9; NEI 2021. All rights reserved.                                                                  nei.org 20
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021
* 7.4.8 - Requirements for Software Integration Testing
* 7.5.2 - Requirements for Programmable Electronics Integration (Hardware and Software)
* 7.7.2 - Requirements for Software Aspects of System Safety Validation
* 7.9.2 - Requirement for Software Verification 9.1.2  Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
* First Principle 6.4 - Operating history can provide evidence of software quality 9.1.3  Safe Design Objectives Safe design objectives for achieving platform software requirements quality are listed below:
9.1.3.1      The platform software, including user programmable integrated circuits (such as FPGA, CPLD, ASIC, etc.), meets or exceed a systematic capability of SC3 (as for a SIL 3 system) as described in IEC Std. 61508-3. If a platform does not have SC3 certification, the assurance case should demonstrate how the platform meets the SIL 3 criteria in IEC 61508-3.
9.1.3.2      The platform is used in the HSSSR system consistent with the SIL3/SC3 safety function certification and its safety manual.
9.2    Platform Software Integration within a System Architecture 9.2.1  Goals
* Platform software elements are described to the extent necessary to enable integration into a system, subsystem, or element
* When a platform software element is re-used or is intended to be re-used in other systems, information about the element is sufficiently precise and complete to support an assessment of the integrity of any safety functions that depend on the re-used element
* Platform software element attributes are defined, including hardware constraints or other software that must be accounted for during integration and application
* Platform software element properties are described in terms of what the element is designed for, including its intended behavior and characteristics 9.2.2  Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 21
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021
* First Principle 6.2 - Concurrent triggering conditions are required to activate a latent software defect
* First Principle 6.3 - The effects of a software CCF can be reduced by design 9.2.3    Safe Design Objectives 9.2.3.1      When platform software elements are integrated at the system level, subsystem level, or among other elements, they are integrated in accordance with a safety manual that complies with IEC 61508-2 Annex D or 61508-3 Annex D (for pre-existing platform software elements).
10 Software at the Application and Plant Integration Levels Similar to the arguments for why the IEC 61508 criteria applied to a platform can allow for the conclusion that a CCF sourced from the SIL3/SC3 certified platform is adequately addressed, the same IEC 61508 criteria is the source for the SDOs for application software, assuming the application software is executed on the certified platform. The SDOs are synthesized from the same IEC 61508-3 software            Commented [A25]: What is expected for alternate or requirements that are applied to SIL/SC certified platforms.                                                  equivalent techniques/measures where none is Highly Recommended but some are Recommended?
(e.g., 3a through 3g alternatives for SIL 3 in Annex A Table The process of synthesizing the IEC 61508-3 SIL3 requirements into SDOs involved evaluating the                A.2) standard criteria and converting them into objectives. The SDOs are primarily synthesized from IEC                Will at least one be of the Recommended alternatives be 61508-3, Clause 7. Some clauses are not exactly objective criteria. For example, Clause 7.2.2.1 states,          performed?
The first objective of the requirements of this subclause is to specify the requirements for safety-          What is expected for alternate or equivalent related software in terms of the requirements for software safety functions and the requirements for          techniques/measures where two or more are Highly software systematic capability. As a result, not all clauses are adaptable to an SDO.                        Recommended?
(e.g., 1a and 1b alternatives for SIL 3 in Annex A Table A.4)
The synthesizing process adapted the criteria to application software hosted on a platform. Some IEC              Will both of the Highly Recommended alternatives be performed?
61508-3 clauses may be combined into one SDO as part of the synthesis process.
What is expected for alternate or equivalent techniques/measures where it is Not Recommended?
There are some normative sections of IEC 61508-3 that were not synthesized into SDOs. One example is Clause 6. The reason Clause 6 was not synthesized into SDOs is because the underlying configuration              Will it be ensured that Not Recommended alternatives have not been applied?
management (CM) principles are not unique to software or digital in general.
Application of the Annex A tables state Appropriate techniques/measures shall be selected according to the safety There are two normative annexes in IEC 61508-3. Annex A is a set of techniques and measures related            integrity level. Alternate or equivalent techniques/measures to criteria in Clause 7 and are considered implementation approaches. The techniques in Annex A are            are indicated by a letter following the number. It is intended the only one of the alternate or equivalent indicated as either Not Recommended, Recommended, Highly Recommended, or silent on any                    techniques/measures should be satisfied. The choice of recommendation at all, depending on the SIL. It is expected that the assurance case will demonstrate          alternative technique should be justified in accordance with the use of the techniques, or variations with adequate justification, that are Highly Recommended for          the properties, given in Annex C, desirable in the particular application.
SIL3 when providing the argument and evidence to meet the applicable SDO associated with them.
Commented [A26]: What does this sentence mean?
Annex D establishes the requirements for a Safety Manual. Its perspective is commodity software such              The preceding sentence indicates that an application would not require a safety manual for its proper use.
as a PLC that would be used in multiple applications. Application software development is not about creating reusable elements that would require a safety manual for proper use. SDOs for a safety manual        Which SDO is there for a safety manual for application software?
for application software would essentially be all the other SDOs in NEI 20-07.
The only SDOs relating to a safety manual indicate the platform will have one (SDOs 9.1.3.2, 9.2.3.1). It is further understood that the application system designer will ensure a compliant use of the platform in accordance with all safety manuals for the equipment used in the system.
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 22
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 Demonstrating that the SDOs for the application software, hosted by the SIL3/SC3 hosted platform, have been met, can provide reasonable assurance that the application software will not be a source of CCF in a system.
10.1 Requirements Quality 10.1.1 Goals The safe design objectives for application software requirements quality are intended to achieve the following goals:
* Requirements correctly express system functions allocated to application software
* Requirements completely express system functions allocated to application software
* Application software requirements are unambiguous
* Application software requirements are understandable
* Application software requirements provide a basis for verification and validation
* When application software functions of different safety classifications are required in one system, independence between such software functions is expressly required (e.g., software functions within different safety classes do not interact or share data) 10.1.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
* First Principle 6.2 - Concurrent triggering conditions are required to activate a latent software defect
* First Principle 6.3 - The effects of a software CCF can be reduced by design 10.1.3 Safe Design Objectives Safe design objectives for achieving application software requirements quality are listed below:
10.1.3.1    Application software requirements are derived from, and backward traceable to, the functional and performance requirements of the affected plant systems and their design and licensing bases.
10.1.3.2    A hazard analysis method is used to identify hazardous control actions that can lead to an accident or loss, and application software requirements and constraints are derived from the identified hazardous control actions. The hazard analysis is focused on the system (not just the application software) and should consider plant-level and system-level functions and processes. The hazard analysis should include faults and failures as well as misbehaviors in the absence of any faults or failures.
&#xa9; NEI 2021. All rights reserved.                                                                  nei.org 23
 
NEI 20-07, Draft C                                  DRAFT                                      May 2021 10.1.3.3    The application software requirements resulting from activities performed under SDOs 10.2.3.1 and 10.2.3.2 are sufficiently detailed to support an assessment of functional safety.
10.1.3.4    Hardware constraints on the application software are specified and complete.
10.1.3.5    Application software functional and performance requirements are decomposed from I&C system requirements, the I&C system architecture, and any constraints imposed by the I&C system design.
10.1.3.6    If application software requirements are expressed or implemented via configuration parameters, the specified parameters and their values are consistent and compatible with the I&C platform and the I&C system requirements.
10.1.3.7    If data communications are required between application software elements and/or between application software elements and external systems, data requirements are specified, including best- and worst-case performance requirements. Best-case performance is based on ideal conditions. Worst-case performance is based on conservative assumptions of conditions (e.g., communication retries).
10.2 Application Software General Quality 10.2.1 Goals The safe design objectives for application software general quality are intended to achieve the following goals:
* The application software design fulfills the specified requirements
* Application software requirements imposed by the hardware architecture are fulfilled, including hardware/software interactions that influence the safety of the equipment under control
* The tools, languages, compilers, run-time system interfaces, user interfaces, and data formats are suitable, and assist in verification and validation activities
* The application software is analyzable and verifiable, and is capable of being safely modified
* The required safety functions designed and implemented via application software are achieved and verified 10.2.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
* First Principle 6.4 - Operating history can provide evidence of software quality 10.2.3 Safe Design Objectives
&#xa9; NEI 2021. All rights reserved.                                                                nei.org 24
 
NEI 20-07, Draft C                                            DRAFT                                                May 2021 Safe design objectives for achieving application software general quality are listed below:
10.2.3.1      When the application software can include or affect a number and/or variety of system elements, and responsibilities for application software design of such elements are split among two or more organizational entities1, then a clear division of responsibility (DOR) is developed and agreed upon by all entities, and the DOR is maintained throughout the course of application software development activities.
10.2.3.2      Abstraction and modularity are used to control complexity in the application software design.
10.2.3.3      The application software design method aids the expression of functions; information flow; time and sequencing information; timing constraints; data structures and properties; design assumptions and dependencies; exception handling; comments; ability to represent structural and behavioral views; comprehension by organizational entities who need to understand the design; and verification and validation.
10.2.3.4      Testability and modifiability in the operations and maintenance phase of the system lifecycle is considered during application software design.
10.2.3.5      The application software design method has features that support software modification, such as modularity, information hiding, and encapsulation.
10.2.3.6      Application software design notations are clearly and unambiguously defined.
10.2.3.7      The application software design elements are simple to the extent practicable.
10.2.3.8      The application software design includes self-monitoring of control flow and data flow, and on failure detection, appropriate actions are taken.
10.2.3.9      Application software elements of varying safety classifications shall all be treated as the highest safety classification unless adequate independence between elements of different safety classifications is justified.
10.2.3.10      When a pre-existing application software element is used to implement a system function, it meets the SDOs in Section 10.
10.2.3.11      When the digital equipment consists of pre-existing functionality that is configured via data to meet application-specific requirements, the applied configuration design is consistent with the design of the equipment. Methods are used to prevent errors during design and implementation of the configuration data using specified configuration data structures.
10.3 Application Software Architecture Design Quality 10.3.1 Goals 1 An organizational entity is either a group of people within a corporate structure or a separate corporate entity.
&#xa9; NEI 2021. All rights reserved.                                                                                    nei.org 25
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 The safe design objectives for application software architecture design quality are intended to achieve the following goals:
* The application software architecture design is complete and correct with respect to application software requirements
* The application software architecture design supports freedom from intrinsic design faults
* The method of expressing the application software architecture design promotes simplicity and understandability
* The application software architecture design promotes predictable behavior
* The application software architecture design promotes verifiable and testable design
* The application software architecture design promotes fault tolerance
* The application software architecture design provides defense against common cause failure from external events 10.3.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
* First Principle 6.2 - Concurrent triggering conditions are required to activate a latent software defect
* First Principle 6.3 - The effects of a software CCF can be reduced by design 10.3.3 Safe Design Objectives Safe design objectives for achieving application software architecture design quality are listed below:
10.3.3.1    The application software architecture design uses an integrated set of techniques necessary to meet the functional and performance requirements developed via the SDOs in Section 0.
10.3.3.2    Application software architecture design is partitioned into elements or subsystems, and information about each element or subsystem provides verification status and associated conditions.
10.3.3.3    Application software architecture design determines hardware/software interactions unless already specified by the system architecture.
10.3.3.4    Application software architecture design uses a notation that is unambiguously defined or constrained to unambiguously defined features.
&#xa9; NEI 2021. All rights reserved.                                                                  nei.org 26
 
NEI 20-07, Draft C                                    DRAFT                                          May 2021 10.3.3.5      Application software architecture design determines the features needed for maintaining the integrity of safety significant data, including data at rest and data in transit.
10.3.3.6      Appropriate software architecture integration tests are specified.
10.4 Application Software Support Tool and Programming Language Quality 10.4.1 Goals The safe design objectives for application software support tool and programming language quality are intended to achieve the following goals:
* Tools support the production of the application software and its required characteristics
* Tool operation and functionality is clear
* Tool output is correct and repeatable 10.4.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
* First Principle 6.4 - Operating history can provide evidence of software quality 10.4.3 Safe Design Objectives Safe design objectives for achieving application software tool and programming language quality are listed below:
10.4.3.1      Application software is supported by on-line and off-line support tools. Off-line support tools are classified in terms of their direct or indirect potential impacts to the application software executable code.
10.4.3.2      An application software on-line support tool is an element of the system under design.
10.4.3.3      Application software off-line support tools are an element of development activities and are used to reduce the likelihood of errors, and to reduce the likelihood of not detecting errors.
When off-line tools can be integrated, the outputs from one tool are suitable for automatic input to a subsequent tool to minimize the likelihood of human error.
10.4.3.4      Offline tools have specified behaviors, instructions, and any specified constraints when 1) they can directly or indirectly contribute to the executable code, or 2) they are used to support the test or verification of the design or executable code where errors in the tool can fail to reveal defects.
10.4.3.5      Offline tools are assessed for the reliance placed on them and their potential failure mechanisms that may affect the executable application software when 1) they directly or indirectly contribute to the executable code, or 2) they are used to support the test or
&#xa9; NEI 2021. All rights reserved.                                                                      nei.org 27
 
NEI 20-07, Draft C                                  DRAFT                                            May 2021 verification of the design or executable code where errors in the tool can fail to reveal defects.
10.4.3.6    Offline tool conformance to its documentation may be based on a combination of history of successful use (in similar environments and for similar applications) and its validation.
10.4.3.7    Tools are validated with a record of their versions, validation activities, test cases, results, and any anomalies.
10.4.3.8    When a set of tools can function by using the output from one tool as input to another tool then the set is regarded as integrated and they are verified to ensure compatibility.
10.4.3.9    The application software design representation or programming language uses a translator that is assessed for suitability at the point when development support tools are selected.
The suitability assessment evaluates qualities such as the use of defined language features, support for detection of mistakes, and support for the design method for the project.
10.4.3.10  If SDO 10.4.3.9 is not fully demonstrated, then the fitness of the language and any measures to address identified shortcomings is justified.
10.4.3.11  Programming languages for developing application software are used per a suitable set of rules which specify good practice, prohibit unsafe features, promote understandability, facilitate verification and validation, and specify code documentation requirements.
10.4.3.12  When offline tools are used, the application software configuration baseline information includes tool identification and version, traceability to the application software configuration items produced or affected by the tool, and the manner in which the tool was used, when 1) the tool can directly or indirectly contribute to the executable code, or 2) the tool is used to support the test or verification of the design or executable code where errors in the tool can fail to reveal defects.
10.4.3.13  Offline tools are under configuration management to ensure compatibility with each other and the system under design, and only qualified versions are used, when 1) the tool can directly or indirectly contribute to the executable code, or 2) the tool is used to support the test or verification of the design or executable code where errors in the tool can fail to reveal defects.
10.4.3.14  Qualification of each new version of an offline tool may be demonstrated by qualification of an earlier version if the functional differences will not affect compatibility with other tools, and evidence shows that the new version is unlikely to contain significant faults. The evaluation that the new version is unlikely to contain significant faults includes identifying the changes made for the revision, a review of the verification and validation activities performed on the revision, and review of any relevant operating experience with the revised version.
10.5 Application Software Detailed Design and Development Quality 10.5.1 Goals
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 28
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 The safe design objectives for application software detailed design and development quality are intended to achieve the following goals:
* The application software detailed design and development is complete and correct with respect to application software requirements developed per Section 0
* The application software detailed design and development demonstrates freedom from intrinsic design errors
* The method of expressing application software detailed design promotes understandability
* The application software detailed design demonstrates predictable behavior
* The application software detailed design is verifiable and testable
* The application software detailed design demonstrates fault tolerance / fault detection 10.5.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
* First Principle 6.2 - Concurrent triggering conditions are required to activate a latent software defect
* First Principle 6.3 - The effects of a software CCF can be reduced by design 10.5.3 Safe Design Objectives Safe design objectives for achieving application software detailed design and development quality are listed below:
10.5.3.1      Information items that describe application software requirements, architecture design, and validation planning are completed prior to application software detailed design and implementation activities and are used to inform the detailed design and its implementation.
10.5.3.2      The application software is modular, testable, and modifiable.
10.5.3.3      For each major element or subsystem identified in the application software architecture design produced via the SDOs provided in Section 10.2.3, further refinement into application software modules is based on partitioning, and modules are designed in sets suitable for integration and integration testing at the software and system levels.
10.5.3.4      Application software integration tests and software/hardware integration tests ensure conformance to the requirements produced under the SDOs in Section 0.
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 29
 
NEI 20-07, Draft C                                DRAFT                                        May 2021 10.6 Application Software Implementation Quality 10.6.1 Goals The goals for application software implementation quality are as follows:
* The method of expressing the application software implementation is readable, understandable, and testable.
* The application software implementation is performed using the results of SDO 10.4.3.11.
* The application software implementation satisfies the design resulting from the SDOs provided in Section 10.5 10.6.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation 10.6.3 Safe Design Objectives Safe design objectives for achieving application software implementation quality are listed below:
10.6.3.1    Each application software module is reviewed against the goals listed above.
10.6.3.2    When an application software module is produced by an automatic tool, the SDOs provided in Section 10.4 are demonstrated.
10.6.3.3    When an application software module consists of reused pre-existing software, SDO 10.2.3.10 is demonstrated.
10.7 Application Software Module Test Quality 10.7.1 Goals The goals for application software module test quality are as follows:
* Completeness of module testing with respect to the application software design
* Correctness of module testing with respect to the application software design specification
* Module testing is repeatable
* The module testing configuration is precisely defined 10.7.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
&#xa9; NEI 2021. All rights reserved.                                                              nei.org 30
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 10.7.3 Safe Design Objectives Safe design objectives for achieving application software module test quality are listed below:
10.7.3.1    Each application software module is verified (as specified via SDO 10.4.3.5) to perform its intended function and does not perform unintended functions.
10.7.3.2    Application software module testing results are documented.
10.7.3.3    If an application software module test is not successful, corrective actions are specified.
10.8 Application Software Integration Test Quality 10.8.1 Goals The goals for application software integration test quality are as follows:
* Completeness of integration testing with respect to the application software design
* Correctness of integration testing with respect to the application software design specification
* Integration testing is repeatable
* The integration testing configuration is precisely defined 10.8.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation 10.8.3 Safe Design Objectives Safe design objectives for achieving application software integration test quality are listed below:
10.8.3.1    Using the results of activities performed under SDO 10.5.3.4, application software integration testing is performed using specified test cases, and test data; in a specified and suitable environment; with specified acceptance criteria.
10.8.3.2    Application software integration tests demonstrate correct interaction between all application software modules and/or application software elements/subsystems.
10.8.3.3    Application software integration testing information includes whether test acceptance criteria have been met, and if not, the reasons why such that corrective actions are specified.
10.8.3.4    During application software integration, any module changes are analyzed for extent of 1) impact to other modules and 2) rework of activities performed under prior SDOs.
&#xa9; NEI 2021. All rights reserved.                                                                  nei.org 31
 
NEI 20-07, Draft C                                  DRAFT                                            May 2021 10.9 System Integration Quality 10.9.1 Goals The goals for I&C system integration and test quality are as follows:
* Application software and system hardware are combined in a mutually compatible manner
* System integration is complete and correct with respect to design specifications
* System integration is repeatable
* The integrated system configuration is precisely defined 10.9.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
* First Principle 6.2 - Concurrent triggering conditions are required to activate a latent software defect
* First Principle 6.3 - The effects of a software CCF can be reduced by design 10.9.3 Safe Design Objectives Safe design objectives for achieving system integration and test quality are listed below:
10.9.3.1    Application software is integrated with the system hardware in accordance with SDO 10.9.3.2.
10.9.3.2    Using the results of activities performed under SDO 10.5.3.4, system integration testing is performed using specified test types, test cases, and test data; in a specified facility with a suitable environment; using specified software and hardware integration instructions; and with specified acceptance criteria.
10.9.3.3    System integration testing information includes whether test acceptance criteria have been met, and if not, the reasons why such that corrective actions are specified. During application software integration, any module changes are analyzed for extent of 1) impact to other modules and 2) rework of activities performed under prior SDOs.
10.10 System Validation Quality 10.10.1 Goals The goals for system validation quality in the context of application software functions are as follows:
* The integrated system complies with the requirements developed via activities under the SDOs provided in Section 0
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 32
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021
* System validation is complete and correct with respect to design specifications
* System validation is repeatable
* The validation configuration is precisely defined 10.10.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation 10.10.3 Safe Design Objectives Safe design objectives for achieving system validation quality in the context of application software functions are listed below:
10.10.3.1    System validation procedural and technical steps are specified in order to demonstrate the application software meets the requirements produced via activities performed under the SDOs in Section 0.
10.10.3.2    System validation information includes a chronological record of activities; the validated functions; tools and equipment used; results; and any anomalies - including the reasons why so that corrective actions are specified.
10.10.3.3    For application software, system testing is the primary method of validation, and the system is tested by exercising inputs; exercising expected conditions (both normal and abnormal);
and exercising hazards that require system action (as identified via activities performed under SDO 10.1.3.2). Analysis, modeling, and simulation may supplement system testing.
10.10.3.4    Tools used for system validation meet the SDOs provided in Section 10.4.
10.10.3.5    System validation results demonstrate 1) all application software functions required via activities performed under the SDOS in Section 2.1 are met correctly, 2) the application software does not perform unintended functions, 3) test case results information for later analysis or assessment, and 4) successful validation, or if not, the reasons why.
10.11 Application Software Verification Quality 10.11.1 Goals The goals for application software verification quality are as follows:
* Verification is complete and correct with respect to the results of activities performed under the SDOs in Sections 0 and 10.3 through 10.9, unless such results are already demonstrated via validation activities under the SDOs in Section 10.10
* Verification is repeatable
* The verification configuration is precisely defined
&#xa9; NEI 2021. All rights reserved.                                                                  nei.org 33
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 10.11.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation 10.11.3 Safe Design Objectives Safe design objectives for achieving application software verification quality are listed below:
10.11.3.1    Application software verification activities are specified: selection of strategies and techniques; selection and utilization of tools; evaluation of results; and corrective action controls.
10.11.3.2    Evidence of application software verification activities is recorded, including verified application software configuration items; information used during verification; and the adequacy of results from activities conducted under prior SDOs, including compatibilities between prior activities.
10.11.3.3    Application software functional and performance requirements produced via activities under the SDOs in Section 0 are verified against the I&C system requirements that are identified via SDO 10.1.3.
10.11.3.4    The results of activities performed under the SDOs in Sections 10.2 through 10.6 are verified to ensure conformance to the requirements produced via activities performed under the SDOs in Section 0, as well as completeness, consistency, and compatibility between the results of the activities performed under the SDOs within each Section, and the feasibility, readability, and modifiability of the results produced under the activities of SDOs in each section.
10.12 Protection Against Concurrent, Untested Triggering Conditions 10.12.1 Goals The goals for protection against concurrent, untested triggering conditions in the context of application software are as follows:
* The number of latent defects in the application software are minimal via preceding SDOs
* Plant and/or plant system conditions that can trigger potentially hazardous behavior in an application software element are identified, then mitigated in the I&C system design
* Concurrent, untested triggering conditions among I&C system elements that have identical application software elements have no impact on those system elements 10.12.2 Associated First Principles of Protection Against Software CCF
* First Principle 6.1 - Software quality depends on complete and correct requirements, design and implementation
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 34
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021
* First Principle 6.2 - Concurrent triggering conditions are required to activate a latent software    Commented [A27]: Can NEI provide more information on what is meant by causal factor scenarios? is this akin to defect                                                                                                identifying CCF vulnerabilities?
Since 10.1.3.2 is a global analysis, are the mitigating actions 10.12.3 Safe Design Objectives                                                                                limited only to the scope of NEI 20-07 or do these mitigating actions extend to the system architecture?
Safe design objectives for achieving protection against concurrent, untested triggering conditions in the      Commented [A28]: This additional guidance is not sufficient context of application software are as follows:                                                                for the following reasons:
1.The level of detail does not provide an adequate 10.12.3.1    For each potentially hazardous control action identified via activities performed under SDO                  level of content to suggest a viable path forward.
10.1.3.2, causal factor scenarios related to the application software are identified and                    2.This section does NOT provide a minimum level of diversity (i.e. a floor) of diversity that would be mitigated.                                                                                                  sufficient.
3.Theres not objective criteria provided here to evaluated against to determine if youve 10.12.3.2    Analysis demonstrates that untested combinations of external and internal I&C system                        incorporated a minimum level of diversity states have no impact on achieving the application software functional and performance                          a.If you chose to incorporate diversity, theres no requirements resulting from the SDOs provided in Section 0.                                                    criteria to evaluated against.
4.There is no mechanism described that ensures diversity would be incorporated.
10.12.3.3    When equipment under the control (EUC) of the I&C system is normally in the state needed These aspects are important to ensure that the processes in to perform a safety function, the I&C system design has no inputs that will change state        NEI 20-07 are consistent with the policy statements in SECY when the EUC is in its normal state, and non-normal states in the EUC are readily detectable    93-087 which is clear that quality and diversity are necessary components of defense in depth.
via means independent of the application software controlling the EUC. Administrative controls limit the duration of non-normal EUC states and limit the EUC in a non-normal state    Commented [A29]: Do not believe this is an accurate statement in light of considerations such as GDC 22 which to one channel or division.                                                                      specifically talks of functions diversity.
Also this sentence appears to imply that an analog I&C plant 11 Diversity                                                                                                  did not consider systemic failures which is not true, see statement above.
Existing nuclear power plants have a defense-in-depth design. For those plants that do not have an            Commented [A30]: Attaching the application of diversity to HSSSR digital system, the defense-in-depth design did not consider the potential systematic failure of        completion of the hazard analysis seems to be a good place to start.
the HSSSR digital system. When an HSSSR system is replaced with digital technology, a method for                                    1.Because Section 11 does not constitute a analyzing potential systematic failures of the digital HSSSR system is required. The HSSSR system hazard                            safe design objective, there is no true connectivity here to the referenced analysis required by SDO 10.1.3.2 involves analyzing the HSSSR potential systematic failures. An                                    SDO10.1.3.2. If Diversity aspects were important aspect of the HSSSR system hazard analysis is identifying HSSSR systematic misbehaviors in                                SDOs, then this reference would make more the absence of any HSSSR faults and failures. The results of such a systematic approach to a hazard                                logical sense.
2.If a licensee chooses to incorporate analysis identifies HSSSR systematic failures that can rise to a CCF.                                                              diversity:
: a. What is the criteria that is used to do so?
For each systematic failure identified in the hazard analysis under SDO 10.1.3.2, control methods are                                  b.If diversity is used, how does that fit determined to avoid the hazard. While implementing the SDOs in Section 10.12.3 or control methods                                      within the 20-07 processes?              ... [2]
identified to address HSSSR systematic failures in the hazard analysis under SDO 10.1.3.2, diversity may      Commented [A31]: When control methods are developed, be selected as one attribute of the control method.                                                            do they get converted into SDOs or are they considered independent of NEI 20-07?
12 Assurance Case Development                                                                                  With regard to configuration management -
1.What mechanism in NEI 20-07 tracks the creation of The Assurance Case is used to document adherence to platform and application software SDOs such                    control methods?
that an auditor or inspector can clearly discern how each SDO was applied and how the software 2.Does NEI 20-07 cover the circumstance or provide development complies with the first principles of protection against software CCF. Any exceptions taken            guidance for a licensee that chooses to deviate from the    ... [3]
to application of SDOs should be clearly documented with an explanation of why the excluded SDO was            Commented [A32]: Should this be achieved or met?
not applicable or essential to software development quality. Appendix B provides a suggested roadmap It doesnt seem that one applies an objective. Rather it seems for developing the assurance case.                                                                            that the design techniques and measures (such as those in IEC 61508-3 Annex A for SIL 3 software) are applied in order to achieve SDOs. This understanding is consistent with the paragraph that follows.
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 35
 
NEI 20-07, Draft C                                DRAFT                                          May 2021 IEC 61508-3 Annex A is a set of techniques related to the SDOs and are considered implementation approaches. The techniques in Annex A are indicated as either Not Recommended, Recommended, Highly Recommended, or silent on any recommendation at all, depending on the SIL. It is expected that the assurance case will demonstrate the use of the techniques, or variations with adequate justification, that are Highly Recommended for SIL3 when providing the argument and evidence to meet the applicable SDO associated with them.                                                                    Commented [A33]: See comment to 5th paragraph of Section 10.
13 Summary and Conclusion Creating an HSSSR system using a SIL3/SC3 platform with application software developed in accordance        Commented [A34]: The EPRI report identified that there were non-random systematic failures in the hardware. Should with the SDOs provides reasonable assurance that this aspect of the HSSSR system will not be a source      we be worrying about hardware CCFs when using SIL 3 of software CCF. An HSSSR system D3 analysis is still required to assess the system as a whole and          certified hardware? If not, why not?
identify other CCF vulnerabilities. Examples of other CCF vulnerabilities include the use of data communications and any external hazards that could impact multiple redundancies of the HSSSR system.
14 References
: 1. 10 CFR Part 50, Appendix A, General Design Criteria for Nuclear Power Plants
: 2. 10 CFR Part 50, Appendix B, Quality Assurance Criteria for Nuclear Power Plants and Fuel Reprocessing Plants
: 3. IEC 61508, Edition 2.0, 2010-04, Functional Safety of Electrical/Electronic/Programmable Electronic Safety Related Systems
: 4. EPRI Report 30020011817, Final Report Dated July 2019; Safety Integrity Level (SIL) Certification Efficacy for Nuclear Power
: 5. EPRI 2018 Technical Report 3002011816, Digital Engineering Guide, Decision Making Using Systems Engineering
: 6. IEC 61513, Edition 2.0, 2011-08, Nuclear Power Plants - Instrumentation and Control Important to Safety - General Requirements for Systems
: 7. STPA Handbook, Nancy G. Leveson and John P. Thomas, March 2018
: 8. ISO/PAS 21448:2019, Road Vehicles - Safety of The Intended Functionality, International Organization for Standardization
: 9. EPRI Report 1019183, Effects of Digital Instrumentation and Control Defense-in-Depth and Diversity on Risk in Nuclear Power Plants
: 10. EPRI Report 3002005326, Methods for Assuring Safety and Dependability when Applying Digital Instrumentation and Control Systems
&#xa9; NEI 2021. All rights reserved.                                                                nei.org 36
 
NEI 20-07, Draft C                                DRAFT                                          May 2021 Appendix A: Connection Between Software CCF First Principles and NRC Regulatory Framework This Appendix describes the relationship between the first principles of protection against software CCF and the NRC regulatory framework. The first principles are defined in detail in Section 6. For each first principle below the associated NRC regulatory requirements are identified.
Note that the regulations listed below may not necessarily apply to all applicants and licensees. The applicability of the regulatory requirements is determined by the plant-specific licensing basis and any proposed changes to the licensing basis associated with the proposed DI&C system under evaluation.
: 1. Software quality depends on complete and correct requirements, design, review, implementation, and testing
: a. Design quality depends on complete and correct requirements Commented [A35]: The explanation under each seems very repetitive. Furthermore, this document does not explain in The following regulatory requirements are related to complete and correct requirements for HSSSR            what way it augments existing guidance or in what way it systems:                                                                                                    supports an overall safety case. As explained in Appendix B below, a safety assurance Case is based on claims being supported by arguments and evidence. Specifically, in what
* 10 CFR 50.54(jj), 10 CFR 50.55a(h) - IEEE 603-1991 or IEEE 279 -1971 as incorporated by reference      way is support provided?
requires, in part, that components and modules shall be designed, manufactured, inspected,            Commented [A36]: This requirement is not the requirement installed, tested, operated, and maintained in accordance with a prescribed quality assurance          that imposes a QA program on licensees.
program.                                                                                              Should also probably reference 10 CFR 50.55(i).
SDOs synthesized from IEC 61508-3 for application software for complete and correct requirements      The intent of these two requirements is the same as the intent (requirements quality) in NEI 20-07 augment the current set of NRC regulatory guidance for            of the first sentence of GDC 1.
requirements development to meet these regulatory criteria. This and the application of IEC 61508      Commented [A37]: A single requirement in each of these criteria on the platform hosting the application software support an overall safety case to            STDs does state that the applicable systems are developed in accordance with a QA program, but single requirements are adequately address CCF sourced from either the platform or its hosted application software in the      not the ones that impose a QA program. So effectively, HSSSR DI&C system architecture.                                                                        referencing these STDs as the basis for programmatic quality requirements is inappropriate.
Commented [A38]: The SDOs do not appear to add
* 10 CFR Part 50, Appendix A General Design Criteria (GDC)                                            anything that is not already addressed by existing set of guidance.
      -    GDC 1, Quality Standards and Records - states, in part, that Structures, systems, and        Commented [A39]: This statement is inconsistent with the components important to safety shall be designed, fabricated, erected, and tested to quality    content of the document:
9.1.3 Safe Design Objectives standards commensurate with the importance of the safety functions to be performed.            Safe design objectives for achieving platform software requirements quality are listed below:
Since HSSSR systems are considered of high significance regarding the importance of safety      9.1.3.1 The platform software, including user programmable functions to be performed, this GDC applies. SDOs synthesized from IEC 61508-3 for              integrated circuits (such as FPGA, CPLD, ASIC, etc.), meets or exceed a systematic capability of SC3 (as for a SIL 3 application software for complete and correct requirements (requirements quality) in NEI 20-    system) as described in IEC Std. 61508-3. If a platform does 07 augment the current set of NRC regulatory guidance for requirements development to            not have SC3 certification, the assurance case should demonstrate how the platform meets the SIL 3 criteria in IEC meet this GDC. This and the application of IEC 61508 criteria on the platform hosting the        61508-3.
application software support an overall safety case to adequately address CCF sourced from      9.1.3.2 The platform is used in the HSSSR system consistent either the platform or its hosted application software in the HSSSR DI&C system architecture. with the SIL3/SC3 safety function certification and its safety manual.
GDC 1 also states, in part, Where generally recognized codes and standards are used, they      Specifically only some of the criteria in IEC 61508 are applied in the document.
shall be identified and evaluated to determine their applicability, adequacy, and sufficiency Commented [A40]: Please explain how and in more detail.
and shall be supplemented or modified as necessary to assure a quality product in keeping with the required safety function.                                                              Commented [A41]: The reasoning in this statement is confused. This GDC applies because HSSSR are part of the systems important to safety.
Commented [A42]: Where is the documented evaluation?
&#xa9; NEI 2021. All rights reserved.                                                                nei.org 37
 
NEI 20-07, Draft C                                DRAFT                                          May 2021 NEI 20-07 credits the SIL 3 certification of platforms based on IEC 61508 and establishes SDOs synthesized from IEC 61508-3 for application software to support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture. IEC 61508 is a recognized standard by non-nuclear safety related industries (e.g., oil & gas industry and petrochemical processing industry).
GDC 1 also states, in part, A quality assurance program shall be established and implemented in order to provide adequate assurance that these structures, systems, and components will satisfactorily perform their safety functions. Appropriate records of the design, fabrication, erection, and testing of structures, systems, and components important to safety shall be maintained by or under the control of the nuclear power unit licensee throughout the life of the unit.
SDOs synthesized from IEC 61508-3 for application software for complete and correct requirements (requirements quality) in NEI 20-07 augment the current set of NRC regulatory guidance for requirements development to meet this GDC. This and the application of IEC 61508 criteria on the platform hosting the application software support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
      -  GDC 13, Instrumentation and Control states, Instrumentation shall be provided to monitor variables and systems over their anticipated ranges for normal operation, for anticipated operational occurrences, and for accident conditions as appropriate to assure adequate safety, including those variables and systems that can affect the fission process, the integrity of the reactor core, the reactor coolant pressure boundary, and the containment and its associated systems. Appropriate controls shall be provided to maintain these variables and systems within prescribed operating ranges.
The HSSSR system requirements development needs to address the functional requirements stated in this GDC. SDOs synthesized from IEC 61508-3 for application software for complete        Commented [A43]: This document should not try to state the applicability of regulatory requirements and principle and correct requirements (requirements quality) in NEI 20-07 augment the current set of NRC        design criteria of the facility; it will only create problems and is regulatory guidance for requirements development to meet this GDC. This and the application        not needed.
of IEC 61508 criteria on the platform hosting the application software support an overall          Furthermore, this document does not include or address safety case to adequately address CCF sourced from either the platform or its hosted              specific functional requirements; therefore, eliminate application software in the HSSSR DI&C system architecture.                                        regulatory requirements and GDCs that impose functional requirements from this appendix.
Commented [A44]: This is already an Appendix B
      -  GDC 19, Control Room states, in part, Equipment at appropriate locations outside the            requirement.
control room shall be provided (1) with a design capability for prompt hot shutdown of the reactor, including necessary instrumentation and controls to maintain the unit in a safe condition during hot shutdown, and (2) with a potential capability for subsequent cold shutdown of the reactor through the use of suitable procedures.
The scope of NEI 20-07 is HSSSR DI&C systems and these systems need to meet this GDC. The HSSSR system requirements development needs to address the functional requirements stated in this GDC. SDOs synthesized from IEC 61508-3 for application software for complete and correct requirements (requirements quality) in NEI 20-07 augment the current set of NRC regulatory guidance for requirements development to meet this GDC. This and the application of IEC 61508 criteria on the platform hosting the application software support an overall
&#xa9; NEI 2021. All rights reserved.                                                                  nei.org 38
 
NEI 20-07, Draft C                                DRAFT                                            May 2021 safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
      -  GDC 20, Protection System Functions states, The protection system shall be designed (1) to initiate automatically the operation of appropriate systems including the reactivity control systems, to assure that specified acceptable fuel design limits are not exceeded as a result of anticipated operational occurrences and (2) to sense accident conditions and to initiate the operation of systems and components important to safety.
The scope of NEI 20-07 is HSSSR DI&C systems and these systems need to meet this GDC. The HSSSR system requirements development needs to address the functional requirements stated in this GDC. SDOs synthesized from IEC 61508-3 for application software for complete and correct requirements (requirements quality) in NEI 20-07 augment the current set of NRC regulatory guidance for requirements development to meet this GDC. This and the application of IEC 61508 criteria on the platform hosting the application software support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
      -  GDC 21, Protection System Reliability and Testability states, The protection system shall be designed for high functional reliability and inservice testability commensurate with the safety functions to be performed. Redundancy and independence designed into the protection system shall be sufficient to assure that (1) no single failure results in loss of the protection function and (2) removal from service of any component or channel does not result in loss of the required minimum redundancy unless the acceptable reliability of operation of the protection system can be otherwise demonstrated. The protection system shall be designed to permit periodic testing of its functioning when the reactor is in operation, including a capability to test channels independently to determine failures and losses of redundancy that may have occurred.
The scope of NEI 20-07 is HSSSR DI&C systems and these systems need to meet this GDC. The HSSSR system requirements development needs to address the design requirements stated in this GDC. SDOs synthesized from IEC 61508-3 for application software for complete and correct requirements (requirements quality) in NEI 20-07 augment the current set of NRC regulatory guidance for requirements development to meet this GDC. This and the application of IEC 61508 criteria on the platform hosting the application software support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
      -  GDC 25, Protection System Requirements for Reactivity Control Malfunctions states, The protection system shall be designed to assure that specified acceptable fuel design limits are not exceeded for any single malfunction of the reactivity control systems, such as accidental withdrawal (not ejection or dropout) of control rods.
The scope of NEI 20-07 is HSSSR DI&C systems and these systems need to meet this GDC. The HSSSR system requirements development needs to address the functional requirements stated in this GDC. SDOs synthesized from IEC 61508-3 for application software for complete and correct requirements (requirements quality) in NEI 20-07 augment the current set of NRC regulatory guidance for requirements development to meet this GDC. This and the application
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 39
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 of IEC 61508 criteria on the platform hosting the application software support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
      -  GDC 28, Reactivity Limits states, The reactivity control systems shall be designed to have a combined capability, in conjunction with poison addition by the emergency core cooling system, of reliably controlling reactivity changes to assure that under postulated accident conditions and with appropriate margin for stuck rods the capability to cool the core is maintained.
The scope of NEI 20-07 is HSSSR DI&C systems and these systems need to meet this GDC. The HSSSR system requirements development needs to address the functional requirements stated in this GDC. SDOs synthesized from IEC 61508-3 for application software for complete and correct requirements (requirements quality) in NEI 20-07 augment the current set of NRC regulatory guidance for requirements development to meet this GDC. This and the application of IEC 61508 criteria on the platform hosting the application software support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
* 10 CFR Part 50, Appendix B Quality Assurance
      -  Criterion III, Design Control states, in part, Measures shall be established to assure that applicable regulatory requirements and the design basis, as defined in &sect; 50.2 and as specified in the license application, for those structures, systems, and components to which this appendix applies are correctly translated into specifications, drawings, procedures, and instructions. These measures shall include provisions to assure that appropriate quality standards are specified and included in design documents and that deviations from such standards are controlled. Measures shall also be established for the selection and review for suitability of application of materials, parts, equipment, and processes that are essential to the safety-related functions of the structures, systems and components.
SDOs synthesized from IEC 61508-3 for application software for complete and correct requirements (requirements quality) in NEI 20-07 augment the current set of NRC regulatory guidance for requirements development to meet this criterion. This and the application of IEC 61508 criteria on the platform hosting the application software support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
: b. Implementation and testing quality depend on design quality and process discipline The following regulatory requirements are related to design quality and process discipline, the elements that implementation and testing quality depend on:
* 10 CFR Part 50, Appendix A General Design Criteria (GDC)
      -  GDC 1, Quality Standards and Records: Similar to the disposition of this GDC for complete and correct requirements, the SDOs in Section 10.6 - 10.11 synthesized from IEC 61508-3 for application software address the design quality and process discipline for implementation and testing. These SDOs augment the current set of NRC regulatory guidance for design
&#xa9; NEI 2021. All rights reserved.                                                                  nei.org 40
 
NEI 20-07, Draft C                                  DRAFT                                            May 2021 quality and process discipline for implementation and testing to meet this criterion. This and the application of IEC 61508 criteria on the platform hosting the application software support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
* 10 CFR Appendix B, Quality Assurance Criteria
      -    Criterion I Organization: From a holistic perspective the quality requirements imposed on the HSSR system including this criterion from 10 CFR 50 Appendix B plus the requirements from NEI 20-07 support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
      -    Criterion II Quality Assurance Program: The quality requirements imposed on the HSSR system including this criterion from 10 CFR 50 Appendix B plus the requirements from NEI 20-07 support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
      -    Criterion III Design Control: Similar to the disposition of this criterion for complete and correct requirements, SDOs synthesized from IEC 61508-3 for application software for implementation and test quality (10.6 - 10.11) in NEI 20-07 augment the current set of NRC regulatory guidance for HSSSR system design quality and process discipline for implementation and testing to meet this criterion. This and the application of IEC 61508 criteria on the platform hosting the application software support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
: 2. Concurrent triggering conditions are required to activate a latent defect
: a. A common defect depends on the quality and commonality of the software Quality of the software is addressed in first principle 1. The following regulatory criteria relate to commonality of software for HSSSR systems:
* GDC 24, Separation of Protection and Control states, The protection system shall be separated from control systems to the extent that failure of any single control system component or channel, or failure or removal from service of any single protection system component or channel which is common to the control and protection systems leaves intact a system satisfying all reliability, redundancy, and independence requirements of the protection system. Interconnection of the protection and control systems shall be limited so as to assure that safety is not significantly impaired.
SDO 10.1.3.2, SDOs in 10.12.3, and Section 11 address the necessity to evaluate HSSSR system hazards at the system architecture level keeping in mind the current defense in depth strategy of the nuclear power plant that addresses this GDC. Any hazards identified that jeopardize the plants defense in depth design would require control methods to eliminate those hazards.                          Commented [A45]: This is a requirement without NEI 20-07.
* 10 CFR Appendix B, Quality Assurance                                                                    What does address mean in this context? It does not mean necessary and sufficient.
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 41
 
NEI 20-07, Draft C                                DRAFT                                          May 2021
      -  Criterion III Design Control: The quality requirements imposed on the HSSR system from 10 CFR 50 Appendix B plus the requirements from NEI 20-07 to address platform and application software reliability (and conversely addressing common defects) by applying the criteria of IEC 61508, support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
: b. A triggering condition depends on system conditions The following regulatory criteria relate to a trigger condition depends on system conditions:
GDC 22, Protective System Independence states in part, Design techniques, such as functional diversity or diversity in component design and principles of operation, shall be used to the extent practical to prevent loss of the protection function.
The scope of NEI 20-07 is HSSSR DI&C systems and these systems need to meet this GDC. The design basis for operating nuclear plants includes functional diversity for the protective functions. SDO 10.1.3.2, Commented [A46]: This requirement was based on the equipment used at the time, not regardless of equipment SDOs in 10.12.3, and Section 11 address the necessity to evaluate HSSSR system hazards at the system        used.
architecture level. As described in Section 11, the HSSSR system hazard analysis involves analyzing the HSSSR potential systematic failures. An important aspect of the HSSSR system hazard analysis is              The equipment used at the time was simple and independent.
Modern digital systems offer many more functions and identifying HSSSR systematic misbehaviors in the absence of any HSSSR faults and failures.                  interconnections which make these systems complicated.
Implementing the SDOs in Section 10.12.3 or control methods identified to address HSSSR systematic failures in the hazard analysis under SDO 10.1.3.2 can require diversity in component design and principles of operation as an attribute of the control method. As stated in SDO 10.1.3.2, any required control methods applied to the application software are to be included in the application software requirements.
: c. A concurrent triggering condition depends on timing and commonality of system conditions The same regulatory criteria in b. A triggering condition depends on system conditions apply to this CCF first principle.
: 3. The effects of a software CCF can be reduced by design
: a. The plant systems or components affected by a software CCF can be limited by design The following regulatory criteria relate to a software CCF can be reduced by design:
GDC 23, Protective System Failure Modes states, The protection system shall be designed to fail into a safe state or into a state demonstrated to be acceptable on some other defined basis if conditions such as disconnection of the system, loss of energy (e.g., electric power, instrument air), or postulated adverse environments (e.g., extreme heat or cold, fire, pressure, steam, water, and radiation) are experienced.
The scope of NEI 20-07 is HSSSR DI&C systems and these systems need to meet this GDC. SDO 10.1.3.2, SDOs in 10.12.3, and Section 11 augment NRC regulatory guidance to address this GDC, by identifying the necessity to evaluate HSSSR system hazards at the system architecture level. As stated in SDO            Commented [A47]: This is already a regulatory requirement.
10.1.3.2, any required control methods applied to the application software are to be included in the application software requirements.
&#xa9; NEI 2021. All rights reserved.                                                                  nei.org 42
 
NEI 20-07, Draft C                                  DRAFT                                          May 2021 Limiting the impact of a software CCF on plant systems or components must meet the regulatory requirements in:
GDC 24, Separation of Protection and Control: SDO 10.1.3.2, SDOs in 10.12.3, and Section 11 address the necessity to evaluate HSSSR system hazards at the system architecture level keeping in mind the current defense in depth strategy of the nuclear power plant that addresses this GDC. Any hazards identified that jeopardize the plants defense in depth design would require control methods to eliminate those hazards. As stated in SDO 10.1.3.2, any required control methods applied to the application software are to be included in the application software requirements.
: b. An I&C system can be designed to force a preferred state in the event of a software CCF                      Commented [A48]: Not always true. This statement should be refined to account for cases where this is not true.
See the disposition of GDC 23 in 3a.
: c. Detection of an event or condition due to a software CCF provides an opportunity for response and recovery                                                                                                Commented [A49]: Not clear what this means. Please clarify.
See the disposition of GDC 23 in 3a.
: 4. Operating history can provide evidence of software quality                                                    Commented [A50]: This statement is only vaguely true for different versions of software. Should be refined to be more specific.
The following regulatory criteria related to operating history can be used as evidence of software quality.
10 CFR 21 states, in part, that basic components are items designed and manufactured under a quality assurance program complying with appendix B to part 50 of this chapter, or commercial grade items which have successfully completed the dedication process. It also states, This assurance is achieved by identifying the critical characteristics of the item and verifying their acceptability by inspections, tests, or analyses performed by the purchaser or third-party dedicating entity after delivery, supplemented as necessary by one or more of the following: commercial grade surveys; product inspections or witness at holdpoints at the manufacturer's facility, and analysis of historical records for acceptable performance.
One of the methods for commercial dedication is analyzing historical records for acceptable performance. The platform used for a DI&C HSSSR system, if not developed under a 10 CFR 50 Appendix B quality assurance program, must go through a commercial grade dedication process. The requirement for platform SIL3 certification augments the NRC regulatory guidance to address 10 CFR 21 commercial grade dedication. This and the application of SDOs for the hosted application software support an overall safety case to adequately address CCF sourced from either the platform or its hosted application software in the HSSSR DI&C system architecture.
&#xa9; NEI 2021. All rights reserved.                                                                    nei.org 43
 
NEI 20-07, Draft C                                      DRAFT                                    May 2021 Appendix B: Assurance Case Development (Informative)
The assurance case structure provided in this appendix was adopted from IEEE 15016-2. The assurance      Commented [A51]: Believe this should be 15026-2 case starts with a top-level claim for the system and uses a structured argument and evidence to          Staff believes it made this comment in a previous comment support the claim. Through multiple levels of subordinate claims, the structured argument connects the    phase. Please ensure that all of our previous comments were top-level claim to the evidence.                                                                          read and addressed.
The assurance 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.
* Evidence which provides 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 B-1.
Top Claim Supports        Supports Sub-claim 1                      Sub-claim 2 Supports                          Supports Argument                          Argument Is evidence for                  Is evidence for Evidence                          Evidence Figure B Simplified Assurance Case Structure Enclosure 2
 
NEI 20-07, Draft C                                          DRAFT                                                  May 2021 B.1    Assurance Case Claim Structure to Ensure Software CCF is Adequately Addressed Software CCF is Adequately Addressed Assurance Case Documents Complete and Correct Implementation of SDOs Section 11.0 Platform Software Design                                    Application Software Design Implements                                      Implements SDOs Provided in Section SDOs provided in Section 9.0                                              10.0 Supports                                                    Supports Platform SDOs Met                                      Requirements Quality SDOs Met (Sections 9.1 and 9.2)                                            (Section 10.1)
Is evidence for                                              Is evidence for Documentation that software design Documentation that software design meets SDOs listed in Sections 9.1.3 meets SDOs listed in Section 10.1.3 and 9.2.3 Typical for all applicable SDOs Figure B-2 NEI 20-07 Enclosure 2
 
Page 8: [1] Commented [A4]                        Author NEI should explain why the synthesized information from IEC 61508-3 did not include that associated with diversity.
Rationale - Some excerpts from IEC 61508-3 (2010) related to the topic of diversity [emphasis added] which are not included in the proposed NEI 20-07 SDOs:
: 1. Section 7.4.2.13: g) There shall be evidence that all credible failure mechanisms of the software element have been identified and that appropriate mitigation measures have been implemented.
NOTE 3 Appropriate mitigation measures include:
* appropriate system architecture (e.g. partitioning, wrappers, diversity, credibility of checking of outputs);
* exception handling.
: 2. Section 7.4.3.2: The software architecture design shall be established by the software supplier and/or developer, and shall be detailed. The software architecture design shall:
a) select and justify (see 7.1.2.7) an integrated set of techniques and measures necessary during the software safety lifecycle phases to satisfy the software safety requirements specification at the required safety integrity level. These techniques and measures include software design strategies for both fault tolerance (consistent with the hardware) and fault avoidance, including (where appropriate) redundancy and diversity.
: 3. From Table A-2 (Table A.2 - Software design and development -software architecture design):
: a. Diverse redundancy, implementing the same software safety requirements specification
: b. Functionally diverse redundancy, implementing different software safety requirements specification
: 4. Table A-10 (Functional safety assessment): Common cause failure analysis of diverse software (if diverse software is actually used)
Page 35: [2] Commented [A30]                      Author Attaching the application of diversity to completion of the hazard analysis seems to be a good place to start.
: 1. Because Section 11 does not constitute a safe design objective, there is no true connectivity here to the referenced SDO10.1.3.2. If Diversity aspects were SDOs, then this reference would make more logical sense.
: 2. If a licensee chooses to incorporate diversity:
: a. What is the criteria that is used to do so?
: b. If diversity is used, how does that fit within the 20-07 processes?
: c. If used, is a diversity SDO(s) necessary to be created? If so, is there sufficient guidance in NEI 20-07 that allows for a licensee to understand how to synthesize them from 61508 or other sources?
Page 35: [3] Commented [A31]                    Author When control methods are developed, do they get converted into SDOs or are they considered independent of NEI 20-07?
With regard to configuration management -
: 1. What mechanism in NEI 20-07 tracks the creation of control methods?
: 2. Does NEI 20-07 cover the circumstance or provide guidance for a licensee that chooses to deviate from the stated Section 10 SDOs and, for example, creates additional custom SDOs? In this instance, custom SDOs may open up unintended vulnerabilities.}}

Revision as of 07:42, 8 September 2021

May 18, 2021, Summary of the Public Meeting to Discuss the Nuclear Energy Institute'S Pre-Submittal of NEI 20-07, Draft C
ML21162A073
Person / Time
Issue date: 06/11/2021
From: Tekia Govan
NRC/NRR/DRO
To: Jeanne Johnston
NRC/NRR/DEX
Morton W
References
Download: ML21162A073 (47)
v • d • e


Text

Retrieved from "https://kanterella.com/w/index.php?title=ML21162A073&oldid=3281423"